STORES でエンジニアをしている片桐です。 STORES では店舗運営に関するさまざまなプロダクトを提供しています。これらのプロダクトは元々別の会社で運営されてきた完全に異なるプロダクト群で、アカウント体系から全く異なるシステムになっていました。近年はこれらのシステムを本格的に統合する取り組みを進めてきており、その中で統合のためにいくつかのシステムが新たに作成されてきました。 ある程度統合が進み、うまくいったところ・いかなかったところが見えてきた中で、これまでに作ったシステムの技術選定・システムの役割に対する課題感が見えてきました。 現在弊社ではこの課題を解決していくプロジェクトを進めています。その中の1つで、Goで作られたシステムをRuby on Railsで作られたシステムに移植する作業を行なっているので、今回はそれについて紹介させていただきます。 移植元のシステムの課題 今回別シ
GraphQLスキーマを共通言語にするための食べログノートの実践 - Tabelog Tech Blog
目次 目次 はじめに 食べログノートの開発体制 保たれていた秩序 GraphQLを導入した背景 クライアント要求への柔軟性の向上 並行開発を促進する、スケーラブルな開発体制の確立 専任の管理者不在でGraphQLを運用 開発拡大で露呈したスキーマ運用の課題 レビューコストの増大 スキーマに対する認識のズレ クライアントサイドの実装都合のスキーマ サーバーサイドの実装都合のスキーマ スキーマを「チーム間の共通言語」にする 「疎結合」と「密なコミュニケーション」 密なコミュニケーションを促進するための取り組み 開発初期段階からの共同参画 設計思想を問うスキーマレビュー 共通言語がもたらした組織的な効果 チーム間の認識統一 サービス理解の向上 みんなで育てるという意識 おわりに はじめに こんにちは。食べログ開発本部アプリ開発部の小嶋です。 「食べログノート」という飲食店運営者向けのオンライン予
概要 初めまして、CTO室のいがにんこと山口(@igayamaguchi)です。一休.com/Yahoo!トラベルのフロントエンドの開発を担当しています。 この記事ではWebアプリケーションのフロントエンドの画面実装をボトムアップに実装することのメリットと、その方法を紹介します。 ボトムアップに画面を実装する ボトムアップに画面を実装する、というのは小さなコンポーネントや処理から実装をしていき、それを組み合わせて徐々に大きなコンポーネントを作り、最終的に画面を作る実装方法です。 昨今のWebアプリケーションの実装で使用するReactやVueといったフレームワークはHTML、CSS、JavaScriptなどをディレクトリ、コンポーネントとしてまとめて実装することができます。この機能を利用し、 input、ボタンといった小さなコンポーネントを作成 上記のコンポーネントを使用しさらに大きなコンポ
Getting Started with Apollo MCP Server for any GraphQL API | Apollo GraphQL Blog
Blog /Announcement /Getting Started with Apollo MCP Server for any GraphQL API Back to Blog May 15, 2025Getting Started with Apollo MCP Server for any GraphQL API As a developer, you’re likely familiar with the challenges of integrating AI systems into your existing infrastructure. This might have entailed implementing your own custom integration, or using framework like LangChain. These approache
株式会社ヘンリーでオブザーバビリティを担当しているsumirenです。 先日のHoneycombでスパンを削減する - 株式会社ヘンリー エンジニアブログ という記事で、スパン削減にはトレースカットとトレース横断の2つのアプローチがある話をしたうえで、トレース横断での削減について紹介しました。 この記事ではトレースカットでの削減についてヘンリーでの事例を紹介します。 スパン削減の戦略（再掲） 前の記事でも紹介したとおり、スパン削減には大きく2つの方向性があります。（アプリケーションを直す以外） トレースカットでのアプローチ トレースカットでサンプリングする 例：正常なトレースは1%だけサンプルする、無料ユーザーのトレースは1%だけサンプルするなど トレース横断的なアプローチ スパン種類ごとにドロップの条件をつける 例：SET TRANSACTIONのスパンは正常かつ高速ならドロップする こ
ADRで意思決定し、そのADRを破棄して新しくADRを作成する実例を紹介します - GraphQLクライアントのキャッシュアルゴリズム変更編 - ROUTE06 Tech Blog
ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。2025/03/26 に、Findy Tools さん主催の「実例！フロントエンドの技術選定とその後を ADR から振り返る」というイベントで登壇します。 発表タイトルは「チームの性質によって変わる ADR との向き合い方と、生成 AI 時代のこれから」の予定です。サイボウズ株式会社の @sakito さん、ファインディ株式会社の @puku0x さんとパネルディスカッションも行います。オンラインのイベントなので、ぜひお気軽にご参加ください！ findy-tools.connpass.com 発表に先立ち、私が関わったプロジェクトで運用していた Architecture Decision Record(ADR) のマークダウンファイルをできるだけそのままの形で公開します。 私は ADR を「意思決定をアップデートするた
はじめまして、一休でプロダクト開発・技術広報を行っている山本（@kymmt90）といいます。 今回は「一休.comレストラン」のバックエンドのRust移行の取り組みについて、バックエンドを中心に、背景や現在の移行状況をお伝えします。 なぜRustを選定したのか？サービス概要「一休.comレストラン」は、上質なレストランを対象に店舗や食事コースの検索、詳細情報の閲覧、Web予約機能を提供するサービスです。2006年にローンチされ、従来はPython・C#・VBScriptといった技術スタックを用いたシステム構成となっていました。 選定背景5年以上Pythonを中心にサービスを開発／運用してきましたが、コロナ禍や開発チームの再編成を経て、既存のコードベースのままだと事業の要求に沿った開発や運用が難しくなってきたという課題がありました。 そこで、サービスのUI自体の刷新を含めリライトしていくとい
GigaViewer内部解説！アプリとWebをつなぐ技術！ #GigaViewer - Hatena Developer Blog
こんにちは、はてなで GigaViewer for Web とバックエンドを開発している id:cateiru です。 この記事は『Inside GigaViewer for Apps』連載の第4回目です。ここまではアプリを中心に連載していましたが、今回は Web とアプリの両方で使用しているバックエンドについて、複数サービスとアプリを支えるしくみを紹介していきます。 GigaViewer のバックエンド構成 マルチテナントにする理由とメリット課題 アクセス数のピークはサービスによって分散する 機能を横展開しやすい システム障害が発生すると全サービスに影響しうるという課題 サービスごとにある固有機能と出し分け Feature を使用して機能を出し分けるさまざまな方法 開発環境でのみ Feature を有効化する WIP Feature 終わりに GigaViewer のバックエンド構成 G
こんにちは、estieでソフトウェアエンジニアをしている木村です。 今回は私がテックリードを務めている「estie 物流リサーチ」というプロダクトにおいて、RESTからGraphQLに「迅速」かつ「安全」に移行した話をします。 移行のタイムラインとしては以下の通りで、既存の開発も進めつつ二人のメンバーで約2.5ヶ月という期間で完全に移行することができました。 2024/08/14 移行の計画と開始 2024/10/31 GraphQLへの完全切り替えの完了 2024/11/21 移行後の片付けの完了 今回はいかにして少人数で安全に素早く移行できたかについてその工夫を紹介していきます。 なぜ移行したのか？ 「estie 物流リサーチ」は社内では DaaS（Data as a Service）と呼ばれており、物流施設の情報を良い感じに検索・表示・分析するためのアプリケーションです。 物流リサー
Reactはシンプルなサイトから複雑なアプリケーションまで、非常に幅広く採用されている人気のフレームワークです。OSS化から10年以上の歴史がありながら、昨今もReact Server Componentsなど革新的なアイディアを我々に提案し続けています。 一方で、React Server Componentsへの批判的意見やBoomer Fetching問題などを見ていると、Reactチームと一部Reactユーザーの間には意見の相違が見て取れます。この意見の相違はそれぞれが置かれた状況の違いから生じるもの、つまり「見てる世界が違う」ことに起因してると筆者は感じています。 本稿では「Reactチームの見てる世界」を歴史的経緯を踏まえながら考察し、Reactの根本にある思想やコンセプトに対する読者の理解を深めることを目指します。 要約 ReactはMetaの大規模開発を支えるべく開発され、シ
Amazon Aurora バージョンアップについて、改めて理解する ～バージョンアップ手法と文字コードへの影響～
Flutter x GraphQLで大変革！求人アプリのアーキテクチャ刷新秘話 - Techouse Developers Blog
はじめに はじめまして、ジョブハウスでエンジニアリングマネージャーをしているhira22です。Techouseには2023年に入社し、ジョブハウスのモバイルアプリ開発を担当してきました。 2023年10月にリリースしたジョブハウスアプリは、FlutterとGraphQLを組み合わせたモバイルアプリとして開発を進めています。ユーザーが手軽に求人情報を検索・応募できるように毎月機能を追加しながら、成長を続けてきました。 この記事では、アプリをさらに速く改善しやすくするために実施した「アーキテクチャの変更」について紹介します。ジョブハウスアプリの技術スタックや主要なパッケージについては以下に列挙しますが、詳細な説明は省略します。ここでは「なぜアーキテクチャを変える必要があったのか」「旧アーキテクチャと新アーキテクチャはどのように違うのか」を中心にお伝えします。 Flutter: https://
2025 is the year of GraphQL error handling!Lots of exciting things are happening in the GraphQL space this year! Happy new year everyone! 🎉 You may not have noticed it yet, but something big has happened on January 1st 2025… GraphQL servers are now required to support the application/graphql-response+json content type 🎉! (PS: At least according to the current GraphQL over HTTP draft) From 1st Ja
バクラク事業部エンジニアの id:itkq です。ラブライブ！全国決勝大会プレーオフが迫り、緊張感が続く日々を送っています。 最近私はバクラク勤怠のSlack連携関連機能を開発しています。この記事では、Slack連携のアーキテクチャについて紹介します。 バクラク勤怠とは バクラク事業部では、これまでバクラク請求書受取をはじめとするBSM (Business Spend Management / 法人支出管理) 領域のサービスを複数リリースしてきました。お客様のお話を伺うなかで、勤怠サービスへの期待の声を多く頂いたことをきっかけに、開発することが決まりました。 comemo.nikkei.com これまでのバクラクシリーズ同様、従業員・管理者両方の体験についてこだわり抜いた勤怠サービスを目指しています。 Slack連携 バクラク勤怠の特徴として、Slack連携が挙げられます。Slack経由で
どうも、トラハックこと、toraco株式会社の稲垣です。 複数のバックエンドを抱えるプロダクトにおいて、Next.js ( App Router ) 製 の Web アプリケーションを新規開発するにあたり、Route Handlers による BFF と、クリーンアーキテクチャを取り入れることで、バックエンドに依存しないクライアント実装を実現しました。 将来的に、通信するバックエンドが増えたり、バックエンドのアーキテクチャが変更になったとしても、クライアントの実装に修正を加えることなく移行が可能です。 さらに余談ですが、一般的な設計や実装に関しては技術記事を読まなくても生成AIに任せることができてしまう現代になっているように思います。（それが "問題ない" のかは議論の余地がありますが...） なので、この記事では以下の観点を重要視して書いていきます。 アーキテクチャ選定や設計段階で考えて
これは はてなエンジニア - Qiita Advent Calendar 2024 - Qiita 15日目の記事です。昨日は id:utgwkk さんの「ISUCONの感想戦を支えるEC2の自動開始・停止、そしてAWS Step Functions」でした。 はてなでフロントエンドエキスパートをしている id:mizdra です。この記事では、JavaScript で GraphQL サーバーの技術選定をする際に、どのようなツールやライブラリがあるのかを紹介します。 というのも、JavaScript で GraphQL サーバーを作ろうと思って検索してみると、「Next.js + Apollo Server + graphql-codegen で GraphQL サーバーを作ろう！」だとか、そういう記事が多数出てきます。ただ、複数のライブラリやツールを組み合わせると作れることは分かるので
[2024年12月版] Unity Catalogセットアップガイド / Unity Catalog Setup Guide
はじめに この記事はTSKaigi Advent Calendar 2024の記事です。(TSKaigiの運営メンバーとして最初の記事になりそうです。) みなさん、TypeScript書いてますか？最近、フロントエンドもバックエンドも（加えてインフラも）TypeScriptで統一する、Full-Stack TypeScriptを採用する事例が増えてきました。 Full-Stack TypeScriptの由来やメリットはこちらの記事から フロントもバックもTypeScriptだし、どうせならMonorepoで管理しようということで、TypeScript専用のMonorepo管理ツールであるTurborepoを導入し、T3-Turboというアーキテクチャを導入することになりました。 T3-Turboというアーキテクチャは、以前導入を考えた際に記事にしているので、こちらをご参照ください。 またT
この記事は 食べログアドベントカレンダー2024 の6日目の記事です🎅🎄 はじめに こんにちは。2022年に入社し、飲食店システム開発部の予約サービスチームに所属している @aaknsk です。 当社では、業務効率化のため社内向けに生成AIを活用したチャットボットを導入しています。 この記事では、オンライン台帳の「食べログノート」で分析機能を開発したときにチャットボットを活用して効率が上がった事例について紹介します。 食べログノートとは 食べログノートはオンライン予約台帳サービスです。 食べログネット予約はもちろん、電話予約や他社ネット予約、ウォークイン(ご予約無し来店)も全て統合管理できます。 2022年4月にリリースされ現在では多くの店舗で導入されています。 食べログノートの分析機能とは 機能の目的 食べログノートの分析機能は、店舗が日々の業務で収集するデータを視覚的に分析すること
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、Watanabe Jin(@Sicut_study)です。 今回はGraphQLの初心者向けチュートリアルを行っていきます。 REST APIと肩を並べて知られるGraphQLですが、なかなかイメージがしづらく初心者には難しいものです。私も駆け出しの頃に勉強しましたが全然身につけることができませんでした。 GraphQLのクエリのイメージがしづらい DBとGraphQLをどう接続すればいいかわからない 実際にアプリケーションと組み合わせる方法がわからない このように教材をやりながら感じていました。 GraphQLはふわっとし
GraphQLのダイエット術 TypeScript Language Service Pluginで未使用フィールドをなくす
はじめに GraphQLは、API開発において柔軟性と効率性を提供する強力なツールです。しかし、クエリの記述が自由な分、クライアント側で不用意に多くのフィールドを要求してしまうと、パフォーマンス低下や保守性の悪化につながる可能性があります🥲 本記事では、TypeScript Language Service Pluginの1つであるGraphQLSPを活用し、GraphQLクエリの"ダイエット"、つまり未使用フィールドの削減を実現する方法を紹介します。 ※ この記事はTSKaigi Kansai 2024で共有した内容を記事にしたものです。 GraphQLの課題と対策 over fetching問題 GraphQLは、クライアントが厳密に必要とするデータのみを要求できるため、REST APIに比べてオーバーフェッチによるパフォーマンス低下を抑えることができます✊しかし、GraphQLでも
WebフロントエンドにおけるGraphQL（あるいはバックエンドのAPI）との向き合い方 / #241106_plk_frontend
WebフロントエンドにおけるGraphQL（あるいはバックエンドのAPI）との向き合い方 / #241106_plk_frontend
株式会社ハウテレビジョン様で、 質問箱サービスMondのパフォーマンス分析と改善を行いました。 内容としてはLCPの内訳の計測、その解決方法の提案、そして一番大きな問題だった GraphQL リクエストの最適化という話になります。 現時点で全ての問題の修正には至っていませんが、開発的には全ての問題の内訳が認識可能になっていて、検証が終われば段階的にリリースできる、という状態です。 以下、敬称略 相談内容 mond.how のLighthouseスコアを改善してほしい 主要な技術構成 Next.js - Page Router Hasura CE - GraphQL Server Hasura のセルフホスティング版 計測と問題 最近は Chrome が出してくれる Lighthouse スコアの推移が見れるダッシュボードがある。 ここで Mond の直近のスコアをみる。 代表例として ht
Relay v18.0.0 にて @throwOnFieldError や @catch, @semanticNonNull といったエラーハンドリングに関連する Directive が追加された。 これらの Directive の意味と活用方法をこのエントリで解説していく。 なお、今回のエントリは自分が書いた以下エントリの続編としての意味合いも含んでいる。 Relay v18 で追加された Client Side DirectiveGraphQL Erorrs をコンポーネントから扱えるRelay v18 で追加された @throwOnFieldError および @catch はクライアントサイド, すなわち GraphQL オペレーション側に記述する Directive である。 以降の解説のため、次の GraphQL クエリを題材とする。 query { book { title
React NativeとExpo RouterのRSC導入に向けたアップデートが来そう - laiso
Expo Routerとは Expo Routerは、React NativeおよびWebアプリケーション用に設計されたファイルベースのルーティングライブラリ。 docs.expo.dev RSCを活用してサーバー側でコンポーネントレンダリングとストリーミングを行う新しいSDUIの構想 "Fetch Once, Render Everywhere: React Server Components in Expo Router"はReact Summit 2024におけるExpo作者のひとりEvan Baconによる講演。 gitnation.com ここでExpoを使った新しいSDUIの構想が発表され、Reactネイティブアプリにおけるサーバー側のコンポーネントレンダリングとストリーミングが提案されてXのタイムラインが盛り上がっていた。 今クライアントがWeb APIで取得して画面に適用し
Jetpack ComposeとGraphQLによるServer Driven UI/jetpackcompose-grahpql-serverdrivernui
Tailor Technologies、ローコードフロントエンド開発基盤”fabrix”をOSSとして公開〜GraphQLカンファレンス（サンフランシスコ 現地時間9/10-12で開催）にて発表〜 業務システムを従来の10倍の速さで開発できる基盤「Tailor Platform（テイラープラットフォーム）」を提供するTailor Technologies, Inc.（本社: 米国カリフォルニア州、代表：柴田陽）は、フロントエンド向けのローコード開発基盤、「fabrix」をオープンソースとして公開し、GraphQLカンファレンス2024（サンフランシスコで9/11開催）にて発表、またGithubにオープンソースソフトウェア（OSS）として公開したことをお知らせします。 公開リポジトリ https://github.com/fabrix-framework Fabrixの開発背景 近年、ノーコ
動機 Webサーバーを書いているとしばしばRDBMSのN+1問題に遭遇する 別名ループクエリ あるレコードを取得する際に同時にこのレコードが持つ(has-oneやhas-many関係)のレコードを同時に取得するケースがある user レコードが持つ user_item 一覧を取るなど 親のレコードが複数ある場合、ナイーブな実装をするとループで回して子のレコードをクエリすることになる 大量にSQLが発行されてDBサーバー(場合によってはアプリケーションサーバーも)負荷が増大する GraphQLではこの問題が起こりがち あるresolverに属する子供のresolverが芋づる式に呼ばれる RESTfulや他のRPCサーバーの形態ではループクエリが発生する場所が比較的見えやすいが(一つのエンドポイントで解決するエンティティ一覧が決まっているため)、GraphQLでは見えにくい そこでdatal
今年のアップデートで振り返るCDKセキュリティのシフトレフト/2024-cdk-security-shift-left
このデックでは、エラーレスポンス設計から考える、プロダクトの0→1開発におけるGraphQLへの向き合い方について紹介します。 記事: 【技術選定】 0→1 の SaaS に…
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL はじめに 新たに書きました。 MySQLを使っても会社は潰れない 久々に記事を書いたのでどうぞお手柔らかに... 私が過去2年間で行った技術選定の成功と失敗を振り返り、その学びを共有したいと思います。 文才無いので淡々と箇条書きでいきます Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 注意 意見を押し付けるものではありません。ただ建設的な議論は大事だと思う。 自分の意見は明確に、歯切れのよい表現を意識している。人それぞれだよねみたいな感じに逃げたくない。技術選定に結論はある（過激）。 ただし技術選定にはコンテキストがあり、例えばプロダクトのフェーズや組織の事情によって当然結論は変わる可能性がある。 OSSの開発者さん達は偉大ですごい。あ
ジャンプTOON Next.js App Router の活用〜得られた恩恵と課題〜 | CyberAgent Developers Blog
目次 はじめに Colocation を意識した設計方針 Parallel Routes と Intercepting Routes を用いた設計パターン サーバー側に処理を寄せたことによる恩恵と課題 Next.js が抱える課題 おわりに 参考文献 はじめに ジャンプTOON のWeb版（以降、ジャンプTOON Web）の開発を担当している浅原昌大（@assa1605）です。 5 月にサービスを開始した「ジャンプTOON」は、オリジナル縦読みマンガ作品や人気作品のタテカラー版を連載する、ジャンプグループ発の新サービスです。 ジャンプTOON のフロントエンドには、Next.js を採用し開発をしています。 本記事では、Next.js の最新機能や設計パターン、Next.js を採用した恩恵と現在の課題について紹介します。 Colocation を意識した設計方針 Parallel Rou
gql.tada に graphql-code-generator から移行した話 - Gaudiy Tech Blog
こんにちは。ファンと共に時代を進める、Web3スタートアップのGaudiyでエンジニアをしているkodai（@r34b26）です。 Gaudiyでは、以前からフロントエンド(Next.js)とGateway(Node.js)の通信においてGraphQLを使用しています。 techblog.gaudiy.com その際に、GraphQLスキーマからコードを自動生成するツールとしてGraphQL-Codegenを活用してきましたが、開発者体験やユーザー体験においていくつかの課題を抱えていたため、今回、gql.tadaに移行しました。 この記事では、課題背景から実際の移行プロセスを紹介してみるので、gql.tadaが気になっている人やGraphQLの運用に課題感のある人の参考になれば嬉しいです。 1. GaudiyとGraphQL 2. GraphQL-Codegenにまつわる課題 3. gql
Server Actions で経費削減できた話
はじめに 個人開発にて、App Routerのフロントエンドとkotlin / Spring Boot / REST APIのサーバーサイドで構築されるシステムを2022年くらいから運用していました。機能的には問題なく使えていたのですが、如何せんAWS / EC2 上にNginx, Tomcat, RDBを立てているため、初年度無料枠で使用できても2年目からは月々2000~3000円ほど利用料が発生していました。 どうにかいい方法はないかと模索していたら、Server Actionsが使えるのでは？ということで思い切ってサーバーサイドを刷新することにしました。 以下は、この刷新を受けて得られたメリット・デメリットです。 メリット 今回採用した環境ではすべて無料なので、サーバー使用量がまるッと浮いた。（2024/08/13時点） kotlin のお守りがなくなり、TypeScriptのみの改
ジャンプTOON Web アプリケーションの全体像〜採用技術と開発方針〜 | CyberAgent Developers Blog
目次 はじめに Next.js × GraphQL のサーバー間通信 Fastly でのコンテンツ配信とキャッシュ方針 vanilla-extract の採用とスタイリングシステム Chromatic による UI テスト / UI レビュー Datadog でのサービスモニタリング ジャンプTOON の CI/CD リリース戦略とブランチ運用の工夫 おわりに はじめに ジャンプTOON の Web 版（以降、ジャンプTOON Web）の開発を担当している2024年度新卒入社の鏑木 俊樹（かぶらき としき） @tosssssy_ です。 5 月にサービスを開始した「ジャンプTOON」は、オリジナル縦読みマンガ作品や人気作品のタテカラー版を連載する、ジャンプグループ発の新サービスです。 ジャンプTOON Web では Next.js App Router （v14.2）を採用して開発をしてお
App Router で1年間開発した知見と後悔
Next.js の App Router を 1 年間使用した経験をもとに僕なりの知見と後悔したことを共有しようと思います。 データフェッチング戦略（知見） App Router では RSC 内でのフェッチのため分離しづらいです。なおかつ、以前より柔軟にサーバー側の処理を書けるため、より多くのコードが集まり肥大化しやすいです。 したがって Pages Router と比較して以下のような違いがあります。 Pages Router(SSR) App Router(RSC によるフェッチ) この違いにより、App Router ではデータフェッチのロジックを自身で抽象化する必要性が高まっています。 ベンチャーでは Next.js にすべてのロジックをもたせて、スピード感のある開発をしたい場合があります。それがメインのプロダクトの場合、将来的には肥大化を解消するために API サーバーを実装す
ジャンプTOON Flutter × GraphQL ~宣言的なアプリ開発の工夫~ | CyberAgent Developers Blog
ジャンプTOON アプリチームの吉田航己(@koki8442)です。 5 月にサービスを開始した 「ジャンプTOON」 では、モバイルアプリを Flutter で開発し、通信には GraphQL を用いています。 本記事では GraphQL の解説、Flutter アプリで GraphQL を活用する際の工夫点や開発の知見を紹介していきます。 目次 GraphQL の概要 ジャンプTOON アプリでの GraphQL の使用 Flutter で GraphQL を使うメリット Flutter × GraphQL 開発の工夫 おわりに 参考文献 GraphQL の概要 GraphQL は Meta 社が REST の問題点を解決するために開発した API クエリ言語およびランタイムです。その概念は特定の言語やデータベースなどに依存するものではなく、ビジネスドメインのデータを Node と E
GitHub - webpod/graphql-megaera: GraphQL to TypeScript Generator
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
この記事は LayerX のエンジニアブログがたくさん出る #ベッテク月間 の8記事目になります。こちらのカレンダーに、これまでの記事と今後出る予定がまとまっています。 LayerX のバクラク事業部には GraphQL Gateway というバクラク全プロダクトから参照される GraphQL スキーマが存在します[1]。今回の記事は、その GraphQL Gateway のスキーマをより良い状態にしていくためにぶつかった課題を強引に突破したときの話です。 モチベーション GraphQL スキーマの破壊的変更によって GraphQL Document がスキーマに適合しなくなる場合、そのリクエストはエラーになります。例えば以下のようなケースが考えられます： 使わなくなったフィールドを削除したい 削除されたフィールド（存在しないフィールド）を含む Document を処理することはできない
マルチプロダクト戦略の実現を目標として掲げ、急速にプロダクトを増やしているSmartHR。 そのような中、これまでプロダクトごとに分断されていたデータを相互に利用できるようにすることで、価値を高める試みが始まっています。この活動の中心となっているプロダクト連携ユニットに、現状と今後の展開を聞いてみました。 インタビューの様子。左：プロダクト連携ユニット 右：インタビュアー f440： それでは、プロダクト連携ユニットのインタビューを始めたいと思います。よろしくお願いいたします。 一同： よろしくお願いします。 f440： お時間を取っていただきありがとうございます。突然呼ばれてびっくりしていると思うんですけれども、個人的に一番興味あったのがプロダクト連携ユニットだったので、この度はインタビューしたいと思いまして。 最初に自己紹介から始めさせてください。まずは私から。現在プロダクト基盤開発部
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Goで作られたシステムをRuby on Railsに移植しています - STORES Product Blog
フロントエンドの画面実装をボトムアップに行う - 一休.com Developers Blog
エンドポイントカットのトレースサンプリングを提案したい - 株式会社ヘンリー エンジニアブログ
一休における C#,PythonからRustへの移行の現状と見えてきた課題
RESTからGraphQL への迅速かつ安全な移行 - estie inside blog
Reactチームが見てる世界、Reactユーザーが見てる世界
もし今からGraphQLを採用するなら
2025 is the year of GraphQL error handling!
バクラク勤怠におけるSlack連携のアーキテクチャ - LayerX エンジニアブログ
Next.js App Router から複数バックエンドを扱うための BFF + クリーンアーキテクチャ戦略
JavaScript で GraphQL サーバーの技術選定をする際の登場人物 - mizdra's blog
テーブルが200以上あるSaaSでRSCとGraphQLを併用する理由
Full-Stack TypeScriptの最終到達点、T3-Turboで新規開発した話
生成AIを使ったらAPIの開発が捗った話 - Tabelog Tech Blog
【図解解説】これ1本でGraphQLをマスターできるチュートリアル【React/TypeScript/Prisma】 - Qiita
GraphQL BatchでクライアントN+1を無理矢理倒す (事例紹介:株式会社ハウテレビジョン様)
Relay v18 の throwOnFieldError と GraphQL Nullability
Iteratorでページネーションを実現する
Tailor Technologies、ローコードフロントエンド開発基盤”fabrix”をOSSとして公開
iter.Seqを非同期解決して普通のRESTfulでもdataloaderが使えるようにできないか
GraphQL あるいは React における自律的なデータ取得について
エラーレスポンス設計から考える、0→1開発におけるGraphQLへの向き合い方
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL
GraphQL 界の Babel こと Envelop を使ってスキーマの破壊的変更をごまかす
マルチプロダクト間データ連携への技術的挑戦 - SmartHR Tech Blog