that's not defined by the term, and is left up to you to decide. All it requires is a lightweight interface, often http.
This is basically where the complex programming will be in these systems, understanding all of the various ways to route messages and where and how to deploy them effectively.
Seneca.js has support for redis, kafka, and so many others.
Next post: Microservice Architectures—"what is needed to create an architecture composed of Microservices"
Hmm, well, I eagerly await the next post.
It seems like what's needed is a concrete, simple tutorial on coding and deploying a microservice infrastructure. That'd demonstrate that this design is practical and, importantly, would reveal any pain points or cornercases that the design is susceptible to.
One pain point is that if a microservice goes down, any messages that were in the process of being handled may be dropped. So there has to be a way to ensure that every message eventually returns exactly one result, and that messages are never accidentally dropped due to microservice crashes.
Actually if you set you message broker up and message handling up properly, you can get your microservice to only acknowledge receipt once it's finished processing and output it's result. If it crashes in the process, the queue would try to redeliver the message once the next service comes on-line. It's built into AMQP as a standard.
Hmm, well, I eagerly await the next post.
It seems like what's needed is a concrete, simple tutorial on coding and deploying a microservice infrastructure. That'd demonstrate that this design is practical and, importantly, would reveal any pain points or cornercases that the design is susceptible to.
One pain point is that if a microservice goes down, any messages that were in the process of being handled may be dropped. So there has to be a way to ensure that every message eventually returns exactly one result, and that messages are never accidentally dropped due to microservice crashes.