6 ms·

Why does the idea of having frontend guys directly query the db without any kind of interface scares me ? Seems like going the nosql to sql route once again( n

by bsaul 11y ago

Why does the idea of having frontend guys directly query the db without any kind of interface scares me ? Seems like going the nosql to sql route once again( nosql is great until you realize query language and schema constraints are actually a good thing). Having some kind of pipe structure and interface between your db and your GUI that can be used as a contract,or as an intermediate level to do data rearranging, and can be documented, without having to know all the db schema internals really seems like a sound approach. Now of course some people tackling very special problems may reach the limits of such an approach, yet i hope it won't become mainstream too soon.

spion 11y ago
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&t=5m59s https://www.youtube.com/watch?v=WQLzZf34FJ8&feature=youtu.be...
- bsaul 11y ago
  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.
  - spion 11y ago
    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...
lewisl9029 11y ago
> 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.
- cageface 11y ago
  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.
  - hcarvalhoalves 11y ago
    The caching happens at the "DB" level, where it can happen more efficiently (e.g., Datomic caches segments on peers).
  - lewisl9029 11y ago
    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.

by bsaul 11y ago

spion 11y ago

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&t=5m59s https://www.youtube.com/watch?v=WQLzZf34FJ8&feature=youtu.be...

bsaul 11y ago
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.
- spion 11y ago
  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...

lewisl9029 11y ago

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

cageface 11y ago
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.
- hcarvalhoalves 11y ago
  The caching happens at the "DB" level, where it can happen more efficiently (e.g., Datomic caches segments on peers).
- lewisl9029 11y ago
  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.