SmartHRのマルチアプリケーションに分散した従業員データを集約する - SmartHR Tech Blog
こんにちは、プログラマーのkinoppydです。最近はSmartHR内でのプロダクトを横断して開発を行うプロダクト基盤チームというところで仕事をしています。 tech.smarthr.jp GraphQL集めるマンの概念図 分散したプロダクトの課題 SmartHRは、祖業である労務管理と従業員情報を集約している「基本機能」と呼ばれる巨大なアプリケーションと、その「基本機能」にある従業員情報を使い文書配布、年末調整、タレントマネジメントなどを行う小さなアプリケーション群によってサービスが提供されています。各アプリケーションは完全に独立したリポジトリとデータベースを持っており、「基本機能」とのデータのやり取りには公開・非公開のREST APIを利用しています。 SmartHRのプロダクト間の構成概略図 APIで繋がれた基本機能とサービスの世界観には、一つ問題点があります。それは、複数のサービス
GraphQL実践ノウハウ/graphql-knowhow
GraphQL実践ノウハウv2 https://speakerdeck.com/sonatard/graphql-knowhow-v2 宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui…
RESTful API との比較で GraphQL API を作ることの難しさ｜qsona
上の資料でも書いてるんですが、要点を言うと以下のようなことを主張している。 API の設計手法として、以下の2つのパターンが考えられる ・Resource-based API ・Usecase-based API Usecase-based というのは要はクライアントの要求にそのまま沿った形で API を作るということだ。しかし、UI やその他クライアントの要求というのは変わりやすいものなので、そのたびにいちいち API を変更しないといけないとか、API に一貫性がなくて使いにくいとか、1つの endpoint で多数の要求に対処する "神API" が作られてパフォーマンスが悪化する、というような問題が起こる。 したがって、注意深く RESTful API を設計すると Resource-based になる。ここで言っている Resource というのはテーブル設計にやや近いが、そのまま
GitHub GraphQL のノードIDフォーマットが変わるらしい
弊社では Terraform GitHub Provider を使って GitHub のレポジトリ管理・権限管理などを行っているのですが、 プロバイダーが repository_id を認識してくれない問題に遭遇しました。 原因を探ってみると GitHub GraphQL API に かなり大きな変更が入ること を知ったので、メモとして残しておきます。 グローバルノードID GraphQL API から扱えるすべてのオブジェクト (レポジトリ、ユーザー、etc) にはIDが振ってあります。 Using global node IDs 例えば僕 (@shogo82148) のノードIDは MDQ6VXNlcjExNTczNDQ= です。 $ curl https://api.github.com/users/shogo82148 | jq .node_id "MDQ6VXNlcjExNTcz
TypeScript * GraphQLのバックエンド設計プラクティス
2冊目も公開中なのでみてください！ https://zenn.dev/tatta/books/4e993c596e7dc9 TypeScriptを使いはじめて1年になるので、バックエンドのWebアプリを設計するときに気を付けていることをまとめました。（※社内勉強会用資料の公開版です。） TypeScriptについては、Next.jsを中心にフロントエンドに関する公開情報が豊富です。一方でバックエンドに関する公開情報が少ないと感じています。（かくいう私もNext.jsからTypeScriptデビューしたわけですが） TypeScript * GraphQL という構成は仕事・趣味で採用されている方も多いのではないでしょうか？ 私もその1人です。私のような方のためにも、バックエンドの設計プラクティスについてまとめようと思い筆を取りました。 本書がこれから始める読者にとっては教科書のようになり、
RustでProtocol BuffersからGraphQL BFFを自動生成してみた知見 | Wantedly Engineer Blog
Wantedlyでインターンをしている遠藤です。インターンのタスクとして「RustでProtocol BuffersからGraphQL BFFを自動生成する」という技術検証を行ったので、その知見を共有したいと思います。 今回の技術検証で作成したツールのソースコードはここにあります: EXPERIMENTAL] Generate GraphQL schema and gateway from Proto definitions. Licensed under either of Apache License, Version 2.0 or MIT license at your option. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in
On GraphQL-to-SQL
GraphQL has a reputation for its N+1 problem which can often happen when implemented naively. This leads to a lot of us trying to solve the issue of data fetching with GraphQL in the most efficient way possible. Besides the popular Dataloader approach, another very common way of tackling this problem is by taking a GraphQL query, and coming up with the exact SQL needed to resolve it: // example fr
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/
RustでGraphQLやってみるその1(導入編) - 虎の穴ラボ技術ブログ
こんにちは、とらラボのY.Fです。 先日、こんな記事を書きました。 toranoana-lab.hatenablog.com 本を読んだだけでは寂しいので、実際に作ってみたいと思います。 今回の記事では導入編として、DBなどを利用しないGraphQLサーバーを立ててみようと思います。 ちなみに、著者はRust初心者に毛が生えたような感じなのでツッコミも歓迎です！ 環境 今回メインで使うものは以下のようになります。 rustup 1.12.1 Rust本体とツールチェインをインストールするためのツール Rust 1.42.0 言語本体 actix-web 2.0系 Webフレームワーク juniper 0.14.2 Rust用GraphQLライブラリ GraphQLサーバーを作る ということで、作って行きたいと思います。 rustupを使った言語のインストールなどは割愛します。 rustup
React HooksとGraphQLで社内レガシーサービスを巻き取ってみたらものすごくはかどった話
New Network Provisioning System Leveraging Kubernetes and Cloud Native Open Source
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NestJSでスケーラブルなBFFを構築。メルカリShopsエンジニアがGraphQL活用のリアルを語る【技術選定の裏側：GraphQL編 vol.2】 | IT/Webエンジニアの転職・求人サイトFindy – GitHubからスキル偏差値を算出
API設計が楽でコア業務に集中できるように。GraphQLで開発がどう変わったか？タクシーアプリGOの中の人に聞きました【技術選定の裏側：GraphQL編 vol.1】 | IT/Webエンジニアの転職・求人サイトFindy – GitHubからスキル偏差値を算出
GraphQLとの向き合い方2022年版
GraphQL Highway
GitHub - Quramy/gql-study-workshop