13 yıl sonra Go ile HTTP servislerini nasıl yazıyorum

GrafanaCON 2024: Hemen kaydolun ve yerinizi ayırtın!

• GrafanaCON 2024, bu yılın en büyük topluluk etkinliği ve kayıtlar resmen başladı.
• Etkinlik, Nisan ayında Amsterdam'da yüz yüze katılabileceğiniz canlı bir deneyim sunuyor.

GN⁺ Görüşü

• GrafanaCON 2024, veri görselleştirme ve izleme ile ilgilenenler için önemli bir etkinlik. Bu etkinlik, Grafana kullanıcıları ve geliştirici topluluğunun bir araya gelerek en son trendleri ve teknolojileri paylaşacağı bir ortam olacak.
• Amsterdam'da düzenlenecek bu etkinliğin, katılımcılara networking ve öğrenme fırsatları sunması; veri analizi ve görselleştirme araçları hakkında derinlemesine kavrayış sağlayacak oturumlar içermesi bekleniyor.
• Kayıtların açılması, Grafana kullanıcıları için heyecan verici bir haber; bu alanda çalışan profesyoneller içinse yeni bilgiler edinmek ve sektör meslektaşlarıyla bir araya gelmek adına iyi bir fırsat olacak.

[GN⁺]

Hacker News görüşleri

• The Valid method takes a context (which is optional but has been useful for me in the past) and returns a map. If there is a problem with a field, its name is used as the key, and a human-readable explanation of the issue is set as the value.

  • Doğrulama yöntemi: İsteğe bağlı bir context alır, sorunlu alanların adını anahtar ve sorunun insan tarafından okunabilir açıklamasını değer olarak içeren bir map döndürür. Bu yaklaşımın geçmişte faydalı olduğu belirtiliyor.

• I used to do this, but ever since reading Lexi Lambda's "Parse, Don't Validate," I've found validators to be much more error-prone than leveraging Go's built-in type checker.

  • Doğrulama yerine parse etme: Lexi Lambda'nın "Parse, Don't Validate" yazısını okuduktan sonra, Go'nun yerleşik type checker'ını kullanmanın doğrulayıcılara göre hataya daha az açık olduğu düşünülüyor.

• For example, imagine you wanted to defend against the user picking an illegal username. Like you want to make sure the user can't ever specify a username with angle brackets in it.

  • Kullanıcı adı doğrulama örneği: Kullanıcının angle bracket içeren geçersiz bir kullanıcı adı seçmesini engellemek istediğiniz bir durum hayal ediliyor.

• With the Validator approach, you have to remember to call the validator on 100% of code paths where the username value comes from an untrusted source.

  • Validator yaklaşımının sorunu: Güvenilmeyen bir kaynaktan gelen kullanıcı adı değeri için tüm kod yollarında validator çağrısını hatırlamak gerekiyor.

• Instead of using a validator, you can do this:

  • Doğrulamaya alternatif öneri: Validator kullanmak yerine başka bir yöntem öneriliyor.

• That guarantees that you can never forget to validate the username through any codepath. If you have a Username object, you know that it was validated because there was no other way to create the object.

  • Nesne oluşturarak doğrulamayı garanti etme: Username nesnesi oluşturulurken doğrulama yapıldığı için, hangi kod yolundan gelirse gelsin doğrulamayı atlamak mümkün olmuyor.

• I really like Mat Ryer's work, and I've applied most of the ideas in the 2018 version of this article to all of my Go projects since then.

  • Mat Ryer'ın çalışmalarını beğenme: Mat Ryer'ın çalışmaları çok beğeniliyor ve 2018 sürümündeki makaledeki fikirlerin çoğu o zamandan beri tüm Go projelerine uygulanıyor.

• The one weak spot for me is this aspect:

  • Zayıf noktaya işaret etme: Sorunlu görülen bölüme dikkat çekiliyor.

• This has always felt wrong to me, but I've never been able to figure out a better solution.

  • Daha iyi çözüm bulunamaması: Bunun hep yanlış hissettirdiği ama daha iyi bir çözüm bulunamadığı ifade ediliyor.

• It means that a huge chunk of your code has a huge amount of unnecessary shared state.

  • Paylaşılan state sorunu: Kodun büyük bir bölümünün gereksiz miktarda paylaşılan state taşıdığı belirtiliyor.

• I often end up writing HTTP handlers that only need access to a tiny amount of the shared state.

  • HTTP handler'lar ve paylaşılan state: HTTP handler'ların çoğu zaman paylaşılan state'in sadece çok küçük bir kısmına ihtiyaç duyduğu söyleniyor.

• Nothing against Mat Ryer, as his pattern is the best I've found, but I still feel like there's some better solution out there.

  • Mat Ryer'ın pattern'ine saygı: Mat Ryer'ın yaklaşımının şimdiye kadar görülen en iyi çözüm olduğu söylenirken, yine de daha iyi bir çözüm olabileceği hissi korunuyor.

