Hacker News Reader

Comment by zdragnar | Hacker News Reader

The problem with 1 model = 1 rest entity (in my experience) is that designers and users of the applications I have been building for years never want just one model on the screen.

Inevitably, once one update is done, they'll say "oh and we just need to add this one thing here" and that cycle repeats constantly.

If you have a single page front end setup, and a "RESTful" backend, you end up making a dozen or more API calls just to show everything, even if it STARTED out as narrowly focused on one thing.

I've fought the urge to use graphql for years, but I'm starting to think that it might be worth it just to force a separation between the "view" of the API and the entities that back it. The tight coupling between a single controller, model and view ends up pushing the natural complexity to the wrong layer (the frontend) instead of hiding the complexity where it belongs (behind the API).

View on HN

Why the assumption that an API endpoint should be a 1:1 mapping to a database table? There is no reason we need to force that constraint. It's perfectly legitimate to consider your resource to encompass the business logic for that use case. For example, updating a user profile can involve a single API call that updates multiple data objects - Profile, Address, Email, Phone. The UI should be concerned with "Update Profile" and let the API controller orchestrate all the underlying data relationships and updates.

You seem to be in agreement with the parent, who argues 1 model (aka database row) = 1 rest entity (aka /widgets/123) is a bad paradigm.

Different widget related front-end views will need different fields and relations (like widget prices, widget categories, user widget history and so on).

There are lots of different solutions:

- Over fetching. /widgets/123 returns not only all the fields for a widget, but more or less every possible relation. So a single API call can support any view, but with the downside that the payload contains far more data than is used by any given view. This not only increases bandwidth but usually also load on the database.

- Lots of API calls. API endpoints are tightly scoped and the front-end picks whichever endpoints are needed for a given view. One view calls /widgets/123 , /widgets/123/prices and /widgets/123/full-description. Another calls /widgets/123 and /widgets/123/categories. And so on. Every view only gets the data it needs, so no over fetching, but now we're making far more HTTP requests and more database queries.

- Tack a little "query language" onto your RESTful endpoints. Now endpoints can do something like: /widgets/123?include=categories,prices,full-description . Everyone gets what they want, but a lot of complexity is added to support this on the backend. Trying to automate this on the backend by having code that parses the parameters and automatically generates queries with the needed fields and joins is a minefield of security and performance issues.

- Ditch REST and go with something like GraphQL. This more or less has the same tradeoffs as the option above on the backend, with some additional tradeoffs from switching out the REST paradigm for the GraphQL one.

- Ditch REST and go RPC. Now, endpoints don't correspond to "Resources" (the R in rest), they are just functions that take arguments. So you do stuff like `/get-widget-with-categories-and-prices?id=123`, `/get-widget?id=123&include=categories,prices`, `/fetch?model=widget&id=123&include=categories,prices` or whatever. Ultimate flexibility, but you lose the well understood conventions and organization of a RESTful API.

After many years of doing this lots of time, I pretty much dislike all the options.

Lots of API calls scales pretty well, as long as those APIs aren't all hitting the same database. You can do them in parallel. If you really need to you can build a view specific service on the backend to do them in parallel but with shorter round-trips and perhaps shared caches, and then deliver a more curated response to the frontend.

If you just have one single monolithic database, anything clever you do on the other levels just lets you survive until the single monolithic database becomes the bottle-neck, where unexpected load in one endpoint breaks several others.

"you can do them in parallel" - not in Rails.

Well, you could do them in parallel from the client to independent endpoints.

But yeah, rails might be a bad match

Webapps are going back to multiple requests because of http2 / quic multiplexing.

This solves the problem of slow transport between your frontend and your backend, but it will still incur a lot of unnecessary load on the database as well as compute on your backend (which isn't normally a problem unless you're using something really slow like Rails).

Why? Queries would still have to be done. Yes, a few things would be duplicated (authentication), but on the other hand, queries can be cached at a more fine grained level. It's easier to cache 3 separate queries of which one can be re-used later, than to cache one monster query. s/query/response

So what do you do instead?

I do one or some combination of the options above. I've also tried some more exotic variations of things on the list like Hasura or following jsonapi.org style specs. I haven't found "the one true way" to structure APIs.

When a project is new and small, whatever approach I take feels amazing and destined to work well forever. On big legacy projects or whenever a new project gets big and popular, whatever approach I took starts to feel like a horrible mess.

Rails began that trend by auto-generating "REST" routes for 1:1 table mapping to API resource. By making that so easy, they tricked people into idealizing it

Rails' initial rise in popularity coincided with the rise of REST so these patterns spread widely and outlasted Rails' mindshare

No, it's an API Entity can be composed of sub-entities which may or may not exposed directly via API.

