APIのコードを自動生成させたいだけならgRPCでなくてもよくない?

こんにちは、エンジニアリンググループの福林 (@fukubaya) です。

先月から、今年の秋くらいにリリース予定の新サービスの設計、開発を始めました。 せっかく新しく始めるサービスなので、まだ経験したことがない言語やフレームワーク、技術を使わないと楽しくありません。

そこで、バックエンドにGoにして、フロントのAPIまで含めてgRPCの .proto ファイルで定義を一元化し、APIコードは protoc で生成させる計画を立てていたのですが、

• フロントでgRPCとなると、 gRPC-web か grpc-gateway になるが、リリースまでに使える期間では認証も含めると検証が間に合わなさそう
• Goだけでなく、terraform(インフラ設計もやります) も Vue.jsも今回が初めて、というメンバーもおり、さらにRESTではなくgRPCも、となると未経験技術が多すぎてキャッチアップが追いつかなさそう

ということもあって見送りました。

それでも何かしら新しく触る言語やフレームワークは入れたいので、今回は バックエンドにSpringBoot(Kotlin)を、フロントエンドに Vue.js(Typescript)を使うことになりました*1。gRPCは見送ったので、RESTのAPI定義一元化、コード自動生成を実現するためOpenAPIを利用することにしました。

パシフィコ横浜は、横浜市にある世界最大級の国際会議場と展示ホールとホテルからなるコンベンション・センター。本文には特に関係ありません。

*1:Typescriptは前プロジェクトで諦めていたので今回入れたかった https://www.m3tech.blog/entry/2019/04/23/114832

【Sansan 藤倉成太×エムスリー 山崎聡】「二者択一の考え方はエンジニアのキャリアを先細りさせるだけ」（エンジニア type 対談後記）

エムスリーエンジニアリングGでVPoEをやっている山崎です。

先日、Sansan株式会社CTOの藤倉さんとエンジニアのキャリアについて対談させて頂きました。対談中に感じたことや、対談を振り返ってみて改めて感じたことについて書いてみたいと思います。

type.jp

きっかけ

先日の対談にて

藤倉さんとの出会いは、2017年12月にエムスリーの初代VPoEに就任した後、改めて他社のCTOやVPoEについて学んでいた頃にCTOミートアップでお見かけしたのが最初だったと思います。その後、機械学習関連の勉強会などでSansanさんとご一緒する機会も増え、藤倉さんと別のイベントでご一緒することもあり、ビジネス領域の課題を解決する同志として意気投合したのが今回のイベントのきっかけとなりました。

「現場」か「マネジャー」か、という議論を振り返って

これは採用活動でエンジニアのキャリア相談に乗っていると、本当によく耳にする悩みです。考えの多くは対談中に触れたとおりですが、このような二者択一の考えになってしまう原因の一つは、日本のソフトウェア産業における「現場」と「マネージャー」の報酬格差にあるのではないか、というのが、対談で触れなかった考えです。

というのも、1980年代のマイコン黎明期から始まり1990年代を経てWeb関連のビジネスが一般的になる前の2000年頃までの日本のビジネス向けのソフトウェア産業は、どちらかといえばメーカー製品にバンドルされるようなパッケージソフトウェアや、何十人何百人で作り上げる大型のソフトウェアプロジェクトなどが主流だったため、ソフトウェアを発注する側と受託する側の切れ目が比較的明確で、その中でソフトウェアを作り上げる作業もマネージャーが指示を出し、現場のエンジニアが構築するという比較的トップダウンな開発が主流だったと思います。

その結果、典型的なSI構造、つまり基本的には（一部のスーパープログラマーを除いて）マネージャーのほうが報酬が高く、現場のエンジニアが報酬が上がりにくいという構造が出来上がりました。そのような環境の中では、対談中に触れた「やりたいこと」を続けようとしても、ライフステージの変化とともに、そろそろ現場から離れてマネージャーに上がらなくては…と考えてしまうという強い力学が働くのもある意味仕方ないと思います。

報酬格差を解決するための3つの選択肢

二者択一の考え方も含め、解決策は3つあると思います。

Google Cloud Next '19 in Tokyo & Leaders Circle

こんにちは、CTO の矢崎(id:Saiya)です。

先日、Google Cloud Next '19 in Tokyo とその中で開催される Leaders Circle という会に参加してきました。

かつてないクラウドを体験しよう。

イベント全体の内容などは 公式サイト をご覧いただくとして、ここでは私個人の主観として印象に残った点や、エンジニア・アーキテクト観点での気になりどころなどをご紹介いたします。

AWS AppSync を IAM 認証で使うための graphql-client のアダプター gem を公開しました

こんにちは、エムスリーエンジニアリンググループ 兼 QLife エンジニアの園田 (@ryoryoryohei) です。

AWS AppSync 使ってますか？ サーバーレスで GraphQL のエンドポイントを提供できる強力なサービスです。

AppSync には認証方式が現状 4 つあり、そのうちの 1 つである IAM 認証を設定した場合、GraphQL の HTTP リクエストは AWS の 署名バージョン 4 で署名 されている必要があります。

GraphQL の代表的な Ruby ライブラリである Github の graphql-client は当然 IAM 認証には対応していないので、IAM 認証に対応させるためのアダプターライブラリを実装して公開しました。

Jenkinsをエンジニアでない人も使えるDigdagのWeb UIとして使う

こんにちは、エンジニアリンググループの福林 (@fukubaya) です。

現在、弊社では長年運用され続けているレポート基盤のリニューアルを昨年から続けています。 その一環で、エンジニアでない人も使えるレポート生成UIを実現するため、 DigdagとJenkinsを利用した仕組みを検討しました。 本記事ではその一例をご紹介します。

横浜赤レンガ倉庫は横浜港にある歴史的建築物。本文には特に関係ありません。

ALB 経由で Lambda の Rails を実行してみた

お久しぶりです、エムスリーエンジニアリンググループ 兼 QLife エンジニアの園田です。

今回は、Rails のアプリを AWS の Lambda で動かして、ALB 経由でアクセスしてみようという内容です。

実現するためには

• ALB から Lambda を呼び出す。
• Lambda で Rails を動かす。

上の２つをクリアするだけでいいので、動かすだけならとても簡単にできてしまいます。

ドメイン駆動設計座談会 & モデリングハンズオンを開催しました

エンジニアリンググループの西名(@mikesorae)です。

最近エムスリー社内でドメイン駆動設計(以下DDDと表記)への関心が高まり、社内でも勉強会を開催する流れになりました。

せっかくなので有識者から効率的な学習方法や注意点を学ぼうということで、DDD Community JPの運営などで活躍されている松岡幸一郎(@little_hand_s)さんをお招きし、DDD座談会を開催しました。

エムスリーさんにお邪魔してドメインモデリングハンズオンしました。実際の業務のネタでモデリングはやはり盛り上がる！

出張ハンズオン、勉強会やってますので興味ある方ご相談を〜！ pic.twitter.com/7oTAQetSZY

— 松岡@DDDブログ書いてます (@little_hand_s) 2019年6月19日

本記事では、その中でも面白かった内容をピックアップしてご紹介します。

DDDを始める際の注意点

まずは、DDDに取り組む際にどんなことに気をつけるべきかを質問してみました。