Planning version 5

[thetutlage]

This discussion is open for the public to share their ideas on features they want to see in AdonisJs with version 5.

Please note:

1. All requests cannot be accepted, but we can always discuss the reasons like adults.
2. All accepted requests will be added to this comment.
3. The work on version 5 has not yet started. I will update this thread when I will start working on it.
4. The focus is to reduce the number of breaking changes.
5. If you like some idea, then use the reactions to thumbs up and please do not comment with +1.
6. If you are interested in working on a feature, please lemme know and we can discuss it in depth.

Big features

• Add support for Http2
• Add JSON API serializer to Lucid serializers list.
• Add support for Queue jobs. I have been playing with bee-queue recently and really liked it. Open for more suggestions.
• Add presence support in WebSockets.
• Re-write Edge AST parser from scratch. There have been some open issues on how sensitive Edge parser is. We want it to work with any Javascript Expression
• First class support for graphQL.
• Passwordless auth

Enhancements

• Allow validator unique rule to be more versatile, by applying runtime database constraints.
• Improve how seeds are executed. There is an open RFC on same.
• Use eslint over standard.
• Upgrade vow-browser to the latest version of the puppeteer. Puppeteer has evolved a lot in last few months, so there will be the bunch of breaking changes. We just need to fix them and keep the API compatible.
• Translate validation messages when using Route validator.
• Support for global traits, which are added to all test suites.

Good to have

• API Docs. For this, we need to improve docblocks in the code and also make use of YuiDoc or similar tools to generate API docs for all the official repos.
• Almost every component of Adonis uses the concept of Drivers, we can abstract the driver behavior to its own module and simply re-use it everywhere. Examples of same are: Mail, Session, Drive.
• Move all config files to a single repo. Currently, a single change in a config file needs to be done in all the boilerplates.
• Scheduled jobs AKA Cron jobs but created from ace commands to run ace commands
• Use import syntax over use method to resolve dependencies from IoC container. This highly depends upon the progress done in the core of Node.js. Also, since ES6 modules in Node.js supports .mjs extensions, will have to think about that too.

Breaking changes

Performance Wins

• Use native sets and maps in places where values are dynamically added over time.
• Replace all Arrays with Sets, were are later use _.unique to pull unique items. This results in some serious performance gains.

[moltar]

1. Add a validator that uses JSON Schema. This makes it easier to re-use work across backend/frontend and nicely integrates with many form libraries.
2. Maybe outside the scope of this, but maybe there is some work that needs to happen to make this work, but it'd be nice to be able to use Adonis websockets with GraphQL subscription transport.
3. Request I made via PR elsewhere: Proposal to add Cookie scheme auth#103

[fractalzombie]

Typescript or flow types support

[rtablada]

Hey @thetutlage poking in here to discuss jsonapi.org serializer support.

Especially with the introduction of operations, the structure of Lucid serializers is not a fit for compliant serialization.

Some things that would be needed for compliance is to properly be aware of include and fields from the request object. While I'm not saying the serializer should be responsible for fetching/lazy loading this data it is important for coverage that included relations are ONLY included when include is present in the URL and fields should only include the fields in the specified type when fields is present in the URL query params.

From experience implementing, teaching, and working on OSS that uses jsonapi.org spec, my recommendation is to have a serializer with a serialize function that takes in two arguments (shown with pseudo typescript): serialize(req: Request, collection: LucidCollection).

Some good implementations are:

• JA Serializer - This uses a more functional and addon approach to serialization with a separate model and "view" for serialization
• JSON API DotNET Core - This takes a much more embedded approach to integration and adds descriptions/decorators to models which are used for serialization later on and it changes the view/serialization layer built in to MVC
• JSON API Resources - This is probably the most magical implementation and changes a lot of the controller, view, and even model behavior

My preference is somewhere between JA Serializer and JSON API DotNET Core.

Some other things to really think about and work with, a built in integration layer for jsonapi should also help with error serialization and should be aware of links for resources and relationships (which then requires some integration to the router potentially for best use).

