ネイティブアプリエンジニアが伝える、バックエンドエンジニアに認識して欲しい4つのこと
この記事は、eureka Native Engineer Advent Calendar 2017 25日目の記事です。
24日目はJohnの「Convolutional Neural Networkを理解しよう」でした。
はじめに
こんにちは、CTOのkaneshinです。業界では、『エウレカのCTO』か『Go言語の人』という認識を持たれていますが、エウレカでは4年ほど前にネイティブアプリのマネージャーを2年半ほど担当していました。
開催が40回を超えているpotatotipsにも登壇させていただいたことがあります。
ネイティブアプリのマネージャー時代では、マネジメントに限らず、第一線で手を動かして開発をゴリゴリと担当していました。そのため、大量の技術課題をネイティブアプリに負債として残しているため、ネイティブアプリエンジニアと話していると、時々、私が書いたコードが話題にあがるので本当に申し訳ない気持ちで一杯です。笑
さて、今回は『サーバーサイドエンジニアに意識して欲しい』というポイントを話そうと思います。
注意
- フロントエンドはWebフロントとネイティブサイドの両方を含めます。
- 弊社の事例というわけではないです。エウレカの開発組織の話であれば:
- Pairsを支え続ける開発組織『BI / SRE / QA / CTO Office』チームの技術横断の考え方・動き方
- エウレカという組織で、スクラムがチームに起こした変化
- エウレカのアジャイル・コーチが新しいオフィスにこだわったポイントを紹介します。
ここが大変なんだよ、ネイティブアプリ・フロントエンド4選
弊社の事例というより、経験や聞いたことがベースになっています。
勝手にAPIレスポンスの返却値の構造を変えることはしないで…
非常に当たり前なのですが、感覚的に気にしていない人がまだ世の中には多くいる気がしています。サーバーサイドを担当する人は、Webフロントは実装したことがあると思いますが、一度本番にリリースすれば古いのは考慮しなくていいのは当たり前ですね。
リリースをコントロールできる側からしたら、一部分だけ古いのを残すことにメリットなんて基本はないですからね。（何かしらのテストをしているならこれに限らない）
だがしかし、サーバーサイドやWebフロントと違い、ネイティブアプリはユーザーのiPhoneやAndroidに古いバージョンのアプリをインストールしたままの人が少なからず存在します。
そのような古いままのアプリがハンドリングできない情報が出て来る場合、情報欠落として不具合となる可能性があるし、最悪の場合、アプリがクラッシュすることがあります。
もし、あなたがAPIレスポンスの構造を変更・削除をしようと思った場合、一度、フロントサイドとご相談することをオススメします。
Generative Programming
「あ、あと、ちゃんとAPI仕様書更新してな！」というときに、更新を手動でやらずにバックエンドとしてはGenerative Programmingで解決をしましょう。
これの解決方法として、gRPC？
最近、巷ではWeb APIの相互の認識相違を無くすためにgRPCが活性化してきていますが、本当にフロントサイドからやりたいという声が出てきてから実装にしましょう。
私の所感で、gRPCはマイクロサービス間での通信はとても良いです。ただ、gRPCの仕様に沿った完成度が各言語によって違うことがあったりするのと、結局、protoファイルで統一されていても、勝手に命名変更や追加に追従できるかというと、フロントサイドのエンジニアが結局調べることになるためです。
正解（＝銀の弾丸）はもちろん無いのですが、チョイスは使う側に委ねたほうが良いです。サーバーサイドエンジニアがgRPCを導入して、工数が削減できたとして、フロントサイドはむしろ工数が増えることになるかもしれません。『顧客（ネイティブアプリエンジニア）が真に求めているものを理解』するために、しっかりと対話を積み重ねましょう。（GraphQLも同様に）
複雑なロジックをアプリ側で実装させないでほしい…
ネイティブアプリエンジニアが重要にしていることは、ユーザーに最高の体験を提供できるUI/UXを実装することです。
皆さんがスマートフォンを初めて使ったときのあの体験を、アプリで提供できるくらいの革新的なUI/UXを常に追い続けなければいけません。
それを達成するために、ネイティブアプリはUI/UXに集中すべく、サーバーサイドで吸収できるような複雑なロジックはネイティブアプリで実装させないような工夫をしていって欲しいです。例えば、複雑なロジックをサーバーサイドにてバリデーションするようなAPIを提供してしまうとかです。
先述した、『最高のUI/UXを提供する』ためには、約17ms(約60fps)の世界でネイティブアプリは勝負をしています。サーバーサイドも『◯◯msで勝負している』ということはあると思いますが、それはエンドユーザーを考慮に入れていますか？サーバーサイドを速くするためにフロントエンドを考慮し忘れていたら意味がありません。
むしろ、サーバーサイドの方が潤沢なCPUリソースを保持しているので、処理はサーバーサイドに委譲すべきです。なので、複雑なロジックは全てサーバーサイドに吸収してもらいたいです。
全ては 最高のUI/UXのため です。
状態遷移を伴うエラーなら、エラーとして扱わないで…もしくはもうちょい考えて…
これ、ネイティブアプリエンジニアなら非常に『あるある』と思ってもらえると思うのですが、サーバーサイドエンジニアがWeb API側で何らかのエラー発生時に『エラーコード』と『エラーメッセージ』を返却して、 『このエラーメッセージを表示すればいいから！』 みたいに会話してくるケースがあると思いますが、 『そのエラーはフロントサイドでユーザー側の持つデータと照合して、別のエラーじゃないアラート出さないといけねーから！！』 みたいなケースを体験したことはありませんか？
例えば、とある画像を複数枚アップロードしようとしたときに、一枚だけ適さない画像が存在したときに、UI/UXの観点から適さない画像を特定してハンドリングをすることなど。
これは、複雑なロジックをフロントサイドで保持していることとも同じなので、『エラーを良しなに実装してやったぜ！』となる前に、一度、フロントサイドと相談してあげてください。
そして、ちゃんと、エラーコードやエラーメッセージはサーバーサイドのソースコード以外で、フロントサイドの人間が見える場所にドキュメンテーションしておいてください。
『エラーコードとエラーメッセージ？ソースコードにあるよ？』
OMG…
サーバーサイドもUI/UXの観点を持ち、エラーの実装をしていきましょう。
そんなにデータ要らない…情報量削減しよう…
上に述べた3つの対策などをやったり、様々な施策が開発されていくと、次第にデータ量が増えて増えて増えまくります。要件に則したAPIが増えていることと、データの転送量が増えることによって、ユーザーの方に負担してもらわなければならないことが増えるのです。
これの結果として、『遅い』や『データたくさん使う』と思われてしまい、アプリの削除につながってしまう可能性があります。適切にデータを追加していくことと、長期プランの上でデータを削除すること（むしろ、必要なデータとなるキーとペアとなる値を追加した人が責任をもって消すタイミングも考慮すべきである）も視野にいれていくのがエンドユーザーのためにつながります。
おわりに
フロントエンド視点での『あるある』はもっとネタがあると思います。私の考えでは、サーバーサイドが提供しているAPIは使う側（Webフロントとネイティブ）が存在するからこそ意義があるので、サーバーサイドだけが考えるのではなくて、フロントサイドも考慮しなければならないと思っています。
フロントエンドはWebフロントもネイティブサイドも両方を含めているので、バックエンドはフロントエンドのために全てを考慮してもらえると、APIの受け手側はハッピーになれます。
全ては、アプリで最高のユーザー体験を提供するために、全エンジニアが協力して開発ができれば最高だな、と思っています。そんなエンジニア組織にしていければと思って、今年のAdvent Calendarを締めさせてもらいます。
