Should Spryker dev team enable GraphQL implementation out-of-the-box?

Denis Turkov

With the most recent Glue API releases, Spryker Framework enabled project developers to build their own GraphQL implementation or integrate a 3rd party one. That means that you can bring GraphQL to your project in as fast as 15 min (confirmed!).

However, we do not provide an OOTB (out-of-the-box) GraphQL implementation. There is a lot of theory, on why GraphQL is suitable or not suitable in a specific case. So let's leave the theory for a moment and face your real day-by-day challenges!

Should Spryker dev team enable GraphQL implementation out-of-the-box? 😻

Alberto Reyer

It’s enough, that I can enable it myself. 🤓

What would be the consequence of an out-of-the-box implementation?
Will it be maintained in addition to the existing JSON-API endpoints? If so, how active?
How adaptible would such an out-of-the-box implementation be? Is it still possible to overwrite and extend the whole API or would that mean to be bound to the OOTB provided schemes?

To be honest, I don't really see the need to provide an OOTB implementation and would have voted for the hype option, but it's still a nice to have possibility to be able to implement a GraphQL API, if there would be any use case.

Denis Turkov

If we would look into OOTB implementation, you could expect a wired infrastructure for GraphQL schema management and documentation. Also, a standard set of API schemas would be available. They definitely would be as extendible as any other Spryker module.

However, it's only when there is a need for such OOTB support. :)

Thanks for all your votes!

@piotr.budner396 @ranjanpratik could you share, why GraphQL is a better tech solution to your use case?

amansilla

It’s enough, that I can enable it myself. 🤓

That's fantastic news, @Denis Turkov! In around 30% of my conversations with prospects, they've expressed interest in this aspect. However, I can't definitively confirm if they have a genuine use case for its implementation. In my view, during the pre-sales phase, prospects seem more confident about our solution when they know they have both REST API and GraphQL API options available. This flexibility expands our potential to cater to a wider array of use cases.

In my perspective, it should suffice to provide support for GraphQL in a disabled state out of the box. However, if enabling it doesn't adversely affect overall performance, it might be advantageous to have it enabled by default or offer the option through the back office. This would offer a comprehensive solution while maintaining adaptability.

christiankilb

It’s enough, that I can enable it myself. 🤓

In my opinion, before implementing GraphQL or other API languages the CRUD logic behind should be cleaned up.

Why does creating/reading/deleting/updating entities work different for products, customers, orders etc.? There's a lot of inconsistency here. For example, if I want to know how to get some product by ID, I first have to look into the ProductRepository/ProductFacade. If I finally found out how, I won't know how it will work for orders or customers. The method names, arguments etc. look totally different. In worst case there might even not be an existing method for this.

Until there is no consistency here, it's practically not possible to implement an consistent API.

Once there is a consistent way to work with database entities, all places in Spryker should make use of it.
Right now Yves is working totally different to Glue. While Yves is - using the Client layer - able to read out some (filtered) data, Glue may be not. Even worse, there are Spryker packages that only work for Yves but don't provide a Glue endpoint.

Once this is done, it should be comparatively easy to implement more API layers.
Before this is done it will be very hard to implement more API layers and the result will not be satisfying.

So, first things first, that's why I voted for "It's enough I can implement it myself".

victor.vanherpt

It’s enough, that I can enable it myself. 🤓

I would say It’s enough, that I can enable it myself. As long as it is well documented and in order to enable you don't have to fight other systems (good configurable defaults, not having to override a bunch of stuff to get this).

fsmeier

https://commercequest.space/discussion/comment/28177#Comment_28177

Heyhey @christiankilb,

small insight and maybe useful information for you related to your valuable feedback:

Often the inconsistency exists because we improve our architecture and conventions over time and we can not change right away existing features because of our non-BC promises.

Yet we have a current standard all new modules should follow and all older modules should transition over time. You can have an example by executing the following spryk:

docker/sdk cli spryk-run AddCrudFacade --module Penguin --organization Pyz --domainEntity Penguin -n -vvv

Hope this gives you at least some insight. But your feedback is of course right as well!

All the best,

Florian

christiankilb

It’s enough, that I can enable it myself. 🤓

https://commercequest.space/discussion/comment/28331#Comment_28331

@fsmeier Hey Florian, thanks for the info. That's definitely a step in the right direction, but in my view, it wouldn't be sufficient for simplifying the API layer. The API layer can't assume that every facade (and every underlying repository) has methods like getCollection, createCollection, and so on. That means, in the API layer, you'd still have to create specific logics and implementations for each module or entity.

The implementation of an API layer - and working with Spryker in general - would be much easier if we ensure through appropriate interfaces that the required methods are always available (getCollection, createEntity, etc.). In this case, the method headers would need to be adjusted, and they shouldn't expect specific (filter) transfer objects. However, even here, a generic solution would be preferable in my opinion because generating filter transfer objects for each individual entity can lead to inconsistencies.

Fundamentally, Propel already provides some tools for this, such as the Criteria class (which should of course be abstracted further to prevent Propel objects from appearing outside the persistence layer).

In a perfect Spryker world, I would wish for the following:

(new PenguinFacade())->findEntityById(123);
(new PenguinRepository())->findEntityById(123);
(new PenguinFacade())->createEntity(new PenguinTransfer());
(new PenguinEntityManager())->createEntity(new PenguinTransfer());
(new PenguinFacade())->getCollection((new Criteria())->addFieldFilter('type', 'foo'));
(new PenguinRepository())->getCollection((new Criteria())->addFieldFilter('type', 'foo'));
...and you should be able to replace "Penguin" with any module name:

(new ProductFacade())->findEntityById(123);
(new ProductFacade())->getCollection((new Criteria())->addFieldFilter('type', 'foo'));

Ideally, in the entity definition, you could specify that it is automatically exported to Redis and, again through an interface, provide corresponding methods in the client.

If this were in place, implementing a new API layer would be much easier. For strict REST endpoints, in theory, you would only need to add an entity for which CRUD endpoints should be provided in a configuration, possibly with adjusted access policies. If it were that simple, you could focus your work exclusively on those (rare) cases that can't be covered by the standard.

GraphQL is popular because it's more dynamic than REST, and the corresponding queries and mutations don't have to correspond 1:1 to an entity. However, in practice, this often is the case (for example, there's probably a need for a Product-Query or CreateProduct-Mutation), and it would be nice if the implementation for such simple endpoints were consistent.