5

What about Smart endpoints and dumb pipes in terms of different type of requests?

After reading that I was thinking that it's enough to subscribe for some events and deal with that. But now I've realised that sometimes you should have opened API (maybe not for the end customers, but for the API Gateway etc). Is this ok? Or you should "eventize" (transform into event) any request which coming to Microservices cloud?

So, for instance, you have Invoice and Order services. It's clear that when order created you might use an event which might be consumed by Invoice service to create an invoice. It's clear that for receiving list of last user's orders you may use CQRS on Order service side or even just make new service LastOrders which will keep just projection of required data. But should this request transformed into event or LastOrders should provide API for that and listen for events to update it's own DB?

user1016265
  • 2,307
  • 3
  • 32
  • 49

1 Answers1

4

We do it like this:

  • All commands are issued as messages in durable queues with type-based routing
  • Processing takes places in isolated handlers
  • REST POST and PUT are only created for the API that should be accessible from legacy/external systems
  • These "command"-style REST endpoints only form command as a message and send it via the message bus
  • REST GET is perfect for fetching the data and we do not use messaging there, although we could have some message handlers to retrieve data for long-running processes that can only use messages
  • Command (message) handlers always publish events about what they have done or not done
  • Downstream event processing can do whatever they want by subscribing to these events
Alexey Zimarev
  • 17,944
  • 2
  • 55
  • 83
  • Thanks for sharing your experience, I've just one more question: do you encapsulate GET endpoints by API gateway? – user1016265 Jun 13 '16 at 13:54
  • Each service provides its own set of GETs for the data it can make available. Since each service has strong defined boundaries and a local storage, it is quite explicit where you need to go to fetch the data you want. Udi Dahan goes further and suggests that you actually have to design a client for you service as part of the service and distribute it, take complete ownership. – Alexey Zimarev Jun 13 '16 at 18:21
  • Could you please share the link for Udi Dahan article about that? It would be very interesting. Based on your answer it seems that you don't have an API GW for GETs endpoints? – user1016265 Jun 14 '16 at 20:28
  • This is not an article but part of the course. You might bet some of it from his talk he gave at SkillsMatter when I was on his course https://skillsmatter.com/skillscasts/7784-multi-dimensional-architecture. What we try to do now is instead of delivering REST typed models for others to consume, we deliver nuget packages with client libraries that hide the implementation. We can do some nice stuff there like caching, for the client it is still transparent. We can even change the transport if we want. – Alexey Zimarev Jun 15 '16 at 07:21
  • Many ideas also in this talk https://skillsmatter.com/skillscasts/5235-keynote-an-integrated-services-approach – Alexey Zimarev Jun 15 '16 at 07:42
  • Thanks for the links – user1016265 Jun 15 '16 at 08:27