NATS Architecture Question with micro

[jasonmccallister]

This is probably just me not doing things right, but worth an ask.

I’m developing a HTTP API that is going to handle events from another system, some of these are short lived and most are long running tasks. The API is deployed to a single region, but the events need to occur in a specific region.

Since most of the events are long running, the API filters the events and validates payload and sends a message with the required data (headers and etc) and subject. I had a working version of a custom Go package that would listen to subjects for that specific region and perform the work, but it feels cumbersome to have a giant struct with all the dependencies. Then I remembered the work being done on the micro package. However, its design is more for request reply semantics, which makes a lot of sense but now I feel like I’m missing out on some of the benefits of that package (stats, done and error handlers). Ideally it would be great to deploy the service that does the work in the region using micro, but also have it be somewhat async for those long running jobs.

Am I missing something that would glue this together or do I need to kind of rethink the design?

[Jarema]

Hey. Yes, micro is designed around request/reply.

You can make it a bit more async with goroutines, but for more straightforward pub/sub pattern, micro framework stats would not make enough sense and would probably require a different abstraction layer.