Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nodegate v2 roadmap #85

Open
7 tasks
Shudrum opened this issue Nov 4, 2020 · 0 comments
Open
7 tasks

Nodegate v2 roadmap #85

Shudrum opened this issue Nov 4, 2020 · 0 comments

Comments

@Shudrum
Copy link
Contributor

Shudrum commented Nov 4, 2020

Hello!

At Weekendesk, we have a huge numbers of routes and many internal feedbacks of the usage of nodegate. We know that some choices made from the beginning must be changed, and long term ideas / improvements needed to be done.

This is why we decided to start the development of the v2.

Here is what we want to achieve:

  • Replace request by got.
    Request is now deprecated, and we still didn't want to manage the requests by ourselves, this is why our current candidate is got.

  • Simpler and better URL management.
    At the beginning we wanted full text URL management to allow usage of variables and maybe having an external editor. It just doesn't works well. URLs will only allow parameters declaration, and assigning variables to the parameters, query parameters and body will be done in pure javascript.

  • New service entity.
    Currently all calls are done by writing full URLs, repeating ou (?:micro)services urls, and reusing everywhere many environment variables. This entity will allow to set only one time the URL's domain, and optionnaly hardcode some headers specific to the http calls made to the services, and predefining some requests, for reusing and maintainability.

  • Some new workers.
    Behind all: doAsynchronously, so waited to do asynchronous process, the reason why the container before immutable became mutable.

  • A log system.
    A real, good, log system, making debugging easier. And I hope with a Chrome extension for.

  • Workers improvement.
    The workers will have names for debugging, and are going to be directly configurable (instead of a single configuration system like we have).

  • Simpler request system.
    Allowing workers to reuse it easily.

Stay tuned!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant