A time-saving alternative for GraphQL
GraphQL is great, if you have a segregation between backend and frontend developers in your company. It offers the frontend developers a kind of self-service, since they now have a query language, similar (but less powerful) like a backend developer has SQL for the database.
However providing an API with a query language like GraphQL is a significant effort. If you are bootstrapping your SaaS company, you are most likely the only developer anyway. Consequently you write the frontend and the backend. If you need an additional column from a database table in your UI, you can just adapt the backend REST API yourself.
Maybe you don't even need a 'classic' REST API, if the only API consumer is your frontend app and you don't know, if you ever will provide a public API to external developers. By designing your API with only your frontend app in mind, you can avoid a lot of pitfalls and save a considerable amount of time. I've wrote a blog post with more thoughts about these trade-offs:
https://maxweber.github.io/blog/2019-06-15-approaching-the-web-after-tomorrow-part-3
Furthermore I wrote an example app that demonstrates an alternative way to design your API. I named this approach db-view:
https://maxweber.github.io/blog/2019-08-05-introducing-db-view-part-2
The example uses Clojure(Script) as programming language and Datomic as database. However the db-view approach is applicable to other programming languages and databases as well. I would be thankful for feedback.
Best regards and a great day,
Max
Thanks a lot for all your comments. I was not aware of how much companies already were built around GraphQL (and providing a Firebase-like offering). Also interesting to see GraphQL with real-time capabilities: https://github.com/hasura/graphql-engine
The real-time mechanism of db-view is pretty simple, comparable to clicking the browser's reload button within a 'classic' server-side web application, but automatically and without any full page reload (thanks to React).
Agree to 100%. I like to prototype ideas fast and build things fast and I LOVE GraphQL. Nothing really comes close. Also, for me, it is important that the underlaying database is a relational database (SQL).
This is why I built nhost.io which gives you:
You just create your regular SQL tables and Hasura will automatically provide a GraphQL API for you.
All built using open source tools! Please check it out: https://nhost.io
Agreed. I'm currently using Gridsome which is super useful as a starterpoint but makes heavy use of GraphQL which I've so far in my career not encountered directly. Learning that coupled with the quirks of Gridsome + no documentation has been tough.
Spent a good while trying to wrestle an external API into it and actually decided that for an MVP and a very limited dataset a local JSON file is perfectly acceptable since I'm not designing APIs here, just consuming them.
Eeeenteresting. I've waffled on the one frontend per API dilemma. It feels so much ~cleaner~ to make a generic API that you can use freely. But that of course comes at a huge cost. Excited to see where these types of discussions go in the next 1-2 years.
We introspect our DB to auto-generate a GraphQL API (I'm a frontend engineer, and as you mention, I absolutely love the flexibility/power a frontend querying language gives me). We turned this into a service we do for others (in addition to user auth and payments) at https://midtype.com.
Hey Max totally agree with your point of view. I've been using Graphql on my last projects for the sake of learning it (and once using https://www.prisma.io/) and it's a love-hate affair. Most of the articles are describing it as the future of REST APIs but to me they just serve different objectives, leveraging different design and features.
Going to read your article now, sounds refreshing!
This comment was deleted 5 years ago
Hi Nazar, thanks a lot for the feedback, I'm happy to hear that.