5 ms·

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 databa

by 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]
tenshi47 11y ago
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.

by Ciantic 11y ago

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]

tenshi47 11y ago

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.