Connecting to networked endpoints is an IO task that takes significantly more time than a monolith service's in-memory runtime, and you shouldn't expect to see similar performance with a microservice architecture. What is most definitely not a microservice benefit is response speed. Scalability of services is a great benefit too, but it doesn't always apply in every scenario. The greatest benefit is reaped by simplifying the deployment of individual modules, which is a DevOps benefit more so than an end user benefit. Lastly, don't forget that microservices are not inherently about runtime performance. From what I know, GraphQL allows you to create an endpoint in which clients can dynamically query the data they need. I can't really explain it well due to lack of experience with it. I have no real experience with the tech stack, but it also sounds like GraphQL might be right up your alley for this particular need. The one downside here is that updates to the account package will require a redeploy of the application, but this may be a perfectly reasonable trade-off for your scenario. Your client services can still be independent, but the account service is reusably absorbed into each client service. This also means that different services don't need to merge into one big monolith. Nuget) which contains the basic DAL to access account data, meaning that it's actually your client's runtime which will access the account database while also leaving the DAL extensible for the client to add/alter/extend its querying capability. If you need tight coupling, you should consider different avenues.įor example, rather than an account service, you could opt for an account package (e.g. There's also the consideration that microservices might not be the right fit for you in this scenario. How many accounts are we talking about? How often is this going to be queried? How constrained are you for bandwidth/performance/developer effort? Are there privacy/security/permission concerns for the account data? Which is better? Well, there are a lot of things to consider here. This means that your account service is as general as it can be, but it comes at the cost of using more bandwidth that the client needs, and the client needing to do some less efficient query logic after the fact. To minimize coupling and developer effort, you expose your accounts as a simple list, possibly with some basic filtering. Note that you can still try to generalize each endpoint as much as you can/can be bothered to. This ensures that you get the best query performance by letting the account service's database do the heavy lifting for you, while also keeping bandwidth down to strictly the data you need. To maximize efficiency, you'd develop these separate endpoints. then out of curiosity, what was the better approach before those technologies existed?Īs is often the case, efficiency comes at the cost of having to make things efficient. If the answer is a technology like GraphQL, etc. Is there a pattern that can avoid this kind of coupling? Is there a name for this problem or related concepts? in the upstream service) forces a tight coupling between the upstream and downstream service, namely by having to implement a downstream service's concept as a filter in the upstream service. In layman's terms, it's as if the fact that one must filter at the database level ( i.e. getting 10 items at a time after applying some filter. And a key aspect that highlighted the problem in all the contexts I've seen is, for some reason, paginated views, i.e. The real scenario I'm dealing with is a little more complex, sometimes joining data from multiple upstream services. That is, why does AccountService need to know what PaymentService considers a "valid" account state for billing? Or another perspective: If PaymentService modifies their definition of a valid accounts to bill, they'd have to modify AccountService-doesn't that seem wrong? (Or more sophisticated forms of this.)īut it seems then like my AccountService is being tightly coupled to a feature specific to downstream services. Now, I can obviously expose 2 endpoints in AccountService such as getAccountsWithValidPaymentDetails() and getAccountsWithValidEmail() that execute corresponding SQL queries. For example, PaymentService needs a paginated listing of accounts with the fields business_address, tax_id, and invoiced set meanwhile PreferenceService needs to send batches of emails to accounts whose email field has been set. Suppose each of those services for some reason have to GET a list of accounts according to some criteria. It is a "platform" service used by many other services, such as PaymentService and PreferenceService. Suppose I have a service, AccountService, that serves accounts from a database, e.g.
#DOMAIN DRIVEN DESIGN MICROSERVICES EXAMPLE HOW TO#
I've seen this problem in a few different contexts now but I'm not sure what it's called or how to think about it.
0 kommentar(er)
