Next.jsのAPI Routesを中間APIとして使う方法
全体の概要 基本的なAPI結合 基本的にはフロント(Next.js)からaxios等を利用して、サーバー側のAPIエンドポイントに対して直接リクエストを送る構成かと思います。 今回紹介するNext.jsのAPI Routesを中間APIとして挟んだ場合 今回紹介する構成は下記のようになっています。 この構成にするメリット・デメリットは後の章で解説をしていきます。 この記事の対象者 フロントエンド初級者から中級者 Next.jsのAPI Routesの基本を学びたい人 セキュリティーを考慮したAPI通信手法について知りたい人 Next.jsのAPI Routesを中間APIとして挟むメリット セキュリティーが強化できる ログの管理ができる APIエンドポイントの抽象化 セキュリティーが強化できる Next API Routesを中間APIとして挟むことで、外部から直接本体のAPIにアクセスさ
メルカリ Shops での NestJS を使った GraphQL Server の実装 | メルカリエンジニアリング
ソウゾウの Software Engineer をやっています、@mookjp です。 8/10 の記事「メルカリShopsの技術スタックと、その選定理由」では、メルカリ Shops のアーキテクチャについて、その全体像を紹介しました。 この記事では、そのうちの BFF（Backend for Frontend） レイヤとして用意した GraphQL サーバについて、NestJS を使った実装例を交えて紹介します。 GraphQL とは GraphQL サーバ周辺の構成 NestJS とは GraphQL Module NestJS で Code First なスキーマ定義をする Object types の定義 Query と Mutation の定義 GraphQL スキーマの生成 スキーマの Breaking Change （破壊的変更）を防ぐ DataLoader を使って Bat
GraphQLが解決する問題とその先のユースケース
サーバーサイドからみたGraphQL Serverlss Meetup#19 2021/03/31 に行われた Serverlss Meetup#19 で上記のタイトルで登壇してきました。サーバーサイドの話をしようと思ったけどGraphQLの解決している話をしようと思ったらクライアントの事もかなりはいってしまったので記事のタイトルは変えました。 以下内容です。記事の最後に資料を書くにあたって参考になった資料のリンクを置いてます。 GraphQL and me この1年書いたQiita記事 GraphQLの特徴を分解する ~API インターフェース・Universal BFF・API Gateway~ GraphQLはサーバーサイド実装のベストプラクティスとなるか GraphQLの全体像とWebApp開発のこれから 今回話す事 そもそもGraphQLはなんで作られたのか、何を解決しようとして
Next.js + NestJS + GraphQLで変化に追従するフロントエンドへ 〜 ショッピングクーポンの事例紹介
今回は、fragmentを活用するためにパターンCを採用しており、厳密には、以下のように方針を定めています。 SSR時のクエリ発行: ページコンポーネント単位 CSR時のクエリ発行: CSRが必要なコンポーネント単位 この際、取得したqueryの結果をどのようにfragmentへ変換するかというのがポイントです。 そこで、graphql-anywhereの filter メソッドを用いることで、クエリ結果をfragmentへ変換します。 以下は、簡略化されたクーポンページの実装例です。 type DetailPageProps = { // GraphQLクエリの結果 data: Query } const DetailPage: FunctionComponent<DetailPageProps> = ({ data }) => { // couponはGraphQLのCouponスキー
SSR / SSGの理解を一段深ぼる: BFFアーキテクチャ
BFFとは Backend for Frountendの略で、UI/UXを向上させる目的でフロントエンド専用のサーバーを用意したアークテクチャパターンです。 Webアプリケーションサーバーは下記の処理を行います。 リクエストを受ける DBからデータの取得・更新 ページを構築 (これはクライアントですることも) ページ or データの返却 このうち、「DBからデータの取得・更新」とそれ以外をフロントエンドとバックエンドの役割に明確にわけます。 BFFの役割となるサーバーをクライアントをWebサーバーの間に設け、「リクエストを受ける」と「ページ or データの返却」、場合によっては「ページの構築」をここで処理します。 こうすることで、これまでリクエストというUX関わる部分をフロントエンドエンジニアの責務に移行することができます。 ページの構築をクライアントではなくサーバーで行う場合、これもBB
BFF（Backends For Frontends）の5つの便利なユースケース
BFF（Backends For Frontends）の5つの便利なユースケース：マイクロサービス/API時代のフロントエンド開発（2） マイクロサービス/API時代のフロントエンド開発に求められる技術の1つ、Backends For Frontends（BFF）について解説する連載。今回はBFFの代表的なユースケースを5つ紹介します。 マイクロサービス/API時代のフロントエンド開発に求められる技術の1つ、Backends For Frontends（BFF）について解説する本連載「マイクロサービス/API時代のフロントエンド開発」。前回の「BFF（Backends For Frontends）超入門――Netflix、Twitter、リクルートテクノロジーズが採用する理由」では連載初回ということで、BFFの概要を紹介しました。 まだBFFは何をするサーバなのか分かりにくい面もあるかと思
LINE and BFF - Speaker Deck
組織と責任 それで、BFFやってますか？ • やってます！ • React + Node.js (Express) • Nuxt • どうやって組織と責任の争いから抜け出したか Development サーバ、デザイン、企画、QA Development • BFFがないと • テンプレートがサーバにあるため、責任が不明確 • サーバ側が修正し始めたらトラッキングが難しい • ２度作業するようになることも Development • BFFを導⼊すると • サーバ: データ処理、API • フロントエンド: その他 • 責任が明確になる • 結果的にはみんな喜ぶ Development • サーバ側はNode.jsの経験がないかも • Node.jsサーバは怖くない、と納得させる • サーバの運⽤は⼿伝ってもらう Deployment サーバ、インフラ、DevOps Deployment
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
