Don’t we all just want to use SQL on the front end?
vjpr.medium.com
Don’t we all just want to use SQL on the front end?
1–10 of 184 posts
Re: Don’t we all just want to use SQL on the front end?
#2[deleted]
Re: Don’t we all just want to use SQL on the front end?
#3> Why hasn’t this been tried?
https://caniuse.com/sql-storage
Supported in Chrome 4, circa January 2010.
I'm forgetting the name of it but there is a spec, I think in wicg, for low-level/byte-level file access. This should make using emscripten to compile things like sqlite far more straightforward, to build whatever you want.
I like the shout out to streaming changes out of the database, which the author mentions in terms of redux & time travel abilities from having a wal. Server side systems like Debezium for doing this have been gamechanging. At the moment, the high-level file api has no support for watching for changes (https://github.com/WICG/file-system-access/issues/72). Maybe post 1.0 we might see progress. I don't believe the low-level api has anything for watching for changes.
From a more meta-assesment level of this article: I do hope we can stick with HTTP centric entities, personally. GraphQL with it's generic endpoint that all operations get sent to is, in my view, quite a bad development. But not irreconcileably so: bridges could be built. I'm definitely in favor of experimentation, trying things out. But I also think there's good reasons to keep entities and their urls around, to not abandon that. GraphQL right now doesn't seem to think about that or care about that, but I also think it could be reformed.
Re: Don’t we all just want to use SQL on the front end?
#4https://docs.datasette.io/en/stable/ like this?
Re: Don’t we all just want to use SQL on the front end?
#5No
Re: Don’t we all just want to use SQL on the front end?
#6Each horrible codebase I’ve seen in my career started by some early employee who thought « all we want is to expose the database over http ».
And it’s true this works. If you only have to manage a non-shared todo list.
tl;dr: nope.
Re: Don’t we all just want to use SQL on the front end?
#7https://docs.datasette.io/en/stable/ like this?
Yep, but not just for data journalism.
Re: Don’t we all just want to use SQL on the front end?
#8I think, basically, yes. What GraphQL really solves is letting the frontend compose complex, yet specific, queries. SQL lets you do the same thing. But REST APIs and gRPC-based APIs generally do not.
I guess what I would argue against in this post is that SQL is the right language for this. The post starts off with the assertion that we're just using SQL on the backend anyways - not so, in fact my company doesn't have a single SQL database.
But I think the overall point remains - if you want powerful clients you can't beat a query language.
Apache Calcite comes to mind: https://calcite.apache.org/
Re: Don’t we all just want to use SQL on the front end?
#9Each horrible codebase I’ve seen in my career started by some early employee who thought « all we want is to expose the database over http ». And it’s true this works. If you only have to manage a non-shared todo list. tl;dr: nope.
There's a massive difference between exposing SQL as your API and exposing the database over a proxy. Your exposed SQL may have a separate model, or a more limited model, than what's actually in your database.
Re: Don’t we all just want to use SQL on the front end?
#10Abstraction exists for a reason. It comes with trade-offs. Often they are worth it. To me, abstracting the DB layer seems like a no-brainer so often but I’ll admit that may be a bias due to getting minor heartburn when dealing with the DB layer in general...