0

Background: different developers are building an e-commerce system using Spring. Some are working on the user facing arm, others are working on the CMS, while the other group are working on the vendor bit.

My first thought was to combine all three into a modular monolith, since I imagine the 3 of them will have cross-cutting concerns. This is proven correct through the authentication system and mongo models, but not much else. The trio grow into full-fledged projects, with eventual slight demand on the vendor for content on the CMS. So, they are splitted into 4 different projects (with the general dependencies being imported in the other 3)

This incident was brought to my notice – there may have been other similar situations on the vendor project that required data from the CMS, but for the purpose of clarity, let's assume it was just a few (2) business classes. Is consuming this 2 enough reason to make http calls, or is it satisfactory to import the CMS module (just like general dependencies) and call them directly?

My understanding is "same language, first party API, import and invoke"

I'm also tempted to think that the interdependencies is an indication that the projects shouldn't have been splitted, but I imagine I may be penalised for merging two questions in one

Improve this question

1 Answer 1

Reset to default
1

Presumably if you import the CMS library and use it directly then your calling application will need direct access to the underlying database?

This is the main concern here, having access to the db might tempt future developers to implement features by bypassing the CMS library.

Exposing the CMS api over a network call of some kind allows you to insert an extra authentication layer which forces the caller to use only the methods exposed. It doesn't really matter if its http or some other protocol or even some clever in memory call to another process.

These days its pretty trivial to wrap your service in a REST api, the overhead is negligible for most cases, front ends tend to need HTTP access and microservices are a popular pattern. The question is why not do it?

Improve this answer
4
  • The big advantage of direct invocation is type-safety – you don't have to duplicate your types across the wire, and each code base is not gonna break when updates are made on the shared type, since it'll be caught at compile time and duly refactored Commented Aug 30, 2021 at 19:37
  • if it all builds together as one big monolith yes. But you can also publish a client lib to get a similar type safety Commented Aug 31, 2021 at 21:11
  • 1
    If the Db connection is in the monolith you will have to very carefully watch for, and argue down, any PR that directly accesses it. Your devs will go for the easiest option under delivery pressure so remove the temptation by keeping the db behind an Api. Api calls are also easier to mock when unit testing ;-) Commented Sep 22, 2021 at 6:54
  • @Ross Idk why I didn't reply immediately. You made a fair point, but I use an ORM, so mocking is not a problem. The thing is, as said earlier, all the projects use the same models ie same database. That means the client library has freedom to access the data. This isn't a public facing api where clients have the need to spin up malicious queries Commented Oct 18, 2021 at 18:06

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.