Bringing Convention over Configuration to Fastify with @syora/fastify

Hi everyone 👋

If you enjoy Fastify's performance but sometimes miss the developer experience of file-system routing, this project might interest you.

I've been working for some time on @syora/fastify, a library that brings the Convention over Configuration approach to Fastify.

🚀 How it works

Instead of manually declaring and importing routes, hooks, and plugins, everything is inferred from your project's directory structure.

The key idea is that everything happens ahead of runtime. During startup, @syora/fastify scans your project, generates optimized manifests and TypeScript type definitions, and then Fastify only loads those generated files.

👉 The result is no filesystem scanning while handling requests, while preserving Fastify's API and performance characteristics.

For example, this structure:

api/
  users/
    index.ts
    [id].ts
    [id].post.ts

middlewares/
  auth.ts

plugins/
  cors.ts

...automatically generates the corresponding routes, middleware registrations, and plugin registrations.

The goal isn't to replace Fastify, but to provide a convention layer for developers who enjoy this style of development—similar to frameworks like Nuxt or Next.js—while staying true to Fastify's philosophy.

The project has just reached v1.1.0, and I'd really appreciate your feedback:

• Do you think this approach makes sense for real-world applications?
• Can you spot any technical limitations, edge cases, or trade-offs that I may have overlooked?
• What features would you consider essential for the project's next steps?

If you're curious, you can find the project here:

👉 GitHub Repository

Feedback, suggestions, and contributions are all very welcome.

And a huge thank you to the entire Fastify team for building such an amazing ecosystem. ❤️

fastify typescript node opensource

Comments

[Frank]

This looks promising! I'm curious how @syora/fastify handles dependency injection or specific

[Mamadou]

Thanks, Frank!

At the moment, @syora/fastify doesn't introduce its own dependency injection system. It relies entirely on Fastify's existing plugin and decoration mechanisms.

The idea is to stay as close as possible to the Fastify ecosystem. Plugins are still regular fastify-plugins, registered in the usual way, so decorators, hooks, and encapsulation behave exactly as they do in a standard Fastify application.

The only thing @syora/fastify changes is how those plugins, routes, and middlewares are discovered and registered. Instead of manually wiring everything together, it generates manifests ahead of time and registers them automatically during startup.

So if your application already uses decorators like decorate(), decorateRequest(), or plugins exposing services, they continue to work as expected.

I'm also interested in hearing about any DI patterns that people feel are important to support, so I'd love to hear your thoughts.