The good thing is that this work could also be applied for other specs like JSON Schema and even GraphQL

[ammezie]

It will be nice to have some kind of release plan for new versions of AdonisJs. That way we know when to expect new versions.

[ammezie]

Add support for task scheduling.

[ghost]

Please add support for MongoDB

[wxs77577]

Please make MongoDB as built-in support

[Zizaco]

As @ammezie said. I think a build in way to do task scheduling would be worth having. Due to the way the server process runs, Nodejs is perfect for this and it would make the setup of the schedule runner much simpler than in analog frameworks.

Perhaps you can simply include modules that already exists (or very similar code) to the core. For example:
https://codelike.pro/schedule-jobs-crontab-like-in-an-adonisjs-app/

[Zizaco]

Queue jobs 👍

[thetutlage]

@Zizaco @ammezie Sure I will look into the Scheduled tasks as well. Adding it to the list.

Regarding MongoDB and GraphQL
I personally don't use both. What that means, I am not expert in these technologies to build modules or solutions around them. I know @RomainLanz is passionate about GraphQL, and if he publishes something great, I will be adding to it to the list of 1st party modules.

Regarding MongoDB @wxs77577, you already maintain a module for same. I am happy to share any insights you looking for. But adding that to the core and maintaining it is not possible, since I have almost zero experience with MongoDB.

[wxs77577]

RBAC
Module
Plugin

[ghost]

hello;

Great features. Is it possible to have a release plan; each 6 months so we can make commitments on our products as well :)

thanks for the fantastic job on adonisjs.

[Zizaco]

