golang.tokyo #31(7/30) 参加メモ
golang tokyo
golang tokyoとは
- goを導入している企業のメンバーが集まり、普及を推進するコミュニティ
- オフラインでは頻繁にやってたが、オンラインになって久しぶり
- 今後もオンラインイベントを予定中
- 今回の内容はlogmiに後日記載される
1. httpルーティングライブラリ入門
- ISID(電通国際情報サービス) 宮原さん
- Goのルーティングライブラリってどう動いているのか、実際に実装してみて理解したことを共有
Webアプリケーションで使うライブラリ
Default Serve Max
- net/http ライブラリ
- 標準で使えるやつ
-
- routerとかが他の言語のルーティングと似てる
- パスパラメータを取得可能
-
- gorilla-muxに書き方は似てる
- パスパラメータを取得可能
共通点
- ハンドラの登録
- 呼び出しの登録
- 今回はこれらを行うのがHTTPルーティングライブラリとする
実際に作ってみた
- TinyRouter
- パスベースルーティング
- パスパラメータの取得に対応
- gorilla-muxの実装を参考
実装の概要
ベンチマーク
結果
- chiが遅い
- 比較回数が多い
- 基数木を用いるため
聞いた感想
- ルーティングの仕様はなんとなく使いながら理解していたけど、実装の内容を聞くと意外とシンプルなんだと思った。
- chiが遅くなった点について深堀りして欲しかった
- 木構造なら、エンドポイントの数がさらに増えた時にパフォーマンスが良くなる？
2. フューチャーのとある案件でGoを使ってみて実際のところ
リーダー視点でGoの良い所
- リーダー = 技術選定や処理方式の選定にメインで参加し、開発上の責任を持つ人
(導入してみて)良かったこと
- キャッチアップがしやすい・早い
- A Tour of Go をやればほぼ分かる
- ブラウザで動かせるので事前に勧めやすい
- 組み込みパッケージが揃っている
- A Tour of Go をやればほぼ分かる
- シンタックスシュガーが少ない
- フレームワークの差異がすくない
- コードの互換性が高い
- 適度に隙がある
- 小さいツールとか作りやすい
(技術選定で)困ること
実際の声
- コードが追いやすい
- リフレクションとか少ない
- 先達のコードをコピーしやすい
- 成功体験(コミット)を与えやすい
- 新人が新しい環境で貢献したい気持ちに答えられる
- 開発環境構築からコミットまで1，2日で進める
→ 言語仕様よりもドメイン知識に注力しやすい
A Tour of Goの他コミュニティからキャッチアップがしやすい
発展途上の点があって、初心者でもネタを公開しやすい
- メンバーの成長が実感できる
- 会社として外部露出のプラス
- 新しく参加した人が先達になる正のサイクルがまわる
Goでの開発の工夫編
プロキシ環境
WebAPI
- デファクトがないので採用技術はバラバラ
- ナレッジは他でも生きることが多い。(だいたいnet/httpのラッパーにすぎない)
- ポリシーに応じて選べる
AWS Lambda
多用途向けのシングルバイナリ
バッチアプリ開発
Webとバッチ処理のパッケージ構成をなるべく揃えておくと効果的
非機能面での注意点
- 1行ずつログを出さない
- 冪等な処理になっているか
- 未着チェック
- 起動時間になっても必要な物がない場合のエラー処理がなっているか
- ジョブの多重起動処理防止
- 部分取り込みを許容する場合に中断する方式になってないか
- リカバリ・再起動がしやすい設計か
テスト・品質
テーブルドリブンテストが有名
- テストコードが長くなりがち
- 正常系・異常系をテスト関数自体を分ける
- テストコードが長くなりがち
品質
- カバレッジをとる
- 注意：他の言語に比べ低くでがち
聞いた感想
- 前半のリーダー目線でのGoの導入に関する話は興味深かった。
- 研修で学ぶ言語と、実開発での使用言語との導線は考えるべき点と思った。
- 後半のGoの開発の工夫は、広範囲の内容で役立ちそうと感じた。
- せっかくの勉強会なのでひとつを深堀りしてみてもよかったとは思う。
3. 生産性の壁を突破しろ！ -Excelizeとjenniferによるコード自動生成-
ISID 佐藤太一さん
生産性 = コード生産量/ プログラマの人数×労働時間
- コードの品質が同じならば、量が多い方が生産性は高い
自動生成でコードを作成できれば、生産性が大いに向上できる
自動生成に向くコード
- 条件分岐が少ない
- データ構造が繰り返し
- 処理構造が繰り返し
自動生成のコードは書くこと自体が難しくなりがちなので、生産性があがる内容に適用していく
具体的な自動生成対象例(ドメイン駆動設計の用語)
- ValueObject
- Entity
- Repository
- SQLをそのまま使えるように
- GORMはパフォーマンスのネックになりやすいから使わない
自動生成ツール設計
生成物
- 自動生成コードの実装 → スライド参照
聞いた感想
- 自動生成のメリットと実装の具体例が挙げられていて、すごいと思った。
- Goで自動生成を実装するメリットとかを聞きたかった感
- コードの生産性という意味では、もっとパッケージ化されたtoBサービスを使いまわすとか、NoCodeで実装するとか手段は色々あるような気がする
4. Goで認証プロキシをつくってみた
悩み
- Goは認証仕組みが少ない
- 自前で毎回作るのは面倒
- 開発開始は認証なしで後から追加するのは難しい
- ローカルの認証が遅くて認証に時間かかる
要件
認証を強くしたい
良いライブラリがないので自作する！！→ wru
実装
- シンプルに作るために割り切る
ユースケース(本番環境)
- リバースプロキシとして動作
- OAuthとかOpenIDConnectのプロバイダーを複数同時利用可能
- ユーザ情報はcsvで読み取り
- オンメモリで持つ
- セッション情報は永続可能なストレージに保存
ユースケース(開発環境)
- リバースプロキシとして動作
- ユーザは登録一覧から選択
- ユーザー情報は環境変数から読み込む
セッション情報は温メモリ
セッションストレージ
- クッキーのようにサーバーからヘッダーで設定できる
Goっぽい話
- パラメータは環境変数からのみ取得
- envcofigを利用
- リバースプロキシ httputil.ReverseProxy
- ルーティング chi.Router
- ストレージ
- gocloud.dev
- 画面テンプレート
- go;embed
聞いた感想
- 認証認可についての理解がまだまだだと感じた。
- このライブラリの実装自体には2週ほどで作ったそうで凄いと思った。
- こういうライブラリって使ってみないといまいち理解が進まないと思っている。
セッション後の雑談
Goのモジュールにまつわるセキュリティ
ちゃんとメモしてなかったので気になる人は後日でるであろうLogmi Techの記事を参考にしてください。
全体の感想
- 久しぶりの勉強会聴講で、テーマも興味があるものでよかった。
- 各セッションの合間が短くて質問をする余白がなかった気はする。
