
Sangria – Scala GraphQL Implementation - kolev
http://sangria-graphql.org/
======
eranation
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
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.

~~~
nicolewhite
"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-
introduction.html)

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

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

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

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

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

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

------
morenoh149
related [https://github.com/joshprice/graphql-
elixir](https://github.com/joshprice/graphql-elixir) an elixir implementation
of graphql I've been watching

~~~
gaz
Also related
[https://github.com/tallstreet/graphql](https://github.com/tallstreet/graphql)
a go-lang graphql implementation.

