Have you considered Yeoman and SailsJS integration for complete Front-End & Back-End scaffolding generation? #994

Closed
Gnex77 opened this Issue Mar 25, 2013 · 60 comments

Comments

Projects
None yet
@Gnex77

Gnex77 commented Mar 25, 2013

No description provided.

@passy

This comment has been minimized.

Show comment Hide comment
@passy

passy Mar 25, 2013

Member

That sounds like it would fit into the ongoing discussion about CRUD generation: https://plus.google.com/101063139999404044459/posts/fomAZfaPL9t

Member

passy commented Mar 25, 2013

That sounds like it would fit into the ongoing discussion about CRUD generation: https://plus.google.com/101063139999404044459/posts/fomAZfaPL9t

@Gnex77

This comment has been minimized.

Show comment Hide comment
@Gnex77

Gnex77 Mar 25, 2013

@passy I agree, I read the same post. I didn't see any mention of the SailsJS project in my search through the Yeoman issues. So I wanted make sure I mentioned it and see if there are any other people thinking the same way I am. Sails JS project page: http://balderdashy.github.com/sails/

Gnex77 commented Mar 25, 2013

@passy I agree, I read the same post. I didn't see any mention of the SailsJS project in my search through the Yeoman issues. So I wanted make sure I mentioned it and see if there are any other people thinking the same way I am. Sails JS project page: http://balderdashy.github.com/sails/

@jeffscottward

This comment has been minimized.

Show comment Hide comment
@jeffscottward

jeffscottward Mar 27, 2013

I think the future is really in "real-time" via websockets to the browser with an auto-updating DOM based on declarative data bindings markup. http://www.youtube.com/watch?v=ersEb9vTX3Y - This Angular talk is awesome and tackles that as the main reason for Angular use, and also reflects how I author "state-based" styles in an OOP fashion in SASS.

There is a CRUD "Express Stack" experiment with generators but it is written for .9.6, not the new 1.0 setup which is more modular in process workflow (Yo/Grunt/Bower). I don't think that setup does anything real-time but may be closer to what your looking for albeit a "dumber" version as Sails is built on top of Express.

Sails seems pretty freaking cool btw :)
Was looking into Compound but Sails feels right.

I think the future is really in "real-time" via websockets to the browser with an auto-updating DOM based on declarative data bindings markup. http://www.youtube.com/watch?v=ersEb9vTX3Y - This Angular talk is awesome and tackles that as the main reason for Angular use, and also reflects how I author "state-based" styles in an OOP fashion in SASS.

There is a CRUD "Express Stack" experiment with generators but it is written for .9.6, not the new 1.0 setup which is more modular in process workflow (Yo/Grunt/Bower). I don't think that setup does anything real-time but may be closer to what your looking for albeit a "dumber" version as Sails is built on top of Express.

Sails seems pretty freaking cool btw :)
Was looking into Compound but Sails feels right.

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Mar 30, 2013

Hi all. Integrating Sails into yeoman sounds great-- let me know how I can help.

@jeffscottward Our approach is to be front-end agnostic and leave that decision completely up to the developer. I built Sails to fit the needs of several different client projects, and we're continuing to use it this way, so we really didn't have a choice but to be agnostic towards front-end technology choices; especially since sometimes the front-end is not a web client at all, but a native iOS, Android, or Windows Phone app. Or something entirely new we haven't thought of yet! The good news is, today, everyone speaks HTTP, and more and more of us are starting to speak WebSockets.

Hi all. Integrating Sails into yeoman sounds great-- let me know how I can help.

@jeffscottward Our approach is to be front-end agnostic and leave that decision completely up to the developer. I built Sails to fit the needs of several different client projects, and we're continuing to use it this way, so we really didn't have a choice but to be agnostic towards front-end technology choices; especially since sometimes the front-end is not a web client at all, but a native iOS, Android, or Windows Phone app. Or something entirely new we haven't thought of yet! The good news is, today, everyone speaks HTTP, and more and more of us are starting to speak WebSockets.

@Gnex77

This comment has been minimized.

Show comment Hide comment
@Gnex77

Gnex77 Mar 30, 2013

@jeffscottward I played around with "Yeomen" (CRUD Express Stack experiment) when it became an experiment back in version 0.9.6. But since the release of Yeoman 1.0, I stopped playing around with that. When I saw the demo of Sails I thought that this was the direction I wanted my backend to behave.

@mikermcneil After I saw your video demo of Sails I thought immediately of ways of integrating it with Yeoman 1.0. I agree with you in that the back-end implementation should be front-end agnostic. I want to build one back-end that can be accessed by different front-end clients (web, native mobile app, etc). But it would be really helpful if for the initial creation I could also build the web app front-end using Angular. I also have been trying to figure out a way to really learn proper best practices to incorporate WebSockets into my app to make it real-time. When I saw that Sails had Socket.IO built in I was totally amazed. Please keep up the great work and let me know if there is anything I could do to help. Thanks.

Gnex77 commented Mar 30, 2013

@jeffscottward I played around with "Yeomen" (CRUD Express Stack experiment) when it became an experiment back in version 0.9.6. But since the release of Yeoman 1.0, I stopped playing around with that. When I saw the demo of Sails I thought that this was the direction I wanted my backend to behave.

@mikermcneil After I saw your video demo of Sails I thought immediately of ways of integrating it with Yeoman 1.0. I agree with you in that the back-end implementation should be front-end agnostic. I want to build one back-end that can be accessed by different front-end clients (web, native mobile app, etc). But it would be really helpful if for the initial creation I could also build the web app front-end using Angular. I also have been trying to figure out a way to really learn proper best practices to incorporate WebSockets into my app to make it real-time. When I saw that Sails had Socket.IO built in I was totally amazed. Please keep up the great work and let me know if there is anything I could do to help. Thanks.

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Mar 30, 2013

@Gnex77 Thanks! Will do-- we've got some ongoing roadmap discussion in the group I'd love to get your feedback on. We're in this for the long haul :)

@Gnex77 Thanks! Will do-- we've got some ongoing roadmap discussion in the group I'd love to get your feedback on. We're in this for the long haul :)

