Timeline for Managing Database Access for MicroServices
Current License: CC BY-SA 3.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Mar 3, 2018 at 17:29 | history | edited | The Pax Bisonica | CC BY-SA 3.0 |
grammatical improvements
|
| S Mar 3, 2018 at 17:29 | history | suggested | Saheb Preet Singh. | CC BY-SA 3.0 |
grammatical improvements
|
| Mar 3, 2018 at 11:32 | review | Suggested edits | |||
| S Mar 3, 2018 at 17:29 | |||||
| Feb 27, 2018 at 19:18 | history | tweeted | twitter.com/StackSoftEng/status/968566044074872833 | ||
| Feb 17, 2018 at 13:53 | vote | accept | The Pax Bisonica | ||
| Feb 16, 2018 at 22:18 | answer | added | Vincent Savard | timeline score: 8 | |
| Feb 15, 2018 at 21:19 | comment | added | 9000 | (I wish someone combined an answer from comments by VincentSavard and MrCochese above; I'd upvote it.) | |
| Feb 15, 2018 at 20:37 | comment | added | Mr Cochese | If the aim of good design is to create high cohesion (put code together that regards the same topic) and low coupling (modularity, low impact of change), then this will likely create the opposite effect. The code dealing with one aspect (or bounded context) of your overall system is now split among three code bases. Your microservices are temporally coupled, as for each to work at all the others beneath it must be running. In addition, they are tightly coupled by interface, as changes to entities and fields must, by necessity, cascade up and down the chain. | |
| Feb 15, 2018 at 20:35 | comment | added | The Pax Bisonica | Sorry for the back and forth on this, it was a difficult use case to explain, but the last comment has definitely helped to clear things up a lot for me. I do believe that, that is the appropriate solution to what we need to do. If you add that as the answer I will accept, thanks again! | |
| Feb 15, 2018 at 20:22 | comment | added | Vincent Savard | I'm having troubles grasping your use case. When you have a monolith that you want to split into microservices, you first isolate a small part you want to extract just as if it was a stand-alone application (from the API to the DAL), then you extract it to a different application (e.g. as an independent web service), which the monolith then calls remotely. It seems to me you're trying to work your way backward: creating a service which exposes a public API but uses the monolith as data access. This is useless, you've just increased complexity for none of the benefits. | |
| Feb 15, 2018 at 20:08 | comment | added | The Pax Bisonica | To make things worse is that these calls aren't set up yet, so will have to build two API layers simultaneously, one basically having no real use. | |
| Feb 15, 2018 at 20:00 | comment | added | The Pax Bisonica | part of the issue is that these microservices basically do the same thing, they don't offer different solutions, the plan is to use the new API layer to proxy to the old API layer so we don't have to rewrite the persistence layer. A call from the Web App to the Web Api will look like this: Web App: GetTestObjects -> New Api Layer: GetTestObjects -> Legacy API Layer: GetTestObjects... Its very redudant | |
| Feb 15, 2018 at 19:50 | comment | added | Vincent Savard | What do you mean, "another service entities not being updated"? Entities for the microservice A will never be used by the microservice B. If B requires data from A, then B will ask them through the public API of A. | |
| Feb 15, 2018 at 19:46 | comment | added | The Pax Bisonica | The number one reason was to avoid having issues with the schema changing and another services entities not being updated to reflect that change. Supposedly having a service that we call into means we don't need to know anything about the data access layer and we can call the API and expect the same results... Although to me this just leads to a slew of other issues. | |
| Feb 15, 2018 at 19:29 | comment | added | Vincent Savard | Honestly, your situation seems a bit weird to me. A microservice is already small enough to be self contained, and you absolutely don't want to expose its internals (such as database access) to other services. Thus, I don't see the point of creating another application so that the "front-end" service can talk to the "data access" service. It just adds useless overhead. Do you know why your colleagues are pushing for this design? | |
| Feb 15, 2018 at 18:52 | comment | added | The Pax Bisonica | Yes, that is what I believe, but for whatever reason there is an internal push to use it as a proxy... | |
| Feb 15, 2018 at 18:42 | comment | added | Mr Cochese | What does the intermediate service actually do of use in this scenario? Wouldn’t it be simpler for the UI to just call the service that actually has data access? | |
| Feb 15, 2018 at 18:20 | history | edited | The Pax Bisonica |
adding tag
|
|
| Feb 15, 2018 at 18:17 | comment | added | The Pax Bisonica | That's correct, with one exception the service to access the database was originally built to handle external requests, which it will continue to do. I'm not entirely sure if we plan on just making this a service to access the database. | |
| Feb 15, 2018 at 18:05 | comment | added | Vincent Savard | Just to be quite sure, what exactly do you mean when you say "Web API"? Do you mean that for one "microservice", you have one service which handles incoming external request, and one service which is only used by the first one to access the database? | |
| Feb 15, 2018 at 17:49 | review | First posts | |||
| Feb 15, 2018 at 17:50 | |||||
| Feb 15, 2018 at 17:44 | history | asked | The Pax Bisonica | CC BY-SA 3.0 |