architecture decisions to breakdown core services can increase the response time ?

Good morning all.

A customer decided to breakdown the core services.  One core services will be broken in 4 pieces according his conception of granularity.  The crud actions will be put in another espace too.  Will this have some impact on the time the system will response to the user ?

If we are talking about just moving actions and entities to a different module, then it won't have any impact on system response time. Architectural changes like that are mostly beneficial to deployment time; they allow applications to have less dependencies and thus take less time to deploy.

Sorry, I didn't give the context.

I have only one core services and one end user espace.  I believe this is the best solution for deployment... Am I right ? This one core services espace will be broken in 4 espaces.

If you only have two modules, probably there aren't strong reasons to break the core service down. Some valid reasons I can thing of:

  1. Preparing for a future where other modules will consume the broken down core services.
  2. That one core service is so large that it slows down Service Studio.
  3. You have several developers constantly having to merge their changes, because they are all working on the same module.

If none of these apply, I wouldn't bother refactoring the core service.

Yes Pedro, now you got my point. If I add more espaces is not there more overload into communication ?  I imagine that each espace has a communication line between them... do you know some documentation to research about that? Or, back to my question in the beginning: is there some overhead on this approach ?

Luciano,

More modules have no overhead at runtime. The overhead in communications is more related to the use of either server action, service actions or rest api. server actions are the fastest and share the same transaction, but required faster need to republish if producing module is changed. Service actions and rest api use network to communicate and have their own transactions.

More modules, can make publishing your work faster,as the unit of work you publish is smaller, this also reflects the database space used to save all the versions of your modules.

Regards,

Daniel


Solution

Thank you for your contribution Daniel, however I found a more explanatory answer in this link https://youtu.be/S9hcp1RRcEg

When you position the video on 11 minutes frame will be possible to see better the advantages and problems of having multiples espaces and the way to approach them.

Thanks all for everything

Solution

That video presentation is indeed an excellent presentation from the ODC, one of the best I think. It will really help you understand how to build good architecture.

I actually used this presentation as part of training new developers 

I would advice you to check out more ODC techtalks, they are great learning resources.

Regards,

Daniel

Daniël Kuhlmann wrote:

That video presentation is indeed an excellent presentation from the ODC, one of the best I think. It will really help you understand how to build good architecture.

I actually used this presentation as part of training new developers 

I would advice you to check out more ODC techtalks, they are great learning resources.

Regards,

Daniel

Thanks Daniel


There is ABSOLUTELY a performance cost involved in multiple layers of services in some scenarios.

Tons of stuff is passed by value.

When you use a zillion layers, and a piece of data gets passed through many layers, you are copying that data a zillion times. Each copy costs RAM, each copy takes time to make.

So if your proposed architecture is going to result in data, especially large ones like entity records, being passed through many layers at once, you are going to use a lot more RAM *and* see a performance slowdown.

The Services modules, as others have pointed out, make an internal REST call, with all of the costs associated with that, not the least of which is opening another call into the system, another DB connection, a new transaction, re-reading Session, the context switch of tenant, etc. that's certainly not cheap/free and if you use them a lot, you are really beating your system up.

I know it's not the popular decision, and I know it flies in the face of most "best practices" that I see advocated, and it can make development a lot more work, but my experience has been that for pure performance, a "monolith" is often the right choice. Or something close to a "monolith".

J.Ja

Couldn't agree more with Justin.

You cannot split up your architecture into Services modules without considering the increased overhead in your system. Also consider data consistency problems, since each service will use its own database transaction and error handling. I would only make such a decision if the business benefits of the Service architecture were quite large.

I think we all agree on that using service actions  have more overhead and other impacts like their own transactions and extra need for error handling. But the original question was not about splitting logic in different service modules but just blank modules I think. It was also not mentioned in the original question that  service actions would me used. There was just the question if you can have core services in different modules. Like the _CS module for different concepts. Just the way OutSystems promote how you break down your application in a solid 4CL acrhitrcture.

The responses above however generated one question for me. If I create a service module, but only use server actions, no service actions, my understanding is that that is the same as a blank module. It is only then when I use a service action rather than a server action that we have to consider database transaction and error handling. 

Regards,

Daniel

The answer I gave very definitely addresses exactly what you asked Daniel. As I said, server actions pass by value and if your design ends up taking data and passed it through many additional layers down and and down and then passes result back through many layers it will perform badly because it is copying that data.


J.Ja