はじめに
こんにちは、ヤプリのサーバーチームでインターンをさせていただいている木下です。
今回は、検証環境にデプロイする際に、ハマったことがあり、備忘録としてまとめます。
前提：Yappliの運用について
Yappliでは、クライアントをTypeScript、サーバをGo、APIの通信にgRPC、Protobufを採用しています。
運用に関しては、こちらの記事で詳しく解説してあります！ tech.yappli.io
やりたかったこと
取り組んでいたチケットは、画面上に設定項目を追加するというものでした。
そこで、検証環境にフロントエンド、サーバサイド、Protobufをデプロイして動作確認をするということをしていました。
起きた事象
デプロイ後、アプリは立ち上がるが、DBに新しく追加した項目のデータが保存がされないという事象が起きました。
どうやって解決したか
サーバサイドの作業ブランチで、最新版のProtobufを参照することで解決しました。
なぜこうなったのか・原因
・Protobufで生成されたコードの最新版を参照できていなかった
サーバサイドでは、参照するProtobufをコミットのハッシュ値で決めています。
そして go get "リポジトリURL@ブランチ名" で、そのブランチのProtobufの最新版を参照する必要があります。
これをしていなかったため、Protobufを最新にしても、サーバサイド側で最新版のProtobufを参照しておらず、クライアントや別アプリとProtobufが異なっていたため、正しくデータが送れていませんでした。
Protobufを初めて使ってみた感想
今回のインターンで、初めてProtobufを触りました。
フロントエンドやバックエンドがどういう仕組みでProtobufを参照していたり、gRPCでどう通信しているのかという理解が足りなかったが故にいろいろ手こずって、ハマりました。
ProtobufをgRPCの通信で使用することで、各サーバが問題なくても、参照するProtobufのバージョンが異なったり、Protobufの設定を間違えたりすると、正常に動かないことが多々ありました。
各サーバは問題ないのに動かないとき、どこに問題があるのかという切り分けが難しかったです...
あと、Protobufはコミットでバージョン管理しているので、チーム開発をしていると、他の人が変更してよくコンフリクトが起きていたので、結構面倒だなって思ったこともありました。
Protobufいいな！って思ったこと
上で色々文句を言っていますが、Protobufから生成されたファイルを見ると、クライアントからサーバにどんなデータが送られているのか、またどのメソッドが呼び出されるのかがすぐ分かります。
これがAPI仕様書みたいで、とても便利だと感じました！
個人開発では、ここまでしっかりと決めなくてもゆるゆる送るデータなどを変えたりしていましたが、ヤプリほど大きいサービスでフロントエンドやサーバサイド、モバイルアプリなど多くのアプリが複雑に連携していくとなると、APIアプリ開発ではがちがちに値や型などを決めるProtobufが保守しやすいのかなと思いました！
あと、これはヤプリだからなのかもしれませんが、GitHubにpushをすると、CIが走り、ProtobufファイルからTypeScriptとGo用のファイルを自動生成してくれます。なおかつ、指定もコミットのハッシュ値なので、参照する値を指定しやすく、開発者体験がめちゃめちゃいいなと思いました！
おわりに
今回のインターンで、gRPC、Protobufという新しい技術を知り、触ることができ、すごく学びになりました！
また、ヤプリの大きなサービスのシステムを構成する一部を知って携わることができ、貴重な経験ができました！
ヤプリに興味ある方はもちろん、ノーコードのプラットフォームビジネスに興味ある方、選考やインターンへの参加を検討してみてはいかがでしょうか？ open.talentio.com
