Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Serverless] Case: monolithic deployment

オープン
  • 何か問題がありますか？
#161 コメント 7 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 7 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
15/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
csharp
領域
backend, distributed-systems

調査の方向性

Start with the linked Wait strategy in the read-model concept docs and compare it with the three approaches described here. The issue does not name code files or tests; first identify the subscription and command API entry points that implement read-model waiting. Done means choosing and implementing a serverless approach that reliably waits for all produced events to be processed, with behavior and tests defined.

索引モデルが issue の本文から書いたものです。

説明

enhancement serverless subscriptions

How to make subscriptions work in a serverless world?

Simplest scenario: monolithic deployment

The whole application represents a single bounded context, where commands and queries are combined into a single deployment unit. Such an application would include all the necessary components:

  • Command services
  • Command APIs
  • Query services
  • Read model subscriptions
  • Gateways

There are two ways to make it work:

  1. Just do nothing. Expect the function/container timeout to be enough for all the subscriptions to handle newly produced events. It would work in many cases, but there's no resilience against external infrastructure failures for event handler targets.
  2. Ensure the command is handled in an asynchronous unit of work. The command service would do its thing, as usual; there's no change required. Subscriptions would expose an internal HTTP API to report the last processed event position. A new function is needed to poll the API from inside the service, simulating traffic until all the subscriptions get beyond the position of the last produced event. It will prevent the function from being shut down (in theory).
  3. Ensure the command is handled in a synchronous unit of work. The command API will block until all subscriptions handle all the produced events in the application. It requires some method of internal asynchronous communication. Subscriptions will produce internal messages with the latest processed event position. The command API can observe these messages, so it can ensure that all the new events are handled. After that's confirmed, the command API returns the response as usual.

The last point also applies to non-serverless scenarios, where we must ensure that read models are updated. It essentially implements the Wait strategy from the docs.

主要言語
C#
スター
512
フォーク
99
平均マージ
5日 6時間
マージ済み PR（30日）
5

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Eventuous/eventuous のほかの issue

Eventuous/eventuous の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。