feat(gen): Sub-Generator for REST URLs

[DaftMonk]

Generates boilerplate for creating a new rest URL. Would generate GET/POST/PUT/UPDATE/DELETE routes following standard REST format. Would link routes to a generated controller file.

[andrewstuart]

I was literally just thinking of asking if there'd be value in a subgenerator for :model or some similar name. It could scaffold a $resource, server route, and mongoose schema all pre-linked, plus unit tests. Thoughts?

[DaftMonk]

That sounds like a great idea. I would really like to see this added to the generator.

[andrewstuart]

I'd love to work on it and either do an outright pull request or collaborate, but I wanted to get your thoughts before I started too far down the path. Especially since my path tends to be a bit opinionated towards dynamic route handling.

My first instinct on server side architecture would be to use a route like app.all("/api/1/*", ...) route that hands off to another controller, say ./lib/controllers/api1. At bootstrap, that controller could read the contents of the ./lib/models directory, require each one, and get their respective names, routes, handlers, etc, and shove them into an object/map by name. Then when a request comes in, the api1 controller could check the map for the appropriate route by name, which we'd assume from the path is the first param after /api/1/, then hand off to the appropriate handler.

For the generator, I was thinking something like yo angular-fullstack:model foo ?bar ?baz where foo would be the name and filename, and bar and baz would be optional paramaters tacked onto the end of the route and added to the $resource as :params as well. Maybe that's a bit too much for a first go, though. Anyway, let me know what you think.

[DaftMonk]

That sounds close to what I had in mind. I really like the idea of the dynamic route creation from the loaded models. One egde case I was thinking about was if there'd be a time where you'd want to have private models that you wouldn't to be accesed by the api. I can't think of any examples off the top of my head of that, but it would be worth considering before going down that road in favor of just having the generator find the routes section and insert the new models route and point it to a controller.

I also really like the idea of adding params to $resource, although to be honest, I need to look at the $resource documentation a little more to see how that would work.

One other situation I'd consider is what to do if the project wasn't setup with Mongoose. I guess it would just check for the mongo.js file and if it doesnt find it then sends back an error requiring mongoose?

But this sound like really cool idea. How about I add you as a collaborator and we can setup a branch and work on this when we both have time?

[andrewstuart]

Sounds good to me :-) A thought for private models could be to either ignore file names starting with an underscore, or have a private folder. The underscore has the benefit of being an angular convention as of 1.2 and throws an error as I found out when we upgraded. I'm glad you brought that up because that could be powerful for data driven server behavior and you might want to be pickier with how those routes are set up.

For the mongo dependency perhaps we could set an env option if there isn't one already when the generator asks up front. Then we can check for the option every time and if not present ask if they want to add the route in server.js, the api1.js and mongo.js file. (I may be wrong but I think a subgenerator can still prompt).

I also liked the way route uses a hook for both a view and controller so I was going to attempt that with model using subgenerators for a resource and a schema, so they could be used separately also.

I haven't personally used mongoose or resource yet past brief proofs of concept but I've been anxious for an excuse.

[DaftMonk]

Cool, private models with underscores would work for me.

I'm not sure if prompts work for subgenerators either, but that would probably be ideal.

Anyway, I added you as a collaborator and created the new branch :)

[sullivanpt]

If I can throw in two cents at the start, I also like the idea of creating automatic routing and controllers for simple models; however, in the general case for my use cases my controllers frequently need to do more complex merging and synchronization of multiple models; I suppose the underscore notation will work for me here. My other concern is authorization: I'm currently annotating each resource route with user role access rights (e.g. anyone can read, admin can write); the access annotation doesn't typically belong in the model so I'm not sure how the new auto-router would handle this.

[andrewstuart]

Where do you typically handle that? My first thought would be some sort of
middleware for the routing that just rejects anything but a get for
standard users, but I haven't done that level of access control yet.

On Saturday, February 15, 2014, Patrick Sullivan [email protected]
wrote:

If I can throw in two cents at the start, I also like the idea of creating
automatic routing and controllers for simple models; however, in the
general case for my use cases my controllers frequently need to do more
complex merging and synchronization of multiple models; I suppose the
underscore notation will work for me here. My other concern is
authorization: I'm currently annotating each resource route with user role
access rights (e.g. anyone can read, admin can write); the access
annotation doesn't typically belong in the model so I'm not sure how the
new auto-router would handle this.

Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-35169786
.

[sullivanpt]

Yes, middleware that looks at the req.user object that the passport session attaches. In my case it's a little more complicated because I'm authorizing on several dimensions (user role, oauth2 token scope, etc.), but I think for the generator a simple approach using just the user.role is appropriate. The problem I don't have an answer for is how best to mark up the meta information if routes are auto-generated from the model.

Sent from my Windows Phone

---

From: Andrew Stuartmailto:[email protected]
Sent: ‎2/‎15/‎2014 2:50 PM
To: DaftMonk/generator-angular-fullstackmailto:[email protected]
Cc: Patrick Sullivanmailto:[email protected]
Subject: Re: [generator-angular-fullstack] feat(gen): Sub-Generator for REST URLs (#3)

Where do you typically handle that? My first thought would be some sort of
middleware for the routing that just rejects anything but a get for
standard users, but I haven't done that level of access control yet.

On Saturday, February 15, 2014, Patrick Sullivan [email protected]
wrote:

If I can throw in two cents at the start, I also like the idea of creating
automatic routing and controllers for simple models; however, in the
general case for my use cases my controllers frequently need to do more
complex merging and synchronization of multiple models; I suppose the
underscore notation will work for me here. My other concern is
authorization: I'm currently annotating each resource route with user role
access rights (e.g. anyone can read, admin can write); the access
annotation doesn't typically belong in the model so I'm not sure how the
new auto-router would handle this.

Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-35169786
.

---

Reply to this email directly or view it on GitHub:
#3 (comment)

[sullivanpt]

Now that I've slept on it I think you should ignore my complication as it really is a different use case than the auto-router. What will work best for my case is a simple best-practices code generator similar to angular:route (which makes boiler plate for a controller, a view, unit test harnesses for each, and injects a new route into the app). So I imagine the server side equivalent might be angular-fullstack:route and it would generate a model, a controller, inject the get/put/post/delete into lib/routes.js, create a simple mocha unit test for the whole thing, and then it would be up to me to go in and modify the boiler-plate to fit my needs. Anyway, I think you should move ahead with your vision unhindered; it will be useful!

[kjellski]

Hey all, just wanted to hear on how this is going, I would like to help out here, where should I start?

I would merge master into model_gen and go on from there, is there something particular missing?

[DaftMonk]

Hey Kjellski, I think that would be fine, a rebase of model_gen onto master might be easier though. Model_gen is very dated at this point, but I think most of the changes made in it were relatively isolated so I would imagine a merge to get the latest changes wouldn't be too hard.

[gabzim]

I came into the issues menu to bring this up. Luckily I went through the issues to see if someone hadn't done it already.

+1!

I am new to yeoman so I'm not that knowledgeable on generators/sub-generators but I think soon I'll be able to contribute.

[kjellski]

@arg20 I think this ticket is sort of dispatched into the 2.0 release, it will include way better oportunities to include this cleanly, have a look at #192

And while you're at it, contribute here to the new structure: https://github.com/DaftMonk/modular-fs

[DaftMonk]

Closing with 2.0 launched.