🚀 Share Your Excitement and Feedback about Nitro GraphQL\!

[productdevbook]

👋 Hello Nitro GraphQL Community!

I'm thrilled to share this project with you all and I can't wait to hear your thoughts! Your feedback is incredibly valuable in shaping the future of Nitro GraphQL.

🎯 What I'd Love to Know

📝 First Impressions

What was your initial reaction when you first tried Nitro GraphQL? Share your excitement, surprises, or any "aha!" moments!

💻 Developer Experience (DX)

• How was the setup process?
• Is the API intuitive?
• What did you love about the development workflow?
• What could be improved?

✨ Feature Requests

What features would make Nitro GraphQL even more awesome for your use cases?

🐛 Pain Points

Did you encounter any challenges or frustrations? Let's discuss how we can make things better!

🌟 Success Stories

Have you built something cool with Nitro GraphQL? We'd love to hear about it!

💬 How to Contribute Your Feedback

Feel free to share your thoughts in any format - bullet points, paragraphs, or even just a quick comment. Every piece of feedback matters!

Please be honest - both positive feedback and constructive criticism are equally valuable. This is a safe space for open discussion about making Nitro GraphQL the best it can be.

🙏 Thank You!

Your participation in this community means the world to me. Together, we can build something truly amazing!

---

Please react with 👍 if you're excited about Nitro GraphQL, and don't forget to star ⭐ the repository if you haven't already!

[productdevbook]

nitroping Open-source, self-hosted push notification service built with Nuxt 4 & Nitro.

[lewebsimple]

Hello @productdevbook, this project is quite incredible!

I really like the DX as it feels very natural for nuxt / nitro, i.e. naming conventions and provided functions for defining stuff. Even if ATM it's not overly documented, the provided examples are fairly educational and I could get started easily. Having to configure both the nitro and nuxt modules in nuxt.config.ts was unusual to me, as was the presence of various auto-generated files, but in the end these were not such a big deal.

At first, I was planning on using Pothos as a code-first schema solution but quickly realized the defineResolver was a lot better (I usually called some kind of server utils from the Pothos resolver anyways so I ended up having tightly coupled TS files in every project). Actually giving a chance to schema-first was definitely the aha! moment for me, especially splitting the schema file in multiple places and colocating their corresponding resolver definition in the same place.

I really love the fact it supports projects OOTB (for example default / countries) and graphql-config, but I wasn't sure if I could get rid of the default subfolder if I only plan to use one project.

I didn't get to play with the layers support but it looks very promising for large projects / re-using code.

Once my test project was getting settled in I found the HMR to be relatively good ... I had to restart the dev server to pick up new schema / document files but it was very quick to do so.

Pain points / feature requests:

• How to validate using a standard schema (i.e. server/graphql/schema.ts .. how it this file used? can it be splitted?)
• Can the validating schema be shared between server / client ?
• How to properly handle authentication (the nuxt example seems incomplete, i.e. how to use with nuxt-auth-utils?)
• Is it possible to use nitro-graphql only for server-side and use nuxt-graphql-middleware for the client side?
• I like to use .graphql for schema definition and .gql for the documents but it seems I can't
• With nuxt-graphql-middleware, dev mode lists all the documents file it finds, this project could be more verbose (opt-in?)
• Is it possible to colocate fragments alongside components (i.e. outside app/graphql)? I find this pattern to be extremely useful.

Again, thanks for such a wonderful project!