Feathers: Suggestion: Support for real Micro Services (like Seneca)

[kristianmandrup]

I believe the current FeathersJS Service model is tightly linked to routes/socket request/response (realtime or not) on a web server as is the typical model.

Services should be completely stand-alone "stupid" functions are deployed separately. Each service should subscribe message of a specific pattern.

The HTTP server should simply take incoming socket/http data and generate appropriate messages that are put on the message queue. One or more services then react to the message.
Makes it much easier to scale and make services fully decoupled.

See seneca or similar architectures/frameworks

This is true Micro Services architecture:
https://github.com/hemerajs/aither#architecture

Would be amazing if we could build a plugin system for Micro Services with Feather as well, including CI/CD&D via Docker containers

[bitsoflogic]

Check out #258. Looks like they've got this decoupling in the works for their Buzzard release. I don't know about the underlying architecture though.

[daffl]

I think @slajax can chime in here because he looked into the architecture for basically generating a full mini-app for each Feathers service you create. @ekryski also made an app per service example in https://github.com/feathersjs/feathers-demos/tree/master/examples/app-structure/versioned-sub-services.

My biggest issue with what is considered microservices is that it seems to conflate two things that I don't think have much to with each other, namely how to scale and deploy mini app containers (which is great) and how those services are exposed and consumed (looking at the Aither example of http://localhost:8182/api/add?a=1&b=10 which is not great at all).

[kc-dot-io]

I'm not sure you are really referring to microservices here. What you are describing is more on the end of the new serverless trend - hence lambda. Even serverless and apex still interface with APIG. IMO - this isn't something feathers should ever support but that doesn't mean we aren't supporting "real" microservices. You can build "real" microservices that are http and docker enabled then deploy them at standalone DNS locations on ECS or even combine them into one monolith. Feathers is flexible like that but it's not intended to support the "function only" design that is now emerging because we want to leverage the existing knowledge of the community with regards to the most popular frameworks such as express, koa etc. Some decoupling is neccesssry for that but I don't see us ever going to the extent these function only approaches do - do you @daffl?

[kc-dot-io]

@kristianmandrup the v3 generator already has docker support and I have some side projects that are combining it with terraform support - so the deployment / CI / CD stuff is here already, it just won't be function driven such as lambda is.

[kristianmandrup]

Just use CORBA, DCOM or RPC ;)

Well, the serverless lambda functions are hardly "real microservices" IMO. It's just like function to function message calls, ie. you have to know the endpoint of your receiver and exactly what type of message he expects, what protocol etc.

The beauty of "real" micro services is the use of a message broker in order to have a truly loosely coupled, distributed architecture, where each node is clueless about the other nodes around.
Just pass messages "into the sea" which are picked up by any service which cares to listen and shows interest.

The way we have ben building systems for the past many years will soon go the way of so many past models... bye, bye to monoliths and direct communication, we have the tech to overcome this limitation now. Just like mutation based storage and imperative programming was a pragmatic consequence of too expensive memory/storage back then.
No matter of scaffolding generators and smart frameworks will ever really resolve the problems in these design constraints and explosion in inherent complexity (IMO).

I understand your focused objective with this framework so you're right, not really what you are aiming for. Feathers seems more suited for quick PoC/startup projects. Then you can factor out the "service monolith" to smaller deployable services later if need be when complexity rises and scalability requirements increase beyond just scaling the monolith web app itself.
My 2 cents.

I'm personally going all in with M.S reactive streams and event bus on both client and server.
Fits hand in glove and you end up with similar decoupled services at both ends consuming the same type of messages! Sweet :)

Might use FeathersJS for some realtime use cases beyond what firebase can offer out-of-box!

Cheers 💃 ✌️

[kc-dot-io]

Cool, thanks for the feedback!

[subodhpareek18]

The beauty of "real" micro services is the use of a message broker in order to have a truly loosely coupled, distributed architecture, where each node is clueless about the other nodes around.
Just pass messages "into the sea" which are picked up by any service which cares to listen and shows interest.

@kristianmandrup have you had a chance to look at
https://github.com/feathersjs/feathers-sync
It does exactly what you're referring to.

In fact there is even a rx plugin here
https://github.com/feathersjs/feathers-reactive

I'm not able to understand why you think quote real microservices unquote can't be built with feathers.

[subodhpareek18]

In fact you can even straightaway proxy an endpoint to an external server.

app.use('/path', someFunction)
// someFunction handles the data however you want. Just needs have a service object signature.
// read https://docs.feathersjs.com/services/readme.html#service-methods

And the beauty of creating this thin api wrapper with feathers is you get all the service events as well.

Though let's say if your other microservice is also in node, then you can make that a feathers app too, and then using feathers-sync you can have all the event streaming syncing goodness.

[kristianmandrup]

Awesome!!! Thanks :) Wonderful :) @zusamann

[kc-dot-io]

@kristianmandrup also check out this: https://github.com/feathersjs/feathers-generator/pull/39 it gets you the dockerization neccessary to do CI / CD and also ECS style task isolation in production.

[subodhpareek18]

@slajax checkout what? You haven't shared any link 😛

[kristianmandrup]

@slajax So where is this famous v3 generator you speak so fondly of? I don't see it in any branch on feathers-cli

[kc-dot-io]

Sorry, check the edited post - link didn't paste. feathers-cli doesn't house the generator. Read the source code and you'll see the v2 generator is feathersjs/generator-feathers and v3 is feathersjs/feathers-generator

[kc-dot-io]

@kristianmandrup @zusamann https://github.com/feathersjs/feathers-generator/pull/39

[kristianmandrup]

You guys made my day!!!

[kc-dot-io]

@kristianmandrup good to hear it :) feedback welcome on v3, but take it easy on me! It's still early days over there!

[kristianmandrup]

Hi @slajax, what is the current status on v3? progress since March?

[kc-dot-io]

@kristianmandrup we decided to sunset it, the benefits didn't seem to align as well as we had hoped they would for the community and there was a lot of potential risk in the breaking changes.

[lock[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue with a link to this issue for related bugs.