• one of my biggest pet peeves is when people take a Config object, which represents the configuration of an entire system, and pass it around mutably.

  • Config nesnesinin kullanımına itiraz: Tüm sistemin yapılandırmasını temsil eden bir Config nesnesinin mutable şekilde dolaştırılması büyük bir rahatsızlık kaynağı olarak görülüyor.

• When you do that, you're coupling everything together through the config object.

  • Config üzerinden sıkı bağlanma sorunu: Böyle yapıldığında her şey Config nesnesi üzerinden birbirine bağlanmış oluyor.

• I've worked on systems where you had to configure the parts in a specific order in order for things to work, because someone decided to write back to the config object when it was passed to them.

  • Config'te sıra bağımlılığı sorunu: Birilerinin kendilerine verilen Config nesnesine geri yazması nedeniyle, sistemin ancak parçalar belirli bir sırada yapılandırılırsa çalıştığı örneklerle karşılaşıldığı anlatılıyor.

• Or another case was where I've seen it such that you couldn't disable a portion of the system because it wrote data into the config object that was read by some other subsystem later.

  • Sistemin bazı bölümlerini devre dışı bırakamama: Config nesnesine yazılan verinin daha sonra başka bir alt sistem tarafından okunması nedeniyle sistemin bir bölümünün devre dışı bırakılamadığı durumlar görülmüş.

• The pattern of "your configuration is one big value, which is mutable" is one of the more annoying patterns that I've seen before, both in Go and in other languages.

  • Mutable tek parça büyük config pattern'ine eleştiri: Hem Go'da hem de diğer dillerde görülen, "yapılandırmanın tek ve mutable büyük bir değer olması" yaklaşımı oldukça can sıkıcı bulunuyor.

• I agree with a lot of this, I'll add my own opinions:

  • Katılım ve ek görüşler: Birçok noktaya katılındığı ve kişisel görüşlerin ekleneceği belirtiliyor.

• I would pass a waitgroup with the app context to service structs.

  • Waitgroup ve app context aktarma önerisi: Service struct'larına app context ile birlikte waitgroup verilmesi öneriliyor.

• This way the interrupt can trigger the app shutdown via the context and the main goroutine can wait on the waitgroup before actually killing the app.

  • Interrupt ve waitgroup ile kapanış yönetimi: Bu sayede interrupt, context üzerinden uygulamanın kapanmasını tetikleyebilir; ana goroutine de uygulamayı gerçekten sonlandırmadan önce waitgroup üzerinde bekleyebilir.

• If writing a CLI program, then testing stdout, stdin, stderr, args, env, etc. is useful.

  • CLI program testlerinin faydası: Bir CLI programı yazarken stdout, stdin, stderr, args, env gibi öğeleri test etmenin faydalı olduğu belirtiliyor.

• But for an http server, this is less true.

  • HTTP sunucularında farklı yaklaşım: HTTP sunucuları için bunun daha az geçerli olduğu söyleniyor.

• I would pass structured config to the run function to let those tests be more focused.

  • Yapılandırılmış config ile odaklı testler: Testlerin daha odaklı olması için run fonksiyonuna yapılandırılmış config verilmesi öneriliyor.

• I disagree with parsing templates using sync.Once in a handler because I don't think handlers should do template parsing at all.

  • Handler içinde template parse etmeye itiraz: Handler'ların zaten template parse etmemesi gerektiği düşünüldüğü için, handler içinde sync.Once kullanılarak template parse edilmesine katılınmıyor.

• I would do this when the app starts: if the template cannot be parsed, the app should not become ready to receive any requests and should rather exit with a non-zero exit code.

  • Template parse işleminin başlangıçta yapılması önerisi: Uygulama başlarken template'ler parse edilmeli; parse başarısız olursa uygulama istek almaya hazır hale gelmemeli ve sıfır dışı bir exit code ile kapanmalı.

• I found fx to be a super simple yet versatile tool to design my application around.

  • fx aracının sadeliği ve çok yönlülüğü: fx, uygulama tasarımı için son derece basit ama çok yönlü bir araç olarak görülüyor.

• All the advice in the article is still helpful, but it takes the "how do I make sure X is initialized when Y needs it" part completely out of the equation and reduces it from an N*M problem to an N problem.

  • Makaledeki öneriler ve fx'in avantajı: Makaledeki tüm tavsiyeler hâlâ yararlı olsa da, fx, "Y ihtiyaç duyduğunda X'in başlatıldığından nasıl emin olurum" sorununu denklemden çıkarıp N*M problemini N problemine indiriyor.

• I've used quite a few dependency injection libraries in various languages over the years (and implemented a couple myself) and the simplicity and versatility of fx makes it my favorite so far.

  • fx tercihi: Yıllar boyunca çeşitli dillerde birçok dependency injection kütüphanesi kullanılmış, hatta bazıları bizzat yazılmış; yine de fx sadeliği ve çok yönlülüğü sayesinde şu ana kadarki favori olarak görülüyor.

