2024年4月にリリースされたReact 19 Betaの新機能について、細かい点やポイントを解説します。
最近 React コード生成機を作っていて「一番文句言われなさそうな React コンポーネントの書き方ってなんだ…?」と改めて疑問に思ったので考えてみました。 結論から言うと以下の形をデフォルトにするのが良さそうかなと思いました。 function vs. アロー関数 -> アロー関数 型は基本的に VFC でつけて、 children が欲しい場合は明示的に props に追加する return を省略可能な時省略するか -> しない props を destructure するか -> しない派だったけどした方がいい気がしてきた const Hoge: React.VFC<Props> = ({ title }) => { return ( <Fuga title={title} /> ) } ちなみにですが、大事な前提として TypeScript を使うことを前提としています。(型
はじめに 今回は、現代のWEB開発で最も使用されている言語/フレームワークであるTypeScript/React/Next.jsについて学ぶために、私がおすすめしたい学習資料についてご紹介したいと思います。 非常に有用で、初心者から中級者、上級者まで幅広い層に向けた内容が含まれていますので、時間を見つけて是非読んでみてください。 ※TypeScript/React/Next.jsって何?という方のために、簡単に以下にそれぞれご説明いたします。 TypeScript Microsoftが開発した、JavaScriptを拡張したプログラミング言語。JavaScriptに比べ、型安全性の向上によるエラーの早期発見や、型注釈でコードの意図を明確にすることによる可読性/メンテナンス性の向上が期待できる。現代のWEB開発においては、ほとんどの開発者がJavaScriptからTypeScriptへ移行し
How to Build a Fullstack App with Next.js, Prisma, and Vercel Postgres Prisma is a next-generation ORM that can be used to access a database in Node.js and TypeScript applications. In this guide, you'll learn how to implement a sample fullstack blogging application using the following technologies: Next.js as the React frameworkNext.js API Routes for server-side API routes as the backendPrisma as
useEffectはReactの中でも扱いの難しいフックとして知られています。Reactで開発を行う中でuseEffectを検討するタイミングや適切な使い方について悩んだ経験のある方も多いのではないでしょうか。 本記事では、useEffectの目的を把握し、どのような場合にuseEffectの使用を検討すべきかについて考えていきたいと思います。 コンポーネントの純粋性と副作用 まずuseEffectについて考える前に、コンポーネントの純粋性について理解する必要があります。Reactにおいて純粋性は重要な概念の1つです。 前提として、Reactではすべてのコンポーネントが純関数であることを仮定しています。 Reactは、あなたが書くすべてのコンポーネントが純関数であると仮定しています。 参照:https://ja.react.dev/learn/keeping-components-pure
こんにちは。フロントエンドエキスパートチームの@nakajmgです。 私が所属しているフロントエンドエキスパートチームでは、現在 kintone の脱レガシーの一環として React + TypeScript 化に取り組んでいます。この取組の中で Scss で定義されている既存のスタイルを styled-components で書き直していくという決定をしました。 今回は styled-components の採用を決定するまでの過程や、既存の Scss ファイルの扱いについて検討した内容などを紹介します。 スタイル定義方法の検討 kintone にはユーザーが JavaScript でカスタマイズできる機能があり、ユーザーが行っているカスタマイズの中には、DOM 構造や CSS のクラス名に依存しているものもあります。このようなカスタマイズはサポートの対象外ではありますが、ユーザーにでき
Next.js の App Router が安定版となり、React Server Components (以下 RSC) を実際に試す環境が整ってきた。 実際、今年はやれどこそこのプロダクトが Next.js を採用しただのやっぱり捨てだのといった話題が尽きなかったように思う。 かくいう自分自身も、今年は App Router の案件に取り組んで RSC と格闘する日々を送っていた。 その過程で、こんなようなことを考えるようになったので、今回はこの辺りの話を書き残しておこうと思う(何回か X に同じ旨の POST は上げていたけど、一回もちゃんとまとめてなかったので)。 RSC がない頃の、別の言い方をすると getServerSideProps を使っていた頃の、Next.js におけるアプリケーションの設計は、トラディショナルな MVC にかなり近しい。 ここでいう MVC は、Sp
Reactコンポーネントの開発時、データフェッチは欠かせません。 SPAで開発を行う時、あなたも含めてuseEffect()を使ったことがあるはずです。 あなたがSWRやReact Queryの代わりにuseEffect()を使う理由は、いくつかあるのでしょう。 そんな方のために、Reactが提供する<Suspense>を使ってデータフェッチを行う方法を紹介します。 追記: Suspenseではウォーターフォール問題を解決できないとの指摘について 「Suspenseの実装」に記載のコードを見た限り、ウォーターフォール問題を解決できないとの指摘がありました。 実装の章では問題を解決することではなく、<Suspense>をどのように使うかに焦点を当てました。 具体的な実装方法に踏み込むとテーマから大きく外れてしまう可能性があったためです。 読みやすさを優先した結果、解決のための実装については割
Reactのprops/contextの使い分け 仕事先でたまたまこれの話になり、個人的に思っていることをまとめた。 公開したのは、時々見かける「どっちを使うべき?」みたいな議論に 自分も混ざりたかった 思うところがあったから. 「とにかくpropsでいい」と自分は考えている。 なによりReactは書き方に詰まった場合に、フレームワークライブラリ固有の事情を考慮して解決するというよりも、実装や設計上の問題が一般的なプログラミングパターンの範疇の発想で解決できるのがよい 前提 以下のように考える React/preact のコンポーネント = 通常のclassや関数 状態を隠蔽して抽象する 最近は冪等性がどうとかReact語るときにあんまりいわなくなったけども.... props = 関数やメソッドの引数(入力) context = グローバル変数(モジュールグローバルな変数) 実装の指針
そもそもDOMとは? 仮想DOMについて知るためには、まずDOMについて知っておく必要があります。 以下の動画で、DOMについて100秒で解説しているので、そもそもDOMをよく知らないなぁという人はぜひ確認してみてください! 仮想DOMとは? では、本題です。 仮想DOMとは、UIの "仮想" 的な表現をメモリー上に保持して、実際のDOMと同期させるというプログラミング上の概念のことです。 仮想 DOM (virtual DOM; VDOM) は、インメモリに保持された想像上のまたは「仮想の」UI 表現が、ReactDOM のようなライブラリによって「実際の」DOM と同期されるというプログラミング上の概念です reactjs ...と言っても、これだけだとちょっと難しいですよね。 なので、仮想DOMについて解説する前に、まずはDOM操作とレンダリングの関係について先に解説します。 DOM
OSSとしてリリースされたばかりのReactベースのフルスタックWebフレームワークであるRemixをためしてみました。 はじめに こんにちは、CX事業本部MAD事業部の森茂です。 re:Inventを前にAWSの情報も気になるところですが、フロントエンド界隈もReact Conf 2021を前にReact v18 betaをはじめ、Next.js v12やReact Router v6、新しいRoutingライブラリReact Locationのリリースなどなど注目のリリースラッシュが続いているようです。そんな中Reactをベースにした新しいフレームワークであるRemixが本日(2021/11/23日本時間)リリースされました。 Remixとは RemixはReactRouterの作者でもあるMichael Jackson氏(@mjackson)とRyan Florence氏(@ryan
はじめに 基本的にReact + TypeScriptでフロントの開発をしているんですが、実際にコードを書いている時に気をつけていること、便利な書き方として知っておくと得をするReactコンポーネントの書き方を紹介します。 Propsが多くなりすぎたら やたらpropsが多くなってしまうことありませんか?しかも同じような名称ばっかりを何回も書くことになるという。そうゆうときはできる限りショートハンドで書きましょう。 return ( <SampleComponent type={user.type} name={user.name} email={user.email} image={user.image} /> )
【結論】 5ヶ月かけて無事完了しました。あー長かった。 新規の機能開発を止めないために一般的な開発チームでは今回のようなフロントエンドのフルリプレイスで一部新規の機能開発を止めながら開発を行うことがあると思います。 コードフリーズとなど呼ばれているものですね。 しかしログラスのようなスタートアップではプロダクトを絶えず進化させていくことがとても重要です。 機能開発を止めてしまえばたちまち大きな開発チームをもつ競合に追い抜かれて会社が負けてしまいます。 本記事ではフロントエンドフルリプレイスを新規機能開発を止めずに走らせる方法を解説していきます。 リプレイス概要本題に入る前に今回リプレイス対象となったLoglassについてとプロジェクトの概要について説明します。 【Loglassについて】 「プランニングクラウド Loglass」はBtoB SaaSのサービスの一つです。 基本はSSGやSS
タイトルの通り、めちゃくちゃ良さげなライブラリ react-call を見つけたので紹介するコーナー 実際の動きはわかりやすいデモページがあるので見てください👍 react-call とは react-call がもたらす効果は「ReactComponent を手続き的に処理できるようにする」というのが私の理解です。 これが何を意味するのかというと、Modal や Confirm のような「別のコンポーネントから任意のタイミングで呼び出したい(≒表示したい)」また「その結果(≒値など)を受け取りたい」というごく一般的な要件をシンプルに解決します🙌 詳しく見ていきましょう! window.confirm との比較 下記は README にある例です。
この前ポジショントークしたらそれなりに反響があったので書いてみる。 これまでの人生を振り返ると毎年ラジオや電話や配信サービスを作っている気がするし、なんかそういう仕事が回ってくることが多い気がする。 最近自分なりに答えが出たかなと思ったことがあるので言語化してみようと思う。 OGP は Flux ぽい画像だ。 注意・免責事項 ここにあるソースコードは不完全です。これは私が元々手元で実験していたボイラープレートであるとはいえ、いろんな仕事で培ったノウハウ的なものも含まれているので、念には念を入れて意図的に要件が透けそうな箇所は削除しています。 その結果元々のボイラープレートと乖離してしまい、動作しないコードになっています。ただ概念を伝えるには十分なコードになっているはずなので、脳内補完してください。質問は Twitter のメンション、もしくは Issue でのみ受け付けます。 (完全版を書
Effects are an escape hatch from the React paradigm. They let you “step outside” of React and synchronize your components with some external system like a non-React widget, network, or the browser DOM. If there is no external system involved (for example, if you want to update a component’s state when some props or state change), you shouldn’t need an Effect. Removing unnecessary Effects will make
より良いReact開発者になり、より優れたコードを書き、コーディング面接で抜き出るため、Reactの技量を改善するすぐに使える知識です。 さあ、皆さん。始めましょう。 1. Reactフックを使った関数コンポーネント フックはReact v16.8で導入され、Reactの関数型プログラミングを大きく向上させました。Reactフックで、クラスコンポーネントの代わりに関数コンポーネントが使えますし、使うべきです。しかし...関数コンポーネントとステートとは?ライフサイクルメソッドとは? 怖がる必要はありません。Reactフックを使えばできます。 例をいくつか見てみましょう。 これは、クラスを使う従来の方法です。次のようにuseStateフックが使えます。 簡単に見えますか?その通りです!useStateフックを使って、初期状態を空の文字列('')に設定し、現在の状態(value)とその状態を変
先日、React Server Componentsについてまとめる機会がありました。 この記事では、React Server Componentsの概要と、デモを触る中で感じたことについてご紹介します。 React Server Componentsとは React Server Componentsは、Reactコンポーネントをサーバーサイドでレンダーする新しい技術です。 一部のコンポーネントをサーバーサイドでレンダーしてしまうことで、アプリケーションのパフォーマンスを上げることを目的とします。 図は、デモの画面のうち、サーバーでレンダーされる部分を青で、クライアントでレンダーされる部分を赤で示したものです。 ページ全体をサーバーでレンダーするのではなく、一部のコンポーネントはクライアントにレンダーさせていることがわかります。 また、React Server ComponentsはCo
皆さんこんにちは。筆者の以前の記事では、ReactのuseMemoを無駄に使うことによるレンダリング速度のオーバーヘッドがどれくらいかをベンチマークによって示しました。 それによれば、スマートフォンを想定したとしても、useMemoだけで描画に目に見える影響を与える(16msくらいの遅延を発生させる)には万のオーダーのuseMemoが必要なことが分かります。 速度ではなくuseMemoを使うことによるメモリ消費量の増加を気にする声も聞かれましたが、すみませんが筆者はそこまでメモリクリティカルなアプリをReactで書いたことがなく知見に乏しいため、今回はこの記事の対象外となります。 この結果が出たことでuseMemoをいつ使うのかなどという議論には終止符が打たれたかと思いきや、上記の記事の感想などを見ているとまだ喧々囂々です。 そこで、この記事では筆者の考えを皆さんに共有し、いよいよもってこ
はじめに こんにちは!Ruby on Railsフロントエンドエンジニアを目指し、Hotwireを中心に活動しつつ、Next.jsもReactも勉強している加々美です! 2025年2月14日(バレンタインデイ)に、ReactのチームはCreate React Appを公式に非推奨とするブログポストを公開しました。そして代わりにSPA用のフレームワークを使うべきだと彼らは強く主張しました。 大事なポイントは、SSRフレームワークを推奨したわけではないということです。SPAフレームワークを推奨したのです。CDNとか静的ホスティングサービスにデプロイできるSPAでもフレームワークを使いなさいということです。 「オレはSSRに興味ねぇ!SEOはどうでも良いからSPAで十分だ。Create React Appがダメなら、Viteを使えば良いさ!」 => これは違います。 Reactチームはこういう人
www.youtube.com Meta(当時Facebook)のReact Core Teamの主要人物たちに直接インタビューしたドキュメンタリー動画 タイムライン 2012年まで 最初はFacebook社内でReactが普及するまでの道程。 当時世の中的にはクロスブラウザの解決策はjQueryに落ち着き、モバイルアプリ化の流れでAPIサーバーとViewは切り離される傾向にあり、JavaScriptのクライアントサイドで大きいアプリケーション作るためにMVCフレームワークとか取り入れないとね〜という雰囲気だった Facebook社はマーク・ザッカーバーグがHTML5に賭けていた頃*1にBolt.jsというFacebook版Backbone.jsを開発していた 広告プラットフォームのコードは当時Bolt.jsを中心に構成されていたが、Jordan Walkeが関数型プログラミングのアイデア
Reactアプリを作成 Material-UIで管理画面を作るためのベースとなるReactアプリを作成します。 Create React App Create React Appで新しいReactアプリを作成します。 npx create-react-app react-material-ui-sample --typescript プロジェクトのディレクトリへ移動して実行します。 cd react-material-ui-sample npm start ブラウザにReactアプリが表示されます。 ディレクトリ構成 ディレクトリはあまりネストさせすぎずシンプルな構造にしました。コンポーネントの分け方はAtomic Designを参考にしています。 src/ ├ components/ │ └ atoms/ # 原子(個々のパーツ) │ └ molecules/ # 分子(原子の集合体)
皆さんこんにちは。現在、フロントエンドでは宣言的UIが大流行しており、そのためのライブラリもReactを筆頭に複数存在しています。 ライブラリが複数存在するところには当然のように比較や論争が起こるものですが、UIライブラリの場合はパフォーマンスがよく焦点となります。 筆者はReactの信者ですが、Reactは古株ということもあってか、最近の議論ではReactは他のライブラリと比較されるかませ犬のような役割を担うのがよく見られます。「仮想DOMは必要ない」といった類のものです。 しかし、筆者の考えではReactは今でも、もっとも真剣にパフォーマンスに取り組んでいるUIライブラリです。特に、Reactはパフォーマンスを高いユーザーエクスペリエンスのための手段として捉えており、ドキュメントにもユーザーエクスペリエンスという言葉が多く出てきます。 そこで、今回はReactが最も有利になるようなベン
はじめに 早いものでこちらの記事が公開して約1年、ログラスでReactを書き始めて1年以上が経ちました。 今回はフロントエンドのアプリの中でも特段重要なフォーム、特にReact Hook Formについての解説をしていきます。 今回のTipsは公式がベストプラクティスとして発表しているものではなく、あくまで個人が1年間の経験の上で良いとしているものであしからず。 なるべく何故良いかの説明もしていきます。 目次 useFormをラップしてタイプセーフにする React Hook Formへの依存するコンポーネントを分ける yupを使って見通しの良いバリデーションを実装する 1. useFormをラップしてタイプセーフにする ログラスでは useForm をそのまま使うことはせずラップしています。理由は一部の型づけがゆるく実行時例外が起きる可能性があるためです。 問題なのは defaultVa
こんにちは。フィナンシャル開発センターの鈴木です。LINE証券のフロントエンドを担当しています。この記事は【LINE証券 FrontEnd】シリーズの4番目の記事です。 最近のWeb Vitalsの隆盛を受けて、LINE証券のフロントエンドでもパフォーマンスの改善に取り組み始めました。およそ2週間ほど改善に取り組んだ結果として、開発環境での計測ではLighthouseのperformanceスコアが従来より30点ほど上昇しました。 パフォーマンス改善のためにさまざまな施策を行いましたが、この記事ではその中でも興味深かったものとして、requestIdleCallbackを活用してLazy Loadingされるコンポーネントの読み込みを遅延し、その結果初期レンダリングにかかる時間を約14%削減できた事例をご紹介します。 環境 以前の記事でご紹介したとおり、LINE証券のフロントエンドはTyp
はじめに 私は今、CSVエディタ SmoothCSV 3 を開発しています。フレームワークとして Tauri を採用しており、レンダラーにはWebの技術(React + TypeScript)を使っています。 CSVエディタは大量の行・セルを表示する必要がありますが、Webの技術ではこのようなシーンではバーチャルスクロールを使うのが定石です。 SmoothCSVでもバーチャルスクロールを使っていましたが、どうやらこのバーチャルスクロールにも限界があるらしく、数百万行のような極端に大量のデータを表示する場合に最後まで表示しきれない問題に遭いました。 ここではバーチャルスクロールの基本と、その限界をどう乗り越えたかを紹介します。 About Me 株式会社ヘンリーでソフトウェアエンジニア & アーキテクト的なことをしつつ、個人開発してます。 Social accounts: kohii on
さて、年末が近づいてきましたが今年も 「Redux 使うべき使わないべきか」という話で盛り上がりましたね。 僕もずっと悩める人なのですが、@f_subal さんの Tweet や @takepepe さんの Next.js の状態管理 2020 が示すように Read 要件・Write 要件の多さで使い分けるという指針には深く納得をしました。 Redux の代替になるツールやノウハウもより活発に出てきて、Redux 以外の選択肢を考えるにあたって様々な学びがあった 1 年でした。 自分も色々と Redux 以外の選択肢を試していたのですが、その中で「やっぱ Redux を使えばよかった」と思ったときがあったので、これから Redux を剥がそうと考えている人に向けてその失敗談を語りたいと思います。 自分も手探りで正解がわかっていないところなのでアドバイス・反論・指摘などがあれば頂きたいです
React でフォームを作るとき「制御・非制御」コンポーネントに関する知識は必須です。デザインシステムを作成するにあたり、どちらを採用するか検討されたこともあるかと思います。 「制御・非制御」コンポーネントの差分を一言でまとめると、次のとおりです。 制御コンポーネントはライブラリ(React)が「入力要素の状態」を管理 非制御コンポーネントは「入力要素の状態」を DOM 自身が保持 「制御・非制御」コンポーネントと Form ライブラリ React Hook Form は、非制御コンポーネントを使うことで、少ないコード量で高パフォーマンスの Form 実装が実現できる人気のライブラリです。「非制御コンポーネント」として作成された<Checkbox>コンポーネントの例を見てみましょう。次の方法で<input type="checkbox" name="test" />がレンダリングされ、Fo
カミナシのソフトウェアエンジニア佐藤です。カミナシレポートの開発に携わっています。 フロントエンドのエラーは「画面リロードやブラウザ再起動で復旧できる(かもしれない)」「クラッシュしてもユーザーの端末に閉じる」などの理由から、バックエンドよりは精緻に扱われない傾向があると個人的には感じています。 その一方、カミナシレポートは、ノンデスクワーカー向けの不安定なネットワーク環境で利用されることも多々あるアプリです。そのため、デジタルツールに不慣れな方のために精緻なフィードバックが必要とされる、リロードに頼ることが難しいケースがある、などの理由でエラーの扱いにも慎重になる必要があります。 本記事では、カミナシレポートのフロントエンド開発をする中で、 バックエンドの API コール時にエラーが発生する条件とその内容(型・クラス) これらエラーをハンドリングする箇所 について、把握しておきたいと感じ
もはやReactにHooksのない生活は考えられず、私たちのReactコードの中には多数のHooksが使われています。 一方でその弊害として、使われているHooksが多すぎてコードが散らかり始めた人も多いと思います。Hooksは便利ですが粒度は小さく、プログラムの規模によっては多用しなければなりません。 そこでカスタムHooksの使用を勧めます。カスタムHooksを使うことでコードの見通しを良くすることができます。 カスタムHooksをカジュアルに使っていく カスタムHooksというと、どちらかというとReactの中では難しい部類に入ります。主に「使い方がわからない」「公式ドキュメントが不親切」「ネットの解説が難しい」あたりが問題になるでしょう。しかし難しい機能だからと言って難しく使う必要はなく、自分の使える範囲で自由に使えばいいのではないかと思います。 カスタムHooksは一般にロジック
本資料について 本資料は日本大学文理学部情報科学科の開講科目「Web プログラミング」の教材として作成されました。本資料は下記のライセンスの範囲内で、当授業以外でも自由にご利用いただけます。 対象読者 本資料は、以下の教材を学習済み、もしくはそれと同等以上の知識を持っていることを前提としています。 Web 入門 HTML 入門 課題:手紙をマークアップする 課題:コンテンツページを構造化する CSS の第一歩 課題:新しい知識を使う JavaScript の第一歩 課題:バカ話ジェネレーター JavaScript の構成要素 課題:イメージギャラリー JavaScript オブジェクト入門 課題:バウンスボールに機能を追加する クライアントサイド Web API ドキュメントの操作 サーバからのデータ取得 本資料で学ぶこと 本資料では以下の内容を学びます。 React の基本 開発の始め方
はじめに ここ最近TypeScriptの学習をしていまして、その学習記録をZennに投稿し続けていました。 その中で、TypeScriptの基礎学習の最後として投稿した以下の記事では、TypeScriptを用いてReact開発をする際に最低限必要となるであろうTypeScriptの型について簡単にまとめました。 TypeScript 学習記録 #8(Reactに関わる型定義) 先述の記事を書いている際、TypeScriptを用いたReactの基本的な型定義について網羅的にまとめている記事がまだまだ多くないように感じたため、今回「React × TypeScriptの基本の型定義」について改めてまとめ直してみることにしました。 TypeScriptの基礎学習を終え、これからTypeScriptを利用してReactやNext.jsでの開発をしてみようという方の参考になれば幸いです。 そこそこ長
こんにちは、クレイの正岡です。 コロナ禍が始まってから小学生時代以来のゲーム生活を送っています。ゲームボーイと呼んでください。 さて、今回は React × Typescript でコードを書いている人/書こうとしている人に向けて、Reactコンポーネントの型定義について頭の片隅に置いておいて欲しい情報を共有したいと思います。 寝ながら使えてしまうReactコンポーネントの3つの型 () => JSX.Element 型 interface Props { text: string } const Hoge = ({ text }: Props) => { return ( <p>{ text }</p> ) } 上記のように返り値の型を特に指定していない場合、 このコンポーネントは JSX.Element型 を返す関数( () => JSX.Element )として返ります。 React
SaaS の管理画面を開発していると新規作成画面と編集画面を実装することがよくあります。 これらの画面は一見似ているので共通のコンポーネントで実装できそうですが、意外と多くの違いがあります。 この記事では新規作成画面と編集画面を実装するときに気をつけていることをまとめてみます。 コンポーネント設計について シンプルな例でも新規作成画面と編集画面には違いがありました。 これらを1つの共通コンポーネントで実装するとコンポーネント内でIF分岐が発生し可読性が下がったり、再利用性が低くなったりします。 では両者を完全に別コンポーネントで実装したら良いのかというとそれも微妙です。新規作成、編集の入力項目は仕様的に同じであり、バリデーションも同じであることが多いです。 ここを別に実装してしまうと仕様が変わったときに変更する箇所が多くなってしまいます。 なのでフォーム部分(入力とバリデーション)は共通化
javascripter です。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。 今回は、筆者が社内で書いている技術ガイドラインについて紹介します。 はじめに ハローでは、高品質なコードを維持し、開発チームの技術レベル向上を図るため、社内で継続的に技術Tipsやガイドラインの整備・蓄積を行っています。 チーム横断的に、有用な技術Tips、ベストプラクティス・コーディングガイドラインなど情報をNotion上に集約し、自由にエンジニアが閲覧・編集できるようになっています。 この取り組みの目的は以下の通りです: コード品質の向上と統一 開発チームメンバーの技術スキル向上 「どう」直すかでではなく「なぜ」そう修正すべきかまで理解してる人を増やす 効率的な開発プロセスの確立 新メンバーのオンボーディング支援 今回紹介するドキュメント 今回は、その中から「reac
概要 先日新規の Web サービス開発でフロントエンド側の技術選定を行いました。 利用する技術の中で GraphQL を提案した際に、RESTful な API で呼び出す方法と比較して納得感がないという意見があがりました。 そこで、なぜ、どういうときに GraphQL を選定すべきだと思うか、文章にして自分なりにまとめておこうと思います。 前提 構成が BFF か BE かで意見は大きく変わりません。 例えば BFF として利用されるケースでは、バックエンド側には BE チームとマイクロサービス的な API が存在しており、 BFF として GraphQL を配置するようなケースです。GraphQL のリゾルバは API を叩きます。 一方、 BE として利用されるケースとは、リゾルバが直接 DB を叩くような形です。 今回はフロントエンドのチームが管理する BFF として、JS のみで
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く