Implement Apollo Federation v2

[Aeliot-Tm]

Proposed changes

• Implementation of Apollo Federation v2
• Added support of "compound" key fields

Implemented directives:

• @link
• @inaccessible
• @override
• @shareable
• @key (added support of argument resolvable)

⚠️ IMPORTANT: There are some backward compatibility breaks:

1. deprecated optionkeyFields for entity configs! Use option keys instead of it. Pay attention that value of the new option is not compatible with the previous one. But there was done some work around for supporting of old configurations. Old configs will work "ok" for entities, but they are broken for entity references!
2. there was added some constraints on @key directive of entity reference for better matching of specification. There is not possible multiple directive @key and new argument resolvable: false is required.

How to test

All tests run on CI.

Unit Tests

• This PR has unit tests
• This PR does not have unit tests: why?

Ref #24

[ldiego08]

Amazing work, @Aeliot-Tm! Changes look good to me but will defer to @xiian or anyone else
at SK willing to give this a deeper review and a test run.

[maccath]

Hi @Aeliot-Tm, and thanks for the PR.

I've not reviewed all of the code yet, but I've added some comments and questions on what I've looked through so far. Hopefully you can clarify for me!

[Aeliot-Tm]

@maccath I made updates. Could you recheck it, please?

[Klaas-MY]

Any update on this PR? We could really use V2 :)

[maccath]

Any update on this PR? We could really use V2 :)

Hi @Klaas-MY - we are still working through this on our end. To speed things up, you could help us test this by specifying this branch in your composer.json (docs: Loading a package from a VCS repository) and let us know if you spot any issues!

Thanks!

[Makapashev]

Any updates on this PR?

[tcarrio]

Should we consider dropping support for PHP 7.4 now?

[Aeliot-Tm]

Downgraded to PHP 7.1

But it cannot be tested on this version of PHP. It was locked implicitly on php >=7.3 when required PHPunit ^9.5

apollo-federation-php/composer.json

Line 30 in c1bc216

"phpunit/phpunit": "^9.5",

[rvanlaak]

It would be great if the version bump could happen in #31 , and this PR could become mergeable without this PHP bump first. A minor release can happen first, and the version bumps of #31 can happen in a major breaking release.

When considering the version bump the Stitcher blogposts are helpful: https://stitcher.io/blog/php-version-stats-january-2023
The one thing I am always curious about is how much % of these stats are caused by CI pipelines (and hence the actual PHP <= 7.4 usage is lower).

The PHP supported versions is a better guidance, especially when considering a major release as a library.
The old library versions will still remain available through Packagist, and the need for new functionality will stimulate engineers to get their PHP versions updated.

[Aeliot-Tm]

Hi @maccath ,

Why does it take so long to check this PR?

[xiian]

@Aeliot-Tm Thank you for contributing this PR and apologies for delays on reviews. In order to test this, we've been trying to integrate this on our end and that can take a bit of time.

In addition to testing internally, we also run our code against the apollo-federation-subgraph-compatibility repo (which powers this page on apollographql.com). As you can see on the website, Apollo Federation PHP does not currently support Federation v2, but does support all features of Federation v1 (except federated tracing).

We've run the test suite against this PR locally and had mixed success. We've put up a version of that test in a PR in our fork of apollo-federation-subgraph-compatibiity. It seems that the branch does not have the intended effect.

The code for the test was updated according to the description of the PR and the updates to the README.md, but I think there are more modifications needed.

SchemaBuilder documentation

I see the addition of a SchemaBuilder class in the PR which does not seem referenced anywhere else (outside tests). If this is now required for usage we need to have the README.md updated with proper usage for this as well.

FederatedSchemaTrait justification

There's also a FederatedSchemaTrait that was created that seems to be pulled out functionality from FederatedSchema, but there's no information about why it was pulled out aside from removing those methods (and properties) from the FederatedSchema class. Not to say that there isn't potential use cases for this trait, but we should provide reasons for the change.

@link implementation documentation

As this is the core required functionality of Federation v2, we must have proper documentation on how to use this. As it is, I've attempted to figure out the correct usage locally and been unable to do so. I'm not sure if I'm doing it wrong, or if the functionality is broken.

Other New Directives implementation

While I see the addition of the other directives for Federation v2 support, I don't see any instructions for using them. The unit tests are good for covering the configuration of those directives, and we do have a test for writing them out in the SDL, but there is nothing to cover applying those directives on fields/objects/etc.

@key directive backwards-compatibility break

While I understand that BC is sometimes necessary, we are not looking to break this library's compatibility with Federation v1. It's possible that our updates to the code were incorrect, but the @key (single) test is now failing. If there is a different way of achieving this, please document it.

---

I would suggest breaking this PR up into several smaller PRs, maybe one per directive. This will make it much easier to review, but also much easier to ensure that the functionality is working correctly. We can merge them in as we go,

Also, checking out a local copy of https://github.com/apollographql/apollo-federation-subgraph-compatibility and updating the code inside of implementations/php will allow you to perform the same tests locally.

[Aeliot-Tm]

@xiian Thank you for feedback and the link to the testing repo.
I'll have a look what is the reason of mixed success. And I'll update documentation of course.

[rvanlaak]

Is there anything that can get some help to get this functionality to a mergeable state?

The deprecation functionality that was added in webonyx/graphql-php v15.4.0 might seem to be a great option to get the BC break on this PR resolved in a different way? But, using that deprecation feature would require a package and a PHP version bump, and that might not be something you preferably want to do through this PR?