caffql
generates c++ types and GraphQL request and response serialization logic from a GraphQL json schema file.
-s, --schema arg input json schema file
-o, --output arg output generated header file
-n, --namespace arg generated namespace (default: caffql)
-a, --absl use absl optional and variant instead of std
-h, --help help
caffql \
--schema mygraphqlschema.json \
--output GeneratedCode.hpp
Make an introspection query to your graphql endpoint and use the resulting json response as the schema
parameter to caffql
.
caffql
generates a c++ header file with types necessary to perform queries.
- c++17 for
std::optional
andstd::variant
or c++11 and Abseil forabsl::optional
andabsl::variant
- nlohmann/json for request and response serialization
caffql
will generate request and response functions for each field of the input schema's operation types (query
, subscription
, and mutation
). Currently only a single field can be queried at once.
All subfields and nested types of that field will be included in the query, i.e. there is no way to query a subset of a model. The benefits to this approach are that you don't have to handwrite any queries and the generated request and response functions are kept simple, while the drawback is that you can't omit any unwanted data.
GraphQL Type | Generated C++ Type |
---|---|
Int | int32_t |
Float | double |
String | std::string |
ID | Id (std::string typealias) |
Boolean | bool |
Enum | enum class |
Object | struct |
Interface | struct containing std::variant of possible implementations |
Union | variant of possible types |
InputObject | struct |
List | std::vector |
Nullable fields | optional |
For forwards compatibility, a special Unknown
case is generated. Enum values that the client is unaware of will be deserialized to the Unknown
case.
Interfaces are generated as struct
s with an implementation
member that is a std::variant
of the possible implementations of the interface. For each field of the interface, a member function is generated that visits the implementation
and returns the field.
An alternative approach would be to use a pure abstract class for the interface and have the implementations inherit from it. However, that approach prevents using the interface type as a simple value type (which would require implementing something like a polymorphic value-copying smart pointer).
For forwards compatibility, a special Unknown<InterfaceName>
type is generated that contains the fields of the interface. Interface implementations that the client is unaware of will deserialize to the Unknown<InterfaceName>
type.
For forwards compatibility, the generated std::variant
adds std::monostate
as a possible type to handle unknown types that the client is unaware of.