@Gnex77

This comment has been minimized.

Show comment Hide comment
@Gnex77

Gnex77 Mar 30, 2013

@mikermcneil Would love to help out in any way I can. Thanks.

Gnex77 commented Mar 30, 2013

@mikermcneil Would love to help out in any way I can. Thanks.

@addyosmani

This comment has been minimized.

Show comment Hide comment
@addyosmani

addyosmani Apr 2, 2013

Member

If someone would like to throw together a proposal for what you would like to do with regards to Yeoman + Sails, we would be happy to review. I would like to see whether you're interested in doing something along the lines of ExpressStack or more in line with the more recent proposal for entity-driven tooling which we shared a week or two ago. The latter would be a lot more work, but either way, end-to-end workflow is definitely something I would like to see us experiment with further.

Member

addyosmani commented Apr 2, 2013

If someone would like to throw together a proposal for what you would like to do with regards to Yeoman + Sails, we would be happy to review. I would like to see whether you're interested in doing something along the lines of ExpressStack or more in line with the more recent proposal for entity-driven tooling which we shared a week or two ago. The latter would be a lot more work, but either way, end-to-end workflow is definitely something I would like to see us experiment with further.

@mikermcneil mikermcneil referenced this issue in balderdashy/sails Apr 5, 2013

Closed

More powerful asset configuration #240

@digitalsadhu

This comment has been minimized.

Show comment Hide comment
@digitalsadhu

digitalsadhu Apr 5, 2013

I think I would be pretty interested in even just basic integration of the sails tool into the yeoman stack. I would expect to be able to do something like the following:

yo myApp
sails generate model user
grunt server

and then visit maybe localhost:3501/api/user/create etc. or something along those lines

For me so far the only annoyance i've had with working with both tools is that I have to start up 2 different servers and configure sails for CORS so it would be nice to get them into the same stack running on the same port.

I think I would be pretty interested in even just basic integration of the sails tool into the yeoman stack. I would expect to be able to do something like the following:

yo myApp
sails generate model user
grunt server

and then visit maybe localhost:3501/api/user/create etc. or something along those lines

For me so far the only annoyance i've had with working with both tools is that I have to start up 2 different servers and configure sails for CORS so it would be nice to get them into the same stack running on the same port.

@Gnex77

This comment has been minimized.

Show comment Hide comment
@Gnex77

Gnex77 Apr 5, 2013

@digitalsadhu That is also of my biggest pain points in JavaScript development. An integration like you described it would be the same thing I would be looking for.

Gnex77 commented Apr 5, 2013

@digitalsadhu That is also of my biggest pain points in JavaScript development. An integration like you described it would be the same thing I would be looking for.

@Gnex77 Gnex77 closed this Apr 5, 2013

@Gnex77 Gnex77 reopened this Apr 5, 2013

@Gnex77

This comment has been minimized.

Show comment Hide comment
@Gnex77

Gnex77 Apr 5, 2013

Sorry closed the issue by mistake. Re-opened it.

Gnex77 commented Apr 5, 2013

Sorry closed the issue by mistake. Re-opened it.

@saada

This comment has been minimized.

Show comment Hide comment
@saada

saada Apr 6, 2013

👍

saada commented Apr 6, 2013

👍

@addyosmani

This comment has been minimized.

Show comment Hide comment
@addyosmani

addyosmani Apr 9, 2013

Member

I would be interested in us having a conversation about Sails/Yeoman next week. I would be interested to see if someone would like to prototype a generator for the Sails side.

Member

addyosmani commented Apr 9, 2013

I would be interested in us having a conversation about Sails/Yeoman next week. I would be interested to see if someone would like to prototype a generator for the Sails side.

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Apr 9, 2013

@addyosmani I'm down to chat about it-- maybe a group skype or something? I'd love to be able to rely on the great tools you guys already put together so the Sails community can focus less on asset compilation, etc. and more on what we do best

@addyosmani I'm down to chat about it-- maybe a group skype or something? I'd love to be able to rely on the great tools you guys already put together so the Sails community can focus less on asset compilation, etc. and more on what we do best

@Polyrhythm

This comment has been minimized.

Show comment Hide comment
@Polyrhythm

Polyrhythm Apr 10, 2013

Definitely interested in this.

Definitely interested in this.

@saada

This comment has been minimized.

Show comment Hide comment
@saada

saada Apr 12, 2013

I attempted to write an example that makes both work together...
Here's what I have so far...

https://github.com/saada/sails-ember-yeoman-example

saada commented Apr 12, 2013

I attempted to write an example that makes both work together...
Here's what I have so far...

https://github.com/saada/sails-ember-yeoman-example

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Apr 12, 2013

@saada Awesome :) I know @colinwren i working on this as well. I'm in the midst of a lot of stuff at the moment, but would folks be interested in getting a Skype chat together to talk about this the Saturday night after next (April 20th?)

@saada Awesome :) I know @colinwren i working on this as well. I'm in the midst of a lot of stuff at the moment, but would folks be interested in getting a Skype chat together to talk about this the Saturday night after next (April 20th?)

@saada

This comment has been minimized.

Show comment Hide comment
@saada

saada Apr 12, 2013

Google Hangout FTW

On Thu, Apr 11, 2013 at 8:19 PM, Mike McNeil notifications@github.comwrote:

@saada https://github.com/saada Awesome :) I know @colinwrenhttps://github.com/colinwreni working on this as well. I'm in the midst of a lot of stuff at the
moment, but would folks be interested in getting a Skype chat together to
talk about this the Saturday night after next (April 20th?)


Reply to this email directly or view it on GitHubhttps://github.com/yeoman/yeoman/issues/994#issuecomment-16274062
.

Sincerely,
Mahmoud Saada

saada commented Apr 12, 2013

Google Hangout FTW

On Thu, Apr 11, 2013 at 8:19 PM, Mike McNeil notifications@github.comwrote:

@saada https://github.com/saada Awesome :) I know @colinwrenhttps://github.com/colinwreni working on this as well. I'm in the midst of a lot of stuff at the
moment, but would folks be interested in getting a Skype chat together to
talk about this the Saturday night after next (April 20th?)


