GraphQL, Ecto and Database - Three layers of data abstraction

This is a really good question, and I am also very interested in an answer. Exactly this issue (a seeming duplication between the GraphQL API and the database schemas) has prevented me from using GraphQL in my projects so far, because it seemed overkill most of the time, and I was a bit scared of trapping myself in a web of fake refactored duplication.

Maybe you can find a discussion on some of the problems you found here? Five Common Problems in GraphQL Apps (And How to Fix Them)

Phoenix contexts acknowledge that there are designs beyond CRUD. In CRUD applications the shape of the data in the page on the front end tends to dictate the shape of the data that is stored in the database. This is the hallmark of implementation coupling. Typically when you change something on one end that change ripples through to the other end (and any layers in between).

but the overlapping of three data layers - GraphQL, Ecto and Database schemas - concerns me in some way

That overlap may simply be a result of the technology being applied to an application with an “unsophisticated” domain - which wouldn’t be surprising if the entire point of the application is to clearly showcase how the technologies interact - without being obscured by complex application design concerns.

• The shape of the data in the RDBMS is largely concerned with efficient and effective storage and retrieval of data the application typically uses - clearly the inserts, updates and queries influence the shape - but there may be optimization concerns to favour the performance characteristics of certain insert, update and query operations. That means that the capabilities of the RDBMS engine are going influence the shape of the data inside the database beyond the bare needs of the application.
• Ecto brokers between the shape of the data needed by the application vs the shape of the data stored in the database. The shape of the data for the application is what you are primarily concerned with because that shape is influenced by the processing capabilities of the application.
• GraphQL should be primarily concerned with the shape of the data that is needed by the client of the application (in the spirit of Consumer Driven Contracts). The application should typically hide certain implementation details from the client to stop the client becoming coupled to the implementation details of the application. Also the application could derive (aggregate) some information that doesn’t explicitly exist in the database for the purpose of exposing it to the client via GraphQL.

Though I don’t have much to say on the subject myself, I have found this article to be an excellent read (quite comprehensive of an overview):

Will be interesting to see how things develop.

The biggest oddity I notice in the “GraphQL vs REST” conversation, is the falsehood that you must pick one.

In a world of SoA, you are likely to have multiple services, which expose multiple APIs. In the RPC vs REST article I point out that some services might be REST and some might be RPC, and you can absolutely throw some GraphQL in with your REST.

One mix of REST and GraphQL could just be adding a /graphql endpoint to api.whatever.com and having that as your GraphQL endpoint on an REST API.

Another, is one that has been vaguely tossed around at work, which is the idea of having one GraphQL API, acting as a gateway to our other multiple REST APIs.

Having one GraphQL server act as a sort of data proxy, giving one entry point for mixed data, one Authentication scheme despite each REST API having its own “unique” approach to tokens, one HTTP call for clients - despite it hitting multiple actual REST APIs, etc., would be a damn powerful thing.

I am wondering is there the same problem with https://www.apollographql.com ?
So I assume will be the best have some sort of distributed database with GraphQL functionality …
or GraphQL hosted as service … something like https://firebase.google.com/

Edited
I think there will be the same problem with apollo.
https://github.com/serverless/serverless-graphql

36063546-21c3a540-0e33-11e8-9fa4-1a1e5e9a6537.jpg1780×2922 196 KB

So in this case I prefer hosted service like firebase

I see another option

Deploy Neo4j backed GraphQL APIs based on your custom GraphQL schema.

https://www.npmjs.com/package/neo4j-graphql-cli

https://dzone.com/articles/graphql-meets-graph-database-a-graphql-neo4j-integ

What I think would be best for graphql projects is just have the database, have a graphql layer, and have both the API and Web Controllers access the GraphQL layer (so Controllers just call into the local GraphQL bit), that way it all goes through a single defined point that handles auth and all.

Yes I totally agree.
I have some hopes for Neo4j-GraphQL project or some cloud providers that would distribute it as service , maybe as competitor to google firebase.