Exposing messaging queue to web clients?

Question

Consider a real-time application where a web-client makes a persistent connection to some entity X.

The possible options we have here is:

1. connection to web server which then sends messages to a message queue.
   In this case, entity X equals some web server which then forwards that message to a message queue.

                   |=Backend=             
(client) ----------|-(web server)-----------(messageq)------> process message
                   |             ^--backchannel connection

2. direct connection to a message queue.
   In this case, web client directly connects to message queue endpoint and pushes messages.

                   |=Backend=
(client) ----------|-(messageq)------> process message
                   |

What is the recommended best practice here? Where does the message queue sit in standard enterprise architectures? Also, if you know of a best practice please share how you come to learn that information (what resources / book contains this knowledge?). Thank you.

Answer 1

When the client is a web-browser:

Let me do some Q&A, based on which your question may get answered

Q1: Do we expose application Database to our clients, for simple read operations?

A1: No, we want to control what is exposed to the client

Q2: Based on Q1, does it makes sense to expose messaging-queue to the client?

A2: No, for the same reasons as A2.

When the messaging-queue is exposed to the WebClient:

Q1: What will happen if the messaging queue provider needs to be changed from let's say Rabbit-Mq to Kafka?

A1: Old mobile applications will break. Web-Client needs to be changed in order to compatible with the new queue. (Bad architecture)

Q2: Can someone tap into another topic/queue as well with-in the same messaging-queue ?

A2: Yes (Bad architecture)

When the client is another service:

Inter-service communication using shared messaging-queue is a pattern used for async-communication by many applications.