Plugin interface about ember-cli HOT 12 CLOSED

Absolutely, to derive the plugin interface it would be great if (using EAK as a guide) compiled a list here of possible plugins. From their we can try implementing them, this will hopefully guide us to a useful plugin API

from ember-cli.

@stefanpenner I added 3 use cases that I have in my current app but I don't know if they're clear. Let me know if I need to elaborate on each or describe them.

from ember-cli.

@taras we also need to make a checklist of stuff ember-cli does not support today but EAK does. Do you have some time to begin that list?

from ember-cli.

@stefanpenner should this checklist be a separate issue? something like EAK Feature Checklist?

from ember-cli.

@taras sounds good.

from ember-cli.

Hey guys, where is the checklist located? I'd like to peak at it. My employer (a large global retailer) is interested in using ember, ember-cli and EAK. So as part of our EA team I like to keep up on the progress. Thanks, Jeff

from ember-cli.

@stefanpenner I have an idea about how to implement server plugin interface. It's not 100% yet but I hope that in conversation we can hash it out. I'm going to focus on the server because thats one area that requires customization in every project(and I'm most familiar with).

I propose that we make the server customization look like the Ember Router. Express, by default, prefers configuration over conventions. We can add a bit of conventions while maintaining backwards compatibility with Express Middleware. This will allow us to use the middleware that are available from Express but make it look and feel like Ember.

Here is what an ember-cli server file might look like.

module.exports = function(Router) {
  Router.map(function() {
    // this.resource & this.route are will be built into the Route class
    this.resource('posts', function() {
      this.route('new');
    });

   // proxy can be provided by a plugin
   this.proxy('/v1', 'http://api.example.com');
  });
}

Directory structure

/server/router.js
/server/routes/posts/index.js 
/server/routes/posts/new.js

Conventions

By default, resources and routes will map to a default module that will look something like this.

module.exports.get = defaultGetMiddleware;
module.exports.post = defaultPostMiddlware;
module.exports.put = defaultPutMiddleware;
module.exports.delete = defaultDeleteMiddleware;

To override default behaviour, the user will have to create a module that will override the default behaviour.

// posts/new.js

module.exports.post = function(req, res) {
 // custom behaviour
}

Plugins

The developer will be able to install npm modules that will provide custom Router behaviour. This custom behaviour will be accessible via Router methods that will customize the router. Let's take a proxy example,

After installing ember-proxy npm module, add plugin to the ember.json file(or whatever equivalent).

// ember.json 
{
  plugins: ['proxy']
}

Internally, ember-proxy plugin will use a hook to bind proxy method to the Router. We'd need to discuss how this will work. ember-proxy can be a simple wrapper around node-http-proxy.

This proposal doesn't cover request/response handling. I think we need some mechanism to make it easier to customize the output based on the query or session. Let me know if you have any thoughts about this.

from ember-cli.

Don't hide express. That road leads straight to hell. :) There are so many frameworks out there which already try to do this. But I don't think that this makes things any easier. Pure express nearly always means less code and more flexiblity.

If we want to pack each route into a file then IMO the correct way for doing this is using glob:

var express = require('express'),
    RSVP = require('rsvp'),
    Promise = RSVP.Promise,
    glob = RSVP.denodeify(require('glob'));

Promise.resolve(express())
.then(function(app) {
  // Glob the routes and require them
  return glob('./path/to/your/routes/**/*.js', {cwd: __dirname}).then(function(routes) {
    routes.forEach(function(route) { require(route)(app); });
    return app;
  });
})
.then(function(app) { app.listen(...) }) ;  // Or whatever follows

For middleware, multiple calls to .use() are best because order matters.

Using JSON for that isn't a good idea. What if a middleware is only needed under a certain condition?

from ember-cli.

I'm not suggesting to hide it, I'm only suggesting to give configuration that looks more familiar to an Ember developer. It's one level of abstraction over EAK existing Express Server.

I guess if the user wanted to write an express server directly they could always opt out and just edit the Express Server configuration.

Sent from my iPhone

On Mar 12, 2014, at 2:45 AM, MajorBreakfast [email protected] wrote:

Don't hide express. Express isn't ember!

—
Reply to this email directly or view it on GitHub.

from ember-cli.

As long as it doesn't work 100% like the ember router, I don't see value in it. Learning the differences is harder than learning express (which is pretty minimalistic).

But don't let me discourage you from making changes to this part! My suggestion is ONLY to not build another entire layer on top of express. All I'm saying is: Keep it simple.

from ember-cli.

@MajorBreakfast my phone only showed me 1st paragraph of your responses. I'll comment on everything you wrote shortly.

from ember-cli.

Closing this now.

• Proxying is now integrated
• #153 holds further discussion about the API stub

from ember-cli.