Some basis for authorization (much like laravel's one) would be cool

[RomainLanz]

You can already do that with @slynova/fence or even using the alpha version of adonis-guard. Happy to help you in the Discord Server.

Concerning V5, I want also to... (not in order)

1. Rewrite the Router to be able to add with ease regex for defining parameters.
2. Implement the new design for the website
3. Rewrite the doc completly
4. Add polymorphic support to Lucid
5. Add soft delete support to Lucid (WIP: Soft deletes lucid#315)
6. Extract the view layer to its own module (so people will be able to use something else than edge)
7. Make adonis-bundler an official package.
8. Finish adonis-graphql

[moltar]

For queues, it should be something AMQP-compatible. Or even more ideally, the protocol should be pluggable (kind of like database is now).

One reason I prefer RabbitMQ over Redis, is that RMQ has support for dead letter queue (SQS supports that too). That makes it easier to write fault-tolerant apps. I can simply throw in the task handler code and the task is automatically re-queued according to the queue system logic.

With Redis though, the task needs to be manually re-inserted (error prone).

[hadihallak]

@Zizaco in addition to what @RomainLanz suggested, you should check out enniel/adonis-acl

[moltar]

Support for better logging swapping. E.g. I prefer to use Bunyan.

[pdipax]

Hi guys, add sftp filesystem for remote storage.

[taviroquai]

I know that this request will break everything but hey, its a new major version 5, so people will expect it to break anyway, so it's good to start new projects:

Standard es5/6 import modules, instead of "use"

[rtablada]

@taviroquai depending on the release date plan for 5, this would conflict with latest Node LTS and adoption across companies relying on LTS. I think after Node LTS supports import/export statements then it could be more feasible.

The other way around this would be to require a precompile step which is doable (and can actually lead to some pretty interesting performance improvements) but would be a pretty large departure from what's currently available.
I think if precompile did become an option, then I think that there would need to be a full major version cycle where you could do both.

[lffg]

It would be great to have an native (and optional) assets compiler, lixe Laravel Mix.

---

Also route groups inside another groups would be realy nice in some situations, example:

Route.group(() => {

  Route.group(() => {
    Route.get('/login', 'SessionController.login')
    Route.post('/login', 'SessionController.submitLogin')

    Route.get('/register', 'SessionController.register')
    Route.post('/register', 'SessionController.submitRegister')
  }).middleware('redirect-if-authenticated')

  Route.get('/logout', 'SessionController.logout')
    .middleware('auth')
    
}).prefix('/session')

[PazzaVlad]

I think i would be great to have ability to configure folder structure, like for views, exceptions folder etc. It would make possible use more modular structure and divide app by logical modules.

[rtablada]

Mixing the ideas of @lffg and @PazzaVlad, Engines support could be nice so that you can build sub projects and mount the entire project to the router and have a sharing mechanism to map things within sub DIs.

So in an Engine you might have a User model that you require to be mapped but there would be a way to inject a different Lucid model (for example a Guest model) into the Engine.

This is heavily inspired by rails and Ember engines

[viglucci]

Would be great if the request and response objects were compatible with the objects used by Express, and if middleware in Adonis supported the same interface as Express middlewares.

With no compatibility between Express middleware (mainly due to differences in the request and response objects), it is very costly to migrate an existing Express application to Adonis if your Express application makes heavy use of middlewares.

[feryardiant]

I wonder if validator messages will looking for translation (if available) by default. For example, if we have unique, required or any validations error it will looking for available translation first, otherwise use default message.

The translation file would be located in resources/locales/<locale>/validations.json & should contains the following

// resources/locales/<locale>/validations.json
{
  "unique": "The {field} should be unique",
  "required": "The {field} is required",
  "range": "The {field} should between {0} and {1}"
}

I've done this by creating simple helper that dump all validation keys from indicative like this:

Helpers.validationMessages = () => {
  const formats = {}
  const rules = require('indicative/builds/validations')

  for (let rule of Object.keys(rules)) {
    rule = rule.split(/(?=[A-Z])/).join('_').toLowerCase()

    formats[rule] = (field, type, args) => {
      const params = { field, ...args }
      try {
        return Antl.formatMessage(`validations.${type}`, params)
      } catch (err) {
        Logger.debug('Validation translation not found', { err })
      }
    }
  }

  return formats
}

That way I could simply use validate(data, rules, Helpers.validationMessages), so I don't have to translate each form manually.

I thought it would be great if adonis could handle this kind of functionality by default.

P.s. Hope you guys get the idea even tho my english was so poor 😁

[moltar]

Would be great if the request and response objects were compatible with the objects used by Express, and if middleware in Adonis supported the same interface as Express middlewares.

Totally agree with that. I don't see why we even need these special wrapper objects, when an original object can be extended with all of the same features.

[moltar]

Implement front-matter for email templates.

I think it'd be better if we could define the subject line, and even to and from inside the email template itself. A front matter could be a good solution for this. I don't like that we have to hard-code the subject inside the code itself.

[feryardiant]

@moltar

Implement front-matter for email templates.

I don't think that was good (for me personaly). What I'm currently implement is add from and repyTo inside app.js config and use Translation for subject instead, That way I could simply dispatch a job (using adonis-kue for now)

job.dispatch('mailer', { type: 'user-activation', recipient: userInstance, data )}

Inside the Jobs/Mailer.js

async handle ({ type, recipient, data }) {
  data.recipient = recipient

  const view = `emails.${type}`
  const subject = Antl.formatMessage(view, { extraValueIfAny })

  await Mail.send(view, data, (mail) => {
    mail.to(recipient.email, recipient.username)
      .from(app.mailer.address, app.mailer.name)
      .subject(subject)
  })
}

And here the view/emails/user-activation.edge

@layout('layouts.emails')

@section('content')
  <tr>
    <td align="left" valign="top">
      <p>Hello {{ recipient.username }},</p>
      <p>Welcome bla bla bla:</p>
    </td>
  </tr>

  <tr>
    <td align="center" height="10" style="font-size:10px; line-height:10px;">
      @!component('components.emails-button', ....)
    </td>
  </tr>
@endsection

Because .

I don't like that we have to hard-code the subject inside the code itself.

And also I don't like that I have to add another dependency just for sending a simple email.

Just personal preference

[thetutlage]

@moltar How come you can define the to field inside the email template itself. A single email template is used to send emails to multiple people.

@feryardiant I don't think adding a dependency is really a big deal. That what Node eco-system is all about.

[Larsklopstra]

Ship Adonis with assets support for SCSS & JS like Laravel Mix to avoid hassle with webpack or Parcel.

[Larsklopstra]

Method fields would also be nice instead of form spoofing.

{{ method('POST') }}

[PazzaVlad]

Ship Adonis with assets support for SCSS & JS like Laravel Mix to avoid hassle with webpack or Parcel.

why just don't use laravel mix?

[Larsklopstra]

Ship Adonis with assets support for SCSS & JS like Laravel Mix to avoid hassle with webpack or Parcel.

why just don't use laravel mix?

Requires additional setup, I just would like to install Adonis and code away 😄

[sujai1009]

As @ammezie said. I think a build in way to do task scheduling would be worth having. Due to the way the server process runs, Nodejs is perfect for this and it would make the setup of the schedule runner much simpler than in analog frameworks.

Perhaps you can simply include modules that already exists (or very similar code) to the core. For example:
https://codelike.pro/schedule-jobs-crontab-like-in-an-adonisjs-app/

Unique schedular when running in cluster mode with pm2 or kubernetes. A database based scheduler like "quartz" will be more handy.

[jakesylvestre]

For typescript/flow/static typing discussion, I've gone ahead and opened #65, happy to move it back if we want to but I think it makes sense to have its own issue.

[kieranz]

Do you still plan on using typescript?

[hadihallak]

@kieranz As far as I know, They already started working on it, and yes, the core is being rewritten in typescript.

[RomainLanz]

@kieranz As @hadihallak said, we are currently rewriting the core in TS and fixing bugs + adding features in the same time.

[samueldotfr]

Add support for task scheduling.

https://forum.adonisjs.com/t/bug-with-adonis-make-command/653/2

[shimjudavid]

If Adonisjs 5 is re-wrote in TS, then I assume we can use TypeORM too instead of Lucid?

[rtablada]

@shimjudavid I think the idea is that Lucid would/is being rewritten as well since it’s fairly core to the Adonis experience and because there needs to be a smooth compatibility and upgrade story for existing users. Though having better TS support would likely mean that using other TS libraries does become easier and using TS in your project may be the default for new projects.

[shimjudavid]

If we use TypeORM as a default ORM for AdonisJs 5 then Adonis team no longer need to maintain their Lucid ORM, rather they can focus more on new framework features. BTW, TypeORM is very stable ORM and no point in re-invent the wheels by rewriting Lucid.

[willvincent]

@shimjudavid Lucid is a big part of the reason to choose Adonis, really. Using a different orm would be like using Doctrine in Laravel instead of Eloquent. Sometimes the outcome is worth designing your own wheel. ;)

[microSoftware]

+1 for passwordless auth.

[jpcbarros]

+1 for First class support for graphQL
+1 for Adding support for Queue jobs

[PatrickL789]

Really, just make it more “laravel-esque than it is already :)

[crivera]

Hi
is there a timeline on when v5 is supposed to be released?

[RomainLanz]

Hey @crivera! 👋

No timeline yet but @thetutlage and I are working on it every day 👍

[begueradj]

Unlike relational tables which store data, views store predefined queries that return a result set.

Views have several advantages, the one I appreciate more is that they improve database security and integrity given the fact we can use them to display only the columns we want to particular users, for example.

Until now, migrations deal only with tables. I think we should add the possibility to create views also.

[willvincent]

Until now, migrations deal only with tables. I think we should add the possibility to create views also.

The main blocker, as I see it, to this is that knex doesn't have any native support for views, other than via raw queries -- and there's nothing currently preventing one from using those same raw queries in migration files.

[begueradj]

I think it would be better to use Faker.js instead of Chance.js because:

• Faker.js can fake images whereas Chance.js can not (this is the main reason)
• npm trends
• Github popularity

[geoffreylzf]

Add audit trail (log) for Lucid (insert, update and delete)
example: https://github.com/simontong/adonis-auditable

[begueradj]

I think more core members should join the developers team. You are only 2 for the moment (or 3 since recently, from what I read somewhere)

[begueradj]

Focus on REST & Security.
MVC is dead.