Integration of subscriptions about graphqlite HOT 4 OPEN

I'm interested in this as well. WebSockets require a separate web server, separate configuration for proxying servers (like Nginx).

What about SSE? Stream responses are already supported by Laravel, Symfony, Swoole and are as easy to use on the client as WebSockets are. Their performance under stress conditions is lower than that of WebSocket, but the conclusion of TimePlus' article is that they're "close enough".

This might be a less painful option for graphqlite's users than WS, thanks to everything being in one app, on one server and in PHP.

from graphqlite.

Subscriptions could actually be added!

My current plan is to try the Mercure protocol for real-time communication.

from graphqlite.

@oprypkhantc it'd be nice to see some action around this for sure. I agree that sticking with SSE and the HTTP protocol is more fitting for GraphQLite. Bi-directional communication over WS isn't really necessary for GraphQL.

API Platform has implemented Mercure support for subscriptions
api-platform/core#3321

Here is a small SSE proof of concept app using Mercure and symfony/mercure
https://github.com/AlessandroMinoccheri/sse-poc

Here is a topic with webonyx on subscription implementation
webonyx/graphql-php#9

Webonyx already supports the subscription property on the GraphQL\Type\Schema::__construct(array $config). So, I'm assuming we could just introduce a new GraphQLite\Subscription attribute to annotate the "controllers"/resolvers. We'd likely want to have some abstractions around symfony/mercure, for publishing updates, as that'll require building out the types/fields for the payload, based on the initial client's subscription query.

What I'm unsure about is, when a subscription is made, presumably with an accompanying query (output fields needed - don't see how input fields could be allowed) - where is that query stored for later use? I'm assuming that'd require a custom userland persistence implementation, which is fine.

Maybe as a first step we could outline the API and clear up some of the unknowns with how an implementation might be done.

from graphqlite.

I believe the initial effort should be focused on providing a stupid-simple contract that users could then use to build more sophisticated solutions. For example, ExpediaGroup/graphql-kotlin uses existing Java ecosystem to handle subscriptions on the most basic level: https://github.com/ExpediaGroup/graphql-kotlin/blob/master/examples/server/spring-server/src/main/kotlin/com/expediagroup/graphql/examples/server/spring/subscriptions/SimpleSubscription.kt#L39

The way it works is they have two interfaces: Publisher and Subscriber:

interface Subscriber<TItem> {
    public function onSubscribe​(Subscription $subscription): void;
    public function onNext​(TItem $item): void;
    public function onError(Throwable $error): void;
    public function onComplete(): void;
}

interface Publisher<TItem> {
    public function subscribe(Subscriber<TItem> $subscriber): void;
}

And this is how an example implementation might look:

class EverySecondPublisher implements Publisher<int> {
    public function subscribe(Subscriber<int> $subscriber): void
    {
        $subscriber->onSubscribe();
        
        for ($i = 0; $i < 1000; $i++) {
            $subscriber->onNext($i);
        }
        
        $subscriber->onComplete();
    }
}

class SomeController {
    /** @return Publisher<int> */
    #[Subscription]
    public function intAddedEverySecond(): EverySecondPublisher {
        return new EverySecondPublisher();
    }
}

Then all that's left is to implement Subscriber for SSE and use it:

// Graphqlite internals...

class SSESubscriptionFromPsrRequest implements Subscriber {
    public function __construct(private readonly RequestInterface $request) {}
    
    public function onSubscribe(): void {
        // send HTTP headers ?
        $request->open();
    }
    
    public function onNext($item): void {
        $serialized = json_encode($item);
        
        $request->send($serialized);
    }
    
    public function onComplete(): void {
        $request->close();
    }
}

$publisher = $controller->callSubscriptionMethod();
$publisher->subscribe(new SSESubscriptionFromPsrRequest($request));

then, on top of it, we could implement first-party support for symfony/mercure on top of those interfaces.

But I advocate against it. That can be easily included in the graphqlite/symfony-bundle if needed. I'd rather leave that to be framework-specific; for example, in Laravel the standard practice is to use broadcastable events:

class MaintenanceModeEvent {
    public function broadcastChannel(): string {
        return 'maintenance';
    }
}

// Broadcast to every subscriber of `general` channel
$broadcaster->broadcast(new MaintenanceModeEvent());

So instead of changing events throughout the project or trying to workaround symfony/mercure, I'd much rather just implement an adapter to use the existing Laravel's system:

class LaravelBroadcasterPublisher implements Publisher {
    public function __construct(private readonly string $channel, private readonly Broadcaster $broadcaster) {}
    
    public function subscribe(Subscriber $subscriber): void 
    {
        $subscriber->onSubscribe();
        
        // example code, not a real API
        $broadcaster->listen($this->channel, function ($event) use ($subscriber) {
            $subscriber->onNext($event);
        });
    }
}

class SomeController {
    #[Subscription]
    public function maintenanceMode(#[Inject] Broadcaster $broadcaster): Publisher {
        return new LaravelBroadcasterPublisher('maintenance', $broadcaster);
    }
}

Of course this will also have to account for async use cases (through the use of graphql-php promises I guess),

from graphqlite.