Best practice for server-to-server communication?

[Keith]

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.

[mythz]

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.

@Keith

Is Background MQ suitable for production?

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.

@Keith

Is there a convenient way to register MQ handlers for ALL defined web services; rather than register each individually?

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.