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

support annotation-based approach

オープン
#541 コメント 6 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
java

調査の方向性

まず、現在の ctx.run() の使用方法と issue 内の @Workflow の例を確認し、その後、責任を呼び出されるメソッドに移すことで他のコンテキストメソッドにどのような影響があるかを比較します。実装前に、アノテーションのセマンティクス、サポートするメソッド境界、互換性に関する想定を定義します。アプローチが仕様化され、その実現可能性が解決されれば完了です。

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

説明

I don't like passing all the app logic as lambdas because it makes the codebase messy. It would be great if Restate used an annotation-based approach instead (or something else), which would mean moving the responsibility from the caller method to the called method

What if we created a @Run annotation instead of calling ctx.run()? For example:

  @Workflow
  public boolean run(WorkflowContext ctx, Email email) {
    String secret = ctx.random().nextUUID().toString();
    ctx.set(STATUS, "Generated secret");

    // ctx.run("send email", () -> sendEmailWithLink(email, secret));
    sendEmailWithLink(email, secret);
    ctx.set(STATUS, "Sent email");

    String clickSecret =
        ctx.promise(EMAIL_CLICKED)
            .future()
            .await();
    ctx.set(STATUS, "Clicked email");

    return clickSecret.equals(secret);
  }

  @Run("send email")
  public void sendEmailWithLink(Email email, String secret) {
       // ......
   }

That's not only for ctx.run(), it can be applied to a lot of methods.

主要言語
Java
スター
60
フォーク
17
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

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

restatedev/sdk-java のほかの issue

restatedev/sdk-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

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

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