Yes, a client side DSL for querying data is superior to REST.
But the data model of a complex app is usually more than its sql database. So maybe something closer to gql with code gen for your database is more appropriate?
Don’t we all just want to use SQL on the front end?
11–20 of 184 posts
Re: Don’t we all just want to use SQL on the front end?
#12> 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…
[deleted]
Re: Don’t we all just want to use SQL on the front end?
#13Yah; it’s a game changer. I played around a bit with it on small projects, with obvious limitations/caveats/footguns[0].
Re: Don’t we all just want to use SQL on the front end?
#14> 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…
Doesn't appear it was deprecated for the usage that I propose.
https://softwareengineering.stackexchange.com/questions/2202...
>Byte-level storage
Would be cool.
---
https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...
> From article: we think developer aesthetics are an important consideration...we were resolved that using strings representing SQL commands lacked the elegance of a “web native” JavaScript API, and started looking at alternatives.
Seems a bit short-sighted considering SQL is super popular today on the backend.
Re: Don’t we all just want to use SQL on the front end?
#15a thing a I tried, and ran out of steam with, was writing SQL queries in my client side code but statically extracting them with babel, so you have some code like this:
const users = await sql.query`select * from users`;
console.log(users);
const users = await fetch('/query?id=19a1f14efc0f221d30afcb1e1344bebd');
console.log(users);
This is the same approach Facebook uses for GraphQL. The only reason I gave up with this idea is that getting the developer experience right is hard work and it does introduce some very tight coupling!
Re: Don’t we all just want to use SQL on the front end?
#16each passing year, the web dev world is getting closer to reinventing PHP
Re: Don’t we all just want to use SQL on the front end?
#17I‘m using AlaSQL for years in my projects ... is that the wrong approach or am I missing something here?
Re: Don’t we all just want to use SQL on the front end?
#18This sounds like what Blitz.js is doing: https://blitzjs.com/
Re: Don’t we all just want to use SQL on the front end?
#19Separation of purpose.
* Front end - Show the user what she/he wants in an intuitive manner.
* Back end - Handle business layer which can be scaled horizontally. Have databases that can be scaled.
Mixing it all up results in one huge mess where you cant extend code or change functionalities well.
Re: Don’t we all just want to use SQL on the front end?
#20UNIX: treat everything like a filesystem
This post: treat everything like a SQL database
What's important is that those two EXTREMELY important paradigms of data organization basically don't support each other without kludges galore.
Hierarchical vs relational
But, fundamentally I agree with the poster, what we want are powerful proven data models and powerful proven access languages (SQL for relational, for hierarchical, I'll just throw out XPath which is basically the ONLY good thing from the era of XML that I liked).
Graph could potentially be considered, but IMO it has never proven itself in the practical marketplace. In particular it has no proven and stabilized query language in wide use by people that aren't domain experts, unlike users of the filesystem (basically everyone with a computer) and (less universally) users of databases.