4

I have an architecture with 1 backend server and multiple frontend servers.

The frontend servers are connected in a bi-directional (web sockets) connection to clients so they can send messages to clients.

The frontend and backend are connected through a message bus. There is one queue for frontend to backend messages and another queue for backend to frontend messages.

For example, when a client requests an operation, the frontend sends the request to the backend and acknowledges the client the request was sent.

Sometimes, when the backend finishes handling a request, it sends a status message to the frontend who forwards it to the client that requested the operation.

I've never seen anything similar. Usually the communications only go one way - from frontend to backend.

I'm worried, am I doing something bizarre?

I came up with this architecture because of the bi-directional nature of web sockets. This way the server can notify clients as soon as a request is processed.

  • 2
    That pattern is a pretty normal usage of websockets. The only reason we have one direction messages in legacy systems is because the only ways to get full duplex communication were painful (http long-polling, COMET, etc). – Racheet Jan 27 '15 at 15:18
4

Communications do not usually only go one way. Parties usually communicate using request-response pairs, which are clearly not one way. I presume that you already know this, so what you are probably thinking when you say "one-way" is not how information flows, but who initiates the requests.

So, yes, the way we usually do things is that only one of the parties initiates requests. Which means that the other party always sends responses.

But there is an exception: the "callback", otherwise known as the "notifier-observer" pattern. It is perfectly fine for one side to send a "register observer" request to which the other side will immediately respond with an "observer registered" response and then, in the future, with one or more "event observation" responses.

Your terminology with "front-end servers" and "back-end servers" and other unrelated entities you call "clients" only confuses things, and you should not have brought it into the discussion. Things are very simple: Within the context of a communication session between two parties, the requesting party is always called a client, and the responding party is always called a server. In your case, your server is what you call a "back-end server", and your client is what you call a "front-end server".

EDIT:

Of course, in order to accomplish two-way communication you need to employ two queues. I have worked on one large-scale system which employed two queues per pair of modules that communicated, (one queue for each "way" in the "two-way",) so trust me, it is not something bizarre.

  • If I define the message queue as the medium or protocol between client and server, then the communications are really one way because the server can't send a response through this medium. I more worried about the implementation I came up with (a queue for each direction) than with the abstract concept of 2 way communication. – daramasala Jan 27 '15 at 14:52
  • Okay, it was not clear to me what you meant by "I've never seen anything similar." I have amended my answer. – Mike Nakis Jan 27 '15 at 15:04
  • 2
    Guess I needed the reassurance. I'm a lone server programmer in a group of mobile developers... – daramasala Jan 27 '15 at 15:07

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.