This works similar to http://graphql.org/ - however, once you start filtering relationships things are looking slightly different. For instance, to filter a product with related shipments, we currently need to use the resource keys of each resource to map their filtered fields, like this:
This is the only place in the package we actually use resource keys except for access in the serializers and while it makes sense that shipments is the resource key of the shipments-relationship, it is not so much obvious that the product is mapped to products and not product.
The above form is how Fractal expects the filtered fields, but I believe we can do better and should allow for a more GraphQL-inspired syntax:
I realise most use cases for filtering fieldsets is dynamically through a query string parameter, and then you wouldn't format it in the response either way. However, this might still be wanted in some use cases and makes it a bit more intuitive. The products resource key is still present in the query string:
GET /products?with=shipments&only[products]=id,name&only[shipments]=id
I'm still exploring ideas on how to make that more intuitive as well.
By using the
only
method, the package allows for filtering fields:This works similar to http://graphql.org/ - however, once you start filtering relationships things are looking slightly different. For instance, to filter a product with related shipments, we currently need to use the resource keys of each resource to map their filtered fields, like this:
This is the only place in the package we actually use resource keys except for access in the serializers and while it makes sense that
shipments
is the resource key of the shipments-relationship, it is not so much obvious that the product is mapped toproducts
and notproduct
.The above form is how Fractal expects the filtered fields, but I believe we can do better and should allow for a more GraphQL-inspired syntax:
I realise most use cases for filtering fieldsets is dynamically through a query string parameter, and then you wouldn't format it in the response either way. However, this might still be wanted in some use cases and makes it a bit more intuitive. The
products
resource key is still present in the query string:I'm still exploring ideas on how to make that more intuitive as well.