CODEWITHSUNDEEP
asp.net-web-apiarchitecturenservicebus
Mark
Mark

Reputation: 149

App architecture with NServiceBus and REST API

We are working on a replacement to our legacy VB6 system that uses a SQL backend. Most of the business logic is in stored procedures and triggers. We currently have some NServiceBus functionality by using triggers in the database to put messages on a queue (SQLTransport).

I would like to build a new clean api that uses all the same tables and stored procedures behind the scenes. Once all of the applications and services are using the new api and messaging systems, then we can start to clean up the backend.

The new frontend will call a REST api to retrieve data. The thing I'm struggling with is best practices performing operations which create/update/delete data. For automated processes that don't require an immediate response, they can just send a command over the bus. However, for the end users that will be using the application, they expect immediate results. If something causes a message to go to FLR/SLR, it's obviously not acceptable for a client to sit there expecting something to happen.

One idea is to have a library that handles all the calls to the database, which both the API and any NServiceBus message handlers can use. The issue I see is when an operation needs to publish an event out. From a message handler, one can simply publish the message. If I'm processing a simple command from the REST api, I can't just publish the same event (as nothing subscribes to the REST api and it could be.

One solution could be to have the REST api send (not publish) a message to the endpoint (the one that other endpoints have subscribed to) which will then publish the event out to all of the subscribers.

How have others implemented something like this? The main use cases I am thinking of are simple create/update/delete operations that a client expects real time results from, but the backend may need to publish an event indicating something has happened.

Upvotes: 0

Views: 1350

Answers (1)

Sean Farmar
Sean Farmar

Reputation: 2293

What you are describing is a challenge and I will not attempt to provide a solution here, however, a couple of pointers...

Synchronous communication (request/response on the same channel) is orthogonal to messaging, messaging communication style is fire and forget.

The concept of CQS (Command Query Separation) where by state changing operations do not reply with data of the changed state, read operations therefore are done on a separate channel is a good guide for building systems using messaging.

Also I would avoid using messaging for read operations (use direct ADO).

CRUD operations are a smell (I get it that this is a legacy code base) as these operations hide any intent or business value.

The solution you will end up with will probably be a mix of messaging and synchronous communication (I assume you are not attempting to rewrite from scratch at this time)

I would be happy to have a more in depth discussion (email me sean.farmar at particular.net)

Upvotes: 1

Related Questions