タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
このように、API Gatewayが「システム全体の身を守るための共通基盤」であるのに対し、BFFは「特定のユーザー体験を最高にするための個別最適化レイヤー」であるという違いがあります。 1.2 BFFは「APIを作る場所」ではない BFFを設計する上で重要な視点は、BFFは「リソース（データ本体）を生成する場所」ではないということです。BFFは、バックエンドの各サービスが持つデータ構造や命名規則といった「バックエンド側の都合」が、そのままフロントエンドに流れ込まないように食い止める「境界層」として機能します。 そのため、フロントエンドがバックエンドのDB構造を意識せざるを得ない状況を防ぎ、あくまで「ユーザー体験（UI）」に最適化されたインターフェースを提供することが大切です。それがBFFというレイヤーを設ける目的です。 2. なぜ BFF が必要になるのか 「中間にサーバーを置くなんて、
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。2022 年 2 月入社でそこまで日が経っていないので、今回は社内の技術スタックではなく、今後社内でも検討されるかもしれない「BFF」について触れていきたいと思います。BFF（Backend For Frontend）導入することで得られるメリット/デメリット、GraphQL を用いた技術スタック事例など紹介していますので、ぜひ参考にしてもらえればと思います。 BFF とは？ BFF とは、Backend For Frontendの略称で、「フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン」のことです。これだけだと分かりづらいので簡単にまとめると、「バックエンドの API
どうも、トラハックこと、toraco株式会社の稲垣です。 複数のバックエンドを抱えるプロダクトにおいて、Next.js ( App Router ) 製 の Web アプリケーションを新規開発するにあたり、Route Handlers による BFF と、クリーンアーキテクチャを取り入れることで、バックエンドに依存しないクライアント実装を実現しました。 将来的に、通信するバックエンドが増えたり、バックエンドのアーキテクチャが変更になったとしても、クライアントの実装に修正を加えることなく移行が可能です。 さらに余談ですが、一般的な設計や実装に関しては技術記事を読まなくても生成AIに任せることができてしまう現代になっているように思います。（それが "問題ない" のかは議論の余地がありますが...） なので、この記事では以下の観点を重要視して書いていきます。 アーキテクチャ選定や設計段階で考えて
はじめに こんにちは。EC基盤本部SRE部プラットフォームSREの三神です。 2021年3月18日、ZOZOTOWNは大規模なリニューアルをしました。その中でも、コスメ専門モールのZOZOCOSMEと、ラグジュアリー&デザイナーズゾーンのZOZOVILLAを同時にオープンし、多くの反響をいただきました。 今回のリニューアルではBackends For Frontends（以下、BFF）にあたるZOZO Aggregation APIを構築しています。本記事ではZOZOTOWNが抱えていた課題とBFFアーキテクチャを採用した理由、またZOZO Aggregation API構築時に発生した課題と解決法についてご紹介します。 ZOZO Aggregation APIのサービスメッシュについてはこちらの記事でご紹介していますので合わせてご覧ください。 techblog.zozo.com BFFと
NestJSでスケーラブルなBFFを構築。メルカリShopsエンジニアがGraphQL活用のリアルを語る【技術選定の裏側：GraphQL編 vol.2】 モダンな技術の活用法に迫る、エンジニア座談会企画がスタート！第2弾は、前回に引き続き「GraphQL」の魅力に迫ります。 ＊＊＊ 誰でも簡単に売り買いが楽しめる日本最大のフリマアプリ「メルカリ」。2021年10月には、メルカリ内で個人・法を問わずに自身のお店を開くことができる「メルカリShops」がリリースされました。今回は、メルカリShopsの開発を手がけている株式会社ソウゾウより、CTOの名村さん、フロントエンドエンジニアの末田さん、バックエンドエンジニアの市原さんをお招きし、GraphQLの活用法や、実際に利用した上で感じたことをお伺いしました。 ■登場人物プロフィール 名村 卓 (Suguru Namura) / suguru 株
LINE株式会社 古田 大志 京都開発室 / 出前館マーチャント部 クーポンサービス チームリード 2023.9.12「モジュラモノリス徹底解剖vol.2〜実践者から学ぶLunch LT〜」の登壇資料です https://findy.connpass.com/event/293748/
【追記情報】 2022/06/15 09:00 誤字修正 + cdkk8sについて言及 先日、ハンドブックを公開しました。 ここではKubernetes上で稼働させた実績値としての記録が紹介してあります。が、逆に紹介していないものもたくさんあります。検証が済んでいないもの、時間的制約から導入できなかったものなど、不完全な情報を紹介しようと思います。 したがって、何も保証するための裏付けはないので「そういうことも検討してたんだなぁ」ぐらいで読んでもらえると嬉しいです。元記事もぜひ読んでみてください。 nodejsのDocker Imageの軽量化 Docker Imageを作る際、多くの場合Image内にnode_modulesを含んだ状態でイメージを作成しています。Nodejsのベースイメージが60〜100MBくらいあるのに対して、ビルド後のイメージサイズは200MB〜1GBくらいまで膨れ
｜DMM inside
仕事で新規開発PJの開発本格化フェーズに入り、「BFFって実際必要？」みたいな感じの議論になりました。 私はそもそもBFFというもの自体あまりよくわかっていなかったレベルでしたが、実際導入の是非を検討してみたことで、チームの在り方やWebAPIの扱い方次第で答えが変わってきそうな面白いテーマだなあと感じました。 今回自分のチームでは「一旦BFFは無しで行こう」という話になったが、BFFなしで開発進めることでまた新しい発見もありそうな感じなので、半年後くらいに読み返すことができるように、今回どのようなことを考えたのかなど、Scrapにつらつらとまとめていこうと思います。
2022/06/13に「ニコニコ生放送 WebフロントエンドのKubernetes移行ハンドブック 2022」を公開しました。本発表で…
introduction HonoにはRPCの機能があり、routerで定義している情報（引数とか型とか）を他のファイルで簡単に利用することができます。 この記事では、そのRPCの機能とNextを組み合わせて、HonoをNextのBFFとして使用する組み合わせについて紹介していきたいと思います。 まず、今回作成した２つのサンプルのリポジトリを紹介します。 以下の２つのリポジトリのコードを用いて説明するので、もし興味があればクローンして色々試してみて下さい。 next-hono-webはshadcn/uiのコンポーネントをお借りして作成したサンプルのダッシュボードに対して、一部の値を動的に設定するよう変更を加えたものです。 next-hono-backendはとてもシンプルで、next-hono-webで使用するサンプルデータを返すよう定義されています。 next-hono-backend側
これは SMat Advent Calendar 2024 の12/4分の記事です。 はじめに こんにちは、株式会社エスマット エンジニアの hi6okuni です。 今回は、OpenAPI Specification(以降、OpenAPIと呼ぶ)からTypeScriptの型自動生成の仕組みをサクッと作った時の振り返りです。 型の自動生成自体はすでに多くの事例や記事が公開されていますが、本記事では特にマイクロサービスアーキテクチャにおいて「クライアントサイド（Next.js）とマイクロサービス（Go）の間にBFF（tRPCサーバー）が存在する」という構成に焦点を当て、実装例と得られた知見を紹介します。 特に以下のような課題をお持ちの方に参考になれば幸いです。 複数のマイクロサービスのOpenAPIから型を自動生成したい BFFレイヤーでの型定義の保守コストを削減したい tRPCサーバーとマ
はじめに こんにちは。モノタロウでECサイトの開発・運用を担当している菊川です。 モノタロウではECサイトのフロントエンド刷新に取り組んでおり、その内容をブログで共有したいと思います。よろしければ、関連記事もあわせてチェックしてみてください。 Vue.js？React？フレームワーク選びの７つの選定基準、大規模ECサイトのフロント刷新プロジェクト モノタロウのフロントエンド刷新の取り組み①～大規模ECサイトのフロントエンドをドメイン単位で再設計した話 モノタロウのフロントエンド刷新の取り組み②～工数34%削減を実現した刷新の効果 モノタロウのフロントエンド刷新の取り組み③～「小さく早く試す」UIコンポーネントの整備 今回はこの活動におけるBackend For Frontend(BFF)層の導入とGraphQLの採用の取り組みについて紹介させて頂きたいと思います。 この記事では以下について
受発注・サプライチェーン管理システムとサプライパートナー向けシステムに関する現状や課題などについて、開発を担当しているエンジニアが話す「Rustで負債を解消するために大幅刷新する複雑な業務Webアプリ」。ここでフロントエンドエンジニアのOgura氏が登壇。BFF／FEを大整理した経験について話します。 自己紹介とセッションのあらすじKen Ogura氏（以下、Ogura）：ではOguraから「『Rust製の業務WebアプリケーションをRustでリプレイス』のドサクサでBFF／FEを大整理した話」をします。 私の自己紹介。フロントエンドエンジニアをやっています。もともとはバックエンドでRustバリバリ触ってたんですが、いろいろな事情で今はフロントエンドを触っています。あと趣味でいうと競技プログラミングが得意です。あとYouTuberもやってます。 私の（発表）時間はちょっと短いので、早め
はじめに 本記事の目的は、Web フロントエンド(TypeScript) と BFF(Spring Boot) をタイプセーフに繋ぐ方法を紹介することです。 以前、以下の記事を書きました。 この記事からの変更点は、次の２点です。 OpenAPI Spec を出力する Springfox を springdoc-openapi に変更しています。Springfox はメンテナンスされなくなっているようです。 生成するコードが Angular 用のクライアントでしたが、より汎用的な fetch のクライアントに変更しています。サンプルコードも React に変更しています。 ざっくり説明 まずは、以下のような Spring Boot(BFF)のコードを作成します。 @RestController public class AppController { @GetMapping("/greet"
【書き起こし】gRPC Federation を利用した巨大なBFFに対するリアーキテクチャの試み – goccy【Merpay & Mercoin Tech Fest 2023】 Merpay & Mercoin Tech Fest 2023 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるEngineeringを知ることができるお祭りで、2023年8月22日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。 この記事は、「gRPC Federation を利用した巨大なBFFに対するリアーキテクチャの試み」の書き起こしです。 @goccy：それでは「gRPC Federation を利用した巨大なBFFに対するリアーキテクチャの試み」というタイトルでメルペイ Engineer Produ
業務で BFF の開発をおこなっているが、その役割を十二分に活かすことができていないという感覚がある。明確に言語化できる問題点もあれば、ふわっとした違和感程度のものもあり、いずれにせよ、自分の BFF に対する理解が不十分な点を改めなければならないという結論に帰着した。そこで、BFF に関するインターネット上の信頼できそうな情報を読んでいき、ここにまとめていこうと思う。
はじめに 次のような方を対象にしています。 BFFアーキテクチャの通信の流れを知りたい BFFサーバの役割、メリットを実感したい BFFサーバで行うGraphQLとRESTのプロトコル変換の手法を知りたい この記事で取り扱わないこと Next.js、NestJS、GraphQLの基本的な文法や環境構築の解説 BFFの役割 本稿での説明は割愛させていただきます。 こちらの記事が非常に勉強になりました。 API合成 プロトコル変換 クライアント最適化 エッジ機能 サーバーサイドレンダリング（SSR） 本稿ではそのなかでもプロトコル変換に焦点を当て、解説していきます。 実現したいこと 通信の流れ
はじめに こんにちは!! プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow 普通のバックエンドエンジニアの takkun7171 でございます。 最近 netflix で サイバーパンク エッジランナー を見て、やっぱりサイバーパンクいいなあと思って、PS5 のサイバーパンク 2077 を衝動買いしました w まああんなディストピアで幸せに生きていける気がしないけどね w tRPCとは こちらの記事で紹介されているのですが、 Theo 氏が提唱した最近話題の T3 Stac という技術スタックがあります。 この中の1つとして紹介されている tRPC が、 これから流行るかもしれない BFF フレームワークです。 何が良いの？ next.js の素の API よりも、TypeScript との親和性が高く、 型安全な API 開発が可能です。(
はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 3年前に行われたZOZOTOWNの大規模なリニューアルを行う際、リプレイスプロジェクトと関連する課題を解決するためにBFF（Backends For Frontends）の導入が行われました。今回は、その経緯と効果を紹介します。 目次 はじめに 目次 はじめに ZOZOTOWNの課題とBFFによる解決 通信量の増大 パーソナライズ機能の追加 BFFによる解決 アーキテクチャの説明 BFFをマイクロサービスとして構築 BFF構成にて見えてきた課題 キャッシュの導入 Redisをキャッシュに使う キャッシュを導入したことによる新たな問題 キャッシュスタンピードの対策 サービスの可用性 BFFは可用性が大事 各マイクロサービスに依存し
こんにちは。エージェントチームの佐藤です。 近年、サービスの開発手法の1つとしてBackends For Frontends(以下、BFF)というアーキテクチャを採用する現場が増えています。 それを受けて、弊社フロントエンドエンジニア(以下、FE)と様々な職能のメンバーでBFFの概念や導入事例、そして開発で気をつけていることについて話しているので、ぜひチェックしてみてください！ 幅 ：フロントエンドエンジニア兼BFF／Vtuber好き。飯野さんと前職から同じ。石神：フロントエンドエンジニア／ドローン領域に詳しい長津：カドベヤCOO／弊社WEBディレクターの長(おさ)的存在橋本：キャリアコンサルタント・エージェント部Mgr／ヤクルトと家族大好き飯野：開発ディレクター（以下、開発D）／ゲーム好きなカドベヤのお兄さん古川：WEBディレクター・クリエイティブ部Mgr／サーファー須田：UIデザイナー
マイクロサービスアーキテクチャでよく利用される、APIGatewayパターンとBFFについて調べたのでメモ なぜAPIGateway? マイクロサービスアーキテクチャでシステムを構築する場合、複数のサービスを組み合わせる形でシステムが構築される。 たとえば、ECサイトの商品詳細を表示するために、商品情報サービス、レコメンデーションサービス、レビューサービスを利用する必要がある、ということ。この場合アプリケーションの実装によっては並行リクエストを行うのが難しかったり、モバイルアプリケーションの場合は帯域の問題も発生する。（その他にもいろいろあるが割愛） そこで、アプリケーションとサービスの間にAPIGatewayというレイヤーを追加することで問題を解決する。 APIGatewayの実装 単純な場合はこの図のようになって、全てのアプリケーションからのリクエストを１つのAPIGatewayで受け
ZOZO Tech Meetup〜マイクロサービス化に取り組む、16年目のZOZOTOWN〜 にて登壇した際のスライドです
はじめに sweeep CTOの平下です。先日CADDiさん主催のこちらで「BFFとmicroservicesアーキテクチャ」というテーマでLTさせていただきました。そのときのLT内容を記事にしました。 発表したスライドです。 以下記事の内容です。 BFFとmicroservicesアーキテクチャ採用の背景 GraphQL/BFF導入のメリットと課題 まとめと今後の課題 1. BFFとmicroservicesアーキテクチャ採用の背景 モノリスなアーキテクチャ プロダクトローンチから3年経過し、技術負債がかなりたまっていました。 モノリスなアーキテクチャには以下の課題がありました。 モノリスなアーキテクチャを同時修正でコンフリ 単一DBでデータの肥大化。マイグレーションなど大変 凝集度が低く修正箇所漏れ そのためコンフリやデグレで開発速度低下や機能リリース遅れが生じていました。 micro
こんにちは、エンジニアの taroodr (中村)です。 3ヶ月ほど前アウトドア用品の中古品買取と販売を行うhinataリユースの新規開発が立ち上がり、私が大枠の技術選定をすることとなりました。 www.hinatareuse.jp 結論 はじめに結論を書いておきます。 最初はマイクロサービスの設計パターンの1つである BFF(Backend For Frontend) を導入する構成で開発を進めました。 しかし、ある問題が発生し最終的にはバックエンドとしては1つのAPIサーバのみの構成に移行しています。 この記事ではなぜ上記のような結論に至ったのか背景と意思決定の理由を時系列に沿ってお話しします。 アーキテクチャの全体像 最初に考えたアーキテクチャの全体像は図のような形です。 この図の黄色の枠線で囲んだ部分が新規で開発する部分です。 現在kubernetes上にすでにいくつかのマイクロサ
JJUG CCC 2019 Springの登壇資料です。 http://www.java-users.jp/ccc2019spring/#/sessions/7fbef8cc-bf8d-4855-8534-c7fca118fb1d
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く