Is this a good solution for a distributed application (containers, Dapr, Pub / Sub)? Can I inject middleware?

[tgermain-impirica]

How can I add additional capabilities? I would like to have data written to an audit log table, I want to publish to a queue when certain mutations occur (Dapr pub / sub), etc. Is there any way to add middleware to the Api, or is this project more likely to be used for a non-enterprise app? It seems great for quickly rolling out a simple Api to expose a database, but seems to be lacking some required hooks.
Can you advise on a pattern that might work? Maybe using DAB for the query side of a CQRS pattern and Web Api for the mutations? Or maybe a proxy that requests go through before hitting DAB?

Really, I am just looking for advice on if this is really a good solution for a distributed application.

[JerryNixon]

This is an excellent solution. As you may know, DAB has a narrow scope – it exposes CRUD operations against various backends through REST and Graph endpoints. DAB doesn't support middleware, per se. However, you still have several options to do what your middleware does: either within the client pipeline or on the data layer (using a stored procedure). Though DAB is intentionally designed as a closed box to make it accessible for all kinds of developers, we are planning to support custom scripts to re-project results in some future version. That could be a while, though, so don't build a dependency on that just yet. Although this is not exactly middleware, it will cover a lot of the customizations we anticipate.

So that's the answer. Please, please share your scenario. And don't miss this.

As far as CQRS implementation, the extremely small size of DAB is a real benefit to this pattern. There are a million questions that need to be answered before anyone should give "general" guidance, but here's a strawman architecture that shows how Data API Builder is a solid piece of a much larger puzzle. This is a far different conversation than the middleware one above. As far as complex mutations, every solution is going to have its own special requirements. If yours are special, a custom endpoint to handle them is something you should be thinking strongly about anyway. Offload the SQL complexity to stored procedures. Offload the procedural complexity to your C# backend. But let DAB do what it does very well, straightforward CRUD ops. If the complexity of this diagram is a little much for your project, the more you dial it back, the more likely DAB is going to become a good fit again.

Please note, this architecture just shows what it could look like. This isn't what your solution should look like - because I do not know your situation. In this case, though, the requirements for the client are clearly robust and the data is significant and fast moving. Maybe you can steal some of these ideas. Nonetheless, it also shows how DAB can be a nice part of most architecture but in no way is it the answer to all the problems a solution needs to solve.

[JerryNixon]

Let me know if I am missing anything.

[tgermain-impirica]

Hi Jerry,

This is very insightful, thank you!