概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer(主戦場はフロントエンド)の Kazuya です。2022 年 2 月入社でそこまで日が経っていないので、今回は社内の技術スタックではなく、今後社内でも検討されるかもしれない「BFF」について触れていきたいと思います。BFF(Backend For Frontend)導入することで得られるメリット/デメリット、GraphQL を用いた技術スタック事例など紹介していますので、ぜひ参考にしてもらえればと思います。 BFF とは? BFF とは、Backend For Frontendの略称で、「フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン」のことです。これだけだと分かりづらいので簡単にまとめると、「バックエンドの API
特定のフロント エンド アプリケーションやインターフェイスによって使用される個別のバックエンド サービスを作成します。 このパターンは、複数のインターフェイスのために 1 つのバックエンドをカスタマイズすることが非効率な場合に役立ちます。 このパターンは、Sam Newman が初めて説明しました。 コンテキストと問題 アプリケーションは、当初デスクトップの Web UI 用に導入される場合があります。 通常、バックエンド サービスは、その UI に必要な機能を提供するために、並行して開発されます。 アプリケーションのユーザー ベースが増えてくると、同じバックエンドとやりとりする、モバイル アプリケーションが開発されます。 その結果、バックエンド サービスは、デスクトップとモバイルの両方のインターフェイスの要件に対応する、汎用的なバックエンドになります。 しかし、モバイル デバイスの機能は
It’s time to make good on our promise to use the dependency inversion principle as a way of decoupling our core logic from infrastructural concerns. We’ll introduce the Repository pattern, a simplifying abstraction over data storage, allowing us to decouple our model layer from the data layer. We’ll present a concrete example of how this simplifying abstraction makes our system more testable by hi
Send feedback Common design patterns Stay organized with collections Save and categorize content based on your preferences. Empty Responses The standard Delete method should return google.protobuf.Empty, unless it is performing a "soft" delete, in which case the method should return the resource with its state updated to indicate the deletion in progress. For custom methods, they should have their
If you have any I/O-bound needs (such as requesting data from a network, accessing a database, or reading and writing to a file system), you'll want to utilize asynchronous programming. You could also have CPU-bound code, such as performing an expensive calculation, which is also a good scenario for writing async code. C# has a language-level asynchronous programming model, which allows for easily
こんにちは、研究開発部 Architectグループの藤岡です。 4/26(水)〜 4/28(金)で研究開発部内の技術研修を行ったので、その内容を公開します。 目次 目次 研修の目的 研修の概要 実践編の概要 アプリケーションを作成 バッチを作成 gokartとは パイプラインを実装 APIを作成 FastAPI とは APIを実装 ディレクトリ構成 実行 Webアプリを作成 Streamlitとは Webアプリを実装 Docker化 デプロイ ECRにイメージをプッシュ アプリケーション基盤 Circuitについて アプリのマニフェストを作成 研修終了後 終わりに 研修の目的 この研修の主な目的は、新卒社員がスムーズに業務に入れるようにすることです。 研究開発部にはさまざまなバックグラウンドを持つ研究員が入社するため、チーム開発の経験がない方もいます。 そのため、Gitの操作やプルリクエス
28th July 2021 I’ve been exploring an architectural pattern for publishing websites over the past few years that I call the “Baked Data” pattern. It provides many of the advantages of static site generators while avoiding most of their limitations. I think it deserves to be used more widely. I define the Baked Data architectural pattern as the following: Baked Data: bundling a read-only copy of yo
システムプラットフォーム部で SRE をやっている id:nabeop です。システムプラットフォーム部を一言で表すと、基盤を横断的に見る部署という感じです。 過去の発表などでもたびたび言及していますが、はてなのいくつかのサービスは AWS 上で構築されており、これまで「クラウドに構築する」は「AWS で構築する」とほぼ同義な世界でした。 ただし、AWS 以外も全く使っていなかったわけではなく、小さなプロジェクトや個人では Google Cloud の利用もありました。また最近は、各サービスで技術選択の多様化が進み「Google Cloud 上でサービスを構築する」という選択肢も十分ありえる状態になってきました。 このため、各サービスで Google Cloud の利用が本格化する前に、安心して使えるように IAM (Identity and Access Management) など環境
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く