graphql layer?

[swyxio]

https://github.com/khrome83/khrome.dev/tree/f36c4438b0c87a3190fedef88db676ff5913ce89/www/src/libs

[hdoro]

Given the mutability and complexity of content coming from full-blown sites, in which you could have an array of blocks with multiple conflicting types, for example, and how tiresome it's to write queries with 50+ keys for complex content structures, I honestly would rather steer away from GraphQL.

It's a great option for people building APIs that don't change much over time and it's still better than manipulating YAML and JSON datasets manually through vanilla JS, but in my experience with Gatsby I've spent way too much time and energy maintaining queries and type conflicts, especially when a design change came along breaking new stuff.

I know it's still in its infancy, but GROQ (see the JS implementation) has been a considerably better option for me, even when working outside of Sanity's ecosystem. I've my own way of organizing Sapper for generating static sites of which GROQ is a main component: .json.js files use it to extract the data I need from a central data.json and voilà, my content endpoints are ready. Then it's as simple as using Sapper's <script context="module"> to fetch the json file and render the template accordingly.

One thing that remains fuzzy to me is how to provide functionality similar to GQL's custom resolvers. As for how to operationalize this data layer, we could provide some basic API's for pushing and updating data, maybe using something like lowdb, and for GET requests (the majority of what you do in a SSG) expose a function that gets a GROQ query and returns the corresponding data.

If this options is still unclear, take a look at this example at groq.dev, it shows a fraction of the capability and speed of this querying language, and read through Chris Coyier's take on GROQ vs. GraphQL 😉

PS: Thanks for your work on ssg and the effort in making the JAMstack less bloated with JS, swyx!

[swyxio]

hey np!

yeah thanks for these super helpful links!

where my head is at is that i think types will help address most simple use cases. so graphql will always be optional rather than mandatory. however im very keen on leveraging the existing graphql devtools. groq is nice for sanity, but i'm not particularly interested until it gains traction more broadly. apart from Svelte i'm not in the business of making early bets here. can always develop a plugin for groq endpoints tho.

[m4rrc0]

Hey, just digging a little bit into ssg and I am super pumped about what I see so far.
I am still considering another option but I might go all in on this project if the vibe is good on the first trials. ;)

In any case, I couldn't not reply to this.
I am using Gatsby since early V2 alpha and the GraphQL layer has been the most polarizing topic in my head.

On the one hand, it makes it really easy to explore your data and build queries. It provides a clear(-ish) path to build source plugins.

On the other hand, it makes many things wayyyyyy more complicated than they should be (and probably slows down the build quite a bit but I lack data). For example, I have raised this issue more than 2 years ago and even though it has been closed, it is still not resolved. I can't imagine the complexity the graphQL layer is bringing to Gatsby's code base and it is probably only going to increase.
Now, the new schema customization API is supposed to solve all the issues related to graphQL but a) all those issues would not exist without graphQL in the first place, b) that API is bringing its own set of issues on top of the rest and c) I have to deep dive into graphQL to get my data now so the very thing that made it easy to get started (source plugins and data exploration) makes it super hard to customize anything.

To be honest I am in the process of opting out of graphQL on a gatsby project. I am just fed up with my build failing for bs reasons. And the time I lose trying to fix issues... it is just not worth it!

Still I hear your arguments about making it easy for simple use cases and the devtools that are awesome. I am just wondering if it is a worthwhile goal to set at early stage if this is not going to be core to the project.

Well, enough with the ramblings. I am happy to discuss it more but I will close this one here. ;)

[swyxio]

hey back! you are right.

i'm currently leaning towards making graphql EASY but OPTIONAL. so that for simple things we can use a type system and get 99% of the way there without all the graphql ceremony.

however, as i'm sure you have found by now, i am also concerned that the index + getDataSlice pattern i have created for speed/parallelization is basically a poor man's graphql. i THINK it is different enough from graphql, but if it is not, then that is an argument for just adopting graphql just for tooling's sake.