mghoneimy / php-graphql-oqm Goto Github PK

Related to #6

I use this package with my private graphql endpoint, it generates more than 130 files.
But the package generates the "TournamentQueryObject" class with some functions without params.

For example, the TournamentQueryObject->selectNameByLanguage() function should be selectNameByLanguage(string $lang)

It generates the query :

query {
  tournaments() {
    nameByLanguage
  }
}

But I need the query:

query {
  tournaments() {
    en:nameByLanguage ( lang : "en" )
  }
}

I think there is some uncompleted features in the package while parsing graphql schema, but I have an easy solution without breaking changes.

How to implement these features:

php:

  ->selectNameByLanguage()
    ->addPrefix('en')->addArguments(['lang' => 'en'])

Another example with the https://graphql-pokemon.now.sh endpoint

Can't generate a graphql query with the "new_id:id" prefix

query {
  pokemon(name: "Pikachu") {
    new_id:id 
    number
    name
  }
}

Can't generate a graphql query with the arguments

query {
  pokemon(name: "Pikachu") {
    new_id:id (argument_name: "argument_value")
    number
    name
  }
}

php:

->selectPokemon((new RootPokemonArgumentsObject())->setName('Pikachu'))
        ->selectId()
        ->selectNumber()
        ->selectName();

Easy solution:

php:

->selectPokemon((new RootPokemonArgumentsObject())->setName('Pikachu'))
        ->selectId()
        ->addPrefix('new_id')->addArguments(['argument_name' => 'argument_value'])
        ->selectNumber()
        ->selectName();

The addPrefix() function adds the prefix to the last selection element.
The addArguments() function adds the arguments to the last selection element.

I have added these functions in the php-graphql-client pull request.

Hi,
let's assume we have the following schema:

  enum Provider {
    GOOGLE_PLACES
    WALLET_SAVER
  }

  autocompleteAddress(
    query: String!
    provider: Provider!
    istatCode: String
    limit: Int = 10
  ): [AddressDetails]

