Timeline for impacts on splitting web application (java) for reducing memory & compute footprint on primary user-facing app
Current License: CC BY-SA 4.0
11 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Dec 25, 2023 at 2:48 | vote | accept | veritas | ||
Dec 24, 2023 at 0:05 | answer | added | J_H | timeline score: 1 | |
Dec 15, 2023 at 8:53 | comment | added | veritas | @Basilevs both Central and IMS call the same database, hence they are mapped to the same Domain Entity POJO (ORM) POJO, service layers (pick this data first, then this i.e business logic) I have just dropped a column on the Central Database and IMS had no clue about it and its native queries/JPA etc failed. So not sure what you are talking about when you say the talk with PO was futile. | |
Dec 15, 2023 at 8:01 | comment | added | Basilevs | Security concerns are irrelevant as IMS is not an user-facing service. Service classes are not shared, because most will not be needed in the new service. In other words all of @veritas concerns are easily dispelled. The talk to product owner was an error. | |
Dec 15, 2023 at 7:58 | comment | added | Basilevs | @veritas I don't see any problems as long as both cheap API calls and long DB queries are used in the IMS. Please clarify why you think they are mutually exclusive. | |
Dec 15, 2023 at 2:58 | comment | added | Roman Vottner | Depending on your environment you can either directly expose the DB as data layer to your applications or create simple Spring backend applications that are able to use various technologies (i.e. Web API, Redis or the like) to exchange data with other applications. Such applications can be scaled to multiple instances or containers easily usually. It fully depends on which architecture model you prefer. I.e. with microservices you try to keep the db with the data of that service as close to the application as possible and thus usually deploy the DB to the same container the app is running in | |
Dec 15, 2023 at 2:44 | comment | added | veritas | When you say "data layer" do you mean a separate web app or a jar? Can you share any reference ? I can't find any one doing something similar | |
Dec 15, 2023 at 2:37 | history | edited | veritas | CC BY-SA 4.0 |
added 324 characters in body
|
Dec 15, 2023 at 2:24 | comment | added | Roman Vottner | I'd probably opt for an own data layer in that case which can be used by both. Here you could partition the db-layer further with replicas i.e. to divide concerns further. The current master would then receive all writes while any replica is only used for read operations. If you look at microservice architecture in particular then data duplication isn't a big deal there. It is more important that the respective applications are master of their own data and know how to get data they need. In term of traceability most DB provide a log feature of some form | |
S Dec 15, 2023 at 2:01 | review | First questions | |||
Dec 15, 2023 at 7:27 | |||||
S Dec 15, 2023 at 2:01 | history | asked | veritas | CC BY-SA 4.0 |