Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
新規サービスの技術選定と設計
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
danny
November 19, 2018
Programming
18k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
新規サービスの技術選定と設計
danny
November 19, 2018
More Decks by danny
See All by danny
Datapiaのフロントエンドについて
f96q
0
530
Vue.jsとRailsで作るWebアプリケーション
f96q
0
830
開発環境でDocker使ってみた
f96q
1
2.4k
2013年を振り返って
f96q
0
770
Git勉強会@KRAY
f96q
1
2.1k
等強Ruby会議10に参加しての感想
f96q
2
960
Inside Tripclip
f96q
2
1.6k
Other Decks in Programming
See All in Programming
The Arts and Crafts of Work in the AI Era — Toward Mastery in Software Development
kuranuki
1
750
[2026年度第1回ORセミナー] 計画最適化ベンチャーと競技プログラミング人材
terryu16
0
250
Skillsは効率化、Agentsは"自分の拡張"——Builder時代のエージェント編成(CC Night 2026)
wemra
1
120
Language Server 使ってる? 〜VSCode と Zed の場合〜 / Are you using a Language Server? ~For VS Code and Zed~
handlename
0
780
Webフレームワークの ベンチマークについて
yusukebe
0
160
AI駆動開発で崩れていくコードベースを立て直す
kyoko_nr_nr
1
450
AI時代の仕事技芸論 — ソフトウェア開発で「遊ぶように働く」職人的熟達のすすめ
kuranuki
1
650
ADKを使って簡単にAIエージェントを作ってみよう
k1mu21
0
250
決定論的オーケストレーションの設計と実装 / Design and Implementation of Deterministic Orchestration
nrslib
3
1.3k
Developing with AI Agents — Codex, Claude Code & Cowork Practical Guide
x5gtrn
PRO
0
1.1k
3Dシーンの圧縮
fadis
1
690
TAKTでAI駆動開発の品質を設計する
j5ik2o
6
1.2k
Featured
See All Featured
Ruling the World: When Life Gets Gamed
codingconduct
0
250
Music & Morning Musume
bryan
47
7.2k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
65
55k
Technical Leadership for Architectural Decision Making
baasie
3
400
Ethics towards AI in product and experience design
skipperchong
2
310
The Curse of the Amulet
leimatthew05
1
13k
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
2
1.5k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
390
Facilitating Awesome Meetings
lara
57
7k
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.6k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Transcript
新規サービスの技術選定と設計 DBD DSE 宮城 史明
2 概要 • GraphQL • Railsアプリケーションのテストコードの書き方 • Heroku Review Apps
• React • TypeScript • styled components • Storybook
3 なんでGraphQLなのか • REST APIの問題点 ◦ APIのレスポンスで返したい値を制御するのがやりずらい ◦ 特定の画面を表示するのに必要な値を返したい場合にAPIを増やす必要が出る
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 なんでGraphQLなのか • 新規サービスの開発なので、既存のシステムを考慮しなくて済んだ • gRPCだとProtocal Buffersを使えるシステム同時を繋げるのは良いが そうじゃないと工夫が必要になる • 画面のUIだったり表示項目などの変更があるので、柔軟に取得したい値
を取れるようにしたかった ◦ バックエンド側の改修が不要か最小限で済む ◦ 開発スピードと生産性の向上
6 GraphQLクエリ例
7 GraphQLクエリ例
8 GraphQLクエリ例
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 Railsアプリケーションのテストの書き方 • ランダムな値を入れる • 関連テーブルのデーターはそのテストに必要がある場合のみ生成する https://github.com/willnet/rspec-style-guide
11 テストコードの書き方ダメな例
12 テストコードの書き方良い例
13 テストコードの書き方ダメな例
14 テストコードの書き方良い例
15 Heroku Review Apps • Herokuの機能 • GithubでPull Requestを作成すると、そのPull Requestの内容で新規
にサーバーが自動的に構築されて立ち上がる • データーベースのインスタンスなども完全にPull Request毎に別に作成 される • 開発初期にAWS環境にサーバーを構築する余裕がない場合にも便利 https://devcenter.heroku.com/articles/github-integration-review-apps
16 なんでTypeScriptなのか • JavaScript(動的型付けの言語)の場合どんな型でも入ってきてしまう ◦ 想定してない値が入ってきてしまって不具合が起こることがよくある ◦ そのためテストコードをしっかり書く必要が出る • ES2015のスーパセット
◦ 既存のJavaScriptの機能 + 型システムが使える • コンパイラに統合されている ◦ Flowは別になってる
17 TypeScript
18 TSLint, pretter
19 TypeScript使う上で気をつけたほうが良い点 • TypeScriptの独自拡張はできるだけ使わないようにする ◦ Enumなど ◦ 将来的にECMAScript側に型機能が入った場合に移行するのが大変になるので
20 なんでReactなのか • Vue.jsにしなかった理由 ◦ 型の対応が弱い ◦ 一定以上の規模の複雑なSPAになると破綻する可能性が高そう ◦ 書き方がReactに比べ自由に書けるので、人が増えた場合に一貫性が保ちずら
い
21 最近のReact • Reactのコア機能にReact Hooksが提案されたことによって、 Recomposeが将来的にメンテされなくなる ◦ https://github.com/acdlite/recompose#a-note-from-the-author-acdlite-o ct-25-2018 •
移行するのが大変になるのでRecomposeはあまり使わないほうが良い
22 CSSの問題点 • グローバルスコープなので、定義したクラスがよく名前がぶつかる
23 styled components • styled components ◦ ReactのコンポーネントのタグにCSSを定義して、ほかのところに当たらないCSS クラス名を自動で降ってhtmlにCSSを埋め込む •
styled system ◦ 色とか右寄せとかちょっと調整したい場合に ◦ https://jxnblk.com/styled-system/
24 styled components
25 styled system
26 Storybook • ReactのコンポーネントのUIカタログを表示して、コンポーネントのデザイ ンが確認したりできる • 本体に組み込まなくても、デザインの調整ができるようになるのでデザイ ナーとやりとりがしやすくなる