• I've recently been playing with ogen:

  • ogen deneyimi: Son zamanlarda ogen ile denemeler yapıldığı belirtiliyor.

• Write openapi definition, it'll do routing, definition of structs, validation of JSON schemas, etc.

  • openapi tanımı ve ogen'in işlevleri: Bir openapi tanımı yazıldığında ogen; routing, struct tanımları, JSON schema doğrulaması gibi işleri yapıyor.

• All I need to do is implement the service.

  • Service implementasyonunun sadeleşmesi: Geriye sadece service'i implement etmek kaldığı söyleniyor.

• Validating an integer range for a querystring parameter is just too boring. And too easy to mistype when writing it manually.

  • Query string parametresinde integer aralığı doğrulamanın sıkıcılığı: Query string parametresi için integer aralığı doğrulamanın fazla sıkıcı olduğu ve elle yazarken kolayca yazım hatası yapılabildiği belirtiliyor.

• Anyways, so far only been playing, so haven't found the bad parts yet.

  • ogen hakkında ilk değerlendirme: Şimdilik sadece denemeler yapıldığı ve henüz kötü yanlarının bulunmadığı ifade ediliyor.

• Great article with lots of interesting ideas. Can't believe I didn't know about signal.NotifyContext. Finally I'll be able to actually rememeber how to respond to signals instead of copy-pasting that between projects.

  • Makale ve signal.NotifyContext hakkında olumlu yorum: Çok sayıda ilginç fikir içeren harika bir makale olduğu söyleniyor; signal.NotifyContext'in bilinmiyor olmasına şaşırılıyor ve artık projeler arasında kopyala-yapıştır yapmadan sinyallere nasıl yanıt verileceğinin hatırlanabileceği belirtiliyor.

• I like a lot of what they've done here. My testing looks a bit different however.

  • Yaklaşımı beğenme ama test yönteminde farklılık: Burada yapılanların çoğu beğeniliyor, ancak kendi test yaklaşımının biraz farklı olduğu söyleniyor.

• srv, err := newTestServer()

  • Test sunucusu oluşturma kodu örneği: Yeni bir test sunucusu oluşturma kodu örnek olarak veriliyor.

• require.NoError(t, err)

  • Hata kontrolü kodu örneği: Hata olmadığını doğrulayan kod örneği veriliyor.

• defer srv.Close()

  • Sunucuyu kapatma kodu örneği: Test sonunda sunucuyu kapatan kod örneği veriliyor.

• resp, err := http.Post(fmt.Sprintf("http://localhost:%d/signup/json";, srv.Port()), "application/json", strings.NewReader({ "email": "[e-mail]", "password": "p@55Word", "password_copy": "p@55Word" }))

  • HTTP POST isteği kodu örneği: Bir HTTP POST isteği gönderme kodu örnek olarak veriliyor.

• In my newTestServer, I spin up a server with fakes for my dependencies.

  • Bağımlılıklar için fake'lerle sunucu başlatma: newTestServer içinde bağımlılıklar için fake'ler kullanılarak bir sunucu ayağa kaldırılıyor.

• If I want to test a dependency error, I replace that property with a fake that will return an error.

  • Bağımlılık hatasını test etme yöntemi: Bir bağımlılık hatasını test etmek istendiğinde, ilgili özellik hata döndürecek bir fake ile değiştiriliyor.

• I can validate my error paths. I can validate my log entries. I can validate my metric emission. I can validate timeouts and graceful shutdowns.

  • Çeşitli doğrulama imkanları: Hata yolları, log kayıtları, metric üretimi, timeout'lar ve graceful shutdown davranışları doğrulanabiliyor.

• After the server starts, I inspect to determine which port it is running on (default is :0 so I have to wait to see what it got bound to).

  • Sunucu başladıktan sonra portu belirleme: Sunucu başladıktan sonra hangi portta çalıştığı kontrol ediliyor; varsayılan :0 olduğu için hangi porta bind edildiğini görmek üzere beklemek gerekiyor.

• My "unit" tests can test at the handler level or the http level, making sure that I can fully test the code as the users of my system will see it, exercising all middleware or none.

  • "Unit" testlerin kapsamı: "Unit" testler handler seviyesinde ya da HTTP seviyesinde yapılabiliyor; böylece kod, sistemin kullanıcılarının göreceği haliyle tam olarak test edilebiliyor ve tüm middleware katmanları ya da hiçbiri devreye alınabiliyor.

• I can spin up N instances and run my tests in parallel.

  • Paralel test çalıştırma: N adet instance ayağa kaldırılıp testler paralel çalıştırılabiliyor.

• I don't write go, but I like these patterns. Feels fairly universal for testable code.

  • Go yazmıyor olsa da pattern'leri beğenme: Go yazılmasa bile bu pattern'ler beğeniliyor ve test edilebilir kod için oldukça evrensel görünüyor.