Roadmap

[ericholiveira]

I was thinking what are the next steps on studio. And would see if you have any ideas to our platform
At this moment im thinking on 2 main features:

1 - Isomorphic version of studio (and a plugin to access studio services from browser using websocket/socketio, the same way we do on cluster)
2 - Some kind of "agent" a web app where you can see which services are running in each machines and control it (start/stop)

We also need to document code and check if there are missing parts on Readme.md.

We can try to create some wrappers for famous libraries like mongoose sequelize, but im not sure if we should follow this path atm

@avishnyak @sean-hill i would love to hear your thoughts on this subject. And anyone is highly welcome to join this discussion

[avishnyak]

@ericholiveira Fantastic ideas on both fronts. I was going to suggest 2 myself. In fact, I would love to take that one on because I have a ton of ideas there.

Other ideas (these are not thought through in detail, just things that popped into my head):

1. API interface plugin. Take a SWAGGER spec (or any competing standard) as input and generating a facade out of it which routes to different microservices services. Basically creating a declarative approach to microservices.
2. Express/Koa interface plugin - Given a set of running services, generate an Express or Koa application front-end for them.
3. Service Documentation plugin - Given a set of running services and some sort of metadata, generate a web app which describes the services running in a given environment, their API surface, etc. A self-documenting microservice framework would be really cool...
4. Caching plugin for RPC calls - being able to declaratively set caching policies for services (vary by param, vary by time, etc.)
5. A/B testing plugin - Ability to take over a route and send data to two or more services for A/B testing. Would take a success heuristic function and be able to dynamically adjust amount of traffic going to each one based on probability of wining. Like optimizely by for microservices.

[avishnyak]

Regarding wrappers, I think we would fall into the Seneca trap there where you have a ton of half-baked, buggy wrappers with no maintainers which will give the overall framework a bad name.

[sean-hill]

@ericholiveira once I start on my project in next little bit, I'll be able to help out more here. I don't know to much about the framework other than reading through the README and looking at the examples. As soon as I know more, and use it a bit, I'll be able to contribute more at that time :) Even though I haven't used this framework much yet, I already love it because it's how I already organize and build my current code base for work. This framework however, just adds another awesome level of abstraction I'm excited to try out. I've got some sweet front end skills, so I should be able to help out with whatever web app we decide on making for this.

[ericholiveira]

@avishnyak great... so you can work on 2... i think it should be a new project (like studio-cluster)
Also i already thought about self documentation (actually i started to implement it, but decided to delete because it create an insane amount of boilerplate, so we need to think on some better way to do, anyway i totally agree with this)... and also thought on A/B and i think we should really discuss this. I really love your other ideas because this can turn studio in a full platform of development.

@sean-hill great to know... and if you`re interested in help with frontend issues, its great because as soon as we have better docs i plan to create a website and we are going to need template and design ideas (and im just terribly bad on this ahahhahahah)

[ericholiveira]

@avishnyak since you`re going to work on the "agent" , can you open a issue for it , so we start the discussion?

[ericholiveira]

Its also important to implement yeoman generator

[sean-hill]

Hey @ericholiveira I just began work on my project. I'm hosting the initial boilerplate on github that includes an example using hapi, mongoose, and studio.js as it's framework. It can be found here! I'll add more to it as I build out more functionality.

[ericholiveira]

Cool... are u running on node 6?

[sean-hill]

Nope, Node 6.

Sean Hill
me@seanhill.info
www.seanhill.info

On May 30, 2016 at 9:22:43 AM, Erich Oliveira (notifications@github.com)
wrote:

Cool... are u running on node 6?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#46 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABJmau6MFT5Fsk98Mv4ZbtZxDs9eVxdtks5qGw7TgaJpZM4Id9TN
.

[ericholiveira]

Just a tip.
Node 6 have proxies implemented... so there is a "simpler" way to access your services...
you can do the following:

var services = Studio.services();
services.User.create(/*params*/);

Studio.services() returns a proxy where you can acess your services directly instead of

Studio.module('User')('create')(/*params*/) 

[sean-hill]

Ooo, very nice! I'll give that a shot. I thought that type of structure
would be a better way to access services :)

Sean Hill
me@seanhill.info
www.seanhill.info

On May 30, 2016 at 9:38:57 AM, Erich Oliveira (notifications@github.com)
wrote:

Just a tip.
Node 6 have proxies implemented... so there is a "simpler" way to access
your services...
you can do the following:

var services = Studio.services();services.User.create(/params/);

Studio.services() returns a proxy where you can acess your services
directly instead of
js Studio.module('User')('create')(/params/)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#46 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABJmagWCsXHeNkTEoUgOxigL4kivCQjAks5qGxKhgaJpZM4Id9TN
.

[ericholiveira]

It is also nullpointer safe...
if you try something like this

var services = Studio.services();
service.some.module.and.nonexistent.service(/*params*/);

It only throw a ROUTE_NOT_FOUND for some/module/and/nonexistent/service
no matter how deep you go with it

On Mon, May 30, 2016 at 2:12 PM, Sean Hill notifications@github.com wrote:

Ooo, very nice! I'll give that a shot. I thought that type of structure
would be a better way to access services :)

Sean Hill
me@seanhill.info
www.seanhill.info

On May 30, 2016 at 9:38:57 AM, Erich Oliveira (notifications@github.com)
wrote:

Just a tip.
Node 6 have proxies implemented... so there is a "simpler" way to access
your services...
you can do the following:

var services = Studio.services();services.User.create(/params/);

Studio.services() returns a proxy where you can acess your services
directly instead of
js Studio.module('User')('create')(/params/)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/ericholiveira/studio/issues/46#issuecomment-222525664>,
or mute the thread
<
https://github.com/notifications/unsubscribe/ABJmagWCsXHeNkTEoUgOxigL4kivCQjAks5qGxKhgaJpZM4Id9TN

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#46 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABKaZI5vuhz4HsIIcnmFvlEvCzCGT8nlks5qGxpqgaJpZM4Id9TN
.

[sean-hill]

Super sexy :) Check this out! I love being to keep the business logic of the app wrapped in Studio.js and only calling the service from the routing layer. Super cool.

[ericholiveira]

Really amazing :)

On Tue, May 31, 2016 at 8:21 PM, Sean Hill notifications@github.com wrote:

Super sexy :) Check this
https://github.com/sean-hill/hapi-jwt-auth-mongoose-studio.js/blob/master/app/routes/user/create.js
out!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#46 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABKaZCDnSimg1FuzUyfOcW2XHHLEZl-5ks5qHMJhgaJpZM4Id9TN
.