Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
新規サービスの技術選定と設計
Search
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
550
Vue.jsとRailsで作るWebアプリケーション
f96q
0
850
開発環境でDocker使ってみた
f96q
1
2.4k
2013年を振り返って
f96q
0
790
Git勉強会@KRAY
f96q
1
2.2k
等強Ruby会議10に参加しての感想
f96q
2
970
Inside Tripclip
f96q
2
1.6k
Other Decks in Programming
See All in Programming
IBM Bob Dojo #1 仕様駆動開発入門
oniak3ibm
PRO
0
400
Compiling a real-world CLI tool to native with Static Hermes
tmikov2023
0
120
AWS CDKのカスタムリソースでContinuum(旧Security Agent)を実装した話 | Implementing Continuum (formerly Security Agent) via AWS CDK Custom Resource
akihisaikeda
2
150
當我們開始不讀 Code - AI Agent 時代,Code Review 與 Clean Code 還剩下什麼?
jame2408
1
250
見えないものを探る要求要件定義に必要な基本的思考 / invisible-requirement-thinking
minodriven
15
8.5k
When benchmarks go bad - what I learned from measuring performance wrong
hollycummins
0
220
phperだってパンチカードでコーディングしたい
o0h
PRO
0
350
Domain-Driven Transformation
hschwentner
2
2.3k
S3 TablesのIcebergデータに、AIエージェントからアクセスしてみた / 20261016developersio2026joetsu-accessing-iceberg-in-s3tables-via-agent
kasacchiful
PRO
0
160
HTML-in-Canvasで作る未来のWeb UI表現
clockmaker
5
5.1k
コードで差別化できない時代の ソフトウェアエンジニアリング / Software Engineering in an Era Where Code Doesn’t Differentiate
kishida
2
180
Augmenting AI with the Power of Jakarta EE
ivargrimstad
0
220
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
So, you think you're a good person
axbom
PRO
2
2.2k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
8.1k
Statistics for Hackers
jakevdp
799
230k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
300
My Coaching Mixtape
mlcsv
0
360
Information Architects: The Missing Link in Design Systems
soysaucechin
1
1.2k
Chasing Engaging Ingredients in Design
codingconduct
0
360
jQuery: Nuts, Bolts and Bling
dougneiner
66
8.6k
Being A Developer After 40
akosma
92
590k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.3k
Designing Powerful Visuals for Engaging Learning
tmiket
1
610
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カタログを表示して、コンポーネントのデザイ ンが確認したりできる • 本体に組み込まなくても、デザインの調整ができるようになるのでデザイ ナーとやりとりがしやすくなる