Dışa aktarılan Go backend'leri değişiklikleri kaybetmeden nasıl genişletilir: özel kod nerede olmalı, middleware ve uç noktalar nasıl eklenir ve yükseltmeler nasıl planlanır.
Dışa aktarılan kod el yazması bir Go deposu ile aynı değildir. AppMaster gibi platformlarda backend, görsel modelden (veri şeması, iş süreçleri, API ayarları) üretilir. Yeniden dışa aktardığınızda üretici, modeli güncellemek için kodun büyük parçalarını yeniden yazabilir. Bu temiz tutmak için iyi, ama özelleştirme yaklaşımınızı değiştirir.
En yaygın hata, üretilen dosyaları doğrudan düzenlemektir. Bir kere işe yarar, sonra bir sonraki dışa aktarmada değişiklikleriniz silinir veya çirkin merge çatışmaları çıkar. Daha kötüsü, küçük elle yapılan değişiklikler üreticinin yaptığı varsayımları (rota sıralaması, middleware zincirleri, istek doğrulaması) sessizce bozabilir. Uygulama hala derlenir ama davranış değişir.
Güvenli özelleştirme, değişikliklerinizin tekrarlanabilir ve kolay incelenebilir olduğu anlamına gelir. Eğer backend'i yeniden dışa aktarabiliyor, özel katmanınızı uygulayıp neyin değiştiğini net görebiliyorsanız doğru yoldasınız. Her yükseltme bir arkeoloji çalışması gibi geliyorsa, değilsiniz.
Yanlış yerde özelleştirmenin tipik sonuçları:
Basit bir kural nerede değişiklik yapılacağını belirlemeye yardımcı olur. Değişiklik, geliştirici olmayanların ayarlayabilmesi gereken iş davranışının parçasıysa (alanlar, doğrulama, iş akışları, izinler), bunu no-code modelde yapın. Altyapı davranışıysa (özel auth entegrasyonu, istek loglama, özel header'lar, rate limitler), yeniden dışa aktarmalara dayanacak özel bir Go katmanına koyun.
Örnek: her istek için audit log genellikle middleware olur (özel kod). Bir siparişte yeni zorunlu bir alan genellikle veri modeli tarafındadır (no-code). Bu ayrımı net tutun, yükseltmeler tahmin edilebilir kalsın.
Bir dışa aktarılan backend'i genişletmeden önce, yeniden dışa aktarmada nelerin yeniden üretileceğini ve gerçekten nelerin size ait olduğunu 20 dakika içinde haritalandırın. Bu harita yükseltmeleri sıkıcı kılacak.
Üretilen kod sıklıkla kendini belli eder: "Code generated" veya "DO NOT EDIT" başlık yorumları, tutarlı isimlendirme kalıpları ve insan yorumlarının az olduğu çok düzenli bir yapı.
Depoyu pratik olarak sınıflandırmanın yolu her şeyi üç kova halinde ayırmaktır:
İlk kovayı teknik olarak düzenleyebilseniz bile salt okunur olarak ele alın. Değiştirirseniz, üreticinin daha sonra üstünü yazacağını veya sonsuza dek birleştirme yükü taşıyacağınızı varsayın.
Takım için sınırı gerçek kılın: repoda kısa bir not yazın (örneğin kök README). Basit tutun:
"Generator-owned dosyalar: DO NOT EDIT başlığı olan her şey ve X/Y klasörleri. Kodumuz internal/custom altında yaşıyor (veya benzeri). Sadece A/B bağlantı noktalarına dokunun ve oradaki değişiklikleri küçük tutun. Her bağlantı değişikliği, neden kendi paketimizde olamayacağını açıklayan bir yorum içermeli."
Bu tek not, hızlı düzeltmelerin kalıcı yükseltme acısına dönüşmesini engeller.
En güvenli kural basit: dışa aktarılan kodu salt okunur gibi ele alın ve değişikliklerinizi açıkça sahip olunan bir özel alana koyun. Yeniden dışa aktarma yaptığınızda (örneğin AppMaster'dan), merge işleminin çoğunlukla "üretilen kodu değiştir, özel kodu koru" olması istenir.
Eklentileriniz için ayrı bir paket oluşturun. Repo içinde kalabilir ama üretilen paketlerle karışmamalı. Üretilen kod çekirdek uygulamayı çalıştırır; paketiniz middleware, rotalar ve yardımcılar ekler.
Pratik bir düzen:
internal/custom/ middleware, handler ve küçük yardımcılar içininternal/custom/routes.go tüm özel rotaları tek yerde kaydetmek içininternal/custom/middleware/ istek/yanıt mantığı içininternal/custom/README.md gelecekteki düzenlemeler için birkaç kuralSunucu wiring'ini beş farklı yerde düzenlemekten kaçının. İnce bir "hook noktası" hedefleyin: middleware'i eklediğiniz ve ekstra rotaları kaydettiğiniz tek yer olsun. Üretilen sunucu bir router veya handler zinciri sağlıyorsa, oraya bağlayın. Sağlamıyorsa, entrypoint yakınında custom.Register(router) gibi tek bir entegrasyon dosyası ekleyin.
Özel kodu sanki yarın yeni bir dışa aktarıma koyacakmışsınız gibi yazın. Bağımlılıkları minimal tutun, üretken tipleri kopyalamaktan kaçının ve küçük adaptörler kullanın.
Amaç, mantığı kendi paketinize koymak ve üretilen koda yalnızca bir yerde dokunmaktır.
İlk olarak, middleware'i dar tutun: istek loglama, basit bir auth kontrolü, bir rate limit veya istek ID'si. Üç iş yapmaya çalışırsa ileride daha fazla dosya değişmeniz gerekir.
Küçük bir paket oluşturun (örneğin internal/custom/middleware) ve tüm uygulamayı bilmesine gerek olmasın. Public yüzeyi küçük tutun: standart bir Go handler sarmalayıcısı döndüren bir constructor fonksiyonu yeterli olsun.
package middleware
import "net/http"
func RequestID(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// Add header, log, or attach to context here.
next.ServeHTTP(w, r)
})
}
Şimdi bir entegrasyon noktası seçin: router veya HTTP sunucusunun oluşturulduğu yer. Middleware'inizi orada bir kez kaydedin ve değişiklikleri bireysel rotalara yaymaktan kaçının.
Doğrulama döngüsünü sık tutun:
httptest kullanarak tek bir sonucu (durum kodu veya header) kontrol eden bir test ekleyin.Küçük diff, tek wiring noktası, kolay yeniden dışa aktarma.
Üretilen kodu salt okunur sayın ve uç noktanızı uygulamayı içe aktaran küçük bir özel pakete ekleyin. Bu, yükseltmeleri makul kılan yaklaşımdır.
Önce kontratı yazın: uç nokta ne alıyor (query param, JSON body, header)? Ne döndürüyor (JSON şekli)? Durum kodlarını baştan seçin ki sonra "ne işe yaradıysa onu döndür" gibi bir durum olmasın.
Handler'ı özel paketinizde yazın. Sıkıcı tutun: girdiyi oku, doğrula, mevcut servisleri veya DB yardımcılarını çağır, yanıtı yaz.
Rotayı middleware için kullandığınız aynı entegrasyon noktasında kaydedin. Eğer üretilen proje kullanıcı hook'ları veya özel kayıt desteği sunuyorsa onu kullanın.
Kısa bir kontrol listesi davranışı tutarlı kılar:
Ayrıca router'ın uç noktanızı tam olarak bir kez kaydettiğini doğrulayın. Çift kayıtlar merge sonrası sık rastlanan bir tuzaktır.
Üretilen backend'i bir bağımlılık gibi ele alın. Kompozisyonu tercih edin: çekirdek mantığı düzenlemek yerine üretilen uygulamanın etrafında özellikler wire edin.
Kod yazmadan önce, davranışın konfigürasyon, hook veya standart kompozisyon yoluyla eklenip eklenemeyeceğini kontrol edin. Middleware iyi bir örnektir: kenarda (router/HTTP stack) ekleyin ki iş mantığına dokunmadan kaldırılabilsin veya yeniden sıralanabilsin.
Yeni bir özellik gerekiyorsa (rate limiting, audit logging, request IDs), kendi paketinizde tutun ve tek bir entegrasyon dosyasından kaydedin. Kod incelemede açıklaması kolay olsun: "bir paket, bir kayıt noktası".
Üretilen modeller ve DTO'lar dışa aktarmalar arasında değişir. Yükseltme ağrısını azaltmak için sınırda çeviri yapın:
Gerçekten üretilen koda dokunmanız gerektiğinde, bunu tek bir wiring dosyasıyla izole edin. Birçok üretilen handler'ı birer birer düzenlemekten kaçının.
// internal/integrations/http.go
func RegisterCustom(r *mux.Router) {
r.Use(RequestIDMiddleware)
r.Use(AuditLogMiddleware)
}
Pratik bir kural: değişikliği 2-3 cümle ile tarif edemiyorsanız muhtemelen çok sarmalayıcıdır.
Amaç, bir yeniden dışa aktarmanın sizi çatışmalarla dolu bir haftaya sokmaması. Düzenlemeleri küçük, kolay bulunur ve açıklanabilir tutun.
Baştan Git kullanın ve üretilen güncellemeleri özel işinizden ayrı tutun. Karıştırırsanız sonra hangi değişikliğin hangi hatayı getirdiğini anlayamazsınız.
Okunabilir bir commit rutini:
Basit bir CHANGELOG_CUSTOM.md tutarak her özelleştirmenin ne olduğu, neden yapıldığı ve nerede bulunduğunu listeleyin. Bu AppMaster dışa aktarımlarıyla özellikle faydalıdır çünkü platform kodu tamamen yeniden üretebilir ve hangi şeylerin tekrar uygulanması veya doğrulanması gerektiğini hızlıca görmek istersiniz.
Diff gürültüsünü azaltmak için tutarlı formatlama ve lint kuralları kullanın. Her commit'te gofmt çalıştırın ve CI'de aynı kontrolleri koşun. Üretilen kod belirli bir stil kullanıyorsa, elle o stili temizlemeye çalışmayın; aksi halde her dışa aktarmada aynı temizlemeyi tekrar etmek zorunda kalırsınız.
Eğer takım her dışa aktarmadan sonra aynı elle düzenlemeleri tekrar yapıyorsa, bir patch akışı düşünün: dışa aktar, yamaları uygula (veya bir script), testleri çalıştır, dağıt.
Backend'i yeniden oluşturulabilecek bir şey gibi ele aldığınızda yükseltmeler en kolay hale gelir. Hedef istikrarlı: temiz kodu yeniden dışa aktarın, sonra her defasında aynı entegrasyon noktalarından özel davranışı yeniden uygulayın.
Risk toleransınıza ve uygulamanın ne sıklıkta değiştiğine göre bir yükseltme ritmi belirleyin:
Yükseltme zamanı geldiğinde, ayrı bir branch'te kuru çalıştırma yapın. Önce yeniden dışa aktarılan sürümü tek başına build edip çalıştırın ki özel katman eklenmeden önce nelerin değiştiğini bilin.
Sonra özelleştirmeleri planlanmış seam'lerden yeniden uygulayın (middleware kayıt, özel router grubu, özel paketiniz). Üretilen dosyaların içinde cerrahi düzenlemeler yapmaktan kaçının. Bir değişiklik seam ile ifade edilemiyorsa, bir kez yeni bir seam ekleyin, sonra hep oradan ilerleyin.
Kısa bir regresyon kontrol listesi ile doğrulayın:
Audit logging middleware eklediyseniz, her yeniden dışa aktarma ve merge sonrası bir yazma işlemi için logların kullanıcı ID'si ve rota adını içermeye devam ettiğini doğrulayın.
Bir sonraki yeniden dışa aktarmayı mahvetmenin en hızlı yolu üretilen dosyaları "sadece bu sefer" düzenlemektir. Küçük bir hatayı düzeltirken masum görünür ama aylar sonra neyin değiştiğini, neden değiştiğini veya üreticinin şimdi aynı çıktıyı üretip üretmediğini hatırlamayabilirsiniz.
Bir diğer tuzak ise özel kodu her yere yaymaktır: bir pakette bir yardımcı, başka yerde özel auth kontrolü, routing yakınında middleware tweak'i ve rastgele bir klasörde tek seferlik bir handler. Kimsenin sahiplenmediği bu yapı her merge'i bir keşif avına çevirir. Değişiklikleri birkaç belirgin yerde tutun.
Özelleştirilmiş kodunuz üretilen iç struct'lara, özel alanlara veya paket düzenine bağlıysa yükseltmeler acı verir. Üretilen koddaki küçük bir refactor bile build'inizi bozabilir.
Daha güvenli sınırlar:
Middleware ve routing hataları zaman kaybettirir çünkü hatalar rastgele 401'ler veya "endpoint bulunamadı" gibi görünür. Birkaç odaklı test saatler kazandırır.
Gerçekçi bir örnek: audit middleware ekleyip istek gövdesini loglamak için okursanız, bazı endpoint'ler artık boş body almaya başlayabilir. Router üzerinden bir POST gönderip hem audit yan etkisini hem de handler davranışını kontrol eden küçük bir test bu regresyonu yakalar.
Özel değişiklikleri dağıtmadan önce kısa bir kontrol yapın ki bir sonraki yeniden dışa aktarmada neyi tekrar uygulamanız gerektiğini bilin.
internal/custom/).Sadece bir şey yapacaksanız, yükseltme notunu yazın. Bu "sanırım çalışıyor"u "bunu kanıtlayabiliriz"e dönüştürür.
Diyelim ki Go backend'i dışa aktardınız (örneğin AppMaster'dan) ve iki ek istiyorsunuz: istek ID'si + admin işlemleri için audit logging ve izleme için basit bir /health uç noktası. Amaç değişiklikleri yeniden dışa aktarmadan sonra kolayca yeniden uygulamaktır.
Audit logging için kodu internal/custom/middleware/ gibi sahip olduğunuz bir yerde koyun. Middleware şu işleri yapsın: (1) X-Request-Id header'ını oku veya oluştur, (2) bunu request context'e kaydet, (3) admin rotaları için kısa bir audit satırı logla (method, path, kullanıcı ID'si varsa ve sonuç). Her istek için bir satır tutun, büyük payload'ları loglamaktan kaçının.
Bunu rotaların kaydedildiği yere yakın kenarda wire edin. Üretilen router tek bir setup dosyası sağlıyorsa, oraya küçük bir hook ekleyin ve middleware'i sadece admin grubuna uygulayın.
/health için internal/custom/handlers/health.go içinde küçük bir handler ekleyin. 200 OK dönsün ve kısa bir gövdeye ok yazsın. Monitörleriniz auth gerektiriyorsa auth ekleyin ve bunu dokümante edin.
Değişiklikleri tekrar uygulamayı kolay kılmak için commit'leri şöyle yapın:
internal/custom/middleware/audit.go ve testleri ekleinternal/custom/handlers/health.go ekleyin ve /health'i kaydedinBir yükseltme veya yeniden dışa aktarmadan sonra temel doğrulamaları yapın: admin rotaları hala auth istiyor, request ID'ler admin loglarında görünüyor, /health hızlı yanıt veriyor ve middleware hafif yük altında belirgin gecikme eklemiyor.
Her dışa aktarmayı tekrarlanabilir bir build gibi düşünün. Özel kodunuz eklenti katmanı gibi hissettirmeli, yeniden yazım gibi değil.
Bir sonraki sefer neyin kodda, neyin no-code modelde olması gerektiğine karar verin. İş kuralları, veri şekilleri ve standart CRUD mantığı genellikle modelde olmalı. Tek seferlik entegrasyonlar ve şirkete özgü middleware genellikle özel kodda olmalı.
AppMaster (appmaster.io) kullanıyorsanız, özel çalışmanızı üretilen Go backend etrafında temiz bir uzantı katmanı olarak tasarlayın: middleware, rotalar ve yardımcıları az sayıda klasörde tutun ki yeniden dışa aktarmalar arasında kolayca taşınsın, üreticiye ait dosyalara dokunmayın.
Pratik bir son kontrol: bir ekip arkadaşı dışa aktarabilmeli, adımlarınızı uygulayıp aynı sonucu bir saatten kısa sürede alabilmeli — eğer bu mümkünse iş akışınız sürdürülebilirdir.
Dışa aktarılan Go dosyalarını doğrudan düzenleyebilir miyim?Üreticiye ait (generator-owned) dosyaları düzenlemeyin. Değişikliklerinizi açıkça sahip olunan bir paket içine koyun (örneğin internal/custom/) ve bunları sunucu başlatma yakınında tek bir küçük entegrasyon noktasından bağlayın. Böylece yeniden dışa aktarma çoğunlukla üretilen kodu değiştirirken sizin katmanınızı korur.
Dışa aktarılan depo içinde hangi parçaların yeniden üretileceğini nasıl anlarım?“Code generated” veya “DO NOT EDIT” gibi yorumlarla işaretlenmiş her şeyi yeniden yazılacakmış gibi kabul edin. Çok düzensiz insan notları olmayan, tekrar eden isimlendirme ve tek tip klasör yapısına sahip alanlar da genellikle üretici izlerini gösterir. En güvenli yaklaşım, bunları kurcalanmaz (read-only) saymaktır, derleme olsa bile.
İyi bir “tek entegrasyon noktası” nasıl görünür?Bir adet "hook" dosyası tutun: bu dosya özel paketlerinizi import eder ve her şeyi kaydeder — middleware, ek rotalar ve küçük bağlantılar. Beş farklı routing dosyasına dokunuyorsanız veya birden fazla üretilen handler'ı değiştiriyorsanız, yükseltmelerde zorlanma ihtimaliniz artar.
Yükseltmeleri bozmadan özel middleware nasıl eklerim?Middleware'i kendi paketinizde yazın ve dar tutun: istek ID'si, audit logging, rate limiting veya özel header'lar gibi tek bir sorumluluk. Ardından bunu router veya HTTP stack oluşturulurken bir kez kaydedin; üretilen handler'ların içine route bazında yaymayın. Basit bir httptest ile beklenen bir header veya durum kodunu kontrol etmek, yeniden dışa aktarmalarda regresyon yakalamaya genellikle yeterlidir.
Dışa aktarılan backend'i forkladan kaçınarak yeni bir uç nokta nasıl eklerim?Önce uç noktanın sözleşmesini (contract) belirleyin: hangi sorgu parametreleri, JSON body veya header bekleniyor; hangi JSON şekli dönülecek; hangi status kodları kullanılacak. Handler'ı internal/custom gibi özel paketinizde oluşturun ve rotayı middleware için kullandığınız aynı entegrasyon noktasından kaydedin. Handler'ı basit tutun: girdi doğrula, var olan servisleri çağır, tutarlı bir hata formatı dönün ve üretken handler mantığını kopyalamaktan kaçının.
Neden bir yeniden dışa aktarmadan sonra rotalar ve middleware sırası değişiyor?Generator, route kayıt sırasını, gruplayı veya middleware zincirlerini değiştirebilir; bu yüzden rotalar kaydederken sabit bir seam (kayıt noktası) kullanın ve middleware sırasını kayıt satırının yanında dokümante edin. Örneğin kimlik doğrulama önce olmalıysa (auth before audit) bunu bilinçli olarak sıraya koyun ve küçük bir testle doğrulayın.
No-code model ile özel Go kodu arasında mantığı nasıl kopyalamaktan kaçınırım?Aynı kuralı hem no-code modelde hem de özel Go kodunda uygularsanız zamanla farklılaşırlar. Non-geliştiricilerin ayarlaması gereken iş kurallarını (alanlar, doğrulama, iş akışları, izinler) no-code modelde; altyapı kaygılarını (loglama, özel auth entegrasyonu, rate limit, header'lar) ise özel Go katmanında tutun. Bu ayrım repoyu okuyan herkes için açık olmalı.
Özel kodumun üretilen internal tiplere bağlı olmasını nasıl engellerim?Üretilen DTO'lar ve iç yapılar dışa aktarma başına değişebilir; bu yüzden bu değişimi kenarda tutun. Girdileri kendi iç struct'larınıza dönüştürün, domain mantığını sadece kendi struct'larınızla yürütün, sonra çıktıları kenarda üretilen response tiplerine çevirin. Dışa aktarmadan sonra tipler değişse bile, bir adapteri güncellemek genellikle yeterlidir.
Üre-aktarımlar ve özelleştirmeler için en iyi Git iş akışı nedir?Üretilen güncellemeleri özel çalışmanızdan ayrı tutun ki neyin değiştiğini açıkça görebilesiniz. Pratik bir akış: önce yeniden dışa aktarma sonucu oluşan üretilen değişiklikleri commit edin, sonra minimal entegrasyon ve özel katman ayarlamalarınızı commit edin. Küçük bir CHANGELOG_CUSTOM.md tutmak hangi özelleştirmenin nerede olduğunu ve neden yapıldığını gösterir ve sonraki yükseltmeleri hızlandırır.
Yükseltmeleri nasıl planlamalıyım ki yeniden dışa aktarmalar günler sürmesin?Ayrı bir dalda kuru çalıştırma (dry-run) dışa aktarma yapın, yeni dışa aktarılan versiyonu tek başına build edip çalıştırın ki değişiklikleri custom katman eklenmeden önce görün. Sonra özelleştirmeleri planlanmış seam'lerden tekrar uygulayın, testleri çalıştırın ve kısa bir regresyon seti doğrulaması yapın. Eğer bir değişiklik mevcut seam ile ifade edilemiyorsa, bir kereye mahsus yeni bir seam ekleyin ve sonrasında aynı yöntemle ilerleyin.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
