I am facing a dilemma with designing an api gateway. Currently, I am using the pipeline pattern, with different stages being the requests made to various services, (http, sockets, amqp, ...).

I have a base class, RequestStage, with some subclasses, HttpStage, SocketStage, AmqpStage. These classes extend RequestStage because they can have different unique parameters for each of their requests.

The problem is that each stage/event (subclass) must be a call either to a middleware api or downstream api. If it is a middleware api, then there should be a fail response condition to short circuit the pipeline.

How can I fit this extra field/trait in? If the stage/event class is calling a middleware api request, then it should contain an extra field "failCondition", but how could I implement this cleanly since my inheritance is based on request protocol type and not service type?

  • Inheritance doesn't sound like the right tool for the job here - AMQP and HTTP have fundamentally different semantics to each other (totally different communication patterns). What specific problem are you trying to solve in this attempt to build a unified abstraction? I would think a much better solution would be to separate both of these out entirely and abandon any attempts to unify them. i.e. one API gateway for your HTTP service and another completely separate unrelated API gateway for your AMQP service. Commented Apr 18, 2020 at 10:04
  • Which of the many search results for “pipeline pattern” should I assume you’re using? Commented Apr 18, 2020 at 21:27
  • @candied_orange something like this: michaelscodingspot.com/pipeline-pattern-implementations-csharp Commented Apr 18, 2020 at 23:36
  • @BenCottrell The idea was to create a central gateway that handles protocol translation for all my downstream services (rest -> socket, rest -> grpc, etc), so that's why I am trying to build with all the protocols together Commented Apr 18, 2020 at 23:37
  • @hotswappable Do you really need a unified interface / inheritance heirarchy though? For example, could you have a separate REST endpoint for AMQP handled in an unrelated class compared with some of the others? Keeping in mind that the communication patterns/semantics of these different mechanisms are fundamentally a long way apart from each other, i.e they have so few things in common that any abstraction would likely only be able to offer an extremely limited capability, and would throw away most of the benefits of using them in the first place. Commented Apr 19, 2020 at 9:55

1 Answer 1


so I will implement the gateway with multiple endpoints to handle various protocols vs abstracting them together

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.