fullstack-starterkit VS gqless

I'm learning fullstack JavaScript development, and was trying to get ideas for project organization going forward. I've already started putting the frontend/backend in separate subdirectories in monorepos to allow them to be developed independently, and it seems to be working well. However, this repo (https://github.com/karanpratapsingh/fullstack-starterkit) separates the two, but includes a third package.json in the root directory. What's the point of this? I've had experiences where package versions clash due to differences between package.json files in parent and child directories, is there a way to make sure this is avoided if I copy this organization?

Github: https://github.com/karanpratapsingh/fullstack-starterkit/tree/master/backend-go

Backend is now available in Go! 🥳

Hi, An opensource graphql first boilerplate https://github.com/karanpratapsingh/fullstack-starterkit might help

Full changelog Github

I usually set it up at root level, example that might help: https://github.com/karanpratapsingh/fullstack-starterkit

Full changelog/PR is available here

Full changelog/PR is available here

Maybe GQLess is for you? It's a client that magically creates a query from they way you use objects in your react components.

Yes! We announced experimental support earlier and here's the new spec we're implementing that will support all databases and remote schemas too.

https://github.com/hasura/graphql-engine/issues/6991

General support for inherited roles is one of the things I'm most excited about because it makes a bunch of hard things around reusing and composition so easy.

This improvement plays really well along with things like "role-based schemas" so that GraphQL clients have access to just the exact GraphQL schema they should be able to access - which is in turn composed by putting multiple scopes together into one role.

Also interesting is how well this could play with other innovations on the GraphQL client ecosystem like gqless[1] and graphql-zeus[2] because now there's a typesafe and secure SDK for really smooth developer experience on the client side.

[1]: https://github.com/gqless/gqless

GQless: A GraphQL client built for rapid iteration\ (6 comments)

Cannot recommend gqless highly enough for making graphql actually fun to use and closer to something like meteor/firebase syntax[0].

And I’ll self-promote, but I’ve been working on what I consider to be a “next generation” style system for React that solves my biggest issue with it currently: being able to performantly write styles in a nice syntax that optimize for both web and native. Called SnackUI, though it’s still in beta[1].

[0] https://gqless.com

[1] https://github.com/snackui/snackui

On the GraphQL side you can use gqless[0] (or the improved fork I helped sponsor, here[1]). It's by far the best DX I've had for any data fetching library: fully typed calls, no strings at all, no duplication of code or weird importing, no compiler, and it resolves the entire tree and creates a single fetch call.

[0] https://github.com/gqless/gqless

[1] https://github.com/PabloSzx/new_gqless