nats

[gedw99]

https://github.com/asyncapi/event-gateway currently uses Kafka, but i think adding nats is not hard actually.

You currently use watermill, and so perhaps the nats watermill can be integrated: https://github.com/ThreeDotsLabs/watermill-nats

[gedw99]

Ah i just noticed that they use stan.go, which as i understand it does not use NATS Jetstream. But not sure.

here: https://github.com/ThreeDotsLabs/watermill-nats/blob/master/go.mod#L7

[smoya]

Is there any specific reason we would need Jetstream as a MUST ? (never used it, so I'm asking from the ignorance)

[derberg]

@smoya have a 👀

[jonaslagoni]

Would also love to see support for NATS here 🙂

[gedw99]

I also raised it with the NATS team btw

nats-io/nats.go#864

[smoya]

@gedw99 First of all, I want to say thanks for this discussion. Definitely, NATS should be considered and be supported by AsyncAPI Event-Gateway.

TL;DR: Adding full NATS support means two things: Proxying NATS requests + adding a NATS Watermill pub/sub for event-routing. The first would be to create a new proxy (like the kafka one but for NATS). The second is not fully supported; more about this is below and I'm more than happy (sooo happy!) to help people jump in.

We are in a very early development stage, where only Proxying feature is implemented, having Kafka as the only protocol supported.
Meaning, the only feature we have now available is using the application as Kafka proxy (meaning you can point your clients to this proxy) so you can do things based on the proxied messages (such as message validation, which is the only thing implemented now).

The whole event routing functionality of the Event-Gateway is totally a TODO at this point. Having Watermill makes having most of the core features related to it be under control, however, we should work on the orchestration/configuration side on top of Watermill. Asking questions such as "How do we configure the whole message pipeline, such as ports for input/output and pub/subs, rerouting, middlewares, multiplexing, etc?" would be the path to start from IMHO.

I have some things in mind regarding this topic, such as mixing how KrakenD does for their gateway but adapting it to our EDA world. Also perhaps considering a mix of that plus https://serverlessworkflow.io/ ? Maybe there are solutions already in the market that solve this so we can use as inspiration.

I'm aware I should start creating some issues on this repository so we can use it as some sort of roadmap guidelines 😅 .

I'm more than happy to help people jump in on the project, work with them on all of this, so we can all move forward in the direction we believe the project should take!

[gedw99]

Great and thanks for making this open to ideas / input.

Lura / krachend seems to make sense since it is runtime based configuration. Lura is also in the Linux Foundation too.

Someone asked about why / if we need Jetstream. We do for clustering / durability / HA reasons I think. I presume that’s a requirement of the the message broker .

I wonder if watermill dependency is needed. There are a few nats Jetstream t out there these days .
i don’t know enough of what semantic properties this Event Gateway requires if the NATS proxy .