13 साल बाद मैं Go में HTTP services कैसे लिखता हूँ

GrafanaCON 2024: आज ही रजिस्टर करें और अपनी सीट बुक करें!

• GrafanaCON 2024 इस साल का सबसे बड़ा community event है, और registration आधिकारिक रूप से शुरू हो चुका है।
• यह event अप्रैल में Amsterdam में in-person भागीदारी के साथ एक जीवंत अनुभव प्रदान करेगा।

GN⁺ की राय

• GrafanaCON 2024 data visualization और monitoring में रुचि रखने वालों के लिए एक महत्वपूर्ण event है। यह event Grafana users और developer community को एक साथ लाकर नवीनतम trends और technologies साझा करने का मंच बनेगा।
• Amsterdam में होने वाला यह आयोजन प्रतिभागियों को networking और learning के अवसर देगा, और data analysis व visualization tools की गहरी समझ में मदद करने वाले sessions उपलब्ध होने की उम्मीद है।
• event registration की शुरुआत Grafana users के लिए उत्साहजनक खबर है, और इस क्षेत्र के professionals के लिए नया ज्ञान हासिल करने तथा industry peers के साथ संवाद करने का एक अच्छा अवसर होगा।

[GN⁺]

Hacker News की राय

• 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.

  • वैलिडेशन का तरीका: एक वैकल्पिक context लेता है और एक map लौटाता है, जिसमें समस्या वाले field का नाम key होता है और समस्या का human-readable विवरण value होता है। यह तरीका पहले उपयोगी रहा है।

• 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.

  • वैलिडेशन के बजाय parsing: Lexi Lambda का "Parse, Don't Validate" पढ़ने के बाद, Go के built-in type checker का उपयोग करना validator की तुलना में कम error-prone लगा।

• 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.

  • username validation का उदाहरण: ऐसी स्थिति की कल्पना की गई है जहाँ उपयोगकर्ता angle brackets वाला अमान्य username न चुन सके।

• 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 approach की समस्या: untrusted source से आए username value के लिए हर code path पर validator चलाना याद रखना पड़ता है।

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

  • वैलिडेशन का विकल्प: validator इस्तेमाल करने के बजाय दूसरा तरीका सुझाया गया है।

• 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.

  • object creation से validation की गारंटी: Username object बनाते समय ही validation हो जाती है, इसलिए किसी भी code path में validation छूट नहीं सकती।

• 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 के काम की सराहना: Mat Ryer का काम बहुत पसंद है, और 2018 वाले इस लेख के ज़्यादातर ideas तब से सभी Go projects में लागू किए गए हैं।

• The one weak spot for me is this aspect:

  • कमज़ोर पक्ष की ओर इशारा: एक ऐसे हिस्से का उल्लेख किया गया है जो कमज़ोर लगता है।

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

  • बेहतर समाधान का अभाव: यह हमेशा गलत लगा, लेकिन इससे बेहतर समाधान नहीं मिल पाया।

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

  • shared state की समस्या: इससे code के बड़े हिस्से में बहुत सारा अनावश्यक shared state आ जाता है।

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

  • HTTP handlers और shared state: अक्सर ऐसे HTTP handlers लिखने पड़ते हैं जिन्हें shared state का बहुत छोटा हिस्सा ही चाहिए होता है।

• 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 के pattern के प्रति सम्मान: उनका pattern अब तक मिला सबसे अच्छा है, फिर भी लगता है कि कहीं न कहीं इससे बेहतर समाधान मौजूद है।

• 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 object को लेकर आपत्ति: पूरे system की configuration दर्शाने वाले Config object को mutable रूप में इधर-उधर पास करना बहुत खटकता है।

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

  • Config object से coupling: ऐसा करने पर सब कुछ config object के ज़रिए आपस में tightly coupled हो जाता है।

• 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.

  • क्रम-निर्भर configuration की समस्या: ऐसे systems पर काम किया गया है जहाँ components को एक खास क्रम में configure करना पड़ता था, क्योंकि pass किए गए config object में वापस लिख दिया जाता था।

• 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.

  • system के हिस्से disable न कर पाने की समस्या: कुछ मामलों में system का एक हिस्सा बंद नहीं किया जा सकता था, क्योंकि वह config object में data लिखता था जिसे बाद में कोई दूसरा subsystem पढ़ता था।

• 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 बड़े configuration pattern की आलोचना: "configuration एक बड़ा mutable value है" वाला pattern, Go और दूसरी languages दोनों में, काफ़ी परेशान करने वाला लगा।

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

  • सहमति और अपनी राय: कई बातों से सहमति जताते हुए अपनी राय जोड़ी गई है।

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

  • waitgroup और app context पास करने का सुझाव: service structs को app context के साथ waitgroup देने का सुझाव है।

