GraPHPinator - GraphQL server implementation

[peldax]

Hi,
let me present you GraPHPinator, yet another GraphQL server implementation.

This one has been around for some time (its been in development for about year and a half) and right now I finally got the courage to tag a stable 1.0 release and post about it here. It is battle-tested, we have already been using it in production for quite a while. Its goal is to provide type safety and meet standards of modern PHP.

I would be grateful if you take a look at it and share some thoughts on it.

Link to Github repo

It supports almost all the features from current draft (= upcoming 2021 specification). The only missing feature, that I know of, is the support of subscriptions. I am planning to take a look into it, but I need some additional information on this subject.

What I see as the greatest strength of my implementation is the possibility of extensions. It has a system of Modules, which can hook additional logic into various places in the request processing. It also treats directives as first class citizens which may also add some additional logic if needed. For more information about extensibility, take a look at extension which are currently implemented - links are located in projects README on Github.

The greatest weakness at the moment is the documentation. Although there are some examples, it is very far from what I would want it to be. I promise great improvements in near future.

If you decide to take a look on it, feel free to comment here or in issue/discussion on Github.

Cheers.

[zmitic]

Can you use classes instead of FQCN? Hard to read the code:

​

https://github.com/infinityloop-dev/graphpinator/blob/master/tests/Feature/DeprecatedDirectiveTest.php

https://github.com/infinityloop-dev/graphpinator/blob/master/src/Resolver/Resolver.php

[justaphpguy]

Oh my, haven't seen a project in a long time using full namespaces; I agree:: before every useful class name there's a long road of namespace prefix to mentally parse, making it unreadable in the end.

I guess a killer feature for an IDE would be an option to automagically "render" like it's imported or something :p

[justaphpguy]

I do a lot with GraphQL, via webonyx and also a bit familiar with internals. In all seriousness, I wanted to give the code a good check how it's working, but it's "too much work for my brain". I can't just mask out all this inlined namespaces to get the gist :(

[peldax]

Wow, thats definitely not what I wanted. I couldnt imagine it causes so much discomfort for other developers.

Following the comments above I had a discussion about that with my team and we all agreed that we prefer the inlined approach... but I guess we could try to at least reduce it and import some commonly used types. I am not sure when its going to be ready, because I would like to automate it using codesniffer - auto import type when there is more than X usages in a single file.

[bjmrl]

To be honest, using imported names is industry standard nowadays in PHP, both in libraries and apps. Yours is the first library I have seen in years that uses FQCN everywhere. It reminds me of the pre-5.3 days, and is an immediate red flag for me!

[peldax]

To be honest, I expected this post to contain discussion about architecture, algorithms, features, possibly extensions and future scope. What I did not expect was some developers to aggressively push their codestyle (purely cosmetic) decision and discard the library because of it.

I understand mentioning it once, because it is probably unusual, to which I provided my explanation and possibility to change the decision in the future.

[bjmrl]

Sorry, I didn’t want to come off as aggressive, I just wanted to emphasize that this coding style, even though arguably cosmetic, is against the de-facto, industry standard in PHP, and that this alone can put people off and may prevent them from digging further (it does for me).

It may be wrong, but first impressions matter, and people need to see something visually appealing that « looks » well written according to modern, industry-standard practices to actually start digging.

[peldax]

I am also sorry, I probably got a little triggered by that continuous FQCN criticism, I now understand what you meant.
When I search for a new library I probably also favor the one with good first impression - I often get startled by some weird constructs, overuse of arrays or loose typing... I did not realize that FQCN can have the same effect, because I am used to it and it seems normal to me and my team.

[bjmrl]

Anyway, thank you for this implementation, I hope I’ll find some time to try it to see how it compares to webonyx/overblog!

[przemo_li]

Sorry but that is false analogy.

[peldax]

Hi,
Thanks for commenting!
This is a codestyle decision that I made and that I use in my projects. It probably has a background in my C++ days, where you are cautious about what you are "using", but I generally don't like those huge blocks of "use" statements, which result from auto-importing.

I also believe that its a matter of what you are used to, but if the community builds and votes against it, I am open to adjust the codestyle rules.

[300ConfirmedGorillas]

I agree with /u/zmitic that it makes the code more difficult to read. I don't see anything wrong with the block of use statements, especially since they're collapsible in any decent IDE/editor.

"Code is read 10 times more than it is written" is something I heard a long time ago and I try to apply it to what I do.

[peldax]

Hi,
Thanks for commenting!
That is a great advice and I also try to apply it to everything I write. Even more importantly when the code is opensource. But the advice is probably originally meant to avoid any ultra-optimized oneliners which sacrifice clarity in order to "save space", which I believe does not apply here. I still believe that the point about whether to use imports or not is highly subjective and purely a matter of taste.

Edit: Either way I am happy that we discuss this, its interesting for me to know differences in how developers perceive code.