5 ms·

Sangria – Scala GraphQL Implementation

105 points by kolev 11y ago

eranation 11y ago
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?
- tristanz 11y ago
  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.
  - eranation 11y ago
    Ah... Lots of promise in the name though :) I was optimistic.
    - ci5er 11y ago
      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)
  - whazor 11y ago
    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.
    - phpnode 11y ago
      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.
  - nicolewhite 11y ago
    "It is a query language for graph data..." is directly from their description. https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html https://facebook.github.io/react/blog/2015/05/01/graphql-int...
    - tristanz 11y ago
      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 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.
morenoh149 11y ago
related https://github.com/joshprice/graphql-elixir https://github.com/joshprice/graphql-elixir an elixir implementation of graphql I've been watching
- gaz 11y ago
  Also related https://github.com/tallstreet/graphql https://github.com/tallstreet/graphql a go-lang graphql implementation.
Ciantic 11y ago
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.
- ddispaltro 11y ago
  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.
  - Ciantic 11y ago
    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.
    - 15155 11y ago
      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.
    - leebyron 11y ago
      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.
- deleted 11y ago
  [deleted]
graffitici 11y ago
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..
vimes656 11y ago
Is this using the Facebook GraphQL C bindings? If not, what's the advantage of a full reimplementation in Scala? 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.
- tel 11y ago
  Portability and easier compilation.
- tenshi47 11y ago
  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.
- leebyron 11y ago
  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.

105 points by kolev 11y ago

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?

tristanz 11y ago
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.
- eranation 11y ago
  Ah... Lots of promise in the name though :) I was optimistic.
  - ci5er 11y ago
    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)
- whazor 11y ago
  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.
  - phpnode 11y ago
    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.
- nicolewhite 11y ago
  "It is a query language for graph data..." is directly from their description. https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html https://facebook.github.io/react/blog/2015/05/01/graphql-int...
  - tristanz 11y ago
    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 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.

morenoh149 11y ago

related https://github.com/joshprice/graphql-elixir https://github.com/joshprice/graphql-elixir an elixir implementation of graphql I've been watching

gaz 11y ago
Also related https://github.com/tallstreet/graphql https://github.com/tallstreet/graphql a go-lang graphql implementation.

Ciantic 11y ago

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.

ddispaltro 11y ago
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.
- Ciantic 11y ago
  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.
  - 15155 11y ago
    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.
  - leebyron 11y ago
    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.
deleted 11y ago
[deleted]

graffitici 11y ago

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..

vimes656 11y ago

Is this using the Facebook GraphQL C bindings? If not, what's the advantage of a full reimplementation in Scala? 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.

tel 11y ago
Portability and easier compilation.
tenshi47 11y ago
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.
leebyron 11y ago
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.