Enterprise fastify standard

[kibertoad]

Context: our company is migrating from PHP to Node.js, and one of the major concerns raised is the lack of opinionated standardization in the ecosystem.

Therefore my question is: would broader fastify community be interested in establishing some kind of community-driven "Enterprise fastify standard", suggesting particular approaches, naming and structure for building complex enterprise apps with fastify.

If there is any interest in this, I would be more than happy to drive the process and draft strawman proposals to kick off the discussion.

[jsumners]

Honestly, I don't even know what that means. I haven't been at too many places, but the ones I have been at do things wildly different from each other. In my view, the biggest selling point of something like Fastify is that it doesn't assert itself as an authority on how you should write your software. It provides basic building blocks and then gets out of your way.

[kibertoad]

@jsumners It's an optional set of recommendations for teams who don't want to decide how to write their software. Teams who don't need it should feel free to ignore it.

[RafaelGSS]

@jsumners It's an optional set of recommendations for teams who don't want to decide how to write their software. Teams who don't need it should feel free to ignore it.

Best practices for the project structure you mean? Often, I see developers asking for that kind of help on the Discord channel or privately.

We currently don't enforce any kind of rule in Fastify and I wouldn't like it to be changed. However, creating a new section in docs with project examples would be great.

I'm just wondering, is not fastify-cli solving it in a near future with fastify create project?

[kibertoad]

@RafaelGSS Yup, something along these lines! Definitely not something to be enforced, but as you've said, a good default architecture.

Need to check how fastify-cli is planning to do it, but at least a while ago the default bootstrap had some very questionable design decisions baked into it. Maybe it's different now.

And CLI is not a replacement for documentation in either case, but it can definitely complement it.

[mcollina]

questionable design decisions baked into it

What would you change?

---

I'm planning to work on this problem in the coming months. I'm not 100% sure this should be in Fastify org as it might be too opinionated, but I think we can review it later on.

[climba03003]

Need to check how fastify-cli is planning to do it

If you have any idea on improving the template, the below PR is actually rebuilding the whole CLI and provide a better template.
(Include tools selection on language, linter, test.)

fastify/fastify-cli#491

[kibertoad]

@climba03003 Thank you for the link, added some comments and suggestions.

[kibertoad]

I'm not 100% sure this should be in Fastify org as it might be too opinionated, but I think we can review it later on.

It may work as an outside standartization effort, as long as there are credible backers for it.

[koanplaned]

Hi @kibertoad,

if you want a more "guided architecture" around fastify, maybe NestJS with fastify is an option for you?
https://docs.nestjs.com/techniques/performance

Personally I love the simplicity of fastify(-only) and that I can do the things my way. Therefore I switched from NestJS to fastify-only-version and I'm using the plugin-eco-system to pimp up my application.

NestJS on the other hand tells you, how to structure your application, how to write controllers, interceptors and so on. I think it has a pretty good documentation, so enterprise developers can learn the "architecture" of such an application - but it comes with the cost of complexity.

If you consider to use fastify-only and structure your application for yourself, this repository could be a good starting point: https://github.com/delvedor/fastify-example