subscription implementation

[arec]

Do you have any plan on implementing this:

https://github.com/graphql/graphql-js/pull/189 http://graphql.org/blog/subscriptions-in-graphql-and-relay/

[vladar]

PHP used to be bad choice to handle subscriptions. Now things change slowly with some of new libs like ReactPHP. But most of the real-world projects still use node or other tools for websockets / comet.

So the solution for subscriptions in graphql-php will probably be different than in graphql-js. I will evaluate possible approaches, but probably not until next month.

If you have any thoughts on subject of handling subscriptions in PHP - please let me know!

[smolinari]

If you ask me (and a little off topic), GraphQL with straight PHP is going to be a difficult mix from the start, as seen from the performance concerns already being found with this new project. I feel it is because of the sequential/ share nothing nature of PHP. There is a reason why Facebook created HHVM with Hack's async() function. It's to run requests to data services in parallel, which is also a need to allow GraphQL to perform well IMHO. I believe it is also why Facebook has turned to the NodeJS crowd for the server side. Why haven't they released a Hack version of a GraphQL type system?

Hmmm....

Scott

[vladar]

@smolinari Yeah, honestly I expected to see PHP / Hack version of GraphQL, but instead they released js version. So had to build this library to integrate with existing PHP project.

As for performance concerns - most of them equally apply to ORMs or custom solutions in PHP. Actually such library has some advantage over custom per-project solutions in that it could be re-implemented as PHP module (as drop-in replacement).

And I think it is a direction to follow eventually. But I suspect that even pure PHP implementation may perform reasonably well if you replace recursive Executor with iterative one (as PHP is slow in handling deep recursion). So that is probably the next step.

As for async - if you're stuck with plain PHP it doesn't matter if you use GraphQL or other tools - you don't have async anyway %)

Targeting for HHVM only is not an option at this point, but I would like to have a version that can handle async features of HHVM for those who can afford to use it.

[smolinari]

So had to build this library to integrate with existing PHP project.

And thank you for doing so! :+1:

As for performance concerns - most of them equally apply to ORMs or custom solutions in PHP.

Agreed. PHP7 will help this situation, but I am of the opinion, to scale a lot with PHP, we must break out of the current mold a bit. Facebook did it on their own with HHVM. And amazingly, PHP7 is as good or better as HHVM, even without a JIT compiler. That is really great news and looks promising for the future of PHP. But still, there are things we can do, to get even more performance. Non-blocking I/O and threading for example.

But I suspect that even pure PHP implementation may perform reasonably well if you replace recursive Executor with iterative one (as PHP is slow in handling deep recursion). So that is probably the next step.

Sounds good. I'll be keeping an eye out on these changes myself, as I am going to be attempting to do an appserver.io implementation of this library, where we will try to spread out the resolver work (and I am not certain that is the best cut point yet, but we'll see. If you have a better idea, let me know).

As for async - if you're stuck with plain PHP it doesn't matter if you use GraphQL or other tools - you don't have async anyway %)

True. Thankfully there are other alternatives to plain PHP. :smile:

Targeting for HHVM only is not an option at this point, but I would like to have a version that can handle async features of HHVM for those who can afford to use it.

This is what I was hoping Facebook would give us. I even asked them, what was the reasoning to go with Node instead of an HHVM implementation. I don't expect much of an answer, if any, but you never know.

Scott

[smolinari]

FYI. https://github.com/graphql/graphql-js/issues/219#issuecomment-155284851

Scott

[chrissm79]

@vladar I'm wondering if the way to go about it would be for this package to allow us to define Subscription Types, but leave it up to the developer on how to implement it. If you're in the process of creating functionality to handle subscriptions, maybe it's a separate package?

Not sure what the final spec will look like (seems that they're still flushing out details). But I'm personally thinking that Ratchet with WAMP and ZeroMQ may be the way to go for me. Laravel allows you to easily broadcast events and I'm thinking I will create a custom driver for this setup. Others may find it better to implement some sort of Node/Redis setup. Not sure if something like Pusher would work, but that may another possibility for some (again, depending on what the final spec looks like).

IMO, the way I see it is that GraphQL allows us to define our subscriptions, but doesn't get down into the details of how it's implemented.

[vladar]

@chrissm79 Yes, the goal is to be abstract enough for different backends. Unlike Node PHP doesn't have first-class support for such things, so it doesn't make sense to force concrete implementation.

So I do agree with you: most likely we'll have separate types for subscriptions, but underlying communication / transport layer will be app-specific.

Eventually some backends may be added as optional plugins to simplify initial setup.

[leocavalcante]

If it helps as reference implementation:

https://siler.leocavalcante.dev/graphql#graphql-subscriptions https://github.com/leocavalcante/siler/tree/master/src/GraphQL

[tankerkiller125]

Something that could be done here for subscriptions is something kind of like Laravel does for the Broadcast service where the lib would do pub/sub using redis and then a very basic nodejs server to actually handle the websocket connections.

It wouldn't be the best system, I know that, but it would be a workaround that would work.

[vladar]

Closing this as actual subscription implementations may vary depending on the environment. We won't ship out of the box solution until there is no such solution in the PHP core.

This lib already enables execution of subscriptions but each project will have to come up with own implementation. I encourage everyone to build such implementations as separate projects and link here so that we could add them in the docs.

Siler link above is a good example.

[vladar]

Existing implementations so far:

https://lighthouse-php.com/3.1/extensions/subscriptions.html https://siler.leocavalcante.dev/graphql#graphql-subscriptions

[alanpoulain]

You can add https://github.com/api-platform/core/pull/3321 (not yet merged but soon).

[tristanpemble]

Closing this as actual subscription implementations may vary depending on the environment. We won't ship out of the box solution until there is no such solution in the PHP core.

hey, I think that following along with the built in promise adapters, it won't take that much effort to build a similar AsyncIterator adapter system to handle subscriptions. this implementation can remain implementation agnostic; server and transport implementation would remain up to consumer libraries (like a graphql-ws-amphp, graphql-ws-reactphp, etc that handle protocols).

I am currently working on a proof of concept on this approach and hoping to create a draft PR soon for discussion.

I think with PHP 8.1 adopting Fibers, this is going to be an increasingly relevant usecase

[mcop1]

@tristanpemble did you already have a chance to work on your proof of concept, which you could share? Thank you very much.

[tristanpemble]

@mcop1 I realize this is 2.5 years late, and I have no idea what state it is in, but here was the branch I was working from: https://github.com/tristanpemble/graphql-php/tree/subscriptions

I'm not working with PHP these days