GraphQL provides typesafe API access through the schema definition each server provides through introspection. Sailor leverages that information to enable an ergonomic workflow and reduce type-related bugs in your code.
The native GraphQL query language is the most universally used tool to formulate GraphQL queries and works natively with the entire ecosystem of GraphQL tools. Sailor takes the plain queries you write and generates executable PHP code, using the server schema to generate typesafe operations and results.
Install Sailor through composer by running:
composer require spawnia/sailor
If you want to use the built-in default Client (see Client implementations):
composer require guzzlehttp/guzzle
If you want to use the PSR-18 Client and don't have PSR-17 Request and Stream factory implementations (see Client implementations):
composer require nyholm/psr7
Run vendor/bin/sailor
to set up the configuration.
A file called sailor.php
will be created in your project root.
You can take a look at the example configuration to see what options
are available for configuration: sailor.php
.
If you would like to use multiple configuration files, specify which file
to use through the -c/--config
option.
It is quite useful to include dynamic values in your configuration.
You might use PHP dotenv to load
environment variables (run composer require vlucas/phpdotenv
if you do not have it installed already.).
# sailor.php
+$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
+$dotenv->load();
...
public function makeClient(): Client
{
return new \Spawnia\Sailor\Client\Guzzle(
- 'https://hardcoded.url',
+ getenv('EXAMPLE_API_URL'),
[
'headers' => [
- 'Authorization' => 'hardcoded-api-token',
+ 'Authorization' => getenv('EXAMPLE_API_TOKEN'),
],
]
);
}
Sailor provides a few built-in clients:
Spawnia\Sailor\Client\Guzzle
: Default HTTP clientSpawnia\Sailor\Client\Psr18
: PSR-18 HTTP clientSpawnia\Sailor\Client\Log
: Used for testing
You can bring your own by implementing the interface Spawnia\Sailor\Client
.
You can configure clients dynamically for specific operations or per request:
use Example\Api\Operations\HelloSailor;
/** @var \Spawnia\Sailor\Client $client Somehow instantiated dynamically */
HelloSailor::setClient($client);
// Will use $client over the client from EndpointConfig
$result = HelloSailor::execute();
// Reverts to using the client from EndpointConfig
HelloSailor::setClient(null);
Custom scalars are commonly serialized as strings. Without knowing about the contents of the type,
Sailor can not do any conversions or provide more accurate type hints, so it uses string
.
Enums are only supported from PHP 8.1. Many projects simply used scalar values or an implementation that approximates enums through some kind of value class. Sailor is not opinionated and generates enums as a class with string constants and does no conversion - useful but not perfect. For an improved experience, it is recommended to customize the enum generation/conversion.
Overwrite EndpointConfig::configureTypes()
to specialize how Sailor deals with the types within your schema.
See examples/custom-types.
Errors sent within the GraphQL response must follow the response errors specification.
Sailor converts the plain stdClass
obtained from decoding the JSON response into
instances of \Spawnia\Sailor\Error\Error
by default.
If one of your endpoints returns structured data in extensions
, you can customize how
the plain errors are decoded into class instances by overwriting EndpointConfig::parseError()
.
Run vendor/bin/sailor introspect
to update your schema with the latest changes
from the server by running an introspection query. As an example, a very simple
server might result in the following file being placed in your project:
# schema.graphql
type Query {
hello(name: String): String
}
Put your queries and mutations into .graphql
files and place them anywhere within your
configured project directory. You are free to name and structure the files in any way.
Let's query the example schema from above:
# src/example.graphql
query HelloSailor {
hello(name: "Sailor")
}
You must give all your operations unique names, the following example is invalid:
# Invalid, operations have to be named
query {
anonymous
}
# Invalid, names must be unique across all operations
query Foo { ... }
mutation Foo { ... }
Run vendor/bin/sailor
to generate PHP code for your operations.
For the example above, Sailor will generate a class called HelloSailor
,
place it in the configured namespace and write it to the configured location.
namespace Example\Api\Operations;
class HelloSailor extends \Spawnia\Sailor\Operation { ... }
There are additional generated classes that represent the results of calling the operations. The plain data from the server is wrapped up and contained within those value classes, so you can access them in a typesafe way.
You are now set up to run a query against the server,
just call the execute()
function of the new query class:
$result = \Example\Api\Operations\HelloSailor::execute();
The returned $result
is going to be a class that extends \Spawnia\Sailor\Result
and
holds the decoded response returned from the server. You can just grab the $data
, $errors
or $extensions
off of it:
$result->data // `null` or a generated subclass of `\Spawnia\Sailor\ObjectLike`
$result->errors // `null` or a list of `\Spawnia\Sailor\Error\Error`
$result->extensions // `null` or an arbitrary map
You can ensure your query returned the proper data and contained no errors:
$errorFreeResult = \Example\Api\Operations\HelloSailor::execute()
->errorFree(); // Throws if there are errors or returns an error free result
If you don't need any data, but want to ensure a mutation succeeded:
\Example\Api\Operations\SomeMutation::execute()
->assertErrorFree(); // Throws if there are errors
Your generated operation classes will be annotated with the arguments your query defines.
class HelloSailor extends \Spawnia\Sailor\Operation
{
public static function execute(string $required, ?\Example\Api\Types\SomeInput $input = null): HelloSailor\HelloSailorResult { ... }
}
Inputs can be built up incrementally:
$input = new \Example\Api\Types\SomeInput;
$input->foo = 'bar';
If you are using PHP 8, instantiation with named arguments can be quite useful to ensure your input is completely filled:
\Example\Api\Types\SomeInput::make(foo: 'bar')
GraphQL often uses a pattern of partial inputs - the equivalent of an HTTP PATCH
.
Consider the following input:
input SomeInput {
requiredId: Int!,
firstOptional: Int,
secondOptional: Int,
}
Suppose we allow instantiation in PHP with the following implementation:
class SomeInput extends \Spawnia\Sailor\ObjectLike
{
public static function make(
int $requiredId,
?int $firstOptional = null,
?int $secondOptional = null,
): self {
$instance = new self;
$instance->requiredId = $required;
$instance->firstOptional = $firstOptional;
$instance->secondOptional = $secondOptional;
return $instance;
}
}
The following call:
SomeInput::make(requiredId: 1, secondOptional: 2);
Should produce the following JSON payload:
{ "requiredId": 1, "secondOptional": 2 }
However, from within make()
there is no way to differentiate between an explicitly
passed optional named argument and one that has been assigned the default value.
Thus, the resulting JSON payload will unintentionally modify firstOptional
too, erasing
whatever value it previously held.
{ "requiredId": 1, "firstOptional": null, "secondOptional": 2 }
A naive solution to this would be to filter out any argument that is null
.
However, we would also like to be able to explicitly set the first optional value to null
.
The following call should result in the previous JSON payload.
SomeInput::make(requiredId: 1, firstOptional: null, secondOptional: 2);
In order to generate partial inputs by default, optional named arguments have a special default value:
Spawnia\Sailor\ObjectLike::UNDEFINED = 'Special default value that allows Sailor to differentiate between explicitly passing null and not passing a value at all.';
class SomeInput extends \Spawnia\Sailor\ObjectLike
{
/**
* @param int $requiredId
* @param int|null $firstOptional
* @param int|null $secondOptional
*/
public static function make(
$requiredId,
$firstOptional = 'Special default value that allows Sailor to differentiate between explicitly passing null and not passing a value at all.',
$secondOptional = 'Special default value that allows Sailor to differentiate between explicitly passing null and not passing a value at all.',
): self {
$instance = new self;
if ($requiredId !== self::UNDEFINED) {
$instance->requiredId = $requiredId;
}
if ($firstOptional !== self::UNDEFINED) {
$instance->firstOptional = $firstOptional;
}
if ($secondOptional !== self::UNDEFINED) {
$instance->secondOptional = $secondOptional;
}
return $instance;
}
}
In the unlikely case where you need to pass exactly this value, you can assign it directly:
$input = SomeInput::make(requiredId: 1);
$input->secondOptional = Spawnia\Sailor\ObjectLike::UNDEFINED;
Sailor calls EndpointConfig::handleEvent()
with the following events during the execution lifecycle:
- StartRequest: Fired after calling
execute()
on anOperation
, before invoking the client. - ReceiveResponse: Fired after receiving a GraphQL response from the client.
Since GraphQL uses a different set of reserved keywords, names of fields or types may collide with PHP keywords.
Sailor prevents illegal usages of those names in generated code by prefixing them with a single underscore _
.
Sailor provides first class support for testing by allowing you to mock operations.
It is assumed you are using PHPUnit and Mockery.
composer require --dev phpunit/phpunit mockery/mockery
Make sure your test class - or one of its parents - uses the following traits:
use Mockery\Adapter\Phpunit\MockeryPHPUnitIntegration;
use PHPUnit\Framework\TestCase as PHPUnitTestCase;
use Spawnia\Sailor\Testing\UsesSailorMocks;
abstract class TestCase extends PHPUnitTestCase
{
use MockeryPHPUnitIntegration;
use UsesSailorMocks;
}
Otherwise, mocks are not reset between test methods, you might run into very confusing bugs.
Mocks are registered per operation class:
/** @var \Mockery\MockInterface&\Example\Api\Operations\HelloSailor */
$mock = \Example\Api\Operations\HelloSailor::mock();
When registered, the mock captures all calls to HelloSailor::execute()
.
Use it to build up expectations for what calls it should receive and mock returned results:
$hello = 'Hello, Sailor!';
$mock
->expects('execute')
->once()
->with('Sailor')
->andReturn(HelloSailorResult::fromData(
HelloSailor\HelloSailor::make($hello),
));
$result = HelloSailor::execute('Sailor')->errorFree();
self::assertSame($hello, $result->data->hello);
Subsequent calls to ::mock()
will return the initially registered mock instance.
$mock1 = HelloSailor::mock();
$mock2 = HelloSailor::mock();
assert($mock1 === $mock2); // true
You can also simulate a result with errors:
HelloSailorResult::fromErrors([
(object) [
'message' => 'Something went wrong',
],
]);
For PHP 8 users, it is recommended to use named arguments to build complex mocked results:
HelloSailorResult::fromData(
HelloSailor::make(
hello: 'Hello, Sailor!',
nested: HelloSailor\Nested::make(
hello: 'Hello again!',
)
)
))
If you want to perform integration testing for a service that uses Sailor without actually
hitting an external API, you can swap out your client with the Log
client.
It writes all requests made through Sailor to a file of your choice.
The
Log
client can not know what constitutes a valid response for a given request, so it always responds with an error.
# sailor.php
public function makeClient(): Client
{
return new \Spawnia\Sailor\Client\Log(__DIR__ . '/sailor-requests.log');
}
Each request goes on a new line and contains a JSON string that holds the query
and variables
:
{"query":"{ foo }","variables":{"bar":42}}
{"query":"mutation { baz }","variables":null}
This allows you to perform assertions on the calls that were made.
The Log
client offers a convenient method of reading the requests as structured data:
$log = new \Spawnia\Sailor\Client\Log(__DIR__ . '/sailor-requests.log');
foreach ($log->requests() as $request) {
var_dump($request);
}
array(2) {
["query"]=>
string(7) "{ foo }"
["variables"]=>
array(1) {
["bar"]=>
int(42)
}
}
array(2) {
["query"]=>
string(7) "mutation { baz }"
["variables"]=>
NULL
}
To clean up the log after performing tests, use Log::clear()
.
You can find examples of how a project would use Sailor within examples.
See CHANGELOG.md
.
See CONTRIBUTING.md
.
This package is licensed using the MIT License.