core VS OverblogGraphQLBundle

For instance, there are cache problems on Api Platform v3.0, so you should consider upgrading directly to the latest minor version available.

For a great setup to use as an example, see https://github.com/api-platform/core. The Behat library config is in behat.yml.dist, the feature files (process descriptions) are in the ./features directory, and the context files (Feature file Steps resolved to Context functions) can be found in ./tests/Behat.

/api/same-route is a unique identifier. Calling addPath with an existing identifier just overwrites your previous call, see https://github.com/api-platform/core/blob/main/src/OpenApi/Model/Paths.php You should call addPath once, and the instance of PathItem class should contain all HTTP methods, see constructor arguments.

We started in 2.5 and I believe I upgraded us to 2.6 just before leaving. What was with completely changing how OpenAPI generation worked in a minor release? That took a massive refactor for some of the special things were doing to hook in: https://github.com/api-platform/core/pull/3407 definitely a lot nicer to work with, but was painful for going up a minor version given our workload at the time.

Nope, not yep : https://github.com/api-platform/core/pull/1645

By specification, GraphQL allows us to send multiple mutations in a single request and these mutations will be executed in the order in which they were sent. GraphQL specification doesn't guarantee us that if some of these mutations fail, all others will fail as well. In other words, GraphQL doesn't specify that all mutations should be executed in the transactions. Luckily, this can be easily enabled in the Overblog GraphQL Bundle using built-in events.

Authorization is part of almost any web application and controlling access to specific data is essential for application security. The same goes for GraphQL APIs and with help of Overblog's GraphQL Bundle, this can be done easily.