GraphQL
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. — graphql.org
Here is how you can create a GraphQL endpoint using Siler's simplicity powered by the PHP's GraphQL implemention.
First, let's require it:
1
$ composer require webonyx/graphql-php
Copied!
Siler doesn't have direct dependencies, to stay fit, it favors peer dependencies, which means you have to explicitly declare a
graphql dependency in your project in order to use it.Now let's define our Schema. We're going to use a chat-like domain:
schema.graphql
1
type Message {
2
id: Int
3
roomId: Int
4
body: String
5
timestamp: String
6
}
7
8
type Room {
9
id: Int
10
name: String
11
messages: [Message]
12
}
13
14
type Query {
15
messages(roomName: String): [Message]
16
rooms: [Room]
17
}
18
19
type Mutation {
20
start(roomName: String): Room
21
chat(roomName: String, body: String): Message
22
}
Copied!
Very simple, but if it's not familiar to you, take a look at GraphQL first since this docs will not cover what is it, but how to use it.
For each Query and Mutation we can define our resolver functions. We'll be using RedBean to help us as a simple SQLite storage ORM.
resolvers.php
1
<?php
2
3
use RedBeanPHP\R;
4
5
R::setup('sqlite:'.__DIR__.'/db.sqlite');
6
7
$roomByName = function ($name) {
8
return R::findOne('room', 'name = ?', [$name]);
9
};
10
11
$roomType = [
12
'messages' => function ($room) {
13
return R::findAll('message', 'room_id = ?', [$room['id']]);
14
},
15
];
16
17
$queryType = [
18
'rooms' => function () {
19
return R::findAll('room');
20
},
21
'messages' => function ($root, $args) use ($roomByName) {
22
$roomName = $args['roomName'];
23
$room = $roomByName($roomName);
24
$messages = R::find('message', 'room_id = ?', [$room['id']]);
25
26
return $messages;
27
},
28
];
29
30
$mutationType = [
31
'start' => function ($root, $args) {
32
$roomName = $args['roomName'];
33
34
$room = R::dispense('room');
35
$room['name'] = $roomName;
36
37
R::store($room);
38
39
return $room;
40
},
41
'chat' => function ($root, $args) use ($roomByName) {
42
$roomName = $args['roomName'];
43
$body = $args['body'];
44
45
$room = $roomByName($roomName);
46
47
$message = R::dispense('message');
48
$message['roomId'] = $room['id'];
49
$message['body'] = $body;
50
$message['timestamp'] = new \DateTime();
51
52
R::store($message);
53
54
return $message;
55
},
56
];
57
58
return [
59
'Room' => $roomType,
60
'Query' => $queryType,
61
'Mutation' => $mutationType,
62
];
Copied!
Awesome. We have type definitions and resolver functions. Let's put them together in a Schema:
schema.php
1
<?php
2
3
use Siler\GraphQL;
4
5
$typeDefs = file_get_contents(__DIR__.'/schema.graphql');
6
$resolvers = include __DIR__.'/resolvers.php';
7
8
return GraphQL\schema($typeDefs, $resolvers);
Copied!
Yeah, that simple! And it's exactly where Siler does it magic happen.
Thanks to
webonyx/graphql-php we can parse the schema.graphql into an actual Schema and Siler will override the default field resolver to work with the given $resolvers.Now, let's create our HTTP endpoint:
api.php
1
<?php
2
3
use Siler\GraphQL;
4
use Siler\Http\Request;
5
use Siler\Http\Response;
6
7
require 'vendor/autoload.php';
8
9
// Enable CORS
10
Response\cors();
11
12
// Respond only for POST requests
13
if (Request\method_is('post')) {
14
// Retrive the Schema
15
$schema = include __DIR__.'/schema.php';
16
17
// Give it to siler
18
GraphQL\init($schema);
19
}
Copied!
That's it!
Start the server:
1
$ php -S localhost:8000 api.php
Copied!
Here are some queries you can execute:
Query available rooms:
1
query {
2
rooms {
3
id
4
name
5
}
6
}
Copied!
Yeah, there isn't any Rooms yet:
1
{
2
"data": {
3
"rooms": []
4
}
5
}
Copied!
But. It's working!. Thanks to RedBean + SQLite we can play around without worrying about database setup and migrations.
Creating a new Room:
1
mutation newRoom($roomName: String) {
2
start(roomName: $roomName) {
3
id
4
}
5
}
Copied!
variables
1
{
2
"roomName": "graphql"
3
}
Copied!
Then our first room is created:
1
{
2
"data": {
3
"start": {
4
"id": 1
5
}
6
}
7
}
Copied!
Call the query that fetches Rooms to check again:
1
query {
2
rooms {
3
id
4
name
5
}
6
}
Copied!
Yup! It's there:
1
{
2
"data": {
3
"rooms": [
4
{
5
"id": 1,
6
"name": "graphql"
7
}
8
]
9
}
10
}
Copied!
Without any Messages yet:
1
query roomMessages($roomName: String) {
2
messages(roomName: $roomName) {
3
id
4
body
5
timestamp
6
}
7
}
Copied!
variables
1
{
2
"roomName": "graphql"
3
}
Copied!
No messages yet:
1
{
2
"data": {
3
"messages": []
4
}
5
}
Copied!
So let's chat!
1
mutation newMessage($roomName: String) {
2
chat(roomName: $roomName, body: "hello") {
3
id
4
}
5
}
Copied!
variables
1
{
2
"roomName": "graphql"
3
}
Copied!
First message created:
1
{
2
"data": {
3
"chat": {
4
"id": 1
5
}
6
}
7
}
Copied!
Let's refetch our messages to check:
1
query roomMessages($roomName: String) {
2
messages(roomName: $roomName) {
3
id
4
body
5
timestamp
6
}
7
}
Copied!
variables
1
{
2
"roomName": "graphql"
3
}
Copied!
Aha! Here we go:
1
{
2
"data": {
3
"messages": [
4
{
5
"id": 1,
6
"body": "hello",
7
"timestamp": "2017-04-20 14:58:07"
8
}
9
]
10
}
11
}
Copied!
Liked it? What about listening to added messages and enable real-time features?
Sounds cool? That is GraphQL Subscriptions and we are going to cover next.
GraphQL Subscriptions
Here is how you can add real-time capabilities to your GraphQL applications.
We'll need some help to get WebSockets working, so let's require two libraries.
One is for the server-side:
1
$ composer require cboden/ratchet
Copied!
And the other is for the client-side:
1
$ composer require textalk/websocket
Copied!
First, let's add our Subscription type to our Schema:
schema.graphql
1
# (...previous work...)
2
3
type Subscription {
4
inbox(roomName: String): Message
5
}
Copied!
Simple like that. We can subscribe to inboxes to receive new messages.
And our resolver will look like that:
resolvers.php
1
# (...previous work...)
2
3
$subscriptionType = [
4
'inbox' => function ($message) {
5
return $message;
6
},
7
];
Copied!
Yeap, it is just resolving to the message that it receives.
But where this message comes from?
Siler powers!
Siler has a function at the
Graphql namespace to define where your subscriptions are running:1
GraphQL\subscriptions_at('ws://127.0.0.1:3000');
Copied!
Here we are assuming that they are running at localhost on port 8080.
And why is that for?
This is just a helper that adds the Subscriptions endpoint to the Siler container so another function can actually use it when needed. And this function is
publish!Siler\GraphQL\publish will make a WebSocket call to the Subscriptions server notifying that something has happened.1
GraphQL\publish('inbox', $message);
Copied!
It's first argument is the Subscription that will be triggered and the second argument is a data payload, in our case, the new message that has been created.
Our
resolvers.php will look like this:resolvers.php
1
<?php
2
3
use RedBeanPHP\R;
4
use Siler\GraphQL;
5
6
R::setup('sqlite:'.__DIR__.'/db.sqlite');
7
8
// Here we set where our subscriptions are running
9
GraphQL\subscriptions_at('ws://127.0.0.1:3000');
10
11
$roomByName = function ($name) {
12
return R::findOne('room', 'name = ?', [$name]);
13
};
14
15
$roomType = [
16
'messages' => function ($room) {
17
return R::findAll('message', 'room_id = ?', [$room['id']]);
18
},
19
];
20
21
$queryType = [
22
'rooms' => function () {
23
return R::findAll('room');
24
},
25
'messages' => function () use ($roomByName) {
26
$roomName = $args['roomName'];
27
$room = $roomByName($roomName);
28
$messages = R::find('message', 'room_id = ?', [$room['id']]);
29
30
return $messages;
31
},
32
];
33
34
$mutationType = [
35
'start' => function ($root, $args) {
36
$roomName = $args['roomName'];
37
38
$room = R::dispense('room');
39
$room['name'] = $roomName;
40
41
R::store($room);
42
43
return $room;
44
},
45
'chat' => function ($root, $args) use ($roomByName) {
46
$roomName = $args['roomName'];
47
$body = $args['body'];
48
49
$room = $roomByName($roomName);
50
51
$message = R::dispense('message');
52
$message['roomId'] = $room['id'];
53
$message['body'] = $body;
54
$message['timestamp'] = new \DateTime();
55
56
R::store($message);
57
58
// Then we can publish new messages that arrives from the chat mutation
59
GraphQL\publish('inbox', $message); // <- Exactly what "inbox" will receive
60
61
return $message;
62
},
63
];
64
65
// Our added Subscription type
66
$subscriptionType = [
67
'inbox' => function ($message) { // <- Received from "publish"
68
return $message;
69
},
70
];
71
72
return [
73
'Room' => $roomType,
74
'Query' => $queryType,
75
'Mutation' => $mutationType,
76
'Subscription' => $subscriptionType, // Add to the resolver functions array
77
];
Copied!
Starting the server
As in
api.php endpoint we need to setup the Subscriptions server:subscriptions.php
1
<?php
2
3
use function Siler\{GraphQL, Ratchet};
4
5
require_once '/vendor/autoload.php';
6
7
$schema = require_once __DIR__ . '/schema.php';
8
$manager = GraphQL\subscriptions_manager($schema);
9
10
Ratchet\graphql_subscriptions($manager)->run();
Copied!
Yeah, easy like that. Let Siler do the boring stuff. You just give a Schema to the
subscriptions function. This function will return an IoServer where you can call the run method.1
php subscriptions.php
Copied!
By default, Siler will run the subscriptions at localhost on port 8080.
Production-grade
To run subscriptions server at a production-grade level, please consider using some long-running process manager like Supervisor. Take a look at http://socketo.me/docs/deploy#supervisor.
That's it
No kidding.
Behind the scenes ReactPHP, Ratchet and Pawl are doing the hard work of handling WebSocket communication protocol while Siler is doing the work of adding resolver resolution to webonyx/graphql-php and handling Apollo's sub-protocol.
Ready to test?
A subscription query looks like this:
1
subscription newMessages($roomName: String) {
2
inbox(roomName: $roomName) {
3
id
4
body
5
}
6
}
Copied!
variables
1
{
2
"roomName": "graphql"
3
}
Copied!
The result will not be immediate since we are now listening to new messages, not querying them.
1
mutation newMessage($roomName: String) {
2
chat(roomName: $roomName, body: "hello") {
3
id
4
}
5
}
Copied!
variables
1
{
2
"roomName": "graphql"
3
}
Copied!
Now go back to the subscription tab and see the update!
1
{
2
"inbox": {
3
"id": 42,
4
"body": "hello"
5
}
6
}
Copied!
Awesome! Just one thing you probably have noticed. We have subscribed to all rooms. Make a test: create another Room if you haven't already and add a new message to that to see that our subscription tab, with
{"roomName": "graphql"} as variables, just got this new message. How to solve this?Filters
Filters are part of Siler and based on Apollo's setup functions. Filter functions receives the published payload data as the first argument and the subscription variables as the second, so you can use them to perform matches:
subscriptions.php
1
<?php
2
3
use function Siler\{GraphQL, Ratchet};
4
5
require_once '/vendor/autoload.php';
6
7
$filters = [
8
'inbox' => function ($payload, $vars) {
9
return $payload['room_name'] == $vars['roomName'];
10
},
11
];
12
13
$schema = require_once __DIR__ . '/schema.php';
14
$manager = GraphQL\subscriptions_manager($schema, $filters);
15
16
Ratchet\graphql_subscriptions($manager)->run();
Copied!
As you can see, we have extend our Subscriptions endpoint adding filters. The filters array keys should match corresponding Subscription names, in our case:
inbox. We are just checking if the given payload room_name is the same as the provided by the Subscription variable roomName. Siler will perform this checks for each subscription before trying to resolve and broadcast them.We need just a little thing to get working. Adding this
room_name field to our payload since Message only has the room_id. At the chat resolver, before the publish, add this line:1
$message['roomName'] = $roomName; // For the inbox filter
2
GraphQL\publish('inbox', $message); // <- Exactly what "inbox" will receive
Copied!
When a
RedBeanObject is encoded to JSON it automatically converts camel case properties to underscore ones. That is why we give roomName, but receive as room_name.And that should be enough to solve our problem, now you only receive data from the subscribed rooms. Enjoy!
You can see a complete example including file uploads and directives at: github.com/leocavalcante/siler/examples/graphql.
Last modified 2yr ago
Copy link