Controllers and beyond

[bajtos]

Controllers decoupled from the data models/ORM is a concept I have had in my mind for very long time and that I am personally interested in exploring.

We have already started some exploratory work in this direction, see
https://github.com/strongloop-internal/scrum-loopback/issues/614#issuecomment-187124065 and the rest of the discussion.

Once we have a basic concept of a connector implemented, it will open up many further areas to investigate, for example:

• Right now, defining custom types to describe input/output values of custom remote methods is a bit cumbersome. The format of these definition is LDL, which is our own non-standard language. I would like to allow users to describe their input/output values using JSONSchema and/or the subset of JSON Schema used by Swagger.

• There are only very basic validation of input arguments that are not Models - we check for type (string/number/object) and whether the argument is required or not. I would like to see improved validations, using either JSON Schema or npm modules like joi

• ORM independence. Let's face it, writing and maintaining a good ORM is a lot of work, and in all honesty, I think we are pretty much failing at that. I would like to make it easy for LoopBack users to switch to a different ORM/data-access library when their needs outgrow the basic ORM capabilities we provide in LoopBack.

For the scope of loopback-next, I think there will be more than enough work to implement Controllers as a first-class entity, meaning:

• the runtime
• support in loopback-boot
• support in loopback-workspace
• a CLI tool to create new controller
• a CLI tool to add a new remote method to a controller
• (optionally, but preferably) support in APIC Editor

[bajtos]

As I was writing #6 (comment), I realised the approach chosen for https://github.com/strongloop-internal/scrum-loopback/issues/614#issuecomment-187124065 may not work well if we want to use a strongly-typed implementation, or even if we only want to provide a strongly-typed app.controller() method.

I think the work on Controllers should therefore wait for the resolution of #3.

Ideally, I would like to back-port most of loopback-next version of Controllers to the current 3.x base as an incremental improvement.

[deepakrkris]

@bajtos @superkhau @ritch
We could have a generic inbuilt controller which could be extended or changed , instead of making controllers the alternative for model based routing.

• - A controller is a handler for invoking one or more models using certain invocation patterns.
  we could have a better design of the following:
  https://github.com/strongloop/loopback/blob/master/server/middleware/rest.js#L35 or
  https://github.com/strongloop/loopback-phase/blob/master/lib/phase.js#L139

• - A DefaultRestController handles the request/response without any configuration.

• - Users can add new controllers through configuration

[raymondfeng]

We need to nail down the number of artifacts. Here is what I have in mind (maybe with different names):

1. Resource/Controller: handling REST req/res
2. Model: representing data
3. Repository (backed by Model Def + DataSource/Connector): handling backend interactions

In LoopBack 1.x-3.x, we have singleton classes for 1+2+3. It should be possible for developers to choose either combining or separating the responsibilities by decorating the class.

[superkhau]

We could have a generic inbuilt controller which could be extended or changed , instead of making controllers the alternative for model based routing.

Extensibility is first class citizen, meaning we will probably end up having some sort of generic (I'm personally pushing for minimal) controller which then we'll build off of using a combination of decorators/extending/mixin/etc as described by @raymondfeng above. As far as something concrete, I think we still needs some more discussion/prototyping.

[bajtos]

1. Resource/Controller: handling REST req/res
2. Model: representing data
3. Repository (backed by Model Def + DataSource/Connector): handling backend interactions

Makes perfect sense!

We could have a generic inbuilt controller which could be extended or changed
Extensibility is first class citizen, meaning we will probably end up having some sort of generic (I'm personally pushing for minimal) controller

As I commented in #6 (comment), having a base class that extensions has to inherit from will most likely add extra complexity. We should carefully asses the implications before committing to this design, to prevent going down a dead end street.

[deepakrkris]

I hope we will support the existing model based routing, for example a defined User model with user.json has a path /users.

[ritch]

I think we have a pretty good idea where we are going with this, but i'd like to keep these two points open:

There are only very basic validation of input arguments that are not Models - we check for type (string/number/object) and whether the argument is required or not. I would like to see improved validations, using either JSON Schema or npm modules like joi

ORM independence. Let's face it, writing and maintaining a good ORM is a lot of work, and in all honesty, I think we are pretty much failing at that. I would like to make it easy for LoopBack users to switch to a different ORM/data-access library when their needs outgrow the basic ORM capabilities we provide in LoopBack.

[superkhau]

Closing as this is already happening. Current proposal can be found at https://github.com/strongloop/loopback-next/wiki/Controllers.