Sangria – Scala GraphQL Implementation(sangria-graphql.org)
sangria-graphql.org
Sangria – Scala GraphQL Implementation
http://sangria-graphql.org/
22 comments
In contrast to some other languages, it's not common in JVM community to use native (platform dependent libraries written in c, c++, assenbly, etc.) libraries. I only saw examples of it for code that tightly integrates with the host hardware (e.g. directly uses drivers of some uncommon hardware devices) or other similar scenarios, where you generally don't have other choice but use native libraries.
I think main reasons for this are platform independence and ease of building/packaging/deployment. Also JDK (standard library) and library ecosystem are strong enough to provide pure jvm-based library implementations for most of the scenarios. JVM performance is also pretty good, so there is no necessity to write/use native libraries just to make application more performant.
I think main reasons for this are platform independence and ease of building/packaging/deployment. Also JDK (standard library) and library ecosystem are strong enough to provide pure jvm-based library implementations for most of the scenarios. JVM performance is also pretty good, so there is no necessity to write/use native libraries just to make application more performant.
Portability and easier compilation.
The libgraphqlparser project only provides C bindings for a GraphQL language parser but not an query runner or validator which often have differing APIs to feel natural in each language. Sangria implements query running as well.
I think this is trying to be a DB agnostic, but I don't think it's a good way to approach this.
One reason is that you have to have a schema defined for database already e.g. using Slick, it should be reusable for GraphQL schema as is. Having same schema defined several times is pain.
One reason is that you have to have a schema defined for database already e.g. using Slick, it should be reusable for GraphQL schema as is. Having same schema defined several times is pain.
GraphQL (and falcor) was created for exactly this reason, combining data from disparate sources, making it easy to get what you want from the frontend.
I know, and in front-end they are great, I was talking about this implementation from back-end point of view in Scala.
This implementation requires one to write schema, that is in many ways (maybe fully) identical to your database schema e.g. Slick schema thus you have to write it twice. It would be a better to infer the GraphQL schema from Slick/database schema.
This implementation requires one to write schema, that is in many ways (maybe fully) identical to your database schema e.g. Slick schema thus you have to write it twice. It would be a better to infer the GraphQL schema from Slick/database schema.
In practice, it's actually pretty rare for a GraphQL schema (exposed to clients) to be identical to a database schema which often has admin-only columns or database-specific idiosyncrasies like SQL join tables that you would opt to expose differently to a client.
That being said, there's a lot of low hanging fruit for building a GraphQL schema "generator" libraries for various backing databases - while some things are likely to change, it's quite nice to just apply those edits rather than building up a near-parallel schema again.
That being said, there's a lot of low hanging fruit for building a GraphQL schema "generator" libraries for various backing databases - while some things are likely to change, it's quite nice to just apply those edits rather than building up a near-parallel schema again.
For me, one of the best features of GraphQL is that you're able to completely hide/abstract away non-domain-models such as join tables.
There is no reason why sangria (or any other server GraphQL implementation) can't integrate with libraries like Slick or directly with RDBMS schema. Sangria is designed to be a low-level library that provides a set of building blocks for schema definition, query parsing, validation and execution. These building blocks can be used directly - there is a small DSL layer that makes it easier to compose all these building blocks directly. But they also can be used/generated by some third-party library, which can generate schema and `resolve` functions based on different model like RDBMS schema, Slick mappings, etc. I hope in future me and people will create these integration libraries for scala that are based on sangria. We already see it happening in nodejs community, where people are making early experiments with postgres and mongo backends for GraphQL server.
On the other hand, I would argue that it can be advantageous to have a separate model which is exposed through a public API:
1. GraphQL has `description` fields on all entities like types, fields, enum values, etc. This documentation can be retrieved via introspection API. Its not always possible to extract this information from other models, like object-relation mappings.
2. Being datasource agnostic on a low level gives sangria and it's users much more flexibility in terms of where and how they fetch data. This still has a room for integration with other libraries. For example, I can imagine scenario where part of schema is generated based on the Slick mappings, some other part is hand-written and yet another part of it is generated based on swagger/raml service definition (this part of schema will fetch data from some external REST service).
3. Data model evolves over time. Tight coupling between internal data model and publicly exposed model can look reasonable at the beginning of the project, but can become very frustrating over the time. By decoupling these two models from each other you allow them to age and evolve independently. Public API has much more strict requirements when it comes to change. Because of this GraphQL includes the concept of deprecation - you can deprecate fields and enum values. Deprecated fields and values will not show up in the introspection results unless you explicitly asked for it.
4. GraphQL also includes data mutation. While it can be possible to generate the read model from, let's say, Slick mappings, I don't think it would be a good idea to do the same for a write model. GraphQL allows you to define two different models for reads and writes (`Schema` takes mandatory query `Type` and optional mutation `Type` as an argument). I would say that GraphQL has more in common with CQRS (Command Query Responsibility Segregation) rather than CRUD (create, read, update and delete) model. Considering this, I would say that it is advantageous to put careful attention to a write model modeling and model it independently from a read model.
On the other hand, I would argue that it can be advantageous to have a separate model which is exposed through a public API:
1. GraphQL has `description` fields on all entities like types, fields, enum values, etc. This documentation can be retrieved via introspection API. Its not always possible to extract this information from other models, like object-relation mappings.
2. Being datasource agnostic on a low level gives sangria and it's users much more flexibility in terms of where and how they fetch data. This still has a room for integration with other libraries. For example, I can imagine scenario where part of schema is generated based on the Slick mappings, some other part is hand-written and yet another part of it is generated based on swagger/raml service definition (this part of schema will fetch data from some external REST service).
3. Data model evolves over time. Tight coupling between internal data model and publicly exposed model can look reasonable at the beginning of the project, but can become very frustrating over the time. By decoupling these two models from each other you allow them to age and evolve independently. Public API has much more strict requirements when it comes to change. Because of this GraphQL includes the concept of deprecation - you can deprecate fields and enum values. Deprecated fields and values will not show up in the introspection results unless you explicitly asked for it.
4. GraphQL also includes data mutation. While it can be possible to generate the read model from, let's say, Slick mappings, I don't think it would be a good idea to do the same for a write model. GraphQL allows you to define two different models for reads and writes (`Schema` takes mandatory query `Type` and optional mutation `Type` as an argument). I would say that GraphQL has more in common with CQRS (Command Query Responsibility Segregation) rather than CRUD (create, read, update and delete) model. Considering this, I would say that it is advantageous to put careful attention to a write model modeling and model it independently from a read model.
[deleted]
A naive question here. (I'm in a bar and didn't fully read the docs): how can I leverage GraphQL (or sangria in specific) to existing graph databases / computation engines. Namely: is there a way to implement a GraphQL adapter for GraphX (Spark's graph library) or Titan / Neo4j?
From a first glance GraphQL looks better than Gremlin (no offense)
Can I treat GraphQL as going toward being a "better tinker pop"? If not than what are the use cases for GraphQL in the context of existing graph databases?
Can I treat GraphQL as going toward being a "better tinker pop"? If not than what are the use cases for GraphQL in the context of existing graph databases?
No. They're basically totally unrelated despite the name. GraphQL is a way to build and query a typed API that exposes nested resources. It's an alternative to REST. There is no graph computation happening. I'd view it as a more flexible version of REST with types.
"It is a query language for graph data..." is directly from their description.
https://facebook.github.io/react/blog/2015/05/01/graphql-int...
https://facebook.github.io/react/blog/2015/05/01/graphql-int...
Yeah, except if you look closely at what GraphQL actually is that description is very misleading.
The spec has a better description: https://facebook.github.io/graphql/#sec-Overview
" GraphQL is a query language designed to build client applications by providing an intuitive and flexible syntax and system for describing their data requirements and interactions.
GraphQL is not a programming language capable of arbitrary computation, but is instead a language used to query application servers that have capabilities defined in this specification. GraphQL does not mandate a particular programming language or storage system for application servers that implement it. Instead, application servers take their capabilities and map them to a uniform language, type system, and philosophy that GraphQL encodes. This provides a unified interface friendly to product development and a powerful platform for tool‐building."
This is very different goal that most graph query languages.
The spec has a better description: https://facebook.github.io/graphql/#sec-Overview
" GraphQL is a query language designed to build client applications by providing an intuitive and flexible syntax and system for describing their data requirements and interactions.
GraphQL is not a programming language capable of arbitrary computation, but is instead a language used to query application servers that have capabilities defined in this specification. GraphQL does not mandate a particular programming language or storage system for application servers that implement it. Instead, application servers take their capabilities and map them to a uniform language, type system, and philosophy that GraphQL encodes. This provides a unified interface friendly to product development and a powerful platform for tool‐building."
This is very different goal that most graph query languages.
Why not? Maybe it is not possible currently, but what stops me from creating a graph databases optimised for these types of queries?
Currently a lot of research is being done on graph databases, and they can be potentially faster for queries that normally take a lot of joins.
Currently a lot of research is being done on graph databases, and they can be potentially faster for queries that normally take a lot of joins.
Nothing stops you from integrating GraphQL with your graph database and I know that people are already working on it.
But it isn't a way to specify graph queries, e.g. you can't express concepts like "find the shortest path from vertex A to vertex B using edges with the given label". It's just not designed for that kind of thing.
But it isn't a way to specify graph queries, e.g. you can't express concepts like "find the shortest path from vertex A to vertex B using edges with the given label". It's just not designed for that kind of thing.
Ah...
Lots of promise in the name though :)
I was optimistic.
It's very neat stuff (it saves on multiple round trips to collect just what your UI needs right now), but GraphQL isn't about graphs (although one of my primary use cases does use an underlying graph database), just like React isn't reactive.
I think Facebook's naming people do this on purpose. (j/k)
I think Facebook's naming people do this on purpose. (j/k)
related https://github.com/joshprice/graphql-elixir an elixir implementation of graphql I've been watching
Also related https://github.com/tallstreet/graphql a go-lang graphql implementation.
Excellent package! Speaks very highly of code quality in the Scala ecosystem. It's documentation also seems far superior than that of Scala, the language, or the Play framework. I wish they get to improve those as well..
I'm not implying that the bindings should have been used. I'm now considering writing a implementation of GraphQL in Haskell and I'm trying to assess whether it's worth using the Facebook C bindings or it's better to implement the whole protocol from scratch.