TarikGul
commented
1 year ago Hey @Gioyik, thanks for bringing this up. So this is something I have considered a lot for the current implementation of sidecar. I agree on all the main points you bring up with fastify. The support and ongoing development is way larger than express, and offers way more performance capabilities etc.
There are a few things to note moving forward:
- Sidecar is going to go through a big rewrite soon, and will introduce SidecarV2. It's basically a time for the team and I to improve upon all the nags we currently have.
- Extensibility for parachains
- Improved debugging systems
- Better logging, and log detection
- Increased Error Documentation
- Performance gains
- Ability to plugin and attach controllers based on unique pallet logic. (Builds on parachain extensibility)
- Increased WASM usage for high computation work. We currently use this for calcing fees, and staking payouts, but it would be nice to expand where we can.
This is just a short list of the things we plan on improving upon, but it will make sidecar a little more flexible, and also IMO easier for the community to contribute to, and be apart of.
- Changing Sidecar over to fastify right now would bring a bit of overhead while we are already planning and designing a rewrite. I would say its best to wait for the new and improved version. There is definitely a very high chance we move forward with fasitfy instead of express in the new iteration ;) We'll ofcourse be open sourcing the whole repo so there will be plenty of room for collaboration, and contribution!
Gioyik
A few weeks ago I contacted @Imod7 to discuss what the team maintaining sidecar thinks about moving the express http implementation to fastify.
In my experience, express offers extensive documentation, and it's usually a safe bet as it's well known and supported by the OpenJS Foundation for continuity; however, express hasn't evolved or took advantage of most of the recent libs or runtime APIs in Node.js, most of the releases are dep version bump and security releases (which is great, nothing wrong with that), which is good, but not substantial features or improvements to the core of the framework.
In the other hand, fastify has evolved to be stable, fast, take advantage of runtime improvements and maintain a secure framework (they even have a LTS schedule). As well fastify is backed by the OpenJS Foundation for continuity, ] the development team is strong, diverse and the roadmap looks promising with the plugins and the continuous support of typescript. Out of the box fastify comes with a good set of features with little overhead, they have benchmarks comparing with other frameworks, I think you can run the same benchmark to compare and form your own opinion.
Now, why sidecar should make the move to fastify? From my perspective after the presentation where I saw sidecar, the main premises were light and fast (sorry if I am miss quoting), so the transition to fastify in my opinion is the next step for the long run. Today it could be that express doesn't represent a heavy part of the normal execution of the API endpoint calls, but the introduction of the framework can help reduce inefficient calls in the stack and ease the debugging process. Maybe reducing the cost of the server where sidecar runs as it's a bit more efficient or behaving more stable under high load scenarios, even if that's not a thing today.
For the things mentioned before, I would like to have time to run sidecar and get a few numbers, but I haven't had the time yet. Finally, if a change like this sounds beneficial for the project, I would like to offer slots of my time to work on the migration, as it helps me understand some internals and cooperation between components while I work on it.