why server action?

thanks

Hi ibox,

REST API is already a loosely coupled call. if we create a service action that is again a loosely coupled call, we just do 2 loosely coupled calls one after the other. We consider this a bad practice.  Whereas Server action is tightly coupled.

Thanks,

Neha

the choice of a server or service action is about how you want the coupling to be between the action being offered and all consumers.  

This is regardless of the internal workings of the action, and whether there is tight or loose coupling going on there.

For this, I would say, service action, as you don't want all your consumers to have to republish, just because there has been some internal change to the mechanics of using some external api.

@Neha Sheikh, i never heard of the 2 loosely coupled calls = bad practice rule, where did you see that ?

@ibox : see this medium article for an extensive explanation on the architecture of consuming external api's.

Dorine

Hi @Dorine Boudry ,

I clearly remember I read that on the Forum. it was mentioned by @Daniel Kuhlmann. and that made sense to me that is why I suggested the same to ibox here in this post. and in regular development also that's the usual practice we do to wrap API calls in server actions and not in service actions.

Thanks,

Neha

 Yes, indeed,  REST service integration is already a loosely coupled architecture, calling it from a service action is double the network latency, no need for that. A consumed REST service can be changed by the developer without impacting the consumers. 

If consumer are impacted by a change in the REST service, the best practise is to have a new version of the REST service, that allows each consumer at its own page to adapt the new version.

Bottom line, calling a REST service from a Service action, for me is a bad practise.