Hacker News Reader

Comment by brunoc | Hacker News Reader

I feel that by using these types of tools you could really miss out on a fantastic opportunity to create a schema that models the business domain as accurately and elegantly as you want to make it, regardless of the underlying service topology or the databases behind it.

That's what I find the most attractive about GraphQL. Large companies and companies that have grown fast often have all kinds of APIs made at different time by different people with different standards. GraphQL lets you paper over that without breaking existing, revenue making code.

View on HN

I completely agree. I've posted about this before in discussions about Hasura, but I feel that all these "expose your DB as a GraphQL endpoint" are setting themselves up for a world of hurt down the road.

GraphQL is a fantastic tool to enable an API that maps extremely closely to the front end (check the spec, that is exactly what it was intended to do); instead building it so it exactly matches your DB schema is a huge mistake IMO.

Two points, if your DB schema doesn't model your domain correctly you're doing it wrong to start with. And two, views are typically used to decouple the raw database tables from whatever you want to expose to others, be those other developers or in this case external API users.

Modelling databases this way has fallen out of favour for various reasons, but it becomes extremely useful and relevant again with systems like Hasura.

What's the problem with views?

You can't insert/update/delete data in views in all cases, and they can make debugging performance more challenging, but otherwise nothing. I think they are underused.

I rarely see people using views at all, let alone using them as a test aid (composing big queries from smaller more easily tested views), or using them to define interfaces to an internal data model.

For the most part, you can insert/update/delete.

See: INSTEAD OF triggers.

That is unless you're using MySQL/MariaDB, in which case views are the least of your worries.

If you really do that, people tend to accuse you of doing RPC and not building a "true" API, because you're creating a lot of special case functions for the remote caller's business case.

That is exactly what GraphQL is designed to do. Taken straight from the spec:

> Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that.

The whole point of GraphQL is that since each client asks for exactly the fields they want, having those "special case functions" is not a problem because other clients don't need to ask for those fields.

I was speaking of higher-level abstractions than that. For instance, do you have your API allow all possible arbitrary aggregations for your data or do you only special case the 3 or 4 that are pertinent to your business model?

Doing the former leads to basically reimplementing SQL in GraphQL. Doing the latter leads to functions like `resolve_month_over_month_profit_and_loss_segemented_by_sector`.

There can be a lot in-between here. You might end up with something like `Report(type: PROFIT_AND_LOSS, unit: MONTHLY, segment: SECTOR)`

Like every tool, there's a sweet spot where it really shines and others where it doesn't fit. If you need to have access to a bunch of disparate datasources it's really nice to have that layer of abstraction.

If you want a snappy UI, you have to do this. All those extra round trips and extra data start to add up.

Reply on news.ycombinator.com