新卒入社6年目、サーバーサイドエンジニアの小池です。
9/18日のRubyKaigi 1日目に参加してきました。
1日目は弊社サーバーサイドエンジニア大仲(@onk)による「API Development in 2017」というタイトルで、
これまでのRESTful APIを作ってきた経験を振り返りながら、今後の展望についての登壇がありました。
私も気づけば@onkの元へ弟子入りして5年経ち、この登壇を聞いてノスタルジックな気持ちで胸がいっぱいになったので
当時の思い出を振り返りながら@onkの登壇内容をレポートしたいと思います。
ブラウザソーシャルゲーム時代
私が新卒で入って一番最初の仕事はブラウザソーシャルゲームのサーバーサイドエンジニアでした。
このとき初めて触ったRailsは3.x系、ruby1.8や1.9を使っていました。
極力RESTの原則に沿った実装を心がけることを習いながらも、
ゲームの仕様を実現するためには一部無視しなければならないところとの塩梅でたくさん悩んだ思い出があります。
コードレビューでも主に、リソースに沿った正しいURI設計ができた実装かどうかという視点でのレビューが多かった印象です。
この頃はerbなどを用いてレスポンスはhtmlを返していました。
Web Viewアプリ時代
ブラウザソーシャルゲームの次はWeb Viewアプリという、iOS,Android向けのアプリ内でwebページを表示するものに移りました。
ブラウザソーシャルゲーム時代までは、エンジニアはサーバーサイドエンジニアしかいなかったのですが、
この時から、サーバーサイドエンジニアとクライアントサイドエンジニアの二つにエンジニアの役割分担がされました。
このチームではサーバーとクライアントのやり取りするI/Fの仕様は主にサーバーサイドエンジニアが決定していて、
I/Fの仕様を管理する専門のgitのリポジトリにMarkdownで記述する方法でドキュメントの管理を行なっていました。
この頃は、実際に実装を終えてからクライアントエンジニアとのすり合わせでAPIの修正を行う手戻りがたくさん発生していました。
時間がない時などは、ドキュメントの管理も忘れてしまうこともあり、I/F仕様のドキュメントはあまりメンテされているとは言えない状況だったのを深く反省しております。
この時Rails4.x系,ruby2.0.xを用いてレスポンスは、jbuilderを用いてjsonを返して、jsonの値を用いてhtmlに値を埋め込んで表示する形式でした。
極力表示の繰り返しを避けるために沢山のrender partialを使った部分テンプレートで実装しましたが
レスポンスが異様に遅い原因がこのrender partialにあって全部書き直したのは今となってはいい思い出です。
普通にjbuilderを使っても遅いとのことで、最終的にはslimやerbを使って直接htmlを返す形式に修正もしました。
rspecを使ったテストも導入していましたが、jsonの返り値まではテストできず、ブラウザ上にjsonが表示されるのをみての実装だったので、表示のバグも見つけるのが大変でした。
スマートフォンアプリ時代
次はスマートフォンのアプリのチームになりました。
サーバーサイドエンジニアがレスポンスでjsonで返した値を、クライアントエンジニアが表示に埋め込むという形式です。
ActiveModel::Serializersを用いてjsonを生成するようになり、jbuilderが遅いという問題からも解放されました。
さらに、I/Fの記述はjson-schemaを用いてyml形式で記述するようになりました。
json-schemaを用いてリクエストとレスポンスのvalidationをrspecに記述してテストもするようになりました。
サーバーサイドエンジニアが主導のI/F設計をしてから、クライアントエンジニアと一緒にI/F設計するようになり、
さらにテストもしっかり回せるようになったおかげで、
サーバーとクライアントの結合を行った際の手戻りの数も激減して開発速度が上がった実感があります。
そして、さらに現在はOpenAPIを用いてyamlを1つ書くだけでAPIとテストとドキュメントの３つを同時に行うことが可能になっています。
API開発の今後
まず最初にサーバーとクライアント間でのI/Fを決定してから実装に入る、スキーマファースト開発によって開発の速度は向上してきました。
I/Fのドキュメントのメンテナンス性やテストも出来るようになったが、
json-schemaは実装が変わるたびに更新をしなくてはいけない手間がかかるので100%信用できるドキュメントとは言い切れません。
Railsを使ったRESTfulも作るモノの仕様上どうしても破らなくてはいけない部分もたくさんあり、心が濁ります。
そこで、GraphQLです。
GraphQLでは、クライアントエンジニアが欲しいI/Fをクエリとして投げると、そのI/Fに沿ったスキーマを返すことが可能になります。
サーバーとクライアントは疎結合になることで、サーバーエンジニアが理想とするRESTの実現も可能に出来ます。
そこにはサーバーサイドエンジニアとしてRESTfulを破らなければならない場面での後ろめたさや、
サーバーとクライアント間での意思疎通を介した手戻りやドキュメントの保守の手間も存在しません。
ただ、現状では、実際に導入するためのエコシステムが存在しない点や
エラーハンドリングという点においてはRESTをまだ捨てることは出来ないので、
もうしばらくはRESTで頑張る必要がありそうですが、近い未来GraphQLが台頭してくることでしょう。
まとめ
- スキーマファースト開発ができる環境になり開発スピードが向上した
- OpenAPIを利用することで、APIのドキュメントやテストや実装をyamlを書くだけで可能になった
- GraphQLの台頭によりサーバーサイドがAPIを設計するということなくクライアントの実装が可能になる未来へ
