[Question] Not An Issue - Just A Question

[DarkBlaez]

Just a question, I have reviewed most of the documentation and like what I see. My question is, why develop the API Gateway portion of this. Even at the time of development and refinement there are many solid API Gateway open source products out there . I will refrain from commentary but I would like to understand the rationale and how this fits. Here's my caveat so that this does not spin in a direction of docker vs orchestration since both API Gateway products can be deployed on docker and containers within Kubernetes (docker, containerd, etc). Examples such as Gloo, Ambassador, Nginx+, other exist. Letting me write my services in any language I choose. For a service mesh I can use Consul, Linkerd, Istio, etc. as well. Just looking for some understanding as to why I would use the bolt-on molceuler-web over these other well positioned and seasoned offerings. Thanks

[icebob]

The moleculer doesn't underlie on HTTP protocol. So you can't use an external API gateway directly to communicate with Moleculer services. It has its own protocol and API gateway exposes the moleculer services to an HTTP endpoint.

[ccampanale]

@DarkBlaez I'd like to provide my perspective here as well:

As you pointed out, there are several well positioned and seasoned offerings for polyglot microservice distributed systems when it comes to container orchestration, networking, observability, service discovery, etc. I think of Moleculer as a sort of "easy mode" NodeJS based, microservice framework for "two pizza teams". Your team doesn't need to be concerned with - and more importantly, invest the time in learning, deploying, and operating - various services to address these concerns because several of these features are built into the framework.

As for the API Gateway; as @icebob stated, Moleculer uses its own protocol which is why there is a module specifically for exposing an HTTP API Gateway. Additionally there are modules for other types of gateways; GraphQL, WebSockets, etc. None of these, in my opinion, are bolt-ons but rather, optional modules to support the varying requirements of your project. These gateways are also not mutually exclusive; you can have multiple gateways for different purposes depending your needs.

So when should you use the Moleculer framework? As with most things there is no right or wrong answer here as it boils down to your project/team/organization. For example, in my team's case, we were decomposing an existing monolithic application built entirely in NodeJS making it an absolute no brainer to use Moleculer to do so; the language and runtime was the same and as mentioned above, many of the things you would need to take into consideration for building microservice systems was taken care of for us out of the box. However, if your organization has several well established applications poised to become part of a micorservices landscape, the same may not be true for you. If your organization is poised to build microservice from the ground up but each team has a different skillset and the landscape will be more polyglot, you may want to consider the offerings previously mentioned over a single NodeJS framework.

That being said, I think it's also important to point out that, given a scenario where you organization is embracing microservices (or more arguably an Service Oriented Architecture) and there are several teams working on several solutions in varying languages, each intended to be exposed via common organizational gateways - think the "Jeff Bezos AWS API Mandate" - does not intrinsically preclude a particular team from choosing NodeJS and implementing the Moleculer framework. In this scenario, your team would be building a sort of "microservice system in a larger microservice system". This is made possible in part due to the existence of the gateway modules previously mentioned.

Again, these are mostly just my opinions of the landscape based on my experience as an DevOps/Platform Engineer over the past few years and an avid user of Moleculer. I hope this clears things up or provides something to think about. Feel free to let me know if I can clarify any of my points.

[munjalpatel]

I have similar question. However, in our case, we do have a fairly decent K8S + Istio (Service Mesh) setup and was wondering if Molecular would be able to play nicely in such environment or if its even meant to.

[ccampanale]

@munjalpatel It sounds like your organization/team falls into my thoughts above in the fourth paragraph. I don't think there is anything about Moleculer that would intrinsically prevent you from implementing the framework to build a microservice system deployed in the architecture you described.

All Moleculer services could be deployed as part of a single pod with one or more containers, or as multiple pods; they would be configured with transporters that were either built-in to the container images, as side-cars, or could even be deployed as separate pods (this is of course very much dependent on what you choose as a transporter in Moleculer; for example, NATS clusters should be 3 to 5 nodes in size which would rule out a built-in or side car approach, etc.).

K8S would manage the scheduling, keeping containers online and scaled as necessary, and the service discovery of listio for addressability between the pod(s) that your Moleculer Service(s) is/are running in.

Other services within your K8S deployment would be able to discover and communicate with the one or more pods that make up your Moleculer based deployment and would likely communicate with them (as a whole) using one or more of the API Gateway modules supported by the framework. Internally - amongst the pods/containers running your Moleculer system - service discovery and sync/async communication would happen over the transporter and handled by the framework.

As far as other services are concerned, they would communicating with a single "entity/system" via your exposed API Gateway (HTTP, GraphQL, etc), but internally, unbeknownst to other services, you are using Moleculer to compose a distributed system of services, simplifying the problem of versioning/deploying new/additional services.

Totally doable, however, you might find folks scratching their heads or questioning the feasibility. From my perspective though, this would be no different than using Spring to build and deploy several Java based miroservices deployed in the same environment across multiple pods/containers; I don't think there is any "rule book" out there that says microservices must be "monolithic" in nature...

As always, feel free to ask for clarification.