I enjoyed Sam Newman's take on this capability [1]
> Great to see AWS providing direct data coupling as a service. /s
> This service allows you to directly map a GraphQL endpoint to a database table. It’s like putting getters and setters on an object and claiming your encapsulating private variables. The end result is coupling between GraphQL clients and the underlying datasource.
> Information hiding is a key concept in independent change. Can I change the provider (of the GraphQL) endpoint independent of the clients? Directly exposing internal data structure makes this very difficult.
And [2]:
> So a few people have asked why I have this snarky response. What is my problem with this service? Well, to be clear, it’s not an issue with GraphQL, it’s an issue with direct coupling with underlying datasources #thread
> The service as advertised makes it simple to map a GraphQL definition against a database. Now, what’s the problem with this? Well, the devil here is in the detail. But fundamentally it comes down to how important information hiding is to you.
I don't think Sam is wrong, exactly -- and that second thread does add some of the missing nuance -- but I do think there's a key missing piece here.
He's absolutely right that you shouldn't couple directly to the underlying representation. But Postgres lets you transparently define views that can be queried (and, with a little more elbow grease, updated) just like any other table. You can provide decoupling from within the database, and do so on-demand as your domain and your data model evolve.
I don't enjoy planting a separate bespoke API server on top of the database. Usually you end up lifting many of the same capabilities the database already has (auth, batching, ...) to your custom API, so a lot of the server is just boilerplate. Many API operations are natural consequences of your data model; there's little business or engineering value-add once you've settled on the latter, you're just writing glorified FFI bindings.
Lazy engineering will cause problems no matter what architectural stack you end up using. But a state-first architecture doesn't have to mean a complete loss of loose coupling -- it just means different techniques for achieving it.
I consider views and functions to be my database’s API, and when using a wrapping tool (I’ve used Hasura) I get it to use only the views in a dedicated API schema rather than the tables directly.
In addition to coupling, you want control over what tables and fields you publish.
A simple view is literally one line of SQL; it’s hardly a burden.
We could use PG views or functions to make our own abstraction layer inside the database and handle security better, etc. But putting that complicated database rebuild aside, just because we can publish GraphQL APIs from the database doesn’t mean we have to: it would be interesting to use GraphQL as a communications layer from backend to database too. Just as frontend-to-backend could use GraphQL, so too could backend-to-database communication, but with different schemas (data models) between frontend and backend. Having a backend GraphQL server between the frontend and database could allow for connection pooling, schema versioning and abstraction, for proxying multiple databases, handling business logic and perhaps validating inputs, caching or managing compute tasks.
I think that (on paper at least) it makes perfect safe to allow graphql to be your only hammer (or turtle). I don't think federating graphql over bespoke swahger/json, sql, redis, soap is inherently better - expose graphql and federated graphql:
> Great to see AWS providing direct data coupling as a service. /s
> This service allows you to directly map a GraphQL endpoint to a database table. It’s like putting getters and setters on an object and claiming your encapsulating private variables. The end result is coupling between GraphQL clients and the underlying datasource.
> Information hiding is a key concept in independent change. Can I change the provider (of the GraphQL) endpoint independent of the clients? Directly exposing internal data structure makes this very difficult.
And [2]:
> So a few people have asked why I have this snarky response. What is my problem with this service? Well, to be clear, it’s not an issue with GraphQL, it’s an issue with direct coupling with underlying datasources #thread
> The service as advertised makes it simple to map a GraphQL definition against a database. Now, what’s the problem with this? Well, the devil here is in the detail. But fundamentally it comes down to how important information hiding is to you.
> ... see the thread for more ...
[1] https://twitter.com/samnewman/status/1346541251617828877 [2] https://twitter.com/samnewman/status/1346749556583780352