I mostly see REST. It’s nice to keep the API type consistent across all services and REST is the de facto standard at the moment.
I totally agree with @James Luterek. The additional overhead during implementation is often not worth the benefits of GraphQL (package size does matter for speed optimisation, but it is often not a JSON that is too large).
However, I believe that as soon as expansions are used, it can start to become feasible to use GraphQL. Expansions are super useful to retrieve e.g. the key of a referenced object (such as the key of the categories of a product). However, all the other information of that object is not needed, but sent in the response anyways.
This increases the response size dramatically, especially if used on arrays or paged responses (or both).
Again, highly agree with keeping consistency across services and using REST as default. But as soon as responses become too large, GraphQL can be a good way to tackle that.
Great points Patrick, thanks for your insights,
I wonder if we can dig a bit deeper on the overhead during implementation as maybe we could mitigate some of them, for sure “muscle memory” will be much higher in Http APIs RESTful or not, but there are also some great features for developer during implementation phase, first one that comes to my mind is for example the use of Introspection capability, well integrated into the IDE this can help devs grasp entity structures faster.
I found GraphQL helpful in retrieving custom object attribute I referenced with the product. From speed point of view Rest API is good.
Like most here, I see REST being used more often with Commercetools, but I found GraphQL more interesting in some aspects, by what @Patrick Burkart mentioned, the ability to do expansions, but also the fact of being able to restrict exactly what we get, having a single endpoint, consistency (same response format), the strong typed schemas, and ability to extend with federated GraphQL architectures.
This is one of my favorite topics and I agree with @James Luterek and @Patrick Burkart. I think in general REST makes sense when connecting a BFF or other server-side application to commercetools Composable Commerce. For 2 main reasons:
- The full payload of the response is available to the application. If a new feature requires the use of an existing attribute, the underlying GraphQL query to commercetools would need to be modified instead of just consuming the existing payload. This is especially important during initial/rapid development.
- While GraphQL can be used in the commercetools SDKs, they are geared more toward the REST APIs. For those just learning commercetools, it will likely be easier to develop using the REST APIs.
However, as others have stated, it is very good at constraining payload size on large resources and/or when using Reference Expansion. The ability to run multiple queries in a single request is pretty sweet too. For direct client
commercetools Composable Commerce connections I would lean towards GraphQL.
I would be very interested to know how many developers opted for reference expansion for the sole purpose of getting a key of a referenced object.
For example, when using the product projection to display a product page of some sort, I might want to have links going to the categories in which the product is in. For the sake of this example, let’s assume I didn’t use slugs as they are intended to be used - but i can generate the URLs for the category pages with the key of the category. I would need to do reference expansion on the categories within the product, which would greatly increase the payload, especially if there are many categories.
Though this is a bad and fabricated example, I feel like getting the key (instead of the id) might be one of the main use cases for reference expansion. And I wonder if this leads to increased usage of GraphQL? (as the consensus seems to be that GraphQL is great for replacing reference expansion due to the more controllable payload size).
Or in other words: Would reference expansion and GraphQL each be used less if the key was part of the non expanded reference?
