I’ve recently been exploring Facebook’s GraphQL and I love the way it lets the client specify what it wants in a response in a concise and elegant way. It seems like a great alternative to REST. In many ways GraphQL seems like a good match with ServiceStack with its strongly typed message based philosophy. There are some big differences too and I’m not sure how the two might integrate. @mythz, what are you thoughts on GraphQL and would you see in future for it in ServiceStack? Perhaps the ability to create a GraphQL endpoint similar to how an AutoQuery endpoint can be created now?
There hasn’t been any interest in it until your feature request, not expecting this to be popular in .NET anytime soon, if at all. Looks like it’s better suited to JS / dynamic languages.
I’m not a fan of high-level / untyped / db-agnostic query languages. I personally like my Data API’s that are a thin typed POCO API over the data store they’re abstracting making it possible to easily take advantages of the underlying data store features, it’s also easier to understand how it works if the API is a 1:1 mapping. My preference is for data store API’s to return clean typed POCO’s, which are better suited in C# letting you take advantage of all the reflection utils available for POCO’s whilst also providing metadata/serialization for free and making caching easier/possible.
My prediction is that it’s never going to be popular in .NET, if I see it gaining popularity and providing a lot of value over existing methods I’ll take another look then.
Thanks for the feedback–I guess we’ll have to see if it catches on. Just to clarify however, GraphQL is NOT untyped–it requires schema definition on the server. In my view, it’s a better fit for static typing than for dynamic languages. See this from the Facebook’s disucssion “It [GraphXL] is especially useful in statically typed languages such as Swift, Objective-C and Java [and I would add .NET languages], as it obviates the need for repetitive and error-prone code to shuffle raw, untyped JSON into strongly-typed business objects.” (just like ServiceStack does)
I agree on POCOs. A GraphQL client/server implementation that mapped to strongly typed POCOs on each end and used the GraphQL in the middle is exactly what I’d be looking for. What I like about GraphQL is the ability to specify the exact object graph I want on the client side and get it all back in one call.
Abstraction away from the data store is ok for me because I want to use web services/GraphQL to map my mobile client view models to my server side domain models (with their business/validation logic) not directly to my data store anyway.
And I love that my domain models can evolve to some degree without breaking my older clients. ServiceStack let’s me do this too–but what it lacks is the ability for the client to specify exactly what it wants in a call. Especially if what it wants may span several layers deep into my object graph. To do this with ServiceStack now, I either have to build very specific request/responses for each use case–or I have to use multiple calls. The first option clutters my server API making it difficult to maintain and the second is less performant.
This would imply the client is requesting a custom schema at runtime, i.e. if it’s specified on the client it’s not going to be a Type the server knows about.
I don’t see an explicit service boundary here, it doesn’t look like valid JSON so it’s just posting a blob of free-text to an endpoint. Then how can the server apply business logic/validation/auhtorization/etc to a request it doesn’t know about? i.e. Who’s going to responsible for intercepting this request, parsing the query, translating it to multiple db calls, orchestrating the response into the requested schema? a db driver or a service implementation? This looks like a worse version of OData all over again (at least OData documented the service boundary). I also don’t expect caching a free-text query with in-line params to be very useful.
IMO there’s too many moving parts with impedance mismatches, only way I really see it working is someone creates a GraphQL DB and the client talks directly to it, similar to what Meteor does by allowing querying of MongoDB collections on the client.
To me the GraphQL schema is a graph of DTOs that defines the service boundary. Clients may select from a subset of what the server exposes–but the available Types and their hierarchy are always defined at the server. This seems similar to the ServiceStack request/response model. I see this as an alternative to REST as a way of organizing the services. The advantage being that the client can get (or set) what it needs (and only what it needs) in one call. The actual service implementation would still be responsible for responding to the request graph and populating the response graph (dispatching DB or document store calls, etc…), just like now the service implementation receives a request and populates the response. This could happen through an ORM (like ORMLite), or an entirely different method. Thanks for taking time to look at this. I’m happy with ServiceStack and respect your judgment here when you say it’s not a good fit. GraphQL is a young technology. Time will tell if it really fills a need.
I understand it’s an old subject but what is your opinion now 4 years later.
I believe AutoQuery still do a fantastic job.
I haven’t spent any time thinking about GraphQL since, can’t say I’ve seen it gain any traction in .NET either.
This looks like the intro docs for GraphQL .NET and I struggle to see how this is supposed to provide a superior development model:
https://graphql-dotnet.github.io/docs/getting-started/introduction