GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL
iCARE Dev Meetup 20 で発表した資料です #icare_meetup p.7,8,61 https://graphql.org/ p.18 https://twitter.com/a_suenami/status/1379270185207484417 p.33 [SQLQL - Qiita](https://qiita.com/yancya/items/4b7979d83cbf6af9b819) p.33 https://twitter.com/onk/status/912491093127598080 p.35 [【エンジニアブログ】ダイニーのエンジニアリング3カ条｜dinii（ダイニー）公式｜note](https://note.com/dinii/n/n9be778bd7da3) p.36 [Smart UI パターンが再評価される世界 - id:onk のはてな
GraphQLが解決する問題とその先のユースケース
サーバーサイドからみたGraphQL Serverlss Meetup#19 2021/03/31 に行われた Serverlss Meetup#19 で上記のタイトルで登壇してきました。サーバーサイドの話をしようと思ったけどGraphQLの解決している話をしようと思ったらクライアントの事もかなりはいってしまったので記事のタイトルは変えました。 以下内容です。記事の最後に資料を書くにあたって参考になった資料のリンクを置いてます。 GraphQL and me この1年書いたQiita記事 GraphQLの特徴を分解する ~API インターフェース・Universal BFF・API Gateway~ GraphQLはサーバーサイド実装のベストプラクティスとなるか GraphQLの全体像とWebApp開発のこれから 今回話す事 そもそもGraphQLはなんで作られたのか、何を解決しようとして
The NEXT of REST - onk.ninja
The NEXT of REST 前後リンク RESTful API のおさらい Rails での JSON API 実装まとめ スキーマファースト開発 The NEXT of REST REST で解決していない問題 REST っていうのは本当に難しくて、 開発者のお気持ちで API が異なる 指針であって仕様じゃないのが理由 POST がワイルドカードとして使われるとか クライアントとサーバ間のまだある精神的な溝 API はサーバが作るもので、クライアントは手出ししづらいという意識 REST だとクライアントごとに最適化した API を作りづらい Web とスマホで同じ API を使うときに不要なレスポンスがある 提供されている API が不十分なときにクライアント側で JOIN するハメに のような問題を抱えています。 これかを解決するために、API Query Language (
Node.js + GraphQLでBFFを作った話 - Qiita
whoami @qsona (Twitter, GitHub, Qiita) Node.js developer FiNC 2016/2 〜 Ruby, Rails / MySQL love microservices! Microservices Meetup 主催 昨日3/30に開催: vol.5 (API Gateway & BFF) BFF とは? Backends for Frontends の略 クライアントとバックエンドの中間にサーバを置き、フロントエンド寄りの処理を行う Microservicesの文脈で語られることが多い 昨日の会長のスライド step by step BFF GraphQL とは? クエリー型 Web API RESTful API において問題になりがちな点をカバーしている 仕様として定められている (RESTfulはあくまでAPI設計の指針) Nod
step-by-step BFF
Microservices Meetup で話した step by step BFF の話です。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BFF and Developer Experience
Webサービスの初期開発とマイクロサービス・BFF
