graphql/dataloader を読んだ話
graphql/dataloader のドキュメント及びソースコードを全て読んだので、その話を書く。 読むことにした第一の理由は仕事で使うからだが、以下の特徴から自分のプログラミング学習教材として適していそうだと考えたからでもある。 広く使われている OSS である GitHub の星が 11k npm trends で検索しても多くの人がダウンロードしている コードの量が少ない 実装は src/index.js に全て書かれている コメント含めて 500 行にも満たず、しかもその 1/3 くらいはコメント テストカバレッジが高い 常に 100% 初めて読むコードでテストカバレッジが高いと、テストコードを読むことで期待される挙動を確認できるので嬉しい npm trends によると、一週間で 200 万件近くダウンロードされているようだ。 目次 graphql/dataloader とは
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 のはてな
Protocol BuffersでgRPCとGraphQL両対応のコードを生成するプラグイン書いた - blog::wnotes.net
gRPC、あるいはGraphQL 昨今のAPI開発にgRPC、またはGraphQLを採用するケースは増えてきていて、ドメインロジックをgRPCで実装して、フロントエンド(BFF)はGraphQL経由のHTTP一本で取得するのはベストプラクティスの一つだと思っています。 とはいえ人的リソースや管理の問題から、ProtobufとGraphQLスキーマを両方メンテナンスしていくのはとてもつらくて、 他のエントリでも結果としてどちらかに寄せました、というケースをよく目にしました。 実際自分もやってはみたものの、両方のメンテナンスをしていくのは相当辛くて、Protobufを直してgRPCのI/Fを変更、合わせてGraphQLのSchemaにも手を入れてフロントに渡して…というのは管理コストに見合わないな、ってことで諦めました（今は grpc/grpc-web 、または grpc-ecosystem/
Apollo(GraphQL)+gRPC+WebFlux(Reactive)を利用して2020年のモダンアーキテクチャアプリを作ってみた - Qiita
Apollo(GraphQL)+gRPC+WebFlux(Reactive)を利用して2020年のモダンアーキテクチャアプリを作ってみたJavaScriptKotlinSpringBootgRPCGraphQL はじめに 本記事では2019年から2020年にかけての年末年始を使って開発した、"Hello Worldを出力するアプリ"の話をしたいと思います。 Hello Worldを出力する、と言っても単にフロントエンドでReactの<p>Hello, World!</p>と書いて出力したという話ではなく、 フロントエンドでApollo Clientを使ってGraphQLでQuery/Mutationのリクエストを行い、 BFF(Backend For Frontend)のApollo ServerでGraphQLのリクエストに応じたgRPCのリクエストをバックエンドへ内部的に行い、 バック
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - join-monster/join-monster: A GraphQL to SQL query execution layer for query planning and batch data fetching.
