Proposal

[jaumard]

Here is my idea of what should be this Trailpack :

This Trailpack should offer a Service who can manage micro services. By managing I mean this methods :

• Install/Uninstall micro service from NPM
• Enable/Disable micro service (something like load/unload them into the project)
• Enable them will load config/services/policies/routes/models like Trailpacks
• Disable them will unload config/services/policies/routes/models like Trailpacks

To do this a model is needed to have a list of all micro services installed with there state (enable/disable) in order to load them when Trails start only if they are enabled.

Micro services need to extends a default module like Trailpacks do with trailpack module in order to load them with same structure.

Any feedback ? @tjwebb it is what you have in mind about this ?

[tjwebb]

Would a microservice be a single method? Or would a microservice itself be its own Trailpack that extends this Trailpack?

For context, this is my main starting point for discussing microservices: http://martinfowler.com/articles/microservices.html

in particular:

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

There are a lot of different ways to achieve this, so any design should make sure to not lock us into in particular implementation.

[tjwebb]

Your idea sounds somewhat like what I want to eventually achieve with Trailpacks. It would be awesome to be able to swap trailpacks in and out during runtime. I've gotten part of the way there with this: https://github.com/trailsjs/trailpack-autoreload. Then, conceivably, someone could build some drupal/wordpress type thing on top of node/trails, using trailpacks as an extension mechanism. It's possible that we could do something like this with microservices as well (the microservices architecture might make this easier) but I'd say it's a secondary goal.

@jaumard interested to hear your thoughts.

[jaumard]

HA HA ! You caught me ;) when I start with Trails and see his architecture I already think about "Hey it would be awesome for a WP node like !" So when Trails will be out I'll start "Sublimy" https://github.com/sublimy/sublimy the WP node like :) I currently working on database schema and architecture.

My though was to have a trailpack-blog trailpack-forum and trailpack-shop as 3 core modules and then use micro services as extensions :). Sublimy Trailpacks will then allow some hook methods to modify/add functionalities to the project.

So for me micro services are not a single function, they have a complex structure like Trailpack to allow them managing a full functionality of the project like they say on your link (so with models/controllers/services/config/assets all embedded). Don't know if extending Trailpack too will be a good idea... Maybe too confusing and it will be better to have another name (even if this one extends Trailpack under the hood), it will be more clear for devs.

Where I'm not agree with your link it's when they say that micro service have to speak with HTTP API rather than directly. Because having HTTP API for each micro services sound heavy and not well adapted for a Node plugins system. If you want to install micro services on another server it will be more easy and scalable to have two(or more) Trails project that will load only desire micro services.

In fact I love your definition on Trailpack : Trailpacks extend the functionality of the Trails framework. (Application functionality should be extended using Microservices).

That's why I think Trailpacks should not be able to be installed/uninstalled/updated by Trails directly (start/stop it's ok) and not be used as extenstions/plugins system. Also Trailpack configs are hard coded under config when microservices will need dynamic config load (in some case like plugin/extension system). Micro services are application functionalities so full managing is needed here.

That only my opinion / vision about this :)

I know this will be secondary goal but if we are agree to some implementation/structure here maybe I can have some time to help with this (that will help me too with my project ^^).

[tjwebb]

That's why I think Trailpacks should not be able to be installed/uninstalled/updated by Trails directly (start/stop it's ok) and not be used as extenstions/plugins system.

Ok, I agree with this. Unlike Trailpacks, which utilize an atypical loading system to ensure correct execution order, I think a microservices approach to application extensions could be based on a more traditional plugin system. They can depend on each other, but they should be sandboxed and not allowed to modify framework functionality/behavior so that lateral (i.e. peerDependencies-type) conflicts should be not possible. Extensions/microservices should be additive only -- they should not modify existing things.

I'll think about what you've said and post a more thorough response later.

[devinivy]

Relatedly, what is/are the proposed transport mechanism(s) for microservices? And discoverability? Would it be worth building on the shoulders of a framework like seneca, or does trails have a different take on building interoperable microservices?

[tjwebb]

Relatedly, what is/are the proposed transport mechanism(s) for microservices? And discoverability? Would it be worth building on the shoulders of a framework like seneca, or does trails have a different take on building interoperable microservices?

Yea, great points. I've looked only briefly at seneca, but if there's an opportunity to integrate with another existing tool, I will usually prefer this over building something new. Trails assumes that most of the tools needed to build a great node.js backend already exist. We're offering a tradeoff, halfway between Rails and Node: we're opinionated on the configuration and organization of your project, but we bundle nothing with the core and let you choose what modules should power the application.

@devinivy I think hooking into something like seneca could work really well, but I'd need to spend some time getting up to speed on it. Thanks for your input, and looking forward to hearing other ideas you might have as well.

[jaumard]

@devinivy thanks ! I didn't know about seneca and it look like great for micro services ! I agree with @tjwebb it's better to use existing tools as possible instead of create a new things... And Trails is a great example of how use best tools to make them working together.

I will also look more seneca but I think it's will be good to integrate it with Trails for micro service. Just need to see if there no limitation or incompatibilities between Trails and Seneca...

[jaumard]

@devinivy I look a little bit more on seneca and it look like great, but a lot of features will be duplicates of Trails functionalities ect... Seneca micro services can run by themselves and maybe we don't want this ? For me Trails micro services will depend of Trails only they don't have they re own web server or database they just give models/routes ect... to Trails and micro service only have core code to do specific actions.

I don't say Seneca is not a good choice but personally I don't see how it can be include to Trails and interact with it...

[jaumard]

Seneca seems to be the best micro service framework for Node.js so maybe we can try to use it with Trails and take advantage of all micro services already available for seneca (user auth/ acl...) I'm trying to start something on my fork if they some people who want to help with this :) https://github.com/jaumard/trailpack-microservices

[scott-wyatt]

I'm bumping this thread because this recently came up again in https://github.com/trailsjs/trails/pull/224.

I agree with what @tjwebb said about Micro services:

Extensions/microservices should be additive only -- they should not modify existing things.

I also agree with the idea that Trailpacks should be allowed to be enabled or disabled during runtime. Eg. I ssh into a server and boot the repl without turning on/off the node app (which is like my biggest issue with most node frameworks).

Since we haven't moved to action on this discussion yet, my vote for scena would be for a trailpack-scena because there is so much overlap in functionality, but I think that would make for some community fragmentation. I also agree with @jaumard about their being a Trails specific microservices extension. There are actually some pretty cool things from Scena that I wouldn't mind having in the trails core like '.act()', or even letting a trailpack run on it's own process or instance like Scena(). It might make sense to open a discussion on trails or trailpack about this.