Reply to this email directly or view it on GitHubhttps://github.com/yeoman/yeoman/issues/994#issuecomment-16274062
.

Sincerely,
Mahmoud Saada

@Gnex77

This comment has been minimized.

Show comment Hide comment
@Gnex77

Gnex77 Apr 12, 2013

I would be interested in joining the discussion.

Gnex77 commented Apr 12, 2013

I would be interested in joining the discussion.

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Apr 13, 2013

So far in the 4/20 hangout, sounds like we have:

@Gnex77
@mikermcneil
@saada
@colinwren

So far in the 4/20 hangout, sounds like we have:

@Gnex77
@mikermcneil
@saada
@colinwren

@mikermcneil mikermcneil referenced this issue in balderdashy/sails Apr 13, 2013

Closed

Moved assets.js() to footer #315

@dylanized

This comment has been minimized.

Show comment Hide comment
@dylanized

dylanized Apr 13, 2013

I will try and make the Google hangout too. I love the idea of Grunt and Yo integration. I'm not so hot on Bower but looking forward to learning more!

I will try and make the Google hangout too. I love the idea of Grunt and Yo integration. I'm not so hot on Bower but looking forward to learning more!

@addyosmani

This comment has been minimized.

Show comment Hide comment
@addyosmani

addyosmani Apr 15, 2013

Member

Could someone take notes? Will try to make it but would love to read up on the discussion if I can't.

Member

addyosmani commented Apr 15, 2013

Could someone take notes? Will try to make it but would love to read up on the discussion if I can't.

@prajwalkman

This comment has been minimized.

Show comment Hide comment
@prajwalkman

prajwalkman Apr 16, 2013

How many people would want to have both their "backend agnostic" frontend SPA and their "frontend agnostic" api server on the same project folder?

Most of the generators made for yeoman are aimed at SPAs, which are best served directly by a hardened web server like nginx. Node apps (and Sails) are best for pure APIs. I would personally vote to respect the word "agnostic" and maintain them separately as different projects.

Maybe Yeoman can be used to bootstrap an API server project based on Sails, but it certainly shouldn't be mixed with the client side parts. API servers don't need Grunt or Bower.

IMO the best integration between SPAs and Sails would be a simple way to share data, like resource-url mappings. I raised an issue/feature request in the Sails project with this idea in mind some time back:
balderdashy/sails#269

My proposition was to abstract [resourceful routing] away into a library, which generates a single object containing all information necessary for generating routes, mapping resource names to models and controllers, and nesting information. This object can be consumed by Sails, as well as a client side MVC(through JSON), to generate routing information as well as route helper functions like described above.

Just some of my cents.

How many people would want to have both their "backend agnostic" frontend SPA and their "frontend agnostic" api server on the same project folder?

Most of the generators made for yeoman are aimed at SPAs, which are best served directly by a hardened web server like nginx. Node apps (and Sails) are best for pure APIs. I would personally vote to respect the word "agnostic" and maintain them separately as different projects.

Maybe Yeoman can be used to bootstrap an API server project based on Sails, but it certainly shouldn't be mixed with the client side parts. API servers don't need Grunt or Bower.

IMO the best integration between SPAs and Sails would be a simple way to share data, like resource-url mappings. I raised an issue/feature request in the Sails project with this idea in mind some time back:
balderdashy/sails#269

My proposition was to abstract [resourceful routing] away into a library, which generates a single object containing all information necessary for generating routes, mapping resource names to models and controllers, and nesting information. This object can be consumed by Sails, as well as a client side MVC(through JSON), to generate routing information as well as route helper functions like described above.

Just some of my cents.

@dylanized

This comment has been minimized.

Show comment Hide comment
@dylanized

dylanized Apr 16, 2013

@prajwalkman I agree about being frontend-agnostic but it sounds like you are asking for no-frontend at all. Currently Sails has a view system, for SPA apps that don't need anything rendered I imagine there's a pared down API-only framework available somewhere?

Fwiw I shared my thoughts on Yeoman integration, et al in the Google Group - https://groups.google.com/group/sailsjs/browse_thread/thread/2b66629c4d4b9ccf

@prajwalkman I agree about being frontend-agnostic but it sounds like you are asking for no-frontend at all. Currently Sails has a view system, for SPA apps that don't need anything rendered I imagine there's a pared down API-only framework available somewhere?

Fwiw I shared my thoughts on Yeoman integration, et al in the Google Group - https://groups.google.com/group/sailsjs/browse_thread/thread/2b66629c4d4b9ccf

@prajwalkman

This comment has been minimized.

Show comment Hide comment
@prajwalkman

prajwalkman Apr 16, 2013

@dylanized My comments were mainly in response to @saada 's sails-yeoman-ember example, and other attempts to mix in sails with SPA generators.

I have no qualms with generators specifically for full stack backends. Even then, because of connect-assets, the role of Grunt will be greatly reduced, doing little more than running the test cases and assisting deployment.

@dylanized My comments were mainly in response to @saada 's sails-yeoman-ember example, and other attempts to mix in sails with SPA generators.

I have no qualms with generators specifically for full stack backends. Even then, because of connect-assets, the role of Grunt will be greatly reduced, doing little more than running the test cases and assisting deployment.

@saada

This comment has been minimized.

Show comment Hide comment
@saada

saada Apr 16, 2013

That's exactly what I planned to discuss at the hangout. If you use a front
end framework like backbone, ember, angular, knockout; and use Sails as
your backend, what would be the best workflow, and how would you go by
generating views? For example, say I use backbone, do I completely drop the
Sails view system? Keep in mind that we wanna keep all the livereload,
concat, requirejs, and all the yeoman goodies out of the box...

The ultimate setup would be: 'yo generate sailsapp:angular' then 'sails
generate angular-model user name:string id:integer' then add a few more
models that way and then 'yo generate angular:all-sails-models' or
something along those lines... And the result would be a normal yeoman
setup with the ability to generate backend models with their corresponding
frontend models. If say, you want ONLY a backend model, use Sails generate,
if you want a frontend model, use Yo. This is my opinion, I would like to
hear what you guys think? How do you imagine the workflow to be like?

