8.0.0-rc2 / More Breaking Changes incoming!

Due to some longer standing cleanups, embracing of a more standardized approach how to process the GraphQL request using https://github.com/laragraph/utils, and adding a execution middleware, breaking changes were made for this next major version.

Note: the "breaking changes" between 8.0.0-rc1 and rc2 changed, again; please see the full and current changelog below

To be clear (see below for details): you will need to adapt your configuration file

Breaking changes

• As part of moving the architecture to an execution based middleware approach,
  the following methods have been removed:

  • \Rebing\GraphQL\GraphQLController::handleAutomaticPersistQueries has been
    replaced by the AutomaticPersistedQueriesMiddleware middleware
  • \Rebing\GraphQL\GraphQLController::queryContext has been
    replaced by the AddAuthUserContextValueMiddleware middleware
    If you relied on overriding queryContext to inject a custom context, you
    now need to create your own execution middleware and add to your
    configuration
  • \Rebing\GraphQL\GraphQLController::executeQuery has become obsolete, no
    direct replacement.

• Routing has been rewritten and simplified #757 / mfn

  • All routing related configuration is now within the top level route
    configuration key
  • The following configuration options have been removed:
    • graphql.routes
      It's therefore also not possible anymore to register different routes for
      queries and mutations within a schema. Each schema gets only one route
      (except for the default schema, which is registered for the global prefix
      route as well as under its name).
      If necessary, this can be emulated with different schemas and multi-level
      paths
  • The following configuration options have been moved/renamed:
    • graphql.prefix => graphql.route.prefix
    • graphql.controllers => graphql.route.controller
      Further, providing a controller action for query or mutation is not
      supported anymore.
    • graphql.middlware => graphql.route.middleware
    • graphql.route_group_attributes => graphql.route.group_attributes
  • The actual routes defined have changed:
    • No more separate routes for the HTTP methods
    • 1 route for each schema + 1 route for the group prefix (default schema)
    • If GraphiQL is enabled: 1 route graphiql route for each schema + 1 for the
      graphiql group prefix (default schema)
    • This also means that the per schema config key method (aka HTTP method)
      is not supported anymore
  • It's now possible to prevent the registering of any routes by making the top
    level route an empty array or null
  • \Rebing\GraphQL\GraphQL::routeNameTransformer has been removed
  • It's now possible to register schemas with a - in their name
  • Routes are now properly cacheable

• Remove the \Rebing\GraphQL\GraphQLController::$app property #755 / mfn
  Injecting the application container early is incompatible when running within
  an application server like laravel/octane, as it's not guaranteed that the
  container received contains all the bindings. If you relied on this property
  when extending the classes, invoke the container directly via
  Container::getInstance().

• Remove deprecated \Rebing\GraphQL\Support\Type::$inputObject and \Rebing\GraphQL\Support\Type::$enumObject properties #752 / mfn
  Instead in your code, extend \Rebing\GraphQL\Support\InputType and \Rebing\GraphQL\Support\EnumType directly

• Support for Lumen has been removed

• Integrate laragraph/utils RequestParser #739 / mfn
  The parsing of GraphQL requests is now more strict:

  • if you send a GET request, the GraphQL query has to be in the query parameters
  • if you send a POST request, the GraphQL query needs to be in the body
    Mixing of either isn't possible anymore
  • batched queries will only work with POST requests
    This is due to RequestParser using \GraphQL\Server\Helper::parseRequestParams which includes this check
    Further:
  • Drop support for configuration the name of the variable for the variables (params_key)
  • GraphQLUploadMiddleware has been removed (RequestParser includes this functionality)
  • Empty GraphQL queries now return a proper validated GraphQL error

• In \Rebing\GraphQL\GraphQL, renamed remaining instances of $params to $variables
  After switching to RequestParser, the support for changing the variable name
  what was supposed to params_key has gone and thus the name isn't fitting anymore.
  Also, the default value for $variables has been changed to null to better
  fit the how OperationParams works:

  • old: public function query(string $query, ?array $params = [], array $opts = []): array
    new: public function query(string $query, ?array $variables = null, array $opts = []): array
  • old: public function queryAndReturnResult(string $query, ?array $params = [], array $opts = []): ExecutionResult
    new: public function queryAndReturnResult(string $query, ?array $variables = null, array $opts = []): ExecutionResult

Added

• The primary execution of the GraphQL request is now piped through middlewares #762 / crissi and mfn
  This allows greater flexibility for enabling/disabling certain functionality
  as well as bringing in new features without having to open up the library.
• Primarily register \Rebing\GraphQL\GraphQL as service and keep 'graphql' as alias #768 / mfn
• Automatic Persisted Queries (APQ) now cache the parsed query #740 / mfn
  This avoids having to re-parse the same queries over and over again.
• Add ability to detect unused GraphQL variables #660 / mfn
• Laravels ValidationException is now formatted the same way as a ValidationError #748 / mfn

Changed

• Don't silence broken schemas when normalizing them for generating routes #766 / mfn
• Lazy loading types has been enabled by default #758 / mfn

Removed

• The method \Rebing\GraphQL\GraphQLServiceProvider::provides was removed #769 / mfn
  It's only relevant for deferred providers which ours however isn't (and can't
  be made into with the current Laravel architecture).