docs: write the module guide

[Barbapapazes]

🔗 Linked issue

fix #1862

❓ Type of change

• 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Hello 👋,

This PR add a new guide about modules!

I explain what is a module, how to use them, and some examples on how to add features like routes, middlewares...

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[pi0]

The recipes look good, however, I strongly believe we should rethink the purpose of Nitro modules (they should be mainly for integration purposes) and first-class supporting vite might change to story so for now i do think we should keep module docs internal.

[Exotelis]

Hi @pi0,

Last week, we internally evaluated Nitro as an alternative to Express and have been very impressed with Nitro's features so far. However, a core feature for are also modules. We are developing a BFF that needs to provide different API endpoints (modules) for different projects. For example, one project uses FactFinder, while another uses ElasticSearch. Would this still be within the scope of the modules, so adding endpoints via modules?
Our current solution works just fine, but we want to significantly simplify the architecture, which is where nitro comes into play.

We are delivering a POC by next week and will then make a decision. Could you provide a bit more details on the planned scope of modules in the future, maybe also a timeline?

Feel free to reach out personally if you'd like :)
Greetings from Germany

[pi0]

Thanks for sharing your project status dear @Exotelis.

I believe using Nitro layers (similar concept to Nuxt layers) might be most fitting for your usecase. I had helped other big enterprise teams to adopt this approach for similar purpose.

Nitro can be also extended with modules but modules are not designed for this purpose.

Also since you mentioned you are migrating from a express codebase, i would suggest to first migrate to h3 directly and then Nitro (but only a suggestion, i don't know the scope).

Nevertheless feel free to share your POC perhaps in a discussion or reach out to me (my email is in my gh profile) or via discord @pi0.

[Exotelis]

Thank you very much for your incredibly quick response! Layers sound promising, will look into them 👍
"Migrate" is such a strong word 😃 - it might even turn into a complete rewrite. That hasn't been decided yet. However, you have a valid point.