On Monday, April 15, 2013, prajwalkman wrote:

@dylanized https://github.com/dylanized My comments were mainly in
response to @saada https://github.com/saada 's sails-yeoman-ember
example, and other attempts to mix in sails with SPA generators.

I have no qualms with generators specifically for full stack backends.
Even then, because of connect-assets, the role of Grunt will be greatly
reduced, doing little more than running the test cases and assisting
deployment.


Reply to this email directly or view it on GitHubhttps://github.com/yeoman/yeoman/issues/994#issuecomment-16429188
.

Sincerely,
Mahmoud Saada

saada commented Apr 16, 2013

That's exactly what I planned to discuss at the hangout. If you use a front
end framework like backbone, ember, angular, knockout; and use Sails as
your backend, what would be the best workflow, and how would you go by
generating views? For example, say I use backbone, do I completely drop the
Sails view system? Keep in mind that we wanna keep all the livereload,
concat, requirejs, and all the yeoman goodies out of the box...

The ultimate setup would be: 'yo generate sailsapp:angular' then 'sails
generate angular-model user name:string id:integer' then add a few more
models that way and then 'yo generate angular:all-sails-models' or
something along those lines... And the result would be a normal yeoman
setup with the ability to generate backend models with their corresponding
frontend models. If say, you want ONLY a backend model, use Sails generate,
if you want a frontend model, use Yo. This is my opinion, I would like to
hear what you guys think? How do you imagine the workflow to be like?

On Monday, April 15, 2013, prajwalkman wrote:

@dylanized https://github.com/dylanized My comments were mainly in
response to @saada https://github.com/saada 's sails-yeoman-ember
example, and other attempts to mix in sails with SPA generators.

I have no qualms with generators specifically for full stack backends.
Even then, because of connect-assets, the role of Grunt will be greatly
reduced, doing little more than running the test cases and assisting
deployment.


Reply to this email directly or view it on GitHubhttps://github.com/yeoman/yeoman/issues/994#issuecomment-16429188
.

Sincerely,
Mahmoud Saada

@saada

This comment has been minimized.

Show comment Hide comment
@saada

saada Apr 16, 2013

Also, I have an experimental angular/yeoman setup if anyone wants to take a look... It still has its quirks.

saada commented Apr 16, 2013

Also, I have an experimental angular/yeoman setup if anyone wants to take a look... It still has its quirks.

@dylanized

This comment has been minimized.

Show comment Hide comment
@dylanized

dylanized Apr 16, 2013

My ideal would be something like:

  • generate backend scaffolding using Sails tools
  • Sails offers current view "kit" as a default
  • additional view "kits" can snap on and extend/override the default kit. There might be an Angular view kit, a Backbone kit, and Knockout one, and so forth.

Perhaps at first the kits could be written out as manual recipes - perhaps just a list of dependencies, some hello world templates, and a little glue code. Then later, the kit-install process could be automated...?

My ideal would be something like:

  • generate backend scaffolding using Sails tools
  • Sails offers current view "kit" as a default
  • additional view "kits" can snap on and extend/override the default kit. There might be an Angular view kit, a Backbone kit, and Knockout one, and so forth.

Perhaps at first the kits could be written out as manual recipes - perhaps just a list of dependencies, some hello world templates, and a little glue code. Then later, the kit-install process could be automated...?

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Apr 16, 2013

I'm happy to work on modifications to the Sails.js to respect the use case
where you're only using Sails' API and (optionally) public directories--
the only thing stopping that from happening right now is that express
expects to find a view directory.

Looking forward to the chat!
-Mike

On Tue, Apr 16, 2013 at 2:22 PM, Dylan Hassinger
notifications@github.comwrote:

My ideal would be something like:

  • generate backend scaffolding using Sails tools
  • Sails offers current view "kit" as a default
  • additional view "kits" can snap on and extend/override the default
    kit. There might be an Angular view kit, a Backbone kit, and Knockout one,
    and so forth.

Perhaps at first the kits could be written out as manual recipes - perhaps
just a list of dependencies, some hello world templates, and a little glue
code. Then later, the kit-install process could be automated...?


Reply to this email directly or view it on GitHubhttps://github.com/yeoman/yeoman/issues/994#issuecomment-16466035
.

Mike McNeil
Founder
http://www.linkedin.com/in/mikermcneil/ http://twitter.com/mikermcneil
http://github.com/balderdashy

   C      O
  NFI    DEN
  TIA   L i
  nfo  rma
  tion in
   tended
only for t      he addressee(s).

If you are not the intended recipient, empl
oyee or agent responsible for delivery to the
intended recipient(s), please be aware that
any review, dissemination, use,distribut
ion or copying of this message and its
contents is strictly prohibited. If
you receive this email in error, ple
ase notify the sender and destroy any
paper or electronic copies immediately.

I'm happy to work on modifications to the Sails.js to respect the use case
where you're only using Sails' API and (optionally) public directories--
the only thing stopping that from happening right now is that express
expects to find a view directory.

Looking forward to the chat!
-Mike

On Tue, Apr 16, 2013 at 2:22 PM, Dylan Hassinger
notifications@github.comwrote:

My ideal would be something like:

  • generate backend scaffolding using Sails tools
  • Sails offers current view "kit" as a default
  • additional view "kits" can snap on and extend/override the default
    kit. There might be an Angular view kit, a Backbone kit, and Knockout one,
    and so forth.

Perhaps at first the kits could be written out as manual recipes - perhaps
just a list of dependencies, some hello world templates, and a little glue
code. Then later, the kit-install process could be automated...?


Reply to this email directly or view it on GitHubhttps://github.com/yeoman/yeoman/issues/994#issuecomment-16466035
.

Mike McNeil
Founder
http://www.linkedin.com/in/mikermcneil/ http://twitter.com/mikermcneil
http://github.com/balderdashy

   C      O
  NFI    DEN
  TIA   L i
  nfo  rma
  tion in
   tended
