Comment by lewisl9029 | Hacker News Reader

Comment by lewisl9029 | Hacker News Reader

Parent Full thread

> Why does the idea of having frontend guys directly query the db without any kind of interface scares me ?

I don't think giving frontend a direct path to the db is what the talk is advocating.

You still need a backend in front of the db, even in the special case of using Datomic as the db, to handle things like auth. The difference seems to be that instead of having the backend serve a messy web of REST endpoints for the clients to consume and compose individually, the backend would serve a single endpoint that can speak this new query language. The client can then declaratively request exactly the data it needs in the shape that it needs it in, eliminating an overwhelming majority of network related boilerplate on both the backend and client.

I'm personally extremely excited to see this become mainstream. So much of the front-end code I write on a day-to-day basis involves fetching data from various endpoints and shaping it into a logical structure for my components to display. It's tedious work that provides no intrinsic value. I can't wait to not have to write any more of that and focus my time on solving actual problems.

How does caching work in this scenario? Caching REST responses is fairly straightforward but caching arbitrarily complex queries to a single endpoint seems much more difficult.

Sorry if he answers this in his talk. I haven't had a chance to watch it yet.

I'm not familiar with the approach either, but the video mentioned that you would mainly execute these queries using a client side library. The library would be backend agnostic, and offer remote sync capabilities.

So I believe you can set the primary backend for the library to a local, in-memory data-structure to serve as the local cache, and have the library handle synchronization between the local cache and a remote backend that can also execute these queries.

The caching happens at the "DB" level, where it can happen more efficiently (e.g., Datomic caches segments on peers).

You have to implement it yourself. For some apps, you may need to do this anyway for perf reasons, because you don't want to parse the same HTTP response body more than once.

One solution is to not cache queries, but cache data, as in the case with Datomic.

Of course then you're sacrificing some of the authentication, potentially.

It's worthwhile watching Nubank's talk on how they manage these things with Datomic on the backend [0] - providing a "complete" (filtered) database to the client, http caches for queries based on tx-time, and syncing mobiles data via transactions-since. Takes care of said concerns nicely - I'm just implementing this stuff today however, so I'm not sure how well it'll work in practice.

[0] - https://www.youtube.com/watch?v=7lm3K8zVOdY

Isn't there an argument for abstracting and preparing data at the backend level, rather than facing the db nearly directly from the frontend?

This does that. There's nothing saying that individual query elements have to hit the database directly. Besides authz (which others have mentioned), you have the potential for various caching strategies as well as letting the backend make cost decisions in general about where to get things. It could be that you mostly pass through to a Datomic. It could also be that each element hits a different microservice. The point is that your client doesn't know this or care.

yes this is exactly what it is. it's definitely going to be one of those clutch things in the near future. being able to write some ui code that is acting as if the data is already available to it.

Reply on news.ycombinator.com