モダンBFFを活用した既存APIサーバーの再構築 - クックパッド開発者ブログ
技術部の青木峰郎です。 去年までは主にデータ分析システムの構築を担当していましたが、 最近はなぜかレシピサービスのサービス開発をやっています。 今日は、そのサービス開発をする過程で導入したBFF（Backends for Frontends）であるOrchaについて、 導入の動機と実装の詳細をお話しします。 Orcha導入にいたる経緯 まずはOrcha導入までの経緯、動機からお話ししましょう。 最初のきっかけは、わたしが去年から参加しているブックマークのようなサービスの開発プロジェクトでした。 このプロジェクトの実装のために新しいmicroserviceを追加することになったのですが、 そのときにいくつかの要望（制約）がありました。 1つめは、撤退するとなったときに、すぐに、きれいに撤退できること。 2つめが、スマホアプリからのAPI呼び出し回数はできるだけ増やしたくない、という要望です。
分散キューという名の苦しみ - Software Transactional Memo
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
Webサービスにおけるインフラアーキテクチャの体系化とインフラアーキテクチャの選択自動化の研究課題についての整理と考察 - masayoshiの日記
第1回WSA研究会 開催概要 - Web System Architecture 研究会 (WSA研)で発表したときの予稿になります。 今回はWSA研の第一回ということもあり、自分自身で何をしたいのかという点を整理するための発表という形になりました。 まだ、整理や調査が不十分である状態ではありますが、WSA研のような場所で現状できているところまでを報告し、色々議論できたことでよりより調査を行えるかなと思っています。 このように、明確な成果でなくても発表し議論できるところがWSA研のいいところかなと思っている*1ので、興味ある人はぜひ参加を検討してみてください。 発表資料 speakerdeck.com 研究テーマ Webサービスにおけるインフラアーキテクチャの体系化とインフラアーキテクチャの選択自動化の研究 研究背景 Webサービスに求められるユーザ要求は，高度かつ激しく変化する． それに
How to break a Monolith into Microservices
What to decouple and when As monolithic systems become too large to deal with, many enterprises are drawn to breaking them down into the microservices architectural style. It is a worthwhile journey, but not an easy one. We've learned that to do this well, we need to start with a simple service, but then draw out services that are based on vertical capabilities that are important to the business a
CQRS パターン - Azure Architecture Center
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 CQRS はコマンド クエリ責務分離を表し、データ ストアの読み取りと更新の操作を分離するパターンです。 アプリケーション内に CQRS を実装すると、そのパフォーマンス、スケーラビリティ、セキュリティが最大化される場合があります。 CQRS への移行によって生まれる柔軟性により、システムは時間の経過と共にさらに進化し、更新コマンドでドメイン レベルのマージ競合が発生することを防ぐことができます。 コンテキストと問題 従来のアーキテクチャでは、データベースの更新とクエリに同じデータ モデルが使用されます。 このシンプルな方法は、基本的な CRUD 操作に適しています。 ただし、複雑なアプリケーションの場合、こ
Azure アプリケーション アーキテクチャの基礎 - Azure Architecture Center
このコンテンツ ライブラリは、Azure においてスケーラブル、安全で回復力がある高可用性のアプリケーションを設計するための体系化された方法を示します。 このガイダンスは、顧客エンゲージメントから学んだ実証済みのプラクティスに基づいています。 はじめに クラウドによって、アプリケーションの設計とセキュリティで保護する方法が変わりつつあります。 アプリケーションは、モノリスではなく、小さな分散サービスに分解されます。 これらのサービスは、API を介して、あるいは非同期メッセージングまたはイベントを使用して通信します。 アプリケーションは、需要に応じて新しいインスタンスを追加して水平方向に拡張します。 このような傾向により新たな課題が生まれました。 アプリケーションの状態は分散されます。 操作は並列かつ非同期的に実行されます。 障害が発生しても、アプリケーションは回復力があることが必要です。
マネーフォワードの子会社MF KESSAIが選択したアーキテクチャ
Rails Developers Meetup 2018
The Clean Architecture
In the weeks since I started talking about the need to clean up our architecture, I’ve noticed a surprising resistance to the idea. Apparently the notion that it’s a good idea to hide the framework, UI, or database from the application code is not universally accepted. I first blogged about this topic here , I did a whole cleancoders.com episode on the topic. I’ve also done several keynotes on the
新QiitaでReactをやめてhyperappを採用した背景 - Qiita
12/1 に Qiita のトップページをリニューアルしました。これまで React を使っていましたが、それをやめて hyperapp を採用しました。まわりを見てもあまり採用事例が見当たらないので、この記事では一体なんで今をときめく React ではなく hyperapp を選択したのか、どういうところが魅力的なのかについて プレゼンテーション層を実装するためのツールとして 学習コスト の観点から書きたいと思います。なおこの記事に書かれていることは全て個人の感想であり、はっきりいって個人の日記レベルです。 それと hyperapp の開発者が社内にいるという事情もあるので、そこら辺さっぴいて読んでください。 TL;DR プレゼンテーション層を実装するためのツールとして React は機能過多だし、機能不足 hyperapp は過不足ない 学習コスト 仮想 DOM は学ぶ価値のある知識
The 4 Layers of Single Page Applications You Need to Know | HackerNoon
Too Long; Didn't ReadEvery successful project needs a clear architecture, which is understood by all team members. Let’s architect a React application from the ground up, exploring the domain and its services, store, application services and the view. The four layers of single page applications — by Alberto V Every successful project needs a clear architecture, which is understood by all team memb
10分で振り返るソフトウェアアーキテクチャの歴史2017
CAMPFIRE iOS #1 - connpass https://yj-meetup.connpass.com/event/51735/ での発表資料です。 (2017/3/23追記): 各所からいただいたフィードバックに基づき、不正確な記述を修正しました。（Nyohoさん、あんざ…
Node におけるスケールアーキテクチャ考察(SSP 編) - Block Rockin’ Codes
＊息抜きがてら書いていたら長くなってしまった。。 ＊当たり前ですが、あくまで個人的な考えです。 ＊ころころ変わるかもしれません。 Node の基本的な知識についての話は色々なところで出始めて、 じゃあこーいう場合はどうするの？ みたいな話が出始めたりもするようになってきた気もします。 正直、自分にもまだ分からないことだらけです。 そもそも自分はそこまでスケールに関するアーキテクチャや、OS の低レイヤに精通しているとは言えないので、 これを期に Node は何が得意で何が不得意なのか、スケールさせるために考えないといけないこと、などを自分なりにまとめて、 ついでに、これまで学んできた周辺のアーキテクチャに関する知識も混ぜて、色々思考実験をしてみたいと思っています。 だから WebSocket にブラウザが対応してないとか、そんな複雑なサーバ群本当に運用できるのかとか、 そういう話は無しに、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Atomic Architecture