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