passing some extra value from GraphQLController@query method to Folklore\GraphQL\Support\Mutation@resolve?

[sadeghhosseini]

Is it possible to send some extra value from GraphQLController@query method to Folklore\GraphQL\Support\Mutation@resolve?

I need to be able to get file from $request object in my resolve method of my mutation classes.
Is such a thing possible?

[ivanfilatov]

You can implement your own GraphQLController. In order to do that, just change in config/graphql.php the following: 'controllers' => \App\Http\Controllers\GraphQLController::class . '@query',.

But just to warn you, file upload with GraphQL is not trivial.
Our frontend developers use Appolo packages for communicating with backend. I use custom GraphQLController and middleware from ecodev/graphql-upload package. The point is to convert Laravel request to PSR-7 and back on-the-fly in order to process injected file upload. If you are interested, I can cover this topic in more details.

[mfn]

For one, nothing in your resolver prevents you from simply calling request() and access it; though personally I don't recommend this approach.

---

A better approach is to make use of the GraphQL "context".

The default context is created in \Folklore\GraphQL\GraphQLController::queryContext https://github.com/Folkloreatelier/laravel-graphql/blob/66e92331ff677cf02d2ecfecec8103ada965fbad/src/Folklore/GraphQL/GraphQLController.php#L107-L114

As you can see, it only consists of the authenticated user, so $context in the resolve is really just User $authUser.

However: you can replace the GraphQLController with your own, override this method and return whatever context you have.

This is explicitly supported because in config/graphql.php you can configure which controller should be called.

Since the Folklore controller already receives the Request, you can:

• override the constructor to store it e.g. in a property
• override queryContext which returns whatever you want for your resolve (request, auth user, etc.)

---

A totally different option: nuwave/lighthouse is another GraphQL server which a) is actually maintained and has a lot development activity (this is seems like a dead horse and b) has a Context which actually does implement exactly what you asked for.

[ivanfilatov]

BTW, yes, overriding queryContext is a good idea to store, for example, some non-user data in the request lifecycle. (IMHO)

[ivanfilatov]

A totally different option: nuwave/lighthouse is another GraphQL server which a) is actually maintained and has a lot development activity (this is seems like a dead horse and b) has a Context which actually does implement exactly what you asked for.

@mfn, i had a look on this package when we started our project and it was not ready for production at that moment... How do you think, is it hard to transfer a project from folklore package to nuawe package? And is it production-ready at the moment, in your opinion? Thanks!

[mfn]

Although I'm not using lighthouse, unfortunately I have an opinion 😄

How do you think, is it hard to transfer a project from folklore package to nuawe package?

I think it depends. My mid-sized project using Folklore is using some construct with the programmatic Type definition approach which do not translate to any schema DSL approach. Or, not easy.

lighthouse is schema-first and radically different but OTOH also more "mainstream" (i.e. other tech stacks very well do this schema-first approach, too).

Schema-first also has the benefit of better tooling: many IDE tools understand the GraphQL schema and assist in writing it.

And is it production-ready at the moment, in your opinion?

From what I gather, Yes!

And if you find a problem: they're incredible fast helping/answering/fixing stuff.

Not so this library, you're basically on your own. I lost track of the amount of workarounds (a few weeks of work) I required to make Folklore work the way I need it. Unfortunately back then I wasn't aware of lighthouse 💣

[ivanfilatov]

From what I gather, Yes!

Well, if so, probably we'll be looking forward to implement it, because now we have a huge problem with integrating folklore due to non-published tag 😸 (every time we need to drop vendor/folklore in order to run composer update)
Thanks!

[mfn]

every time we need to drop vendor/folklore in order to run composer update

You can work this around. Composer allows to specify "repositories" and by basically copying the composer.json of Folklore and adjusting in, it kind of "shadows" the real one.

I.e. under the top level repositories key I put this:

{
      "type": "package",
      "package": {
        "version": "v1.1.0.1",
        "dist": {
          "url": "https://github.com/Folkloreatelier/laravel-graphql/archive/66e92331ff677cf02d2ecfecec8103ada965fbad.zip",
          "type": "zip"
        },
        "name": "folklore/graphql",
        "description": "Facebook GraphQL for Laravel",
        "keywords": ["framework", "laravel", "graphql", "react"],
        "authors": [
          {
            "name": "Folklore",
            "email": "[email protected]",
            "homepage": "http://atelierfolklore.ca"
          },
          {
            "name": "David Mongeau-Petitpas",
            "email": "[email protected]",
            "homepage": "http://mongo.ca",
            "role": "Developer"
          }
        ],
        "license": "MIT",
        "type": "library",
        "require": {
          "php": ">=5.5.9",
          "illuminate/support": "5.1.*|5.2.*|5.3.*|5.4.*|5.5.*|5.6.*|5.7.*",
          "webonyx/graphql-php": "~0.10.2"
        },
        "require-dev": {
          "orchestra/testbench": "3.1.*|3.2.*|3.3.*|3.4.*|3.5.*",
          "fzaninotto/faker": "~1.4",
          "mockery/mockery": "0.9.*",
          "satooshi/php-coveralls": "^1.0",
          "phpunit/phpunit": "~4.0|~5.0|~5.7|~6.0"
        },
        "autoload": {
          "psr-0": {
            "Folklore\\GraphQL\\": "src/"
          }
        },
        "autoload-dev": {
          "classmap": [
            "tests/"
          ]
        },
        "extra": {
          "laravel": {
            "providers": [
              "Folklore\\GraphQL\\ServiceProvider"
            ],
            "aliases": {
              "GraphQL": "Folklore\\GraphQL\\Support\\Facades\\GraphQL"
            }
          }
        }
    }

and I reference it with this made up version number:

"folklore/graphql": "1.1.0.1",

I guess there are better ways but this isn't the first time I had to apply this for 3rd party packages starting to get problematic due to be orphaned.

Of course another solution is to fork it, rename it, etc.

[ivanfilatov]

Nice workaround, i'll definitely try it. Recently we were thinking about forking it, because actually this package solves the majority of our problems.