Basic pros and cons of GraphQL vs REST for CMS?

At a glance

The community member is considering using Baserow, which only has a REST API, but is curious about the advantages of a GraphQL API over a REST API in the context of a Webstudio CMS. The community members discuss that the choice between REST and GraphQL may not significantly impact performance, and that the main consideration should be which API format best fits the use case. They note that in Webstudio, making subsequent API calls can be problematic, so a GraphQL API may be advantageous if the required data can be fetched in a single call. The community members also mention that Baserow has the ability to reference other records, which could potentially allow fetching related data in a single API call, even with a REST API.

Useful resources

ppaulrudy

If someone has the time, I would love to get a clearer sense of when a GraphQL API is an advantage over a REST API in Webstudio CMS.

I have a basic familiarity with REST APIs, but no experience with GraphQL. I'm currently leaning toward using Baserow for reasons unrelated to Webstudio, but it only has REST, not GraphQL.

From what I've learned on the web, one of the main advantages of GraphQL is that it can reduce the number of requests needed to get necessary data. Does this apply for basic CMS stuff like getting populating post collections, etc?

Any info that helps me understand the pros and cons of each would be appreciated!

8 comments

JJohn Siciliano

I wouldn't choose the platform based on the API type personally. I'm managing one webstudio site with graphql and another with rest. Both work great

ppaulrudy

Ok, great to know. So I'm guessing from your response that there's really no performance hit with using one over the other, and I should just go with what provides the right interface for my use case

JJohn Siciliano

I'm not a pro on this subject, but I would assume they are comprable. Where the discrepancy may occur is if you need to make subsequent calls using the response from the previous call.

In Webstudio you make many API calls on the same page, but they can't rely on the response from the previous call.

So for notion pages for example this is problematic (see more here https://docs.webstudio.is/university/integrations/notion#use-notion-databases-not-notion-pages). Even if webstudio did support making subsequent api calls, it would be bad for performance because you call 1 then use that data to call 2 and so forth each waiting for the previous to finish.

Most platforms will give you what you need in one call though

ppaulrudy

Got it! That makes perfect sense. I can't imagine a scenario where I'd need subsequent api calls, so I guess I'm good to go with either api format

JJohn Siciliano

I think baserow has the ability to reference other records as column types which should bring in that records data in the api call. So even if you have data from two separate tables, if the api is done well it should still be delivered in one call

ppaulrudy

Ok. Just familiarizing myself with Baserow, but I did see this, which seems related to what you mentioned: https://gitlab.com/baserow/baserow/-/issues/2460
Even before that issue is closed, it looks still possible by explicitly creating a lookup field in one table pointing to the other

JJohn Siciliano

Yep thats what im talking about. So looks like youd just need to add a lookup column for every field you want to bring in from relational data. Airtable is the same IIRC

ppaulrudy

awesome, thanks John!

Add a reply

Join the Webstudio community

Basic pros and cons of GraphQL vs REST for CMS?