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

Denis Turkov
Denis Turkov VP Architecture Sprykee Posts: 40 🏛 - Council (mod)

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? 😻

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

Yes, I have a use case! 🌟
31%
gerhard.bastlcleyurzaizpiotr.budner396ranjanpratikRobson 5 votes
It’s enough, that I can enable it myself. 🤓
56%
vasily.rodinTobias Ouwejanmichael.schmettervictor.vanherptamansillaandreas.penzAlberto Reyersimon.wallner1christiankilb 9 votes
No, GraphQL was a hype and it’s down now 😈
12%
nicolas.messias773vincentchristophe177 2 votes

Comments

  • Alberto Reyer
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer
    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
    Denis Turkov VP Architecture Sprykee Posts: 40 🏛 - Council (mod)

    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
    amansilla Senior Technical Solution Engineer Sprykee Posts: 20 🪐 - Explorer
    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.

  • victor.vanherpt
    victor.vanherpt Spryker Solution Partner Posts: 58 🪐 - Explorer
    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
    fsmeier Senior Software Engineer & Developer Enablement Advocate Sprykee Posts: 1,056 ⚖️ - Guardians (admin)

    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
    christiankilb Software Architect & Technical Lead Posts: 7 🧑🏻‍🚀 - Cadet
    edited September 2023
    It’s enough, that I can enable it myself. 🤓

    @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.