0

I have searched well before asking this question, and some of the questions look like what I need here, but none of the gave a clear answer to my question.

I am writing a web application (in PHP if that matters) that is separated into multiple sub-applications (e.g. Auth, Database, Session, ...etc)

Each of of these sub-applications is deployed to a separate server, and some are deployed on the same server, but not for too long, eventually they will be deployed to their own servers.

Now, my question is simple. What is the standard/correct way of communication between these parts?

I am not sure, but consuming the APIs of these applications over HTTP/HTTPS sounds a bad idea.

Maybe Messaging protocols? Sockets? I am not sure! As I said, I only want to know what is the standard way to handle such cases?

|improve this question
  • There is no "standard" way. There is only the way that best meets your specific requirements. – Robert Harvey Apr 2 '19 at 16:02
  • This's a non-trivial subject you will have to study carefully. The term you need to know is IPC. Note that not everything is reduced to HTTP. It depends on your env. You could even use an SMTP server as message queue. Or flat files as event or OP logs. – Laiv Apr 2 '19 at 16:11
0

The "standard" way would (currently) be HTTPS REST style calls.

It's not the most efficient or best, but it works and is well supported across technology stacks.

An alternative is message queues. Generally these are for async communication, but you can make RPC style calls using them too if required.

The main problem with other alternatives is they require client/server libraries in your language of choice.

If I write my c# WCF service for example, can your PHP website talk to it?

|improve this answer
  • The non-sense point here for me, is the extra requests sent on behalf of the original request. I am imagining a user logging in to the system, that's a request sent to the Auth part, which sends another request to the Database part, and another request to the Session part, and then finally responds. I am imagining that at a large scale where I have like 10 or maybe 15 parts to request each other. That just doesn't sound correct for me! or is this how it goes?? – Osama Aldemeery Apr 2 '19 at 15:58
  • You want to avoid too deep a structure of services regardless of the communication protocol. But yes, that's basically how it goes. Maybe add more detail to your question about your specific case so we can see if there is some other problem – Ewan Apr 2 '19 at 15:59
  • 1
    Perhaps you should not decompose the application in so many parts. – Laiv Apr 2 '19 at 16:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.