Discussion: Node web framework

[remojansen]

We are thinking that express-utils is likely to become a full framework. We are going to use this issue to share ideas and feature requests.

We have already identified support for authorisation as a required feature.

[jhuntoo]

Possible topics for discussion.

Scope of framework;

• Routing
• Authorisation
• Authentication
• Dependency Injection
• Custom Middleware, (method, controller & global)
• ORM ??

Pluggability

• Just express or extendable to other frameworks ?

Use existing frameworks vs roll our own

• Validation - https://github.com/epoberezkin/ajv perhaps
• Sequelize is well established, there are others too

[remojansen]

I think ORM is out of the scope. We should be compatible with ORMs but nothing beyond that.

• Routing 👍
• Authorisation 👍
• Authentication 👍
• Dependency Injection 👍
• Custom Middleware 👍

We can provide the users with default implementations of these features for example we can provide with a default implementation of Authorisation using passport but the users should be able to register their own implementations.

• Pluggability 👍

Based on ASP.net core this is the Built-in middleware that they offer:

• Validation 👍 sounds like another nice idea.

[remojansen]

I would like to also suggest response caching support:

[ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)]
public IActionResult Error()
{
  return View();
}

And make as easy as possible working with multiple environments (dev, prod, uat...)

[lholznagel]

How much do we want to do in terms of Authentication? I think we should support a basic login with database and, to go with the time, something like two-factor authentication. With a module called notp it was very easy when I used it in an application of mine.

[jhuntoo]

I'd suggest we move away from express (or any other framework) handler function signatures and use our own. This means we could do cool things like model binding.

index(@body() body) {
    return ok('Hello World')
}

index(@queryString('filter') filter) {
    return notFound({ object: {} })
}

index(@param('userId')) {
    return ok();
}

[lholznagel]

Wow that's so awesome :+1: I also agree with a move away from other frameworks. Will take some more work, but nothing that we can´t handle

[codyjs]

@jhuntoo I like the idea of doing away with the express handler signatures and making things more customizable. Do we still want users to be able to access the request/response objects? (I.e. index(@req() request: express.Request)) or do we want to hide the express objects entirely?

[lholznagel]

@codyjs Maybe the Objects should only be available in a reduces way. Sometimes when I need to look into the Objects it is so much unnecessary information.

[jhuntoo]

I would say that we should still provide direct access to request and response objects, because sometimes syntactic sugar isn't enough to cover all cases.

I would argue though that we have own request & response objects, that via adapters, get connected to the host http framework like express/koa/hapi etc.

So all code within a controller method is written in the typescript-y style, and we can keep a consistent approach to interacting with the request/response pipeline

In theory users, could write part of their app in Inversify, or natively in their chosen http host framwork.

[lholznagel]

So, do we want to create a whole new framework? When we maybe should create an extra repo for it and we should define some issues, so that we can start working on it.

[remojansen]

:+1: to:

I would say that we should still provide direct access to request and response objects, because sometimes syntactic sugar isn't enough to cover all cases.

and

I would argue though that we have own request & response objects, that via adapters, get connected to the host http framework like express/koa/hapi etc.

I think we need an npm module for the framework and an npm module for each of the adapters so we can do something like:

$ npm install framework framework-express

$ npm install framework framework-koa

And people will be able to extend it...

should create an extra repo for it and we should define some issues.

I'm open to suggestions we can work on the inversify-express-utils repo or create a new repo... if we create a new repo we need a name!

Another suggestion that I would like to do is to use asp.net core as a reference. It can help us a lot for example I used ninject and angular 2 while developing inversify and having a reference was really useful.

[jhuntoo]

Yeah I think so... also Inversify was a name born out of DI right? so given that that this will be a http application framework, I'd suggest a departure from that name.

Trying to use type in it... (though maybe not a good idea as we don't want to exclude ES6/7 folks right @remojansen ) typeroutes troutes typeapi

Maybe something less descriptive and cooler sounding as every other JS framework github 😄

[jhuntoo]

@remojansen Agreed.

I like the way angular, ngrx does it...

npm install @framework/core @framework/express @framework/authorization @framework/validation

[remojansen]

Yes Inversify is related with "inversion of control". We could relate it somehow with the SOLID principles.

Sometimes I use a word translated to another language. For example SOLID in Japanese is kotai that sounds cool to me: kotai.js.

Or maybe because we allow people to replace one framework express with other like koa that is the Liskov substitution principle so maybe Liskov it would be a tribute to Barbara Liskov.

One more suggestion Martin.js as a tribute to Robert Cecil Martin for his relation with the "Dependency inversion principle".

npm install @framework/core @framework/express @framework/authorization @framework/validation

The best solution is to create a new GitHub organization in that case.

[lholznagel]

The angular / ngrx way is pretty awesome.

I like to name my project like stars. kotai sound good to me

[remojansen]

The name of a star could be cool! feel free to suggest some :)

[lholznagel]

Here are some that don´t exist hundreds of times on Github

• wega
• canopus
• enif
• arktur
• mirfak
• elnath
• nunki

[jhuntoo]

@antoniolopesgomes @tenowg @pleerock I"m cc'ing you in on this discussion as authors of similar projects so that we can discuss, overlaps, objectives, and perhaps uniting together to build "the" kick-arse typescript web server framework.

We have a number of folks here that would like to bring to together existing pieces like DI (Inversify), decorator based routing, Authorization, Authentication, Validation into discreet modules that can be leveraged on any underlying http framework such as express/koa/hapi via use of a pluggable engines.

You are already building (or have built) some of this - would you be interested joining forces ??

[remojansen]

Closing this we can follow the conversation at https://github.com/CitadelJS/core/issues 😄

[amir-arad]

hi, the link above is broken. where's the discussion live today? 10x

[lholznagel]

The project idea is not active anymore.

My suggestion would be to use nest

[remojansen]

@amir-arad if you want a fully featured framework nest is the solution if you want more freedom of choice then you can use inversify-express-utils. I will be soon experimenting and trying to finish https://github.com/ZafiroJS which will be an alternative to nest but it is going to take several months due to my lack of free time

[lonix1]

Sorry to perform a thread resurrection... but this thread is full of devs who've done "serious tinkering"...

Has anyone got this to work with koa? The only reason I'm still using express is I love inversify-express-utils - if I could decorate koa routes I'd abandon the callback hell of express!

...inversify officially supports express, restify and hapi - will koa be supported too?