You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Performance is key, even more today when all the users want something quickly. But the first step is to be aware of said performance, monitor it and know if we increase or decrease the overhead when compared to the base runtime.
Performance is also a matter of size, and being able to ship packages with a lower footprint can help with startup time (or cold start).
Expectation
Include performance as part of the development and publish process
Implementation
Implement a workflow to alert if a package is too heavy or grow to much on a PR
Include benchmark and performance testing as part of all repositories
Create a separated benchmarck repo that would test new releases against some use cases, and compare against base Node.js
Status
Part: Organization
Status
workflow for size:
benchmark on repositories
standard application benchmark
Draft
As the largest framework used, performance is key to the adoption of the framework, but as the full ecosystem relies on modules part of the Express organization, we have to provide the best performance for our libraries.
To ensure that we are moving in the right direction, all packages should be monitored for performance using benchmarks. The Express ecosystem is used across multiple use case, but it is definitely handling application under heavy load and packages should be tested against this kind of use case, while also handling specific benchmark tests (for example Cold Start)
The text was updated successfully, but these errors were encountered:
I think this one is under the larger umbrella of documenting the projects technical priorities right? I feel like a similar doc to Node's would be good. And it likely should cover much more than just the approach to performance.
This is a great initiative! I think currently we have some basic performance testing (see: expressjs/express#5312), but we can ask for support from the community on this (there are many potential good first issues). Time ago I started with a very basic and rough perf version comparator.
I will strongly suggest to avoid comparing Express with other frameworks, just to avoid the typical social media flame/drama. We can focus on comparing new changes against previous versions (as Node.js does) or even compare Express against Node.js core libraries to see how our deviation increase/decrease
Motivation
Performance is key, even more today when all the users want something quickly. But the first step is to be aware of said performance, monitor it and know if we increase or decrease the overhead when compared to the base runtime.
Performance is also a matter of size, and being able to ship packages with a lower footprint can help with startup time (or cold start).
Expectation
Include performance as part of the development and publish process
Implementation
Implement a workflow to alert if a package is too heavy or grow to much on a PR
Include benchmark and performance testing as part of all repositories
Create a separated benchmarck repo that would test new releases against some use cases, and compare against base Node.js
Status
Part: Organization
Status
Draft
The text was updated successfully, but these errors were encountered: