Saunter fork ready

[yurvon-screamo]

Hello, i`m rewrite saunter and ready to maintenance and support new version.

link

Additionaly - created pull requests, if current repo maintenaner are interested

Self roadmap list:

The main purpose of the stage works is to make it possible to describe an operation in 1 attribute without restrictions on the number of operations per method/class

• [X] To dotnet 7

• [X] To asyncapi 2.6.0

• [X] Set required and nullable props to schema

• [X] Give the opportunity to work with multiple operations in the one class/method

• [X] Kill channel attribute:

  [SubscribeOperation("asw.tenant_service.tenants_history", OperationId = "TenantMessageConsumer", Summary = "Subscribe to domains events about tenants.", ChannelDescription = "Tenant events.")]
  public void PublishHelloWord(string content) { }
  

• [X] Rework message attribute:

  [SubscribeOperation<BrokerHelloWorldDto>("asw.tenant_service.tenants_history", OperationId = "TenantMessageConsumer", Summary = "Subscribe to domains events about tenants.", ChannelDescription = "Tenant events.")]
  public void PublishHelloWord(string content) { }
  

  [Message(Title = "Hello world, i`m class")]
  public record BrokerHelloWorldDto(string content);
  

• [X] Kill channel params attribute (auto detect parameters from channel name)

  [SubscribeOperation<BrokerHelloWorldDto>("asw.tenant_service.{tenants_name}", OperationId = "TenantMessageConsumer")]
  public record BrokerHelloWorldDto(string content);
  

• [X] Redo the processing of multiple documents in the application (save default document with null name!!)

  [SubscribeOperation<BrokerHelloWorldDto>("asw.tenant_service.{tenants_name}", OperationId = "TenantMessageConsumer", DocumentName = "Foo")]
  [SubscribeOperation<BrokerHelloWorldDto>("asw.tenant_service.{tenants_name}", OperationId = "TenantMessageConsumer")]
  public record BrokerHelloWorldDto(string content);
  

• [X] Rewrite usage docs:

  • [X] Fast start guide
  • [X] Description of the basic config in di
  • [X] Description of the operation attribute (+ description of working with channel parameters)
  • [X] Description of the message attribute
  • [X] Description of working with multiple documents

• [X] Nuget package

• [X] Usability test on my environment Based on the results of the check in my environment. Using the library has become much more convenient, but there is not enough flexibility in implementation. Next, I will develop the library towards tools WITHOUT attributes. Example case:

    public void SubsribeApplication() {
        _js.SubByChannel<MyEvent1>("qwerty", _ => Console.Writeline("hello world"));
        _js.SubByChannel<MyEvent2>("qwerty.123", _ => Console.Writeline("hello world"));
        _js.SubByChannel<MyEvent3>("qwerty.zxc", _ => Console.Writeline("hello world"));
        _js.SubByChannel<MyEvent4>("qwerty.qwerty", _ => Console.Writeline("hello world"));
    }
  
    // ...
  
    private void SubsribeByChannel<TEvent>(this IJetStream js, string channel, Action<TEvent> handler) {
        // honestly, I want to define the operation here. 
        // example:
        // _operations += new PubOperation<TEvent>(channel);
        js.PushSubscribe(channel, (_, m) => handler(_parser.From(m.Msg.Data)));
    }
  

• [X] Release !!

Known limitations of the version that will be received at this stage:

• There is no support for description and location for channel parameters from attributes (only from components ref)

[cvietor]

that's great news! just as a little info, there is already a package called AsyncApi.Net from Lego, so you might consider a different name to avoid confusion:

[yurvon-screamo]

that's great news! just as a little info, there is already a package called AsyncApi.Net from Lego, so you might consider a different name to avoid confusion:

Lego package is asyncapi dto + serializer, my package is document generator. + I'm thinking of rewriting the library using the lego package, then it will be a great addition and the postfix will be useful)

[m-wild]

I agree that this (the generator package) should use the base AsyncAPI.NET package from Lego.

The fork looks fine, but I'm not really sure it's mergable with all the namespace and file path changes.

What would you like to do with this fork?

[yurvon-screamo]

I agree that this (the generator package) should use the base AsyncAPI.NET package from Lego.

The fork looks fine, but I'm not really sure it's mergable with all the namespace and file path changes.

What would you like to do with this fork?

The purpose of my work is very simple - to make a workable library that will close the tasks assigned to my team.

I'm not suggesting we merge our versions. The request pool was created more for information purposes.