only for t      he addressee(s).

If you are not the intended recipient, empl
oyee or agent responsible for delivery to the
intended recipient(s), please be aware that
any review, dissemination, use,distribut
ion or copying of this message and its
contents is strictly prohibited. If
you receive this email in error, ple
ase notify the sender and destroy any
paper or electronic copies immediately.

@Gnex77

This comment has been minimized.

Show comment Hide comment
@Gnex77

Gnex77 Apr 17, 2013

From my perspective I would tend to agree with @saada. I would like to use a Sails/Yeoman hybrid so that I can create my backend API and the corresponding front end models for something like Angular. To @prajwalkman points , I would tend to want to create both backend and frontend in one project but I do see your point of making them separately to ensure proper hardening of the server stuff.

My biggest thing is that I really like the Sails tool and how it automatically integrates Socket.io into the API server for real-time apps. Then I would use Yeoman to create a testable, buildable front end based on Angular (or any of the before mentioned front end frameworks).

Gnex77 commented Apr 17, 2013

From my perspective I would tend to agree with @saada. I would like to use a Sails/Yeoman hybrid so that I can create my backend API and the corresponding front end models for something like Angular. To @prajwalkman points , I would tend to want to create both backend and frontend in one project but I do see your point of making them separately to ensure proper hardening of the server stuff.

My biggest thing is that I really like the Sails tool and how it automatically integrates Socket.io into the API server for real-time apps. Then I would use Yeoman to create a testable, buildable front end based on Angular (or any of the before mentioned front end frameworks).

@jeffscottward

This comment has been minimized.

Show comment Hide comment
@jeffscottward

jeffscottward Apr 17, 2013

2nd what Guario said. The last paragraph is exactly what I would be looking
for.
Easy to use real-time api on the back, easy declarative-style MV* on the
front, with all the grunt goodies now available as well as bower.
Disclaimer: I've never written an SPA or real deal node app, but I can see
this being something nice to transition too. I'm a front end guy by trade
but node infinitely fascinates me. :)

On Tuesday, April 16, 2013, Guario Rodriguez wrote:

From my perspective I would tend to agree with @saadahttps://github.com/saada.
I would like to use a Sails/Yeoman hybrid so that I can create my backend
API and the corresponding front end models for something like Angular. To
@prajwalkman https://github.com/prajwalkman points , I would tend to
want to create both backend and frontend in one project but I do see your
point of making them separately to ensure proper hardening of the server
stuff.

My biggest thing is that I really like the Sails tool and how it
automatically integrates Socket.io into the API server for real-time apps.
Then I would use Yeoman to create a testable, buildable front end based on
Angular (or any of the before mentioned front end frameworks).


Reply to this email directly or view it on GitHubhttps://github.com/yeoman/yeoman/issues/994#issuecomment-16484778
.

Thanks,
Jeff Ward
Front-end Developer
Tel: 516-551-8624
jsward.17@gmail.com
@jeffscottward https://twitter.com/#!/jeffscottward

2nd what Guario said. The last paragraph is exactly what I would be looking
for.
Easy to use real-time api on the back, easy declarative-style MV* on the
front, with all the grunt goodies now available as well as bower.
Disclaimer: I've never written an SPA or real deal node app, but I can see
this being something nice to transition too. I'm a front end guy by trade
but node infinitely fascinates me. :)

On Tuesday, April 16, 2013, Guario Rodriguez wrote:

From my perspective I would tend to agree with @saadahttps://github.com/saada.
I would like to use a Sails/Yeoman hybrid so that I can create my backend
API and the corresponding front end models for something like Angular. To
@prajwalkman https://github.com/prajwalkman points , I would tend to
want to create both backend and frontend in one project but I do see your
point of making them separately to ensure proper hardening of the server
stuff.

My biggest thing is that I really like the Sails tool and how it
automatically integrates Socket.io into the API server for real-time apps.
Then I would use Yeoman to create a testable, buildable front end based on
Angular (or any of the before mentioned front end frameworks).


Reply to this email directly or view it on GitHubhttps://github.com/yeoman/yeoman/issues/994#issuecomment-16484778
.

Thanks,
Jeff Ward
Front-end Developer
Tel: 516-551-8624
jsward.17@gmail.com
@jeffscottward https://twitter.com/#!/jeffscottward

@prajwalkman

This comment has been minimized.

Show comment Hide comment
@prajwalkman

prajwalkman Apr 17, 2013

@mikermcneil I've looked at Sails and there's no need to specifically change anything to make it more favourable to the "pure API server" crowd. Even a pure API server tends to have a couple of views that are mainly used to check status/performance and maintenance mode for admins. Even if we don't use views, Sails is not harming us. Since it lives serverside, having more options doesn't bother us like it would in SPAs where size matters.

The issue here is how and where it would fit in the "yo" workflow, and how it should interact, if at all, with SPA generators, which is currently 100% of the use case for yeoman.

@mikermcneil I've looked at Sails and there's no need to specifically change anything to make it more favourable to the "pure API server" crowd. Even a pure API server tends to have a couple of views that are mainly used to check status/performance and maintenance mode for admins. Even if we don't use views, Sails is not harming us. Since it lives serverside, having more options doesn't bother us like it would in SPAs where size matters.

The issue here is how and where it would fit in the "yo" workflow, and how it should interact, if at all, with SPA generators, which is currently 100% of the use case for yeoman.

@Gnex77

This comment has been minimized.

Show comment Hide comment
@Gnex77

Gnex77 Apr 20, 2013

Wondering if we are still having the Google Hangout or not tonight?

Gnex77 commented Apr 20, 2013

Wondering if we are still having the Google Hangout or not tonight?

@Gnex77

This comment has been minimized.

Show comment Hide comment
@Gnex77

Gnex77 Apr 20, 2013

2nd, your second @jeffscottward! :)

Gnex77 commented Apr 20, 2013

2nd, your second @jeffscottward! :)

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Apr 20, 2013

What time guys? 8pm cst ok?

What time guys? 8pm cst ok?

@saada

This comment has been minimized.

