SSR / SSGの理解を一段深ぼる: BFFアーキテクチャ
BFFとは Backend for Frountendの略で、UI/UXを向上させる目的でフロントエンド専用のサーバーを用意したアークテクチャパターンです。 Webアプリケーションサーバーは下記の処理を行います。 リクエストを受ける DBからデータの取得・更新 ページを構築 (これはクライアントですることも) ページ or データの返却 このうち、「DBからデータの取得・更新」とそれ以外をフロントエンドとバックエンドの役割に明確にわけます。 BFFの役割となるサーバーをクライアントをWebサーバーの間に設け、「リクエストを受ける」と「ページ or データの返却」、場合によっては「ページの構築」をここで処理します。 こうすることで、これまでリクエストというUX関わる部分をフロントエンドエンジニアの責務に移行することができます。 ページの構築をクライアントではなくサーバーで行う場合、これもBB
next.js + vercel + firebase authentication で JWT の検証を行う + Graphql
今個人で作ってるアプリの 認証 + Graphql の部分を抜き出して GitHub に公開した。 mizchi/next-boilerplate-20200727 next.js + vercel + firebase は (パーツを良く選べば) 最高 next.js はルーティングを持つページを作るには最高で、サーバー、静的サイト、JAM スタック、AMP と必要に応じて選択できる。React ベースならこれ一択。 認証サーバーの実装は毎度疲れるし、Firebase Athunetication はこの点においては OAuth Secret を置くだけ + Custom Provider も作れるので、最高。 それと比べて firestore は、ちょっと前に firestore べったりでアプリを試作したことがあったのだが、型がないためにかなり扱いづらく、また読み書きの速度が遅くパフ
Relayで見るNext.jsとSSGの未来
現在自分が取り組んでいるプロジェクトでは、Next.jsとRelay Modernを採用して開発を進めています。 RelayはFacebookが開発しているGraphQLクライアントライブラリです。 Next.jsの9.3で導入されたgetStaticProps, および9.4で導入されたIncremental Static Regenerationは、Relayと非常に相性がいい、ということを説明します。 Example公式のexampleがすでにあるので見てください。 https://github.com/vercel/next.js/tree/canary/examples/with-relay-modern 以下が典型的なpagesの構成です。 pages/index.js
作って学ぶGraphQL。gqlgenを用いて鉄道データ検索API開発入門 | フューチャー技術ブログ
春の入門祭りの7日目です。 はじめに※このエントリーはGoでGraphQLサーバアプリ開発の入門記事です。技術要素にGo, gqlgen, Docker, PosgreSQLなどが登場します。 TIG DXユニット 1の真野です。技術ブログ運営もしています。 フューチャーではOpenAPI関連の過去記事からお察しもできるように、REST-likeなWeb APIを実装することが多いです。しかし日本製HeadlessCMSのmicroCMSを触ってみたの記事で紹介されたように、HeadlessCMS界隈を初めGraphQLのAPIを提供するサービスが増えている体感もあり、GraphQLを春の入門祭りのテーマにしました。 学習する上でドキュメントを読み込むだけでは忘れがちです。手を動かしながらタイトルにあるように鉄道データ検索APIをGraphQLで実装していきましょう。実装の前に結果のみを知
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/
GraphQL の Fragment でコンポーネントの見通しがよくなった話 - vivit engineering blog
vivit株式会社でフロントエンドエンジニアをしている関です。 新型コロナウイルス感染症(COVID-19)への対策として発出された緊急事態宣言の影響で、弊社も2ヶ月ほどリモートワークとなり、私も駆け足で自宅に作業環境を構築しました。買っちゃいましたL字デスク。 さて、弊社ではいくつかのプロダクトのフロントエンドに React(Next.js) + TypeScript を採用しており、バックエンドとの通信には GraphQL(Apollo) を採用しています。 今回はその中で、コンポーネント分割をする際の GraphQL Query の定義と取得したデータの受け渡しについて話をします。 ここからは GitHub GraphQL API v4 を使って説明していきます。 developer.github.com アジェンダ pages から components へのデータの受け渡し方法に
GraphQLを使ったAPI仕様中心開発の導入とその効果の紹介 - Kaizen Platform 開発者ブログ
Kaizen Platformでフロントエンド開発をやっているlacoです。 新規アプリケーション開発において、API仕様中心の開発スタイルを検討し、実験的に取り入れました。 本記事ではその概要と効果を紹介します。 API仕様中心開発 API仕様中心開発を取り入れようと思ったきっかけは、2017年のNode学園祭でpika_shiさんが発表した「JSON Schema Centralized Design」です。 JSON Schema Centralized Design - Speaker Deck Kaizen Platformではリモートワークで開発しているメンバーが多く、非同期にコミュニケーションをすることが多いので、生産性を高めるためには互いの作業を待たずに独立して分業できるワークフローが必要でした。 バックエンドAPIの実装を待たないとフロントエンドが実装できないような依存関
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Strapi - Open source Node.js Headless CMS 🚀