新規サービスの技術選定と設計

C3191b3ed166724aa0ea3ed9d2784772?s=47 danny
November 19, 2018

 新規サービスの技術選定と設計

C3191b3ed166724aa0ea3ed9d2784772?s=128

danny

November 19, 2018
Tweet

Transcript

  1. 新規サービスの技術選定と設計 DBD DSE 宮城 史明

  2. 2 概要 • GraphQL • Railsアプリケーションのテストコードの書き方 • Heroku Review Apps

    • React • TypeScript • styled components • Storybook
  3. 3 なんでGraphQLなのか • REST APIの問題点 ◦ APIのレスポンスで返したい値を制御するのがやりずらい ◦ 特定の画面を表示するのに必要な値を返したい場合にAPIを増やす必要が出る

  4. 4 今の時点で次世代のAPIになる可能性があるのもの • GraphQL ◦ Query、Mutation、Subscriptionを定義 ◦ APIエンドポイントは1つ • gRPC

    ◦ ProtoclBuffersを定義 ◦ Webアプリケーションの場合はREST API Serverを置いて、受けたものを元に gRPCを呼び出す ◦ 最近はgRPC-Webがリリースされて、直接呼び出しできるようになった https://www.publickey1.jp/blog/18/grpc-webwebgrpc.html
  5. 5 なんでGraphQLなのか • 新規サービスの開発なので、既存のシステムを考慮しなくて済んだ • gRPCだとProtocal Buffersを使えるシステム同時を繋げるのは良いが そうじゃないと工夫が必要になる • 画面のUIだったり表示項目などの変更があるので、柔軟に取得したい値

    を取れるようにしたかった ◦ バックエンド側の改修が不要か最小限で済む ◦ 開発スピードと生産性の向上
  6. 6 GraphQLクエリ例

  7. 7 GraphQLクエリ例

  8. 8 GraphQLクエリ例

  9. 9 REST APIと考え方が違う点 • エラーでもステータスコードが200 ◦ エラーはレスポンスのJSONの中に入れる • N +

    1が簡単に発生する ◦ 解決方法がRESTの時は使う関連テーブルをまとめてJOINして検索して回避でき るが、GraphQLの場合どの値を取得するかをクエリーで書くのでなんのデーブル をつかうかどうか実行時に予想できない ◦ Rubyの場合は、まとめて最後に遅延評価することで解決するgraphql-batchと いうgemがある https://github.com/Shopify/graphql-batch • APIのエンドポイントが全部同じなので、NewRelicなどで遅いAPIをAPI のパスで判別できなくなる
  10. 10 Railsアプリケーションのテストの書き方 • ランダムな値を入れる • 関連テーブルのデーターはそのテストに必要がある場合のみ生成する https://github.com/willnet/rspec-style-guide

  11. 11 テストコードの書き方ダメな例

  12. 12 テストコードの書き方良い例

  13. 13 テストコードの書き方ダメな例

  14. 14 テストコードの書き方良い例

  15. 15 Heroku Review Apps • Herokuの機能 • GithubでPull Requestを作成すると、そのPull Requestの内容で新規

    にサーバーが自動的に構築されて立ち上がる • データーベースのインスタンスなども完全にPull Request毎に別に作成 される • 開発初期にAWS環境にサーバーを構築する余裕がない場合にも便利 https://devcenter.heroku.com/articles/github-integration-review-apps
  16. 16 なんでTypeScriptなのか • JavaScript(動的型付けの言語)の場合どんな型でも入ってきてしまう ◦ 想定してない値が入ってきてしまって不具合が起こることがよくある ◦ そのためテストコードをしっかり書く必要が出る • ES2015のスーパセット

    ◦ 既存のJavaScriptの機能 + 型システムが使える • コンパイラに統合されている ◦ Flowは別になってる
  17. 17 TypeScript

  18. 18 TSLint, pretter

  19. 19 TypeScript使う上で気をつけたほうが良い点 • TypeScriptの独自拡張はできるだけ使わないようにする ◦ Enumなど ◦ 将来的にECMAScript側に型機能が入った場合に移行するのが大変になるので

  20. 20 なんでReactなのか • Vue.jsにしなかった理由 ◦ 型の対応が弱い ◦ 一定以上の規模の複雑なSPAになると破綻する可能性が高そう ◦ 書き方がReactに比べ自由に書けるので、人が増えた場合に一貫性が保ちずら

  21. 21 最近のReact • Reactのコア機能にReact Hooksが提案されたことによって、 Recomposeが将来的にメンテされなくなる ◦ https://github.com/acdlite/recompose#a-note-from-the-author-acdlite-o ct-25-2018 •

    移行するのが大変になるのでRecomposeはあまり使わないほうが良い
  22. 22 CSSの問題点 • グローバルスコープなので、定義したクラスがよく名前がぶつかる

  23. 23 styled components • styled components ◦ ReactのコンポーネントのタグにCSSを定義して、ほかのところに当たらないCSS クラス名を自動で降ってhtmlにCSSを埋め込む •

    styled system ◦ 色とか右寄せとかちょっと調整したい場合に ◦ https://jxnblk.com/styled-system/
  24. 24 styled components

  25. 25 styled system

  26. 26 Storybook • ReactのコンポーネントのUIカタログを表示して、コンポーネントのデザイ ンが確認したりできる • 本体に組み込まなくても、デザインの調整ができるようになるのでデザイ ナーとやりとりがしやすくなる