> 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.

This presentation doesn't go into detail of how thats going to work between Om and Clojure, but if its going to be similar to GraphQL, then there is no problem.

Every field request in GraphQL [1] maps really well to a method invocation on an object (GraphQL even supports arguments). Its not necessary that those objects in turn map directly to actual database entities... and you can of course do many things with methods, like authentication / authorization, or perhaps even (with async servers) delaying get() requests in order to aggregate them into a single IN query

[1]: https://www.youtube.com/watch?v=WQLzZf34FJ8&feature=youtu.be...

Thanks for the link. Very interesting talk.

At then end though, you understand why they had to build such a system : dozens of apps, with weekly releases, and mutliple version support.

Now of course, building an API supporting each of those apps needs is almost equivalent to supporting any kind of query. You might as well create a generic implemention, like GraphQL, which they did.

But for the 99.99% of us, i don't think bypassing the API design phase is a really good idea.

I don't think it qualifies as bypassing the API design phase. You still need to design the classes that map to GraphQL object, the methods they support, the authentication / authorization that those methods require and so on.

All in all its pretty much the same thing as with a classic API. The only difference is you can send multiple (as well as nested) calls in one go, and decide which fields you want to include With this scheme you can even include/exclude fields based on user authorization! For example:

  class UserService {
    email() {
      if (this.context.user.id == this._id) 
        return this._email
      else
        throw new CodedError(403, "Cannot request another users email")
    }
  }

What is necessary now I think is an example open source app implemented with it to demonstrate how the stuff we do with regular APIs would work in GraphQL...