I have a Service Gateway for handling requests to an external REST API service. Today, the gateway provides corresponding REST endpoints via HTTP for use from an internal front-end client.
I am now looking to extend the gateway, so it can be used by additional internal back-end (ServiceStack) servers, which want to use the external services. All back-end servers, including the gateway, are installed on IIS 10 (Windows Server 2019) instances.
I like the idea of using MQ for server-to-server communication, but, I am limited to Background MQ, as RabbitMQ and RedisMQ are not allowed.
I would like to ask:
Is Background MQ suitable for production?
Is there a convenient way to register MQ handlers for ALL defined web services; rather than register each individually?
I am happy to receive alternative recommendations.
The Service Gateway is recommended for server communication, MQ’s are useful for processing long running “one way” tasks, e.g. starting a background job, sending emails, etc.
The queue is maintained in memory so it’s as suitable as calling a Service is, where if the server crashes midway through processing a request, the request is lost, along with all other queued requests. A persistent MQ would preserve all unprocessed requests whilst if you used Rabbit MQ, if the App Server crashes any un-ack’d request would be returned to the queue.
No, each Request requires 2 threads by default, 1 for the .inq and one for the .priorityq. If you don’t intend to use them all priority queue’s can be disabled with EnablePriorityQueues=false. Either way you should only register “one way” Services that you intend to call via MQ for MQ.