Create a generator for a feathers app

[ekryski]

Possibly a yeoman generator? Or maybe just a CLI like express does. It should initially scaffold out an app structure and a package.json file that has all the dependencies that a normal express app needs, especially now that they are separate from express now.

I'm thinking an app structure could look like this:

public/
  -> fonts/
  -> images/
  -> js/
  -> styles/
  -> test/
server/
  -> config/
  -> lib/
  -> services/
  -> test/
  -> views/
.jshintrc
package.json
README.md

[Glavin001]

+1 I have been thinking about this, too.

Include common plugins, such as feathers-errors and feathers-mongoose, etc.

[ekryski]

Yep agreed. We're going to bring feathers-errors into core. See issue #79. I'm working on this right now actually.

[daffl]

I think that would be great. The question is... what are we going to support in the generator for client side stuff? I'm inclined to just make it a kickass generator for the server with everything you might need and then provide separate client side generators (although it would be nice to generate a service and it does everything both on the server and client for you).

[Glavin001]

The issue is that the client will depend on the service's query and return structure. For instance, let's say we use feathers-mongooose, it has different queries supported than feathers-orm-service and the results returned could be different, so our client will have to support that.
We may require generator-feathers-server -- which allow you to choose pre-defined model-to-service libraries, such as feathers-mongoose or feathers-orm-service -- and generator-feathers-client -- which allows you to choose canjs-feathers or feathers-ember-mongoose-adapter, et cetera. I'm a fan of Ember, so I'll use that as the example, although that may get even more complicated: do we have them use generator-ember or generator-angular and then include the glue later (Adapter in Ember's case) for the model mapping.

[daffl]

I think that the query mechanism could be normalized with hooks but querying things might also not matter for just scaffolding an application since the basic communication (REST API calls or socket events) will be the same in every case (and methods of pre-implemented services should return the same data structures, too).

[ekryski]

Ya I'm inclined to agree with @daffl. I think that all the query stuff should probably be done with hooks. We should provide examples in the service adapters but shouldn't be built in to the service itself.

For scaffolding I would say let's start with a server side generator. We can iterate as we go and improve things as we come across issues. We may or may not need client side generators... but I can't really tell right now they might fit just yet.

[Glavin001]

I think the server is a great start and will get us a long way. Maybe others will contribute and build client generators in the future.

With regards to the querying: I am not overly familiar with feathers-hooks and even less so how it would be applicable in the case I am thinking of.
For example, feathers-mongoose querying uses the Mongoose query syntax while feathers-orm-service uses Sequelize, which writes SQL/etc queries. These are drastically different, and I cannot really imagine them being normalized by, say, feathers-hooks, to provide a consistent standard to provide from the server API after generated.

Could you two example how feathers-hooks could help in this case? Or maybe we are talking about different cases.

[daffl]

What I mean is that you could add your own querying abstraction on top of your services that implement a common querying pattern so that you can easily swap them out. For example the following hook converts service parameters like { query: { active: true } to an SQL where clause:

userService.before({
  find: function(hook, next) {
    var query = hook.params.query;
    var where = 'WHERE ';

    _.each(query, function(value, name) {
      where += name + "= '" + sqlEscape(value) + "'";
    });

    hook.params.query = where;
    next();
  }
});

We were discussing a generalized querying format for service implementations before but it would be a lot of work to implement (and test against).

As for client side adapters wouldn't we just need something like feathers-ember-adapter though? From how I understand it the querying mechanism is just an additional parameter provided by the user or does it do something Mongoose specific?

[Glavin001]

As for client side adapters wouldn't we just need something like feathers-ember-adapter though? From how I understand it the querying mechanism is just an additional parameter provided by the user or does it do something Mongoose specific?

As long as the returned data is standardized then all we would need is a feathers-ember-adapter. The standard could be nested in meta data:

{
"total_available": 100,
"start": 10,
"end": 20,
"results": [ { /* data 1 */ },... ]
}

Or flatter and without meta data (raw results):

[ 
{ /* data */ }, 
... 
]

After that, the findQuery of the Adapter could simply forward that to feathers --> feathers-mongoose --> mongoose --> mongodb, so it would be up to the user to write and handle those queries.

---

What I mean is that you could add your own querying abstraction on top of your services that implement a common querying pattern so that you can easily swap them out.

I had a feeling that is what you guys meant. I am not sure how that would really work though, because SQL is vastly different from MongoDB and if I am using either, I would like to use the true syntax of the query language. Now that I think about it I could see how it works for the basic functions, such as find, get, create, update, patch, and remove. That would actually be a very cool feature!

If you guys determine a standard, I will update feathers-mongoose, and feathers-orm-service to support it! Each plugin could have it's own adapter, to use when applicable.
Or maybe one plugin with a bunch of adapters? feathers-adapters?

I'm getting very excited to see this generator-feathers come into shape!

[daffl]

Sounds great. I think it would be best to finish up the 1.0 release and the other plugins and the server app generator first and then we'll put a spec for querying service on the roadmap together with client side framework connectors. Makes sense?

[daffl]

We can now keep track for this in https://github.com/feathersjs/generator-feathers

[lock]

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.