13年後にGoでHTTPサービスを書く方法

GrafanaCON 2024: 今すぐ登録して席を確保しましょう！

• GrafanaCON 2024は今年最大のコミュニティイベントであり、登録が正式に開始されました。
• このイベントは、4月にアムステルダムで直接参加できる臨場感ある体験を提供します。

GN⁺の意見

• GrafanaCON 2024は、データ可視化とモニタリングに関心のある人々にとって重要なイベントです。このイベントは、Grafanaのユーザーおよび開発者コミュニティが集まり、最新トレンドと技術を共有する場となるでしょう。
• アムステルダムで開催される今回のイベントは、参加者にネットワーキングと学習の機会を提供し、データ分析および可視化ツールへの深い理解を助けるセッションが用意されることが期待されます。
• イベントの登録開始はGrafanaユーザーにとって興味深いニュースであり、この分野に携わる専門家にとっては、新しい知識を習得し、業界の同僚と交流できる良い機会となるでしょう。

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

  • バリデーション方法: 任意のコンテキストを受け取り、問題のあるフィールドをキー、問題の説明を値とするマップを返す。過去に役立ったことがある方式だと述べている。

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

  • バリデーションの代わりにパース: Lexi Lambda の "Parse, Don't Validate" を読んで以来、Go の組み込み型チェッカーを活用するほうが、バリデーションよりもエラーを起こしにくいと感じている。

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

  • ユーザー名のバリデーション例: ユーザーが山括弧を含む不正なユーザー名を選べないように防ぎたい状況を想定している。

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

  • バリデーター方式の問題点: 信頼できないソースから来たユーザー名の値について、すべてのコードパスでバリデーターを呼ぶ必要がある。

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

  • バリデーションの代替案: バリデーターを使う代わりに、別の方法を提案している。

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

  • オブジェクト生成によるバリデーション保証: Username オブジェクトを生成する過程でバリデーションが行われるため、どのコードパスでも検証漏れが起きない。Username オブジェクトがあるなら、それは検証済みだと分かる。

• 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年版の記事にあるアイデアの大半を、それ以降の自分の Go プロジェクトすべてに適用している。

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

  • 共有状態の問題: コードの大きな部分が、不必要に大量の共有状態を持つことになると指摘している。

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

  • HTTP ハンドラーと共有状態: HTTP ハンドラーはごくわずかな共有状態にしかアクセスしない場合が多いと述べている。

• 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 のパターンへの敬意: Mat Ryer のパターンは今まで見つけた中で最良だが、それでもまだもっとよい解決策がある気がすると述べている。

• 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 オブジェクトの扱いへの不満: システム全体の設定を表す Config オブジェクトを、可変のまま受け渡しすることが大きな不満の一つだとしている。

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

  • Config オブジェクトによる結合の問題: そうすると、Config オブジェクトを通じてすべてが密結合になってしまうと指摘している。

• 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 オブジェクトの順序依存問題: 渡された Config オブジェクトに書き戻す実装のせいで、システムを動かすために部品を特定の順序で設定しなければならなかった経験を語っている。

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

  • Config オブジェクトと一部機能の無効化問題: Config オブジェクトに書き込まれたデータを後で別のサブシステムが読むため、システムの一部を無効化できないケースを見たことがあると述べている。

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

  • 可変な巨大設定パターンへの批判: 「設定が1つの巨大な可変値である」というパターンは、Go でも他言語でも見てきた中でかなり厄介なものの一つだと述べている。

• 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 と一緒に 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.

  • 割り込みと waitgroup によるアプリ終了: 割り込みがコンテキスト経由でアプリ終了をトリガーし、メイン goroutine は実際にアプリを停止する前に waitgroup を待てるようになると説明している。

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

  • CLI プログラムのテストの有用性: CLI プログラムでは stdout、stdin、stderr、args、env などをテストするのが有用だと述べている。

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

  • HTTP サーバーでは事情が異なる: ただし HTTP サーバーでは、その有用性はやや低いと指摘している。

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

  • 構造化設定の受け渡しでテストを集中化: より焦点の定まったテストにするため、run 関数には構造化された 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 内で sync.Once を使ってテンプレートを解析することには反対で、そもそも handler はテンプレート解析を行うべきではないと考えている。

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

  • アプリ起動時のテンプレート解析提案: アプリ起動時にテンプレートを解析し、解析できない場合はリクエストを受け付けられる状態にせず、非ゼロの終了コードで終了すべきだと提案している。

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

  • fx の簡潔さと汎用性: fx は非常にシンプルでありながら汎用性の高いツールで、アプリケーション設計の中心に据えるのに向いていると感じている。

• 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 が初期化済みだとどう保証するか」という問題を完全に取り除き、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 への高評価: 長年にわたりさまざまな言語で多くの依存性注入ライブラリを使い、自分でいくつか実装もしてきたが、fx のシンプルさと汎用性によって今のところ一番のお気に入りだとしている。

• 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 定義と ogen の機能: openapi 定義を書けば、ogen がルーティング、構造体定義、JSON スキーマのバリデーションなどを担ってくれるとしている。

• All I need to do is implement the service.

  • サービス実装の単純化: あとはサービスを実装するだけでよいと述べている。

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

  • クエリ文字列パラメーターの整数範囲検証の欠点: クエリ文字列パラメーターの整数範囲を検証するのは退屈で、手書きするとタイプミスもしやすいと指摘している。

• 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 への好評価: 興味深いアイデアがたくさん詰まった素晴らしい記事だと評価し、signal.NotifyContext を知らなかったことに驚いている。今後はプロジェクト間でコピペせずに、シグナルへの対処法をちゃんと覚えられそうだと述べている。

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

  • 記事の手法への好感とテスト手法の違い: ここで行われていることの多くは気に入っているが、自分のテスト方法は少し異なると述べている。

• srv, err := newTestServer()

  • テストサーバー生成コード例: 新しいテストサーバーを生成するコード例を示している。

• require.NoError(t, err)

  • エラーチェックコード例: エラーがないことを確認するコード例を示している。

• defer srv.Close()

  • サーバー終了コード例: テスト終了後にサーバーを閉じるコード例を示している。

• 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 リクエストコード例: HTTP POST リクエストを送るコード例を示している。

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

  • 依存先のためのフェイクを使ったサーバー生成: newTestServer では、依存先をフェイクに差し替えたサーバーを起動していると述べている。

• If I want to test a dependency error, I replace that property with a fake that will return an 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.

  • さまざまな検証が可能: エラーパス、ログ出力、メトリクス送出、タイムアウト、graceful shutdown などを検証できると述べている。

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

  • サーバー起動後のポート確認: サーバー起動後にどのポートで動いているかを確認している。デフォルトが :0 のため、どこにバインドされたかを待って確認する必要がある。

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

  • 「単体」テストの範囲: 「単体」テストは handler レベルでも HTTP レベルでも行え、システム利用者に見える形でコード全体を十分にテストできる。すべての middleware を通すことも、まったく通さないこともできる。

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

  • 並列テスト実行: N 個のインスタンスを立ち上げて、テストを並列実行できるとしている。

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

  • Go は書かないがパターンは好み: Go は書かないが、これらのパターンは気に入っており、テストしやすいコードにかなり普遍的なものだと感じている。