技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL はじめに 新たに書きました。 MySQLを使っても会社は潰れない 久々に記事を書いたのでどうぞお手柔らかに... 私が過去2年間で行った技術選定の成功と失敗を振り返り、その学びを共有したいと思います。 文才無いので淡々と箇条書きでいきます Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 注意 意見を押し付けるものではありません。ただ建設的な議論は大事だと思う。 自分の意見は明確に、歯切れのよい表現を意識している。人それぞれだよねみたいな感じに逃げたくない。技術選定に結論はある（過激）。 ただし技術選定にはコンテキストがあり、例えばプロダクトのフェーズや組織の事情によって当然結論は変わる可能性がある。 OSSの開発者さん達は偉大ですごい。あ
技術選定の成功 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL
技術選定の成功 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL 技術選定に失敗はない 技術選定に失敗はありません。 仮説を立て、検証し、結果の分析からNext Actionを考える。検証の結果がどうであれ、それは過程に過ぎません。 机上の空論だけで全てを理解できるほど、我々人間は賢くないのです。（注意: これは人類全体を誹謗中傷する意味ではありません。） この記事では、この２年間で行った技術選定の成功例をその理由と共に紹介していこうと思います。 申し訳遅れましたが、私、YadaYadaKonnanYadaといいます。私は今回初めて記事を書いたので、どうぞお手柔らかに。 Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 前提 技術選定に結論はありません。組織毎に前提が違うのだから当然のことです。みんな違っ
GraphQL「良さ」・「難しさ」再探訪 〜スタディサプリにおける実例〜 / StudySapuri with GraphQL
2024/02/08 に「LayerX、スタディサプリ、SHEと考える GraphQLが向いている現場とは？運用実践LT」で、内山高広( @highwide )が発表した資料です。 #Offers_GraphQL実践LT
GraphQL is an incredible piece of technology that has captured a lot of mindshare since I first started slinging it in production in 2018. You won’t have to look far back on this (rather inactive) blog to see I have previously championed this technology. After building many a React SPA on top of a hodge podge of untyped JSON REST APIs, I found GraphQL a breath of fresh air. I was truly a GraphQL h
Backend エンジニア視点からの GraphQL / GraphQL from a perspective of backend engineer
"LayerX、スタディサプリ、SHEと考える GraphQLが向いている現場とは？運用実践LT" で登壇した資料です。 引用した資料 [Rails アプリに RESTful API のレールを敷いて生産性が大きく上がった話 | Wantedly Engineer Blog](https://w…
Next.js の App Router が安定版となり、React Server Components (以下 RSC) を実際に試す環境が整ってきた。 実際、今年はやれどこそこのプロダクトが Next.js を採用しただのやっぱり捨てだのといった話題が尽きなかったように思う。 かくいう自分自身も、今年は App Router の案件に取り組んで RSC と格闘する日々を送っていた。 その過程で、こんなようなことを考えるようになったので、今回はこの辺りの話を書き残しておこうと思う（何回か X に同じ旨の POST は上げていたけど、一回もちゃんとまとめてなかったので）。 RSC がない頃の、別の言い方をすると getServerSideProps を使っていた頃の、Next.js におけるアプリケーションの設計は、トラディショナルな MVC にかなり近しい。 ここでいう MVC は、Sp
はじめに こんにちは、retail HUBで Software Engineer をしているほんだです。 今回は私が現在着手している事業譲渡されたアプリを社内で持続的なプロダクト開発を行える状態にするリプレイスプロジェクトをどのように行っているか紹介しようと思います。 この記事ではリプレイスを行うにあたってどのようなことを課題に感じてその課題に対してどのような解決策をとったか主にサーバーの実装について説明しています。 ネットスーパーアプリとは 現在弊社ではネットスーパーアプリとして Web アプリとスマホアプリの二つのシステムを提供しています。 Web アプリは販促コンテンツの設定や売り上げの管理・集計を行うことが可能な管理システムと受け取り方法に応じた価格変更や送料変更にも対応し、消費者の柔軟な買い物を実現するお客様向けアプリを 17 の小売り様に、スマホアプリでは Web アプリのお客
この記事はTSKaigi2024での以下の私の発表内容を書き下ろしたものです。 なぜAPIに型をつけたいのか 現代のWebのシステム開発において、クライアント・サーバーともに型のある言語で開発されることが増えてきました。静的な型検査はコードの堅牢性やよりよいメンテナンス性の向上をもたらします。 プログラミング内部だけで型検査をするだけでも十分メリットはありますが、外部I/Oに対する型付けが不十分だとそのメリットを最大限に発揮してるとは言えません。外部I/Oとは、例えばWebフロントエンドだとLocalStorageやDOMからの入力値、それからネットワーク通信（今回はこれをAPIと呼びます[1]）などですね。サーバー側でいうとAPIからの入力・レスポンスやデータベースへの読み書きが該当します。 個人的な経験から言うと、Webシステムの開発におけるエラーの多くはAPIやデータベースとのやり取
イベント「【タイミー/Voicy/令和トラベル】Backend LT〜技術選定における“見極める力”とは〜」での登壇資料 https://reiwatravel.connpass.com/event/306794/
銀の弾丸ではないので良し悪しあるのは当然として、それを差し引いても以下の2つの要素があるのではと思った。 なんとなく使ってもメリットが十分得られない RESTでできてたことができなくなる（※ちゃんと調べればできる） なんとなく使ってもメリットが十分得られないWeb界隈は良くも悪くも新しい技術をとりあえず使ってみるところがあると思っていて、そこがGraphQLは十分に事前知識を持って導入しないとメリットが薄いところとミスマッチを起こしてネガティブな意見が出るのかなと思う。 GraphQLはもともとFacebookがReact, Relayとの組み合わせで使い始めたもので、クライアントライブラリとしてのRelayと、IDやページネーションについての追加仕様を公開している。ライブラリとしてのRelayは使わなくても仕様に乗っかることはできるのでそれをRelayスタイルと言ったりする。出典を忘れた
「2024年こそ使いこなす！GraphQL最前線」で発表した資料です。 ソニーのホームエンタテインメント領域では、TVやサウンドバー、ヘッドホンをはじめとする様々な製品、それらに付随…
GraphQL実践ノウハウv2
GraphQL実践ノウハウ https://speakerdeck.com/sonatard/graphql-knowhow 宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-grap…
GraphQL 成熟度モデルの紹介と、プロダクトに当てはめた事例 / GraphQL maturity model
2024/04/19 「tsukiji.graphql」で発表したスライドです。 https://tsukiji-graphql.connpass.com/event/314173/ 参照したURL -
Understand the mechanism! Let's do screenshots tests of Compose Previews with various variations / 仕組みから理解する！Composeプレビューを様々なバリエーションでスクリーンショットテストしよう
バックエンド視点で振り返るGraphQLを採用したプロダクト開発 - enechain Tech Blog
はじめに 技術スタック eScanチームにおけるGraphQLの使い方 開発フローの工夫 N+1問題の対応と注意点 エラーハンドリングの工夫 モニタリングの工夫 ドキュメンテーションを必須化するための工夫 その他の取り組み 振り返り 良かった点 難しかった点 今後の展望 最後に はじめに こんにちは、enechainでソフトウェアエンジニアをしている小沢です。 私が所属しているチーム(以降、eScanチーム)では、eScanという電力会社向けのリスクマネジメントシステムを開発・運用しており、その中でGraphQLを採用しています。すでにGraphQLを採用するメリット・デメリットについて様々なところで語られていますが、eScanチームでもオーバーフェッチが解消できる点、1リクエストで必要なデータをフェッチできる点などのメリットを享受するために採用しています。 今回は実際にGraphQLを採
Signed Query は GraphQL の Trusted Document の新しい実装パターンです - スタディサプリ Product Team Blog
こんにちは。スタディサプリの小中新規開発チームで Web エンジニアをしている @YutaUra です。 去年の４月に新卒で入社をしまして約 1 年が経ちました。インターン生時代にもブログを書いているのでご興味あれば合わせてご覧ください。 GraphQL と Persisted Query スタディサプリ小中講座ではデータ通信に GraphQL を採用しています。 GraphQL を利用することで、クライアントはスキーマに定義された範囲で自由にデータを取得することができます。 query GetUser { user { name age } } また、 GraphQL はデータのグラフ構造に基づいて関連する複数のデータを一度に取得することができます。 query GetUser { user { name age posts { title content } } } GraphQL の
Practical Tips and Tricks to Improve Your Compose Previews (Android Worldwide July 2024)
graphql-code-generator から gql.tada に移行した話 - 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
このデックでは、エラーレスポンス設計から考える、プロダクトの0→1開発におけるGraphQLへの向き合い方について紹介します。 旧タイトル: 「TypeScriptとGraphQLを活用した変化に強いプロダクト作り」。2024年9月9日(月) に更新しました。
GraphQL is for Backend Engineers | Apollo GraphQL Blog
Most articles explaining the benefits of GraphQL focus on advantages for the frontend: things like preventing overfetching, reducing round trips, and iterating faster. But GraphQL provides just as many advantages for backend developers, which is why I choose it by default for new APIs and why you should consider it, too. Improved communication The goal of building any API is to enable someone to u
GraphQLのスカラーとTypeScriptの考察
皆さんこんにちは。筆者は最近、TypeScriptからGraphQLを使用するためのコード生成ツールnitrogqlを開発しています（初手宣伝）。 直近は、GraphQLのスカラーに関する機能拡張を行っていました。この記事では、そこで得た知見と考察について共有します。 GraphQLのスカラーとは GraphQLにおけるスカラーとは、それ以上分解できないデータ型のことです。GraphQLのデータはスカラー・オブジェクト・enumに分類でき、データの末端はスカラーまたはenumになります。 GraphQL仕様では組み込みのスカラー型が定義されており、以下のものがあります。 Int Float String Boolean ID また、カスタムスカラーとして、追加のスカラー型をスキーマ上で定義することもできます。 スカラー値がサーバー・クライアント間でやり取りされるときはシリアライズする必要が
Why, after 8 years, I still like GraphQL sometimes in the right context
A recent post, Why, after 6 years, I’m over GraphQL, made the rounds in the tech circle. The author argues that they would not recommend GraphQL anymore due to concerns like security, performance, and maintainability. In this post, I want to go over some interesting points made, and some points I think don't hold up to scrutiny. Always be Persistin' Ok, first of all, let's start with something may
GraphQLサーバの構成要素を整理する #ハッカー鮨 #tsukijigraphql / graphql server technology selection
tsukiji.graphql x ハッカー鮨 https://tsukiji-graphql.connpass.com/event/314173/
GraphQLとは何か？ イメージを掴む
はじめに 今回の記事ではGraphQLについて、公式などを参考にしながら基本的なことをまとめてみました。 自分自身GraphQLのキャッチアップを始めるときに こんなこと知っときたかったなあ、ということをまとめたので これからGraphQLの勉強を始める方や興味のある方はよかったら読んでみてください。 大枠を掴むことをイメージして書いており、深い部分の説明を省いている箇所もあるので その点はご了承ください。 そもそもGraphQLとは？ GraphQLはAPIのクエリ言語です。 クエリ言語というとSQLが有名ですが、SQLがデータベースに対してクエリを実行するのに対し、 GraphQLはAPIに対してクエリを実行します。 ちなみに、プログラミングにおけるクエリとは データに対する問い合わせや要求などを一定の形式で文字に表現すること、 要は所定の形式で対象のデータにやりたいことを伝えること、
BARフロントえんどう #1 「フロントエンドリアーキテクト」で使用した資料です！ https://cybozu.connpass.com/event/297123/
この記事は LayerX のエンジニアブログがたくさん出る #ベッテク月間 の8記事目になります。こちらのカレンダーに、これまでの記事と今後出る予定がまとまっています。 LayerX のバクラク事業部には GraphQL Gateway というバクラク全プロダクトから参照される GraphQL スキーマが存在します[1]。今回の記事は、その GraphQL Gateway のスキーマをより良い状態にしていくためにぶつかった課題を強引に突破したときの話です。 モチベーション GraphQL スキーマの破壊的変更によって GraphQL Document がスキーマに適合しなくなる場合、そのリクエストはエラーになります。例えば以下のようなケースが考えられます： 使わなくなったフィールドを削除したい 削除されたフィールド（存在しないフィールド）を含む Document を処理することはできない
「攻撃者の視点から見たGraphQLのセキュリティ」というタイトルで登壇したのは、kuzushiki氏。「おもしろかった脆弱性」について解説し合い、脆弱性に関する知識を深めるためのイベント「Security․Tokyo #2」で、「GraphQL」の機能による悪用と、対策について発表しました。 登壇者の自己紹介 kuzushiki氏：それでは、発表を始めていきたいと思います。 まず簡単に自己紹介をさせてください。私は、kuzushikiと申します。現在、とあるセキュリティベンダーで診断員をやっていて、主にWebアプリケーションの脆弱性診断をしています。最近、バグバウンティに興味を持って、そういうものをちょっとやってみています。 “開発者フレンドリー”という特徴を持つ「GraphQL」 今回は「GraphQL」について話しますが、その前に、もうGraphQLを知っているよという方は、どのぐら
Kaggle Tokyo Meetup2023 CommonLit Solutionの紹介と考え方 - Fulltrain戦略と(Seed/Model)Ensembleの可視化 -
GraphQL Schemaの破壊的変更をCIで検知する
ここ数年、私はGraphQL APIサーバーの開発を行っています。GraphQLは柔軟かつ強力なAPIクエリ言語で、Webフロントエンドからモバイルアプリなどいくつかのクライアントがそれぞれ画面に必要なデータをフェッチしており、フロントエンドの開発パフォーマンスが向上しました。 破壊的変更の問題 私のチームではGraphQLサーバーはRailsとGraphQL Rubyを用いてCode First[1]で開発しています。 しかし、複雑性が増すにつれてクライアントやクエリの全体像を把握できずに破壊的変更を引き起こすこともあり、その変更が既存のクライアントに影響を与えないように注意深くSchemaを管理する必要があります。 実際に最近、fieldやmutationの引数の変更がクライアントに不具合をもたらす事態に発生しました。 破壊的変更の検知 そもそもGraphQLは仕様が網羅されているSc
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
はじめに 今回はタイトルの通り、「GraphQLは「オワコン」「流行らない」のか？」という問に対して、個人的に調査した内容となります。 今回のタイトルで記事を書くことにしたのは、Googelの検索フォームに「GraphQL」と入力したところ、サジェストに「Graphql 流行らない」「Graphql オワコン」と表示されたことがきっかけです。 (試しにシークレットモードで入力してもサジェストされるので、私の検索履歴などのパーソナル情報によるバイアスはかかっていないはずです) 「Graphql オワコン」での検索結果TOPに「GraphQLはオワコンですか?これからはtRPCの時代ですか?REST APIの位置づけは何ですか?」というページがあったので読んでみました。 回答者はNodejsユーザグループ代表の古川さんで「GraphQLをオワコンと称するにはまだ早い」と回答されています。 私も
SaaS開発でもGraphQLを使いたい！
SaaSパーティショニングモデル まず、SaaS環境でテナントデータを分割するときには、一般的に使用される3つの基本モデル (サイロ、ブリッジ、プール) があります。 AWSでのマルチテナントストレージモデルの構築より 3つのモデルの詳しい解説については、ここ数年で多くの記事/議論が上がっており、ここでは詳しく解説しませんが、SaaSというビジネスモデル上カスタマイズ性と引き換えにコスト面/生産性を優先してプールモデルを選択することが多く、弊社でも同じくプールモデルを採用しています。 またプールモデルを実現するためのデータベース戦略として、OSSのDBの中ではPostgreSQLのRLS(Row Level Security)機能が唯一の選択肢であり、実質的にデファクトスタンダードとなっています。(OSSではないがOracleやSQLServerでもRLS機能を有している。) GraphQ
ユビーではNestJSでGraphQLのサーバー実装をおこなっています。今回は実践で得られた知見を元にNestJSでGraphQLのResolverに対してGraphQLのスキーマから生成したTypeScriptの型を適用する方法について解説します。 前提としてNestJSにはスキーマファーストとコードファーストがありますが、今回はスキーマファーストで書いたうえで、スキーマから型を生成するアプローチを紹介します。 NestJS組み込みの型生成を使う NestJSのスキーマファーストのアプローチではNestJSの組み込みの機能でスキーマからTypeScriptの型を生成することができます。 以下のように書くことで、 graphql.ts に型が生成されます。 GraphQLModule.forRoot<ApolloDriverConfig>({ driver: ApolloDriver, t
上記は、idとnameそしてroomをプロパティとして持つ、Hotelの型です。 nameが文字列型の必須のプロパティであり、roomというオブジェクトを複数持つことが簡潔に定義できます。 ちなみに、Roomの型は以下のように表現できます。 SDLは非常にシンプルで簡潔であるため、どのような言語を扱う技術者や非技術者でも理解しやすく、チームの枠を超えて、組織のデータモデルを定義するためのドキュメントとして機能します。 一方、欠点として、SDLにはfieldの値を計算して返すResolverの実装が含まれていません。 GraphQLを機能させるためには、何らかの言語でResolverの実装を追加で行わなくてはならず、GraphQLのみをSingle Source of Truthとすることはできません。 Code First Code Fistは、開発者はResolverだけを書くのみでよく
ジャンプ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
はじめに こんにちは！マイベストで入社してから2年目になるtkeita1024 です。現在は、Frontendのエンジニアをしています！ 今回は、新卒で入社してから1年かけてRuby on Railsで表示されているページをNext.js + GraphQLへ置き換えした話について書きたいと思います。 背景 マイベストでは、2022年~2023年にグローバル化対応というプロジェクトでRuby on Railsで表示されているページをNext.js + React + TypeScriptにし、APIをGraphQLを使用するように一部置き換えました。入社した当時は、主要なページのみしか置き換えが完了しておらず、管理画面(Admin)や新規事業（Favlist）の画面の置き換えは完了していない状況でした。そこで、新卒のタスクとして、置き換えが完了していない画面を全て置き換えるというのを取り組
Building Better People: How to give real-time feedback that sticks.
巨大なモノリシック Rails アプリケーションの マイクロサービス化戦略 / 2019 microservices in cookpad
自ブログからの引用です。 概要 あるとき、GraphQLを実務で利用している友人と飲みながら、彼が携わっているシステムに関して、GraphQLやBFF層がそのチームにとって本当に必要なのか？を議論したことがありました。 個人的には、GraphQLは複雑性を増したり、フロントエンドスピシフィックなアーキテクチャを生み出したりするため、GraphQLを利用する明確な理由がなければ、基本的にOpenAPIを利用したプラクティスの方がよりシンプルだと考えています。 その際に、彼から「でも、RESTは使いにくいよね」という反応がありました。 私はよく他のGraphQL, gRPC利用者からも同じような反応を受けることがあるのですが、RESTという言葉は本質的な観点を見落としている可能性があると感じています。 本記事では、なぜREST APIという用語に注意した方が良いのか？と、APIエンドポイントの
弊社(トラストハブ)では、すべてのプロダクトのAPIにGraphQLを採用しています。 しかし、私が入社した時点では、GraphQLの設計に課題がありました。Query, Mutationの設計に統一性がなく、REST的な設計の名残も見られました。そのため、GraphQLの利点を十分に活かせていない箇所が多く存在していました。 自分は以前から業務でGraphQLを使ったAPIを作るために、海外でのGraphQLに関するドキュメントや、Shopify GraphQL APIドキュメントを読んで実践してきたので、この部分で貢献できると思いました。 そこで入社後にまずGraphQLのAPIをこういうルールで作ってみませんか？と提案するドキュメントを書いて、新規で作られるAPIについてはそのルールを使うようメンバーに布教する活動を行っていました。今では、ほとんどのコードではAPIの設計に統一性を持
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL
Why, after 6 years, I’m over GraphQL
React Server Components と GraphQL のアナロジー
ネットスーパーアプリ GraphQL から REST へ移行始めました - every Tech Blog
TypeScriptとGraphQLで実現する型安全なAPI実装
TypeScript x GraphQLで2年開発してみて
GraphQLのよくないところ｜adwd
ソニー: GraphQLを活用したデータ配信プラットフォームの事例紹介
GraphQL あるいは React における自律的なデータ取得について
Fragment Composition of GraphQL
エラーレスポンス設計から考える、0→1開発におけるGraphQLへの向き合い方
GraphQLをServer Componentsで使いたい
GraphQL 界の Babel こと Envelop を使ってスキーマの破壊的変更をごまかす
開発者フレンドリーは“ハッカーにとってもフレンドリー” 「GraphQL」の機能を使った悪用事例と究極の対策
GraphQLクライアントの技術選定 2023冬
GraphQLは「オワコン」「流行らない」のか？ - Qiita
NestJSのGraphQL Resolver関数を型安全にしたい
GraphQL Server実装におけるSchema FirstとCode Firstの比較
Ruby on RailsのサービスをNext.js+GraphQLに置き換えした話
GraphQL 「良さ」・「難しさ」 再探訪 〜スタディサプリにおける実例〜
Kotlin製のGraphQLサーバーをNode.jsでモジュラモノリス化している話
GraphQLとOpenAPIを比較する時は「REST API」に注意する
GraphQL APIを開発するときに気をつけるべき点をまとめたドキュメントを公開します