Show comment Hide comment
@saada

saada Apr 20, 2013

Works for me...
For anyone in CA or AZ, 8pm CST is 6pm PST

saada commented Apr 20, 2013

Works for me...
For anyone in CA or AZ, 8pm CST is 6pm PST

@Gnex77

This comment has been minimized.

Show comment Hide comment
@Gnex77

Gnex77 Apr 20, 2013

8pm CST works for me. I'm on the East coast so that would be 9 PM for me.

Gnex77 commented Apr 20, 2013

8pm CST works for me. I'm on the East coast so that would be 9 PM for me.

@saada

This comment has been minimized.

Show comment Hide comment
@saada

saada Apr 20, 2013

I had a nice chat with @colinwren and we agreed on some important points to discuss today:

❤️ Yeoman ❤️ Sails ❤️

NOTES:

1. Dynamic views vs Static views
    a. Sails forces dynamic views
    b. A good solution would be to make sails static by default and give the option for dynamic views.
    c. The main issue right now is with asset rack.
2. Sails has the best of both Ruby and Node worlds: 
    a. Ruby has an awesome API generator for ORM and Routing.
    b. Node's modularity and the NPM awesomeness.
3. Sails needs to be able to be run in dev or production from grunt (grunt server : dist) and it needs to serve static assets from the 'dist' folder when its in production mode.
4. Lack of sails tests make it easy to break things.

❤️ Yeoman ❤️ Sails ❤️

Checkout his repo: https://github.com/colinwren/generator-sails

saada commented Apr 20, 2013

I had a nice chat with @colinwren and we agreed on some important points to discuss today:

❤️ Yeoman ❤️ Sails ❤️

NOTES:

1. Dynamic views vs Static views
    a. Sails forces dynamic views
    b. A good solution would be to make sails static by default and give the option for dynamic views.
    c. The main issue right now is with asset rack.
2. Sails has the best of both Ruby and Node worlds: 
    a. Ruby has an awesome API generator for ORM and Routing.
    b. Node's modularity and the NPM awesomeness.
3. Sails needs to be able to be run in dev or production from grunt (grunt server : dist) and it needs to serve static assets from the 'dist' folder when its in production mode.
4. Lack of sails tests make it easy to break things.

❤️ Yeoman ❤️ Sails ❤️

Checkout his repo: https://github.com/colinwren/generator-sails

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Apr 21, 2013

@saada all great points!

I'll be on skype in 5 mins (balderdashy) for anyone available to chat

@saada all great points!

I'll be on skype in 5 mins (balderdashy) for anyone available to chat

@Gnex77

This comment has been minimized.

Show comment Hide comment
@Gnex77

Gnex77 Apr 21, 2013

Something just came up. I may be late to the party.

Gnex77 commented Apr 21, 2013

Something just came up. I may be late to the party.

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Apr 21, 2013

@Gnex77 no problem, I'll post some notes back here

@Gnex77 no problem, I'll post some notes back here

@saada

This comment has been minimized.

Show comment Hide comment
@saada

saada Apr 21, 2013

Here's what I was able to decypher during the hangout:

Yoeman - Sails
==============
4/20/2013 Skype Notes:

- Configurable server options on Sails-side in the Gruntfile.
- Couldn't serve production assets due to how asset rack works.
- Sails should be PhoneGap friendly
- Nap is a good alternative to assetrack
- Grunt automatically compiles scss and places it on the page.
- Have some way to control modules including listing dependencies and Grunt would grab all these dependencies.
- CommonJS, AMD, RequireJS vs just a GRUNT backend setup vs Browserify
- We definitely want to use Grunt for dependencies
- Yo cli can just act as a generation tool
- Public folder for frontend stuff
- Api folder for backend stuff
- Less/Sass compiling
- It would be nice if Sails asked the user if they wanted to use Backbone or Ember or whatever and map it to a Yeoman generator etc... Setting up Grunt for you and so on.
- Sails cli, then grunt, 
- Sails should follow Grunt conventions
- Right now we have the VIEWS folder. You can trigger them from the controller. We don't want to get rid of Dynamic Views but at the same time you don't wanna force users to use it right away. It should be more of an option. What do we do about server-side
- What about nested resources/models? Not yet... Probably do validations first, then relations... 

saada commented Apr 21, 2013

Here's what I was able to decypher during the hangout:

Yoeman - Sails
==============
4/20/2013 Skype Notes:

- Configurable server options on Sails-side in the Gruntfile.
- Couldn't serve production assets due to how asset rack works.
- Sails should be PhoneGap friendly
- Nap is a good alternative to assetrack
- Grunt automatically compiles scss and places it on the page.
- Have some way to control modules including listing dependencies and Grunt would grab all these dependencies.
- CommonJS, AMD, RequireJS vs just a GRUNT backend setup vs Browserify
- We definitely want to use Grunt for dependencies
- Yo cli can just act as a generation tool
- Public folder for frontend stuff
- Api folder for backend stuff
- Less/Sass compiling
- It would be nice if Sails asked the user if they wanted to use Backbone or Ember or whatever and map it to a Yeoman generator etc... Setting up Grunt for you and so on.
- Sails cli, then grunt, 
- Sails should follow Grunt conventions
- Right now we have the VIEWS folder. You can trigger them from the controller. We don't want to get rid of Dynamic Views but at the same time you don't wanna force users to use it right away. It should be more of an option. What do we do about server-side
- What about nested resources/models? Not yet... Probably do validations first, then relations... 
@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Apr 21, 2013

thanks! Good to meet/talk to everyone

thanks! Good to meet/talk to everyone

@krzysztofantczak

This comment has been minimized.

Show comment Hide comment
@krzysztofantczak

krzysztofantczak May 12, 2013

For people who want to use this combination right now, i've created a simple solution which i'm using:

  1. sails new foo-project;
  2. cd foo-project;
  3. yo webapp (for example, note that you will have a conflict between sails and yo package.json, You can remove the sails one, and just add sails dependency into package.json from yeoman)
  4. npm install && bower install
  5. change your target dist directory into 'public' instead of '.tmp'
  6. curl http://pastebin.com/raw.php?i=LrphmN9D > proxy.js
  7. node proxy.js
  8. your browser should open http://localhost (without any port by default, since proxy is listening on port 80)
  9. that's all, You are using yeoman as it was before, same thing with sails - all with autoreload feature which works perfect.

