[JA] Golang Package Composition for Web Application: The Case of Mercari Kauru
この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔(?)から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか(相互参照せずに快適に開発を進められるパッケージ構成とは)を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう
最近、golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? という質問を受けた。 回答時間が限られている中で質問を受けたので、 「現実的には難しい」という雑な回答しかできなかった。 さすがに雑すぎるなと思ったので、 自分なりの回答をちゃんと残そうと思う。 影響を受ける対象となるコードは? MySQL -> PostgresSQL への差し替え MySQL -> WebAPI への差し替え インフラレイヤにDB依存のコードをまるっと実装してしまう DDDの場合 独自の接続オブジェクトを作る DDD本 & IDDD本のサンプルはどうなっているか? 差し替える必要はあるのか? まとめ 影響を受ける対象となるコードは?golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? とい
どうも、Gunosyの新規事業開発室エンジニア、高橋(@__timakin__)です。 先日行われたgolang.tokyo#9にて、GoのAPIサーバーの設計についてトークをする機会を頂いたので、いってきました。 スライドはこちらです。全編英語となっておりますが、ご覧頂けると幸いです。 speakerdeck.com 概要 アジェンダの前の序文にも書いてあるのですが、GoのAPIが大企業で試験的に導入するというフェーズを超え、スタートアップなどでも「Goって最近トレンドだよね」という声が聞こえ、小規模のチームでも積極的に登用されるようになってきたように感じます。 あくまで個人の観測範囲での話なのでバイアスがあるとは思いますが、「試してみた」というトークが界隈でも最近少なくなったように思います。 そんな中、参考例となるGoのAPIのOSSは非常に少ないため、新規に始めるハードルは、学習コス
devfest 2017 tokyo の発表資料です。 Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える from pospome 当日は入室できない人もいたらしい & 機材トラブルで10minほど開始が遅れてしまった ということで申し訳なく思っています。 また、立ち見する価値がある内容を提供できたのだろうか? とも思っています。 スライドは単体でも発表内容が伝わるように文章を多めに載せているので、 是非確認してみてください。 100ページ越えていますが・・・。 #DevFest_room2 入れなかった。。— t.junichi (@tjun1) 2017年10月9日 ものすごい立ち見人数 #Devfest17 #DevFest_room2— バトルプログラマー柴田智也@少女終末旅行 (@tomoya_shibata) 2017年10月9日 ルーム2これから並ぶ方はま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く