Version 2.0 Features and Roadmap

[WonderPanda]

There are recurring requests from the community around things like better error handling, retry logic, custom message parsing and validation.

Many of these issues can be addressed together by deciding to make some breaking changes to the API surface instead of trying to tack on non-breaking changes to the current design.

The goal of this discussion is to facilitate brainstorming and consolidated feature requests for what the next version of the library should be capable of.

Any example interfaces/API suggestions are welcome.

[igorz24]

Regarding RabbitMQ

I've started using this library recently and I think it is pretty decent, though it lacks some functionality.
It would be great to unify publish() and request() API.

1. Under the hood request() uses publish() anyway, so it would be nice to have similar API. I don't understand why one of the methods is defined with several parameters, while the other expects an object. (There might be something preventing that, that I'm not aware of).
2. Right now it's impossible to pass custom options into request(). It would be great to extend its definition and allow that.

Regarding those two points, some potential API change may look like this:

public publish(
  exchange: string,
  routingKey: string,
  message: any,
  options?: amqplib.Options.Publish
)
public request<ExpectedReturnType>(
  exchange: string,
  routingKey: string,
  message: any,
  options?: amqplib.Options.Publish & {correlationId?: string; timeout?: number} //simplification
)

Instead of this:

public publish(
  exchange: string,
  routingKey: string,
  message: any,
  options?: amqplib.Options.Publish
)
public request<ExpectedReturnType>({
    exchange: string;
    routingKey: string;
    correlationId?: string;
    timeout?: number;
    payload?: any;
})

3. It's also impossible to pass custom options while returning response from @RabbitRPC handlers. It would be great to do that. As suggested in How to set response message contentType from rpcHandler? #228 by @WonderPanda we could try passing options object as an additional field in response, which might look like this:

@RabbitRPC({
    exchange: "exchange",
    routingKey: "routing.key",
    queue: "test.queue",
  })
  async doStuff(data: Stuff): Promise<{message:any, options: amqp.Options}> {
    const stuff = ...
    return {
       message: stuff:
       options: { ... }
    }
  }

Or we could allow @RabbitRPC to be provided with additional function, that would postprocess outcoming message (and why not the other one to preprocess incoming message). This might look sth like that:

// Function may take exchange name, routingkey, queue name and message content in order to calculate the options dynamically
const postProcessFoo = (exchange: string, routingKey: string, queue: string, message: any): Options => ({
 contentType: "application/json"
 ...
})

@RabbitRPC({
   exchange: "exchange",
   routingKey: "routing.key",
   queue: "test.queue",
   postProcessor: postProcessFoo
 })
 async doStuff(data: Stuff): Promise<{message:any, options: amqp.Options}> {
   const stuff = ...
   return stuff;
 }

I hope this makes sense.

[WonderPanda]

@igorz24 Thank you so much for taking the time to give some thought about the current API surface and potential room for improvement. I definitely agree that it's weird that there's both a method that takes positional arguments versus one that takes an object for similar operations.

I'll take some time to absorb these requests and how best to look at breaking this up into some actual issues.

Before I decide on the best way to pass options when returning responses from Rabbit handlers I want to take another pass on the current state of integration between these handlers and actual NestJS interceptors to see if there are some nice ones that can be provided so that we continue to use patterns that the ecosystem is familiar with as opposed to the possibility of adding it as an additional decorator property like your example here:

// Function may take exchange name, routingkey, queue name and message content in order to calculate the options dynamically
const postProcessFoo = (exchange: string, routingKey: string, queue: string, message: any): Options => ({
 contentType: "application/json"
 ...
})

@RabbitRPC({
   exchange: "exchange",
   routingKey: "routing.key",
   queue: "test.queue",
   postProcessor: postProcessFoo
 })

[igorz24]

You're right. Interceptors would fit perfectly here.

[underfisk]

I do think that allowing custom pipes for the data on RPC is really important for data validation, you could run class-validator by default but it does make sense to have it
Also, another thing is rejecting promises to throw a custom message but that would also require some internal structure to defer from a normal message
At least having pipes/guards working would be really cool, the nestjs rabbitmq module does that so i think it would make sense this library provide also the basic features