For people who want to use this combination right now, i've created a simple solution which i'm using:

  1. sails new foo-project;
  2. cd foo-project;
  3. yo webapp (for example, note that you will have a conflict between sails and yo package.json, You can remove the sails one, and just add sails dependency into package.json from yeoman)
  4. npm install && bower install
  5. change your target dist directory into 'public' instead of '.tmp'
  6. curl http://pastebin.com/raw.php?i=LrphmN9D > proxy.js
  7. node proxy.js
  8. your browser should open http://localhost (without any port by default, since proxy is listening on port 80)
  9. that's all, You are using yeoman as it was before, same thing with sails - all with autoreload feature which works perfect.
@addyosmani

This comment has been minimized.

Show comment Hide comment
@addyosmani

addyosmani May 17, 2013

Member

I think the discussion and the work that's been kickstarted here is just fantastic. As this is a tracker for general Yeoman bugs/issues I think we should move the discussion to the sails generator repo so that it's possible to have more granular control of features, roadmap, what you want to achieve and so on.

If you decide to do that it would be awesome if you could link back to this thread for anyone that organically finds it through search.

Member

addyosmani commented May 17, 2013

I think the discussion and the work that's been kickstarted here is just fantastic. As this is a tracker for general Yeoman bugs/issues I think we should move the discussion to the sails generator repo so that it's possible to have more granular control of features, roadmap, what you want to achieve and so on.

If you decide to do that it would be awesome if you could link back to this thread for anyone that organically finds it through search.

@addyosmani addyosmani closed this May 17, 2013

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Jul 12, 2013

We've implemented Grunt support for asset compilation in the upcoming v0.9. I'd love to hook our CLI/API generators into yo for creating the client-side app structure, and bower for grabbing front-end deps, but I can't personally lead the charge there at the moment, since I'm pretty swamped extending, testing, and maintaining the other parts of the project. If anyone's interested in being the pointman/woman, drop me a line!

-mike

We've implemented Grunt support for asset compilation in the upcoming v0.9. I'd love to hook our CLI/API generators into yo for creating the client-side app structure, and bower for grabbing front-end deps, but I can't personally lead the charge there at the moment, since I'm pretty swamped extending, testing, and maintaining the other parts of the project. If anyone's interested in being the pointman/woman, drop me a line!

-mike

@daslicht

This comment has been minimized.

Show comment Hide comment
@daslicht

daslicht Jul 29, 2013

Automatic server restart & Browserrefresh would be lovely :)

~Marc

Automatic server restart & Browserrefresh would be lovely :)

~Marc

@Lujaw

This comment has been minimized.

Show comment Hide comment
@Lujaw

Lujaw Dec 10, 2013

Came across this thread through search.. Its an awesome idea. Has this been brought into existence ?
Found https://github.com/colinwren/generator-sails too .. but it seems to have been long abandoned..

Lujaw commented Dec 10, 2013

Came across this thread through search.. Its an awesome idea. Has this been brought into existence ?
Found https://github.com/colinwren/generator-sails too .. but it seems to have been long abandoned..

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Dec 16, 2013

Been working on our generators lately-- would love to hook up with Yeoman
in a more sophisticated way, just not sure how....

On Tue, Dec 10, 2013 at 5:36 AM, Lujaw notifications@github.com wrote:

Came across this thread through search.. Its an awesome idea. Has this
been brought into existence ?
Found https://github.com/colinwren/generator-sails too .. but it seems to
have been long abandoned..


Reply to this email directly or view it on GitHubhttps://github.com/yeoman/yeoman/issues/994#issuecomment-30218464
.

Mike McNeil
Founder
http://www.linkedin.com/in/mikermcneil/ http://twitter.com/mikermcneil
http://github.com/mikermcneil

   C      O
  NFI    DEN
  TIA   L i
  nfo  rma
  tion in
   tended
only for t      he addressee(s).

If you are not the intended recipient, empl
oyee or agent responsible for delivery to the
intended recipient(s), please be aware that
any review, dissemination, use,distribut
ion or copying of this message and its
contents is strictly prohibited. If
you receive this email in error, ple
ase notify the sender and destroy any
paper or electronic copies immediately.

Been working on our generators lately-- would love to hook up with Yeoman
in a more sophisticated way, just not sure how....

On Tue, Dec 10, 2013 at 5:36 AM, Lujaw notifications@github.com wrote:

Came across this thread through search.. Its an awesome idea. Has this
been brought into existence ?
Found https://github.com/colinwren/generator-sails too .. but it seems to
have been long abandoned..


Reply to this email directly or view it on GitHubhttps://github.com/yeoman/yeoman/issues/994#issuecomment-30218464
.

Mike McNeil
Founder
http://www.linkedin.com/in/mikermcneil/ http://twitter.com/mikermcneil
http://github.com/mikermcneil

   C      O
  NFI    DEN
  TIA   L i
  nfo  rma
  tion in
   tended
only for t      he addressee(s).

If you are not the intended recipient, empl
oyee or agent responsible for delivery to the
intended recipient(s), please be aware that
any review, dissemination, use,distribut
ion or copying of this message and its
contents is strictly prohibited. If
you receive this email in error, ple
ase notify the sender and destroy any
paper or electronic copies immediately.

@unknownArtist

This comment has been minimized.

Show comment Hide comment
@unknownArtist

unknownArtist Dec 20, 2013

@mikermcneil so where we are at the moment ?

@mikermcneil so where we are at the moment ?

@SBoudrias

This comment has been minimized.

Show comment Hide comment
@SBoudrias

SBoudrias Dec 20, 2013

Member

@mikermcneil Is your generator available on Github? Also, feel free to drop by #yeoman on IRC to dicuss with us.

Member

SBoudrias commented Dec 20, 2013

