Architecture help
Hi all, just trying to get some advice, best practices etc...
I'm working on a platform at the moment which has the following pattern for all CRUD operations:
UI > API > Service
With today's patterns are a lot more of the CRUD functions performed at an API level, reducing the need for services?
14 Replies
no you'd still have some kind of separation between the API surface and the business logic
thanks @Jimmacle - I see with a lot of examples these days all talk about API's so wasn't sure if the days of a Windows Service were gone 😆
i didn't mean windows service, that's not what people usually mean when they say that
that looked like code layers, like UI code calls an API that uses a service class to get the required data
ah sorry, I mean physical boundaries so in this example (which is the same for all 'applications' across our platform):
UI (Angular) sits on our Web server
API (.Net) lives on our API server
Server (.Net console as Windows Service) lives on one of our APP Servers
the common path would be:
UI > API via HTTP Get/Post
API > Windows Service via MessageBus
these are also currently each in their own Repo and have their own pipelines etc...
in that case i would think the business logic tends to be built into the API application unless you have a more complex system that requires that separation
I wouldn't say it's complex at all, just the pattern that has been copied across the platform.
It's a basic validation check and then insert, in most cases
I'm under the impression that it should only be sent up to an app server if it requires background task processing etc...?
i'm not sure what an app server is in this context
for basic CRUD i'd 100% put it all in the same application
Sorry, it's terminology that we use within the business. When I say app server I'm referring to a windows service that's communicated to via a message bus
How would you handle recoverability if the CRUD failed to execute?
what needs to be recovered? at least for me most of my CRUD is done in a single DB transaction and it either all succeeds or all fails
i guess a better question is how do you handle recoverability with your current setup?
I think that's why it's become a crutch to use the message bus, so if it fails, the message can be replayed
my projects are 99% user event driven so i just pass failures back to the UI, for the few things that are automated i use hangfire which will automatically retry jobs if they fail
everything built into a single application
A single monolith application?
How do you scale or have multiple instances?
i don't, i do internal software for a small office
We currently have something similar to:
10 UIs
15 apis
100+ console applications
But all these are using a single database broken up by schemas