Sangria – Scala GraphQL Implementation (opens in new tab)

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.

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.

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.

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.

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.

Also related https://github.com/tallstreet/graphql a go-lang graphql implementation.