@mikermcneil Is your generator available on Github? Also, feel free to drop by #yeoman on IRC to dicuss with us.

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Jan 11, 2014

@unknownArtist @SBoudrias So I'm going to be doing some work on this over the weekend-- current implementation is on the v10blueprints branch, but I'm going to change them up to look like this so they can be nested cleanly. They're more restrictive than a yeoman generator since they're for files generated within a Sails project, but I'd love to be able to cleanly hook into yeoman (as long as interactive prompts can be disabled.) No reason to reinvent the wheel here-- ideally, our shit is just a loose wrapper/glorified config file around yeoman generators people are already using/enjoying.

Anyways, remind me if you think about it and I'll post an update with where things are at next week-- In the mean time, if you have ideas or want to help out, I'll be hacking away on it late tonight (CST) and tomorrow (I'm @mikermcneil on twitter)

@unknownArtist @SBoudrias So I'm going to be doing some work on this over the weekend-- current implementation is on the v10blueprints branch, but I'm going to change them up to look like this so they can be nested cleanly. They're more restrictive than a yeoman generator since they're for files generated within a Sails project, but I'd love to be able to cleanly hook into yeoman (as long as interactive prompts can be disabled.) No reason to reinvent the wheel here-- ideally, our shit is just a loose wrapper/glorified config file around yeoman generators people are already using/enjoying.

Anyways, remind me if you think about it and I'll post an update with where things are at next week-- In the mean time, if you have ideas or want to help out, I'll be hacking away on it late tonight (CST) and tomorrow (I'm @mikermcneil on twitter)

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Jan 11, 2014

@addyosmani btw- my guess is that we're not the only project who's working something like this on top of yeoman. If you have preferences for how you envision this going down (as far as the API for other projects leveraging yeoman generators from their own CLIs), just let me know, happy to set up the interface with however you think makes sense.

@addyosmani btw- my guess is that we're not the only project who's working something like this on top of yeoman. If you have preferences for how you envision this going down (as far as the API for other projects leveraging yeoman generators from their own CLIs), just let me know, happy to set up the interface with however you think makes sense.

@SBoudrias

This comment has been minimized.

Show comment Hide comment
@SBoudrias

SBoudrias Jan 11, 2014

Member

Well, wrapping a generator behind your own façade should be pretty easy.

You'd just need to create an environment, register your generator on it and run it:

var yo = require('yeoman-generator');
var env = yo();
env.register('path/to/generator', 'sails:app');
env.run('sails:app');

This is exactly how yo is running internally (when aliasing yo yo): https://github.com/yeoman/yo/blob/master/cli.js#L59-L96

Member

SBoudrias commented Jan 11, 2014

Well, wrapping a generator behind your own façade should be pretty easy.

You'd just need to create an environment, register your generator on it and run it:

var yo = require('yeoman-generator');
var env = yo();
env.register('path/to/generator', 'sails:app');
env.run('sails:app');

This is exactly how yo is running internally (when aliasing yo yo): https://github.com/yeoman/yo/blob/master/cli.js#L59-L96

@mikermcneil

This comment has been minimized.

Show comment Hide comment
@mikermcneil

mikermcneil Jan 11, 2014

@SBoudrias awesome, thanks :)

@SBoudrias awesome, thanks :)

@emagnier

This comment has been minimized.

Show comment Hide comment
@emagnier

emagnier Jan 30, 2014

Before found this thread, I was also trying to add livereload and an optimized version of the watcher in the SailsJS gruntfile (improve execution speed, auto refresh the browser...), but it still doesn't work well...

A Yeoman template will be a great help for us! Can't wait to see it happen!

Before found this thread, I was also trying to add livereload and an optimized version of the watcher in the SailsJS gruntfile (improve execution speed, auto refresh the browser...), but it still doesn't work well...

A Yeoman template will be a great help for us! Can't wait to see it happen!

@gunish

This comment has been minimized.

Show comment Hide comment
@gunish

gunish Sep 27, 2014

Just wondering if there has been any progress on this yet ? I was trying to start a new project today using yeoman but quickly realised there are some blockers

  1. yo webapp generated pretty much the static view of the world.
  2. It would be awesome if grunt serve would serve the app via the sails lift processor ?
  3. There should be an easy way to build / lint and deploy from dist to assets in sails
  4. The watcher should look at all the files in the sails folders to refresh the server.

I am not sure if all of these are possible but would love to know everyone's thoughts ?

gunish commented Sep 27, 2014

Just wondering if there has been any progress on this yet ? I was trying to start a new project today using yeoman but quickly realised there are some blockers

  1. yo webapp generated pretty much the static view of the world.
  2. It would be awesome if grunt serve would serve the app via the sails lift processor ?
  3. There should be an easy way to build / lint and deploy from dist to assets in sails
  4. The watcher should look at all the files in the sails folders to refresh the server.

I am not sure if all of these are possible but would love to know everyone's thoughts ?

@SBoudrias

This comment has been minimized.

Show comment Hide comment
@SBoudrias

SBoudrias Sep 27, 2014

Member

@gunish and anyone wondering, there's over 1000 generators available for you to use http://yeoman.io/generators/ - Just find one matching your needs.

Member

SBoudrias commented Sep 27, 2014

@gunish and anyone wondering, there's over 1000 generators available for you to use http://yeoman.io/generators/ - Just find one matching your needs.

@guysopher

This comment has been minimized.

Show comment Hide comment
@guysopher

guysopher Nov 30, 2015

Can I bump this thread?
It's been a while and I don't think there is a proper solution for that. Has anyone found a way to make yeoman work with sails?

Can I bump this thread?
It's been a while and I don't think there is a proper solution for that. Has anyone found a way to make yeoman work with sails?

@SBoudrias

This comment has been minimized.

Show comment Hide comment
@SBoudrias

SBoudrias Nov 30, 2015

Member

Search for sails here http://yeoman.io/generators/ - there's a lot of options.

Member

SBoudrias commented Nov 30, 2015

Search for sails here http://yeoman.io/generators/ - there's a lot of options.

@SBoudrias SBoudrias locked and limited conversation to collaborators Nov 30, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.