コンパウンドプロダクト開発の質とスピードを支える Protobuf と Connect #アーキテクチャ_findy / Boosting Compound Product Development Efficiency with Protobuf and Connect
2024-05-22 アーキテクチャを突き詰める Online Conference https://findy.connpass.com/event/314782/ ■ 参考URL - コンパウンドスタートアップというLayerXの挑戦｜福島良典 | LayerX - https://comemo.nikkei.com/n/n7332c93f50c7 - ビジネスドメインの拡大を実現する バクラクシリーズでのモノレポ開発 - Speaker Deck - https://speakerdeck.com/layerx/bakuraku-devsumi-2024-yyoshiki41 - Connect - https://connectrpc.com/ - gRPC - https://grpc.io/ - Protocol Buffers によるプロダクト開発のススメ - API 開発の
REST、gRPC、および GraphQL を使い分ける (パート 2) | エクセルソフト ブログ
パート 1 では、最も人気のある 2 つの API モデル、REST と gRPC の長所と短所を説明しました。 パート 2 では、3 つ目の API モデルである GraphQL を取り上げます。そして、最後に、REST、gRPC、GraphQL を並べて比較し、本シリーズの内容を振り返ります。 GraphQL は、モバイル アプリケーション向けに、合理的でクエリ可能な API を提供するために設計された API クエリ言語です。GraphQL API は、非常に複雑なスキーマのデータのサブセットのみを必要とする実装において人気があります。 GraphQL を理解するには、リクエストとレスポンスの例を見るのが簡単です。国リストの GraphQL 実装について考えてみましょう。この API は大陸と国をリソースとしています。リクエストとレスポンスの例を見てみましょう。 左側 (リクエスト)
Rust の tonic で gRPC の Richer Error Model を扱う — HACK The Nikkei
この記事は Nikkei Advent Calendar 2023 および Rust Advent Calendar 2023 の 10 日目の記事です. はじめに Wave チームの何でも屋さん 伊東 です. 社内に ito さんがたくさんいるので区別が大変です. 最近嬉しかったことは短期インターンシップ参加者に Haskell 使いが2人もいたことです. 弊社にも静的型付け関数型プログラミング言語を普及したいです. さて、弊チームのサービスのバックエンドには gRPC を利用しています. gRPC はクライアント・サーバー間でスキーマ駆動開発をするのに便利なツールですがエラーハンドリングに少し癖があります. gRPC のエラーモデルにはシンプルだが柔軟性に欠ける Standard error model と柔軟だが互換性に欠ける Richer error model があります. St
【ハンズオン】FlutterとRiverpodでgRPCの双方向ストリーミングを状態管理しよう - Qiita
DeNA 24卒 Advent Calendar 2023 13日目の記事です。 DeNA 24卒の@Funobuです。よろしくお願いします！ 最近は、「AI美少女がメンターとして、塾のような手厚い学習のサポートをしてくれる」モバイルアプリを趣味で開発しています。今回は、その時に得た知見の一部を共有します。 冒頭 前提知識 この記事では、Flutter, Riverpod, gRPCを用いた実践的な内容を取り扱います。 そのため、以下の3項目を前提知識とします。 gRPCについて、その仕組みを軽く理解していること。 Flutterについて、基本的な文法やWidgetの仕組みを理解していること。 Riverpod v2について、その仕組みを軽く理解していること。 もし前提知識に関して不安がある方は、下記の記事を参考に学習してみると良いと思います。 目標 gRPCのBidirectional
gRPCの素晴らしいところと技術選択のメンタル
初めに この記事は作者の考えをまとめたポエムで、世間一般常識ではないです。 くれぐれもこれを妄信してシステム開発を行わないように。 言いたいこと やりたいのはリソースアクセスではなくrpcだったことにgRPCは気づかせてくれた gRPCのコード生成は素晴らしい 技術選択は理由をちゃんと考えたい 言わないこと 各技術の使い方 具体的な実装 開発者から見たRESTとgRPC RESTがサーバ間アクセスにルールをもたらした功績は素晴らしい。 しかし、RESTはその思想ゆえに「リソース」に縛られて使いにくく感じる。 フロントエンドからサーバのAPIを叩くとき、サーバから他のサーバを叩くときに、私がやりたいのはリソースへのアクセスではない。他のサーバのメソッドを呼びたいだけ。daoを叩いたら、サーバのコントローラーメソッドが呼ばれることを期待している。 実際にRESTクライアントを実装するときにda
【Connect/gRPC】connect-goとconnect-queryで型安全で高速なAPIを作る
はじめに Connect の学習のために簡単なタスクリストを作ったらとても学びがあったので共有します。 アプリ全体のソースコードもあるので誰かの参考になれば幸いです。 Connect とは？ Connect は簡単に言うとブラウザ・gRPC 互換の HTTP API を構築するためのライブラリ群です。 gRPC とは Google が開発した RPC 技術のことで、異なるプログラミング言語間で高速に通信するためのフレームワークです。 Connect は gRPC のメリットをそのまま引き継いでおり、Protocol Buffers で API のスキーマ定義を記述するだけでバックエンドとフロントエンドのコードを自動生成してくれます。 コードの生成が終わったらあとは型の恩恵を受けながらロジックや UI の開発に注力できます。 Connect は Go 言語だけでなく様々な言語に対応しているた
Vol.06 Connect によるスキーマ駆動開発のススメ - connect-web フロントエンド編 - Sansan Tech Blog
はじめに こんにちは、技術本部 Bill One Engineering Unit の江川です。 普段は、Bill OneでWebアプリケーション開発をやりつつ、フロントエンド周りの技術的な改善に向き合ったりしています。 今回は、バックエンド編の続きとして、フロントエンドにおけるConnectによるスキーマ駆動開発の実例を紹介できたらと思います！ なお、本記事は【Bill One 開発 Unit ブログリレー】という連載記事のひとつになっています。他の記事もぜひぜひご覧ください！ 目次 はじめに 目次 Connectを用いたスキーマ駆動開発 Connectの特徴 Protocol Buffers schemaからのクライアントコード生成 connect-webを利用する上でやったこと 前提 API Client取得用のCustom Hooks生成utilを用意する Interceptorを
次世代gRPC ライブラリConnect はいったい何が「イイ」のか？
はじめに Connect は最近注目されているgRPC のライブラリです。 web, Node.js, Go などの環境でgRPC を使うことができるようになります。 gRPC-web などでも同様のことができていましたが、Proxy サーバを立てる必要がありました。 Connect は、Proxy サーバを立てる必要がなく、gRPC の通信を行うことができます。 今回は、Connect を使ったWebアプリケーションを運用してわかった、メリットを紹介します メリット 主なメリットは下記の３点です。 Node.js, Go, Kotlin, Swift などの複数の環境でgRPC を使うことができる HTTP/1.1, HTTP/2, WebSocket などの通信を行うことができる gRPC のAPI定義から、サーバ、クライアントの両方に型定義を持ったコードを生成できる .proto フ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blazor WASM × Code-first gRPC で始める C# ⼤統⼀理論
作ってわかる！ はじめてのgRPC
Buf Schema Registry
GitHub - gendocu-com/grpc-docs
GitHub - pseudomuto/protoc-gen-doc: Documentation generator plugin for Google Protocol Buffers
GitHub - connectrpc/connect-playwright-es: Utilities for use with Playwright and Connect-ES.
REST vs gRPC vs GraphQLの自分なりのまとめと結論