That's what https://guides.rubyonrails.org/association_basics.html is for.

However, Rails scaffolding is heavily geared towards that 1:1 mapping - you can make all CRUD endpoints, model and migration with a single command.

If you lean into more 1:1 mappings (not that a model can't hold FKs to submodels), then everything gets stupid easy. Not that what you're saying is hard... just if you lean into 1:1 it's _very easy_. At least for Django that's the vibe.

I have actually had a different experience. I feel like I've run into "we can't just see/edit the thing" more often than "we want another thing here" with users. Naming a report is the kiss of death. "Business Report" ends up having half the data you need, rather than just a filterable list of "transactions" for example.

However, I'm biased. A lot of my jobs have been writing "backoffice" apps, so there's usually models with a really clear identity associated to them, and usually connected to a real piece of paper like a shipment form (logistics), a financial aid application (edtech), or a kitchen ticket (restaurant POS).

Those sorts of applications I find break down with too many "Your school at a glance" sort of pages. Users just want "all the applications so I can filter to just the ones who aren't submitted yet and pester those students".

And like many sibling comments mention, Rails has some good answers for combining rest entities onto the same view in a way that still makes them distinct.

Turbo frames solves a lot of this. https://turbo.hotwired.dev/

Multiple models managed on a single page, each with their own controllers and isolated views.

Or you can do it right and use Elixir's LiveView, from which everyone is getting inspired these days.

LiveView is the brainchild of Chris McCord. He did the prototype on Rails before getting enamoured by Elixir and building Phoenix to popularize the paradigm.

LiveView is amazing and so is Phoenix but Rails has better support for building mobile apps using Hotwire Native.

Not everyone can make a dramatic switch of languages and frameworks. Turbo is excellent at what it does. Pure joy to use, replacing much of our Vue frontend.

> you end up making a dozen or more API calls just to show everything

This is fine!

> I've fought the urge to use graphql for years

Keep fighting the urge. Or give into it and learn the hard way? Either way you'll end up in the same place.

The UI can make multiple calls to the backend. It's fine.

Or you can make the REST calls return some relations. Also fine.

What you can't do is let the client make arbitrary queries into your database. Because somebody will eventually come along and abuse those APIs. And then you're stuck whitelisting very specific queries... which look exactly like REST.

GraphQL is not arbitrary queries into your database! Folks need to really quit misunderstanding that.

You can define any schema and relations you want, it's not an ORM.

In the spectrum of "remote procedure call" on one end and "insert sql here" on the other end, GraphQL is waaaaay closer to SQL than RPC.

No it’s not, graphql is an rpc that returns a tree of objects where you can indicate what part of the tree is relevant to you.

Yep. It is not trivial to make it into a pseudo-SQL language, like Hasura did.

Funny enough, see this assumption frustrating a lot of people who try to implement GraphQL APIs like this.

And even if you do turn it into a pseudo-SQL, there's still plenty of control. Libraries allow you to restrict depth, restrict number of backend queries, have a cost function, etc.

...and that's exactly the problem! Without a lot of hardening, I (a hostile client) can suck down any part of the database you make available. With just a few calls.

GraphQL is too powerful and too flexible to offer to an untrusted party.

This is a silly argument and sounds like a hot take from someone who's never used this. You could say the same about REST or whatever. It has nothing to do with "the database".

You sound like someone that's never had an adversarial client. I spent years reverse engineering other companies' web APIs. I'm also responsible for a system that processes 11 figures of financial transactions, part of which (for now) is an incredibly annoying GraphQL API that gets abused regularly.

REST calls are fairly narrowly tailored, return specific information, and it's generally easy to notice when someone is abusing them. "More like RPC".

Your naive GraphQL API, on the other hand, will let me query large chunks of your database at a time. Take a look at Shopify's GraphQL API to see the measures you need to take to harden an API; rate limits defined by the number of nodes returned, convoluted structures to handle cursoring.

GraphQL is the kind of thing that appeals to frontend folks because they can rebalance logic towards the frontend and away from the backend. It's generally a bad idea.

> Your naive GraphQL API, on the other hand, will let me query large chunks of your database at a time

No it won't, because it's not tied directly to the database and does not allow for arbitrary queries.

Any of the "aha!" gotchas you mention are the same issues as you could have with REST, JSON-API, etc.

I'm sorry you don't understand what I'm pointing out, but thanks for the convo though.

It is arbitrary queries though? I can send any query that matches your schema and your graphql engine is probably going to produce some gnarly stuff to satisfy those queries.

You need to program every query resolver yourself, it's not tied to some ORM.

There are of course products that do this automatically, but it's not really that simple. There's a reason things like Hasura are individual products.

No when I say "schema" I mean the GraphQL structure, not your DB schema.

The GraphQL structure can be totally independent from your DB if need be, and (GraphQL) queries on those types via API can resolve however you need and are defined by you. It's not a SQL generator.

The problem is not that you'll expose some part of the database you shouldn't (which is a concern but it's solvable). The problem is that you expose the ability for a hostile client to easily suck down vast swaths of the part of the database you do expose.

How is this different from REST?

Generally, REST calls are narrowly tailored with a simple contract; there are some parameters in and some specific data out. This tends to be easy to secure, has consistent performance and load behavior, and shows up in monitoring tools when someone starts hammering it.

On the other hand, unless you've put some serious work into hardening, I can craft a GraphQL query to your system that will produce way more data (and way more load) than you would prefer.

A mature GraphQL web API (exposed to adversaries) ends up whitelisting queries. At which point it's no better than REST. Might as well just use REST.

I think the OP is possibly confusing GraphQL with an ORM like Active Record. You are correct that you don't accidentally "expose" any more data than you do with REST or some other APIs. It's just a routing and payload convention. GraphQL schema and types don't have to be 1:1 with your DB or ActiveRecord objects at all.

(I'm not aware of any, but if there are actually gems or libraries that do expose your DB to GraphQL this way, that's not really a GraphQL issue)

This is a very common pattern and one that’s been solved in Rails by building specialized controllers applying the CRUD interface to multiple models.

Like the Read for a dashboard could have a controller for each dashboard component to load its data or it could have one controller for the full dashboard querying multiple models - still CRUD.

The tight coupling is one of many approaches and common enough to be made default.

The Rails support for multi-model, nested form updates is superb.

Separate entities on the backend - a unified update view if that’s what’s desired.

No need for any outside dependencies.

You can separate the view and the backend storage without going graphql. You can build your API around things that make sense on a higher level, like "get latest N posts in my timeline" and let the API endpoint figure out how to serve that

It's seemingly more work than graphql as you need to actually intentionally build your API, but it gets you fewer, more thought-out usage patterns on the backend that are easier to scale.

You should checkout phoenix liveview. you can maintain a stateful process on the server that pushes state changes to the frontend. its a gamechanger if you're building a webapp.

https://www.youtube.com/watch?v=aOk67eT3fpg&ab_channel=Theo-...

This may be a misunderstanding on my part, but something that’s kept me away from GraphQL is how it makes for a hard dependency on GraphQL client libraries in clients. I find that very unappealing, it’s nicer to be able to e.g. just use platform/language provided networking and JSON decoding (e.g. URLSession + Swift Codable on iOS) and keep the dependency list that much shorter.

> If you have a single page front end setup, and a "RESTful" backend

Rails really doesn't encourage this architecture, quite the opposite in fact.

> designers and users of the applications I have been building for years never want just one model on the screen.

... and this is where Rails excels. When you need to pull in some more data for a screen you just do it. Need to show the most recent reviews of a product in your e-commerce backend? It's probably as simple as:

    <%= render @product.reviews.order(created_at: :desc).limit(5) %>

Of course this can have the opposite problem of bloated views taking forever to load, but Rails has lots of caching goodies to mitigate that.

---

Going back to the GP post

> Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity"

That's definitely the simple path, but there are very few constraints on what you can do.

Graphql is nice but there are all sorts of weird attacks and edge cases because you don't actually control the queries that a client can send. This allows a malicious client to craft really time expensive queries.

So you end up having to put depth and quantity limits, or calculating the cost of every incoming query before allowing it. Another approach I'm aware of is whitelisting but that seems to defeat the entire point.

I use rest for new projects, I wouldn't say never to graphql, but it brings a lot of initial complexity.

I don't understand why you consider this to be a burden. The gateway will calculate the depth / quantities of any query for you, so you're just setting a config option. When you create a REST API, you're making similar kinds of decisions, except you're baking them bespokely into each API.

Query whitelisting makes sense when you're building an API for your own clients (whom you tightly control). This is the original and most common usecase for graphql, though my personal experience is with using it to provide 3rd party APIs.

It's true that you can't expect to do everything identically to how you would have done it with REST (authz will also be different), but that's kind of the point.

A malicious user who had the knowledge and ability to craft expensive GraphQL queries could just as easily use that knowledge to tie your REST API in knots by flooding it with fake requests. Some kind of per-user quota system is going to be required either way.

Isn’t this there bff stacks show their worth? As in those nextjs apps that sit between react and rails?

Not really, then you're just shifting the complexity from the front-end back to a middle man. Now it still exists, and you still have all the network traffic slowing things down, but it lives in its own little service that your rails devs aren't going to bother thinking about or looking at optimizing.

Much better to just do that in rails in the first place.

Reply on news.ycombinator.com