• 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 और waitgroup से app shutdown: इस तरह interrupt context के ज़रिए app shutdown trigger कर सकता है और main goroutine, app बंद करने से पहले waitgroup पर wait कर सकता है।

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

  • CLI testing की उपयोगिता: CLI program लिखते समय stdout, stdin, stderr, args, env आदि को test करना उपयोगी होता है।

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

  • HTTP server के लिए अलग दृष्टिकोण: HTTP server के मामले में यह बात उतनी लागू नहीं होती।

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

  • focused tests के लिए structured config: tests को ज़्यादा focused बनाने के लिए run function में structured config पास करने का सुझाव है।

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

  • handler में template parsing का विरोध: handler के अंदर sync.Once से template parsing करने से असहमति है, क्योंकि handlers को template parsing करनी ही नहीं चाहिए।

• 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.

  • app startup पर template parsing: app start होते समय template parse होना चाहिए; अगर parse न हो, तो app requests लेने के लिए ready न हो और non-zero exit code के साथ बंद हो जाए।

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

  • fx की सरलता और versatility: fx application design के लिए बहुत simple और versatile tool लगा।

• 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.

  • लेख की सलाह और fx का फायदा: लेख की सारी सलाह अब भी उपयोगी है, लेकिन fx "Y को X चाहिए तो X initialized है या नहीं" वाली समस्या को समीकरण से लगभग हटा देता है और N*M समस्या को N समस्या बना देता है।

• 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 के प्रति पसंद: वर्षों में कई languages की dependency injection libraries इस्तेमाल कीं, कुछ खुद भी बनाईं, लेकिन fx की simplicity और versatility इसे अब तक का पसंदीदा बनाती है।

• I've recently been playing with ogen:

  • ogen के साथ हालिया अनुभव: हाल में ogen के साथ प्रयोग किया गया है।

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

  • openapi definition और ogen की भूमिका: openapi definition लिखने पर ogen routing, structs की definition, JSON schemas की validation आदि संभाल लेता है।

• All I need to do is implement the service.

  • service implementation का सरल होना: बस service implement करनी होती है।

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

  • querystring integer range validation की दिक्कत: querystring parameter के लिए integer range validation बहुत उबाऊ है और manually लिखते समय typo होना आसान है।

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

  • ogen पर शुरुआती राय: अभी तक सिर्फ़ प्रयोग किया है, इसलिए इसकी कमियाँ अभी सामने नहीं आई हैं।

• 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.

  • लेख और signal.NotifyContext की सराहना: लेख को शानदार और ideas से भरपूर बताया गया है। signal.NotifyContext के बारे में पहले न जानने पर हैरानी जताई गई, और अब projects के बीच copy-paste किए बिना signals handle करना याद रह सकेगा।

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

  • approach पसंद, testing अलग: यहाँ किए गए कई काम पसंद आए, लेकिन अपनी testing approach थोड़ी अलग है।

• srv, err := newTestServer()

  • test server creation का उदाहरण: नया test server बनाने का code example दिया गया है।

• require.NoError(t, err)

  • error check का उदाहरण: error न होने की जाँच का code example दिया गया है।

• defer srv.Close()

  • server close का उदाहरण: test के बाद server बंद करने का code example दिया गया है।

• 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 request का उदाहरण: HTTP POST request भेजने का code example दिया गया है।

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

  • dependencies के लिए fake server setup: newTestServer में dependencies के fake implementations के साथ server चलाया जाता है।

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

  • dependency error test करने का तरीका: dependency error test करने के लिए उस property को ऐसे fake से बदल दिया जाता है जो error लौटाए।

• 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.

  • विभिन्न validations की क्षमता: error paths, log entries, metric emission, timeouts और graceful shutdowns सभी को validate किया जा सकता है।

• 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).

  • server start के बाद port जाँचना: server शुरू होने के बाद देखा जाता है कि वह किस port पर चल रहा है; default :0 होने से यह देखना पड़ता है कि वह किस port से bind हुआ।

• 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" tests का दायरा: "unit" tests handler level या HTTP level पर हो सकते हैं, जिससे code को उसी तरह पूरी तरह test किया जा सके जैसा system का उपयोगकर्ता देखेगा—चाहे सभी middleware के साथ या बिना उनके।

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

  • parallel testing: N instances चलाकर tests को parallel में चलाया जा सकता है।

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

  • Go न लिखने के बावजूद patterns पसंद: Go नहीं लिखते, लेकिन ये patterns पसंद हैं; ये testable code के लिए काफ़ी universal लगते हैं।