What are your thoughts on mediator pattern being used from a client and across a web api?, this means:

  • Command definitions are shared between the client and api.
  • Web api exposes only one ExecuteCommand REST method, wich is wired up using mediator pattern to the command handlers.
  • Client app uses mediator pattern too, the mediator job is to reach the web api (send serialized command definition, etc.).

This is not something I'm planning to do nor need, its just an idea and wanted to read some feedback on it.

It seems to me that this is like building a service bus. Maybe useful on small apps. The nice part about this is the ability to introduce logging and similar features easily on the web api link: you have one api method and one client connection code.

Looking forward to your comments. Sal.


I did a proof of concept repo of this for better understanding.

  • Welcome ! But what do you expect from the mediator in the first place ?
    – Christophe
    Commented Nov 26, 2018 at 21:26
  • @Christophe the idea would be to send command definitions from a client using the mediator to a web api, then the api, also using a mediator, would pick the right command handler. Commented Nov 26, 2018 at 21:33
  • The client would gain the ability to work directly with command definitions instead of working against a web api. I don't know if that answers your question. Commented Nov 26, 2018 at 21:38
  • 3
    So, you are saying that you want to abstract the web API into commands on the client side, and translate the API calls back into commands on the server? Neither of those is necessarily the Mediator pattern (more like an Adapter on the client, and something like a Front Controller on the server). But, the exact pattern itself doesn't matter much; is what I've written above a good description of what you are trying to do? Commented Nov 26, 2018 at 21:52
  • @FilipMilovanović yes, you are right. Commented Nov 27, 2018 at 9:59

1 Answer 1


Yes you could in theory create a Service/Event Bus between your client and the server. While you could do this over HTTP, I believe you are looking for WebSockets.

Several possible benefits of this are:

  • distribution of services between the client machine, and server machine. Without either knowing where their collaborators live.
  • the ability to have builtin redundancy, recovery, task relocation, parallel processing.
  • the ability to see communication occur in real time between services located on the other machine.
  • A very simplified api.
  • Reduces the reliance on HTTP, permitting porting to other network protocols.

On the other hand it makes for:

  • Complex distributed message handling.
  • Bus Congestion
  • Asynchrony issues
  • Reduced network support from the Web Architecture.

The problem is this is not the Mediator pattern.

A Mediator doesn't necessarily provide a bus, neither does it expose the communication between the collaborating objects.

The Mediator alone is responsible for knowing how to arrange the communication between these objects, and change it at run-time.

  • It may send some interactions to the equivalent of /dev/null.
  • Other interactions may be farmed out to hundreds of recipient objects.
  • The interaction itself may be transformed into a different series of interactions.

You could create two Mediators one on either side of this Service Bus. They would be responsible for interfacing messages and interactions, perhaps with some interactions being directly forwarded to local contributors.

Run-time reconfiguration of services at scale isn't always needed. It may be wiser to use a builder pattern to construct each service independently. Constructed with an attachment to the service bus that is closed when the service (or service bus) is done.

  • This is not something I'm particularly interested in, just an idea. I pushed some code to toy with it (link on updated question). yeah, it works as expected. Thanks for your pros and cons, thats what I'm looking for. I created two mediators, the client one sends serialized commands trough the api endpoint, then they get picked up and sent to the api's mediator for handling. Commented Nov 27, 2018 at 15:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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