Launching ./vendor/bin/generate_schema_objects without arguments, I'll get the class RootAutocompleteAddressArgumentsObject with the following setter method public function setProvider(ProviderInputObject $providerInputObject) but that class is missing among the generated files.
So I had to create such file as the following (not sure it's the best way though):

<?php

namespace SosTariffe\Components\GqlGenerator\SchemaObject;

use GraphQL\RawObject;
use GraphQL\SchemaObject\InputObject;

class ProviderInputObject extends InputObject
{
    private $value;

    public function __construct(string $enum)
    {
        $this->value = $enum;
    }

    public function __toString()
    {
        return $this->value;
    }

    public function toRawObject(): RawObject
    {
        return new RawObject($this->value);
    }
}

The final test produces a valid GraphQL query:

        $rootObject = new RootQueryObject();

        $args = new RootAutocompleteAddressArgumentsObject();
        $args
            ->setIstatCode("50008")
            ->setLimit(5)
            ->setProvider(new ProviderInputObject(ProviderEnumObject::WALLET_SAVER))
            ->setQuery("Via Tosc");

        $addrDetails = $rootObject
            ->selectAutocompleteAddress($args);

        $addrDetails
            ->selectAddress()
            ->selectToponym()
            ->selectTown()
                ->selectName();

        $addrDetails->selectProviders()
                ->selectWalletSaver();

        echo $rootObject->getQuery();

And the result is the following:

{
  autocompleteAddress(query: "Via Tosc" provider: WALLET_SAVER istatCode: "50008" limit: 5) {
    address {
      toponym
      town {
        name
      }
    }
    providers {
      walletSaver
    }
  }
}

I'm trying to use php-graphql-oqm against Waveapp GraphQL.
https://developer.waveapps.com/hc/en-us/articles/360018937431-API-Playground
It's free to register.

I'm getting an error from php vendor/bin/generate_schema_objects:
Inline argument of type String is not allowed. Provide data using GraphQL variables.

Any idea what might be happening?

Hi there,

Just wanted to try it against eZ Platform GraphQL and got an error. Any ideas what could be the issue?

PHP Fatal error: Uncaught RuntimeException: Unsupported object type in /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php:139
Stack trace:
#0 /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php(106): GraphQL\SchemaGenerator\SchemaClassGenerator->generateObject('DomainContent', 'INTERFACE')
#1 /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php(155): GraphQL\SchemaGenerator\SchemaClassGenerator->appendQueryObjectFields(Object(GraphQL\SchemaGenerator\CodeGenerator\QueryObjectClassBuilder), 'ContentRelation', Array)
#2 /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php(133): GraphQL\SchemaGenerator\SchemaClassGenerator->generateQueryObject('ContentRelation')
#3 /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php(106): GraphQL\SchemaGenerator\ in /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php on line 139

Fatal error: Uncaught RuntimeException: Unsupported object type in /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php:139
Stack trace:
#0 /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php(106): GraphQL\SchemaGenerator\SchemaClassGenerator->generateObject('DomainContent', 'INTERFACE')
#1 /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php(155): GraphQL\SchemaGenerator\SchemaClassGenerator->appendQueryObjectFields(Object(GraphQL\SchemaGenerator\CodeGenerator\QueryObjectClassBuilder), 'ContentRelation', Array)
#2 /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php(133): GraphQL\SchemaGenerator\SchemaClassGenerator->generateQueryObject('ContentRelation')
#3 /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php(106): GraphQL\SchemaGenerator\ in /vendor/gmostafa/php-graphql-oqm/src/SchemaGenerator/SchemaClassGenerator.php on line 139

Thanks for this amazing project, which I've been using for about a year now. :)

In my use case the schema objects change quite frequently. The generate_schema_objects to regenerate them works fine, but putting in the GraphQL-Endpoint, Authorization info & output folder every time is not ideal for me.

I would prefer if I could specify them as command-line arguments (that way I could wrap the script into another one and just call it with the same parameters every time; Or I would put the values in env variables).

I think this functionality would be very beneficial. What do you think?

I'm looking into using this in one of my projects, but I'm seeing that it doesn't properly support using Enums in query arguments.

for example, I have this schema snipit

queryName(OrderBy: [OrderByClause!]){
 ...
}

Input OrderByClause{
 field: String!
 order: SortOrder!
}

enum SortOrder{ 
 ASC
 DESC
}

But when that gets run through your generator, the OrderByClause's order field gets converted into an InputObject argurment, when its an enum.

I am using Laravel and Lighthouse, if it helps any

Hi there. I'm curious if adding support for generating mutation objects from the schema is on the roadmap. I've been toying around and have a really quick and dirty branch, but it looks like adding this functionality would require updating to the client lib to add a AbstractMutationBuilder or something similar.

The apollo code gen does this for android and presumably for the node client. Would be real nice to have it for PHP too, but I haven't found this functionality in any other lib.

So, two questions:

1. have you already gone down this road and decided against it?
2. open to a PR or do you have an idea of how you'd like to see it implemented?

In SchemaClassGenerator::generateObject() and SchemaClassGenerator::appendQueryObjectFields() it seems that enum fields are treated as object fields. This generates query bodies like these:

    public function selectEnumField(ParentEnumFieldArgumentsObject $argsObject = null)
    {
        $object = new EnumFieldQueryObject("enumField");
        if ($argsObject !== null) {
            $object->appendArguments($argsObject->toArray());
        }
        $this->selectField($object);
    
        return $object;
    }

However, EnumFieldQueryObject is never generated because it is only generated for object types. I think somewhere in SchemaClassGenerator::appendQueryObjectFields() a code path should be taken that looks more like scalar.

Am I missing something perhaps?

The object generation script does not accept arguments, which requires an interactive prompt. In environments where vendor directory is not included in the repo, but are built for deploy, it is impossible to generate in the build process.

While a custom write directory can be created and committed, there are additional benefits to allowing CLI arguments instead of the interactive command such as sharing commands between team members or simply bypassing the interactive prompt entirely.

Found a small problems with underscore.

The endpoint is providing the "_foobar" and "foobar" names of objects. The the generated code creates 2 selectFoobar() functions, hence its an error.

Not sure how to tackle this. Maybe replace the underscore with some character combination?

As some API's have rate limits (ex: 80 request in 60 seconds) . A rate limiter implementation can be very useful

Hello,

I was wondering what to do with the generated InputObject Classes ( use then in a mutation ?) when i noticed some "InputObject" classes seems to not be generated.

I understand that InputObject classes are generated with this model name : {OBJECT_NAME}InputObject

I have a table that i can query like this:

query MyQuery {
  solvant {
    id
    name
    abbr
  }
}

i cannot find "solvantInputObject" class, but "solvant_order_byInputObject" class is generated.

I can't undertand why.

Many thanks in advance.

nb: my GraphQL schema is generated with Hasura.

Thank you very much for this awesome tool. I encountered an (admittedly, rather odd) edge-case for which I would open a PR if you consider it worth it (and tell me what your desired resolution is).

The problem is the following:

Duplicate methods are generated for an API with two fields in two different "cases".

Example: an API that has a field timeZone and a field time_zone (of which one might be deprecated) (this applies e.g. to Pipefy: https://api-docs.pipefy.com/reference/objects/User/) will result in two times the function

public function selectTimeZone()

, one time selecting timeZone and one time time_zone.

PHP does not like that of course.
I can imagine various resultions: If there are multiple,

1. just discard the deprecated one,
2. use the case as used in the API (i.e. resulting in one selectTimeZone() and one selectTime_zone(),
3. select both at once

Shall I open a PR with which of these possibilities? (Any hints on where to look for the deciding code?)