I find GraphQL extremely fun and empowering tech to work with, even as a novice just getting started. You’ve probably heard the elevator pitch before: it allows you to ask for exactly the data you need whenever you need it (probably at the component level), and it arrives as lovely JSON data for your usage.
I see it used as part of modern website builds all the dang time. The overall vibe is, “I want to do whatever I want on the front end, and that actually allows for more back-end choices as well.” And by “whatever” on the front end, that generally means a fancy SPA-ish JavaScript-powered thing or a static-site generator-ish thing.
Here’s a quick smattering of articles that are everywhere these days. Instead of the actual article titles, I’ll rename with the stack parts.
- Contentful > GraphQL
- Contentful > GraphQL > Gatsby
- Another Contentful > GraphQL > Gatsby
- CraftCMS > GraphQL
- Craft CMS > GraphQL > Headless site
- CraftCMS > GraphQL > Vue
- GraphQL > 11ty
- WordPress > GraphQL
- WordPress.com > GraphQL > Gatsby
- WordPress.org > GraphQL > Gatsby
- WordPress > GraphQL > Vue
- Drupal > GraphQL
- GraphCMS > GraphQL
- DatoCMS > GraphQL
- DatoCMS > GraphQL > Vue/Nuxt
- CosmicJS > GraphQL
- GravCMS > Gatsby > GraphQL
- Strapi > GraphQL > Gatsby
- Netlify CMS > Gatsby > GraphQL
- Gentics Mesh > GraphQL
- Relax > GraphQL (maybe dead?)
- Jekyll > GraphQL
- TakeShape > GraphQL
GraphQL is certainly in the new-and-hip category, but as ever, everything old is new again. Check out Query by Example, a language from the 1970’s:
.....Name: Bob
..Address:
.....City:
....State: TX
..Zipcode:
Resulting SQL:
SELECT * FROM Contacts WHERE Name='Bob' AND State='TX';
Can’t believe you forgot Our wonderful amazing GraphQL API for WordPress https://www.wpgraphql.com & https://github.com/wp-graphql/wp-graphql. :)
For large projects GraphQL seems to make sense, since you could have multiple databases, services, etc. But for small projects with small teams and a single database a different system seems to make more sense. Like just writing straight SQL. Unfortunately, the tooling isn’t out there that is good enough for writing straight SQL. Basically, this is how it could be done. Write SQL in your client code which does not actually go to your front-end code. What you do is generate the parameters and return types in a class or function which will call the back end code. But wait, how do you not include the SQL in your code? When you build/generate your code you send the SQL up to a database and generate a GUID as a unique identifier. So, when you call that code on the back end all you are doing is sending up the GUID. You change your SQL then you generate a new GUID.
SQL is an amazingly powerful and somewhat elegant language where you can express complex ideas in a relatively short amount of code (unless you are using MySQL which still doesn’t support window functions – really in this day and age???). I just wish there was libraries out there that support this type of work. It would work with SQL Server and PostgreSQL I believe. MySQL sucks enough that it wouldn’t work with it.