タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
BFFとは Backend for Frountendの略で、UI/UXを向上させる目的でフロントエンド専用のサーバーを用意したアークテクチャパターンです。 Webアプリケーションサーバーは下記の処理を行います。 リクエストを受ける DBからデータの取得・更新 ページを構築 (これはクライアントですることも) ページ or データの返却 このうち、「DBからデータの取得・更新」とそれ以外をフロントエンドとバックエンドの役割に明確にわけます。 BFFの役割となるサーバーをクライアントをWebサーバーの間に設け、「リクエストを受ける」と「ページ or データの返却」、場合によっては「ページの構築」をここで処理します。 こうすることで、これまでリクエストというUX関わる部分をフロントエンドエンジニアの責務に移行することができます。 ページの構築をクライアントではなくサーバーで行う場合、これもBB
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。2022 年 2 月入社でそこまで日が経っていないので、今回は社内の技術スタックではなく、今後社内でも検討されるかもしれない「BFF」について触れていきたいと思います。BFF（Backend For Frontend）導入することで得られるメリット/デメリット、GraphQL を用いた技術スタック事例など紹介していますので、ぜひ参考にしてもらえればと思います。 BFF とは？ BFF とは、Backend For Frontendの略称で、「フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン」のことです。これだけだと分かりづらいので簡単にまとめると、「バックエンドの API
はじめに こんにちは。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と
ハイクラスエンジニア向け転職・求人サイト。自社開発のWeb企業の求人多数！GitHub登録をすると、IT/Web企業とマッチングします。ユーザーサクセス (キャリア)面談も実施。
LINE株式会社 古田 大志 京都開発室 / 出前館マーチャント部 クーポンサービス チームリード 2023.9.12「モジュラモノリス徹底解剖vol.2〜実践者から学ぶLunch LT〜」の登壇資料です https://findy.connpass.com/event/293748/
Wantedlyでインターンをしている遠藤です。インターンのタスクとして「RustでProtocol BuffersからGraphQL BFFを自動生成する」という技術検証を行ったので、その知見を共有したいと思います。 今回の技術検証で作成したツールのソースコードはここにあります: EXPERIMENTAL] Generate GraphQL schema and gateway from Proto definitions. Licensed under either of Apache License, Version 2.0 or MIT license at your option. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in
【追記情報】 2022/06/15 09:00 誤字修正 + cdkk8sについて言及 先日、ハンドブックを公開しました。 ここではKubernetes上で稼働させた実績値としての記録が紹介してあります。が、逆に紹介していないものもたくさんあります。検証が済んでいないもの、時間的制約から導入できなかったものなど、不完全な情報を紹介しようと思います。 したがって、何も保証するための裏付けはないので「そういうことも検討してたんだなぁ」ぐらいで読んでもらえると嬉しいです。元記事もぜひ読んでみてください。 nodejsのDocker Imageの軽量化 Docker Imageを作る際、多くの場合Image内にnode_modulesを含んだ状態でイメージを作成しています。Nodejsのベースイメージが60〜100MBくらいあるのに対して、ビルド後のイメージサイズは200MB〜1GBくらいまで膨れ
GraphQLはWeb APIを構築するためのとても強力なアプリケーション（仕様）ですが、多面的な特徴を持つためにすぐに理解しづらいところがあるのかなと思ってます。そのためこれまでにいくつか記事を書いてきました。 GraphQLはサーバーサイド実装のベストプラクティスとなるか GraphQLの全体像とWebApp開発のこれから 今回もGraphQLの解説になりますが、今回は特徴を整理し、手短に見ていきたいと思います。GraphQLの理解につながれば幸いです。 GraphQLの特徴を３つに分ける GraphQLの特徴を分けると大きく3つに分かれると考えます。(プラスでエコシステム） APIインターフェスとして Universal BFFとして API Gatewayとして (エコシステム) それぞれ見ていきます。 APIインターフェースとしてのGraphQL GraphQLの最も目立つ部分で
横断組織として考える共通DBの課題解決 〜 桃園の誓いアーキテクチャ 〜 / Addressing Shared Database Challenges as Cross-Team: “Peach Garden Oath” Architecture
Single NodeのDocker Swarmを利用してオンプレミスにデプロイされるGraphQLサーバを安全にローリングアップデートさせている話
2022/06/13に「ニコニコ生放送 WebフロントエンドのKubernetes移行ハンドブック 2022」を公開しました。本発表で…
こんにちは、リクルートテクノロジーズが開発している、B2Bのスマートフォンアプリ『Airシフト メッセージ用アプリ』（以下、メッセージアプリ）でフロントエンドの開発を担当している辻です。Webフロントエンドエンジニアだけで行っている開発の裏側を明かす連載「Webフロントエンドエンジニアだけでスマホアプリ開発」。今回は、開発を円滑に進めるに当たっての技術的な工夫を紹介します。 React Nativeを活用したアーキテクチャ面の工夫 API再利用のためのBFFアーキテクチャ メッセージアプリでは、AirシフトのWeb版のAPIを再利用するために、「Client Adapter Pattern」を参考にBFF（Backends For Frontends）を導入しています。 一般的なWebアプリ開発においては、BFFの責務としてサーバサイドレンダリングを取り入れているのはよくあることだと思いま
BFFとは 名前の通り、フロントエンドのためのバックエンド（サーバ）です。フロントエンドのためにAPIをコールしたり、HTMLを生成したりするサーバ 2000年代前半のWebアプリは、HTMLが主体で動きがシンプルだった。しかしWebアプリが技術進化で複雑化するにつれて フロントエンド側にクライアントごとの要求に応えるためのサーバを配置してバックエンドのAPIサーバとの橋渡し役とするアーキテクチャが開発されるようになりました。 BFFの役割 BFFはフロントとバックエンドの姿勢・方針が乖離している場合に仲介役となることができる [メリ] バックエンドアプリの仕様が完全に固まっていて変更が難しい場合や、バックエンドとフロントが完全に別チームで開発される場合には「バックエンド側での対応が難しいから、フロント側の開発者がBFFを設け、そこで対応する」ことができる [デメ/思ったこと] フロントと
introduction HonoにはRPCの機能があり、routerで定義している情報（引数とか型とか）を他のファイルで簡単に利用することができます。 この記事では、そのRPCの機能とNextを組み合わせて、HonoをNextのBFFとして使用する組み合わせについて紹介していきたいと思います。 まず、今回作成した２つのサンプルのリポジトリを紹介します。 以下の２つのリポジトリのコードを用いて説明するので、もし興味があればクローンして色々試してみて下さい。 next-hono-webはshadcn/uiのコンポーネントをお借りして作成したサンプルのダッシュボードに対して、一部の値を動的に設定するよう変更を加えたものです。 next-hono-backendはとてもシンプルで、next-hono-webで使用するサンプルデータを返すよう定義されています。 next-hono-backend側
仕事で複数のバックエンドから一つのクライアントと疎通するような構成の可能性があり、BFFが使えるかもということで調べてみました。 対象者 BFF(backend for frontend)の概要を知りたい方 どういったメリット、デメリットがあるかを整理したい方 概要 BFF(backend for frontend)とは簡単にいうと、クライアントとバックエンドの中間に位置し双方の複雑性を吸収するような作られたサーバーのことです。雑に書くとこんな感じです。 これが必要になった、背景はクライアントの端末の種類が増加したことそれに伴うロジックの増加です。 例えばweb,スマホ版web,スマホアプリ、デスクトップアプリなど複数のクライアントが登場し、それぞれにメッセージやコンテンツの出しわけを実装しようとすると、クライアント側のコードが複雑化し、冗長なコードを書かざる追えない状態になります。 そう
受発注・サプライチェーン管理システムとサプライパートナー向けシステムに関する現状や課題などについて、開発を担当しているエンジニアが話す「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"
近年バックエンドのマイクロサービス化とクライアントの種類の増加によって、クライアント↔️サーバー間のやり取りが複雑化する傾向があり、その溝を埋めるためにBFF(Backend for Frontend)という特定のクライアントに特化したサーバーを間に置くというパターンが現れました。発表ではBFFの概要、…
業務で BFF の開発をおこなっているが、その役割を十二分に活かすことができていないという感覚がある。明確に言語化できる問題点もあれば、ふわっとした違和感程度のものもあり、いずれにせよ、自分の BFF に対する理解が不十分な点を改めなければならないという結論に帰着した。そこで、BFF に関するインターネット上の信頼できそうな情報を読んでいき、ここにまとめていこうと思う。
bff.md BFF について 参考資料 Sam Newman - Backends For Frontends マイクロサービスの思想から捉える Backends for Frontendsとその類似パターン BFF's cosmos in FOLIO sec at uit BFF（Backends For Frontends）超入門――Netflix、Twitter、リクルートテクノロジーズが採用する理由 (1/2)：マイクロサービス/API時代のフロントエンド開発（1） - ＠IT BFF（Backends For Frontends）の5つの便利なユースケース：マイクロサービス/API時代のフロントエンド開発（2） - ＠IT BFF @ SoundCloud | ThoughtWorks Sam Newman - Backends For Frontends wrote in 2
JJUG CCC 2019 Springの登壇資料です。 http://www.java-users.jp/ccc2019spring/#/sessions/7fbef8cc-bf8d-4855-8534-c7fca118fb1d
はじめに 次のような方を対象にしています。 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 開発が可能です。(
こんにちは。エージェントチームの佐藤です。 近年、サービスの開発手法の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〜 にて登壇した際のスライドです
Merpay & Mercoin Tech Fest 2023 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるEngineeringを知ることができるお祭りで、2023年8月22日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。 この記事は、「gRPC Federation を利用した巨大なBFFに対するリアーキテクチャの試み」の書き起こしです。 @goccy：それでは「gRPC Federation を利用した巨大なBFFに対するリアーキテクチャの試み」というタイトルでメルペイ Engineer ProductivityチームのGoshimaが発表します。よろしくお願いします。 初めに自己紹介です。@goccyというアカウントで活動しています。2012年に新卒で株式会社MIXIに入り、
はじめに 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上にすでにいくつかのマイクロサ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
