Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t we all just want to use SQL on the front end?

vjpr.medium.com

Post reply on HN
Print view View original

141–150 of 184 posts

Re: Don’t we all just want to use SQL on the front end?

#141

Post by rektide »

vaughan wrote: post #14
rektide wrote: post #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…

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…

i think it's changed names (maybe) since i've last seen it? but here is the low level io spec:

https://github.com/WICG/storage-foundation-api-explainer

Re: Don’t we all just want to use SQL on the front end?

#142

Post by mamcx »

TOTALLY!

A lot of the answers here commit the original sin of think SQL = RDBMS.

Expose the sql OF the rdbms is not ideal (security and all that), but none in this world say SQL demand to be the one of the rdbms.

You can create a SQL layer (alike GraphQL) that is "compiled" to calls that MAYBE are translated to a rdbms.

MAYBE.

If GraphQL is ok, sql is too.

Re: Don’t we all just want to use SQL on the front end?

#143

Post by shakezula »

maxk42 wrote: post #140
shakezula wrote: post #111

Earlier quoted context omitted.

Security problems aside, testing is a much more present and pragmatic reason to say "This is a terrible idea."

Side-effects as well. You'll still need an API in order to handle things like sending transactional emails, kicking off batch jobs, or producing other side effects. It doesn't really spare you from developing an API for any non-trivial application.

Absolutely. Not to mention, it feels like a bleeding of concerns to me. The simplest answer to me is "I don't _want_ my front end concerned with SQL queries"

Re: Don’t we all just want to use SQL on the front end?

#144

Post by dvdkon »

cogman10 wrote: post #29
maxk42 wrote: post #22

I've spent the last six months working with a codebase that does exactly this. Aside from the obvious problems with exposing your schema to potential attackers, opening up potential DOS vectors, and training front-end engineers on yet another technology, you end up with some code that is very, very difficult to test. If you're using it in your hobby project and you're aware of the pitfalls - fine, go ahead and do wha…

These are the types APIs that I CONSTANTLY have to tell our internal guys "Hey, don't do that!" I get WHY you'd want to be able to throw in any random filter/sort to get the exact datapoints you are after, but that's both really hard to scale and often ends up being highly coupled to the underlying datastore. I get it, requirements gathering and making a clean API is hard and time consuming. What's harder is not doin…

A lot of internal enterprise tools explicitly have "filter everything" as a feature, so in those cases you might as well use a super-generic API, since you'll need that flexibility anyway.

Re: Don’t we all just want to use SQL on the front end?

#146

Post by raihansaputra »

aboodman wrote: post #61

Everybody is focused on literally replicating the data model and using SQL which obviously won't work. But the idea is directionally correct. Replicate the subset of data the user has access to and wants locally and work on it disconnected, then sync changes asynchronously to server. This is difficult, but necessary for fully responsive and collaborative applications. Check out https://replicache.dev for a productiza…

I’ve seen replicache before and definitely very interested to use it. Will replicache be self-hostable in the future?

Re: Don’t we all just want to use SQL on the front end?

#147

Post by gervwyk »

AaronFriel wrote: post #27

Because it exposes a lot of inner details and potential security/privacy risks if clients are able to change parameters. But... it seems like if you're willing to expose your data model to the client, then it seems like some combination of code signing the SQL (with parameters left empty) along with the acceptable list of named parameters, e.g.: Signed blob: { sql: "SELECT name, email, ... FROM users WHERE users.id =…

> Someone else replied that if you have sufficiently advanced build tooling, you can statically extract the SQL/GraphQL from the client side code and replace them with IDs, and then move the SQL to the backend.

We’ve taken this approach for implementing database queries in Lowdefy [0] (SQL support will be live in next version, implementation using knex [1]. Also a “shared state” between backend and frontend makes parsing paramaters to queries on the backend really seamless and in return a great dev experience. Also allows to to only parse some parameters like secrets only on the backend.

What we are experiencing with Lowdefy apps is that bringing the data model closer to the UI makes coding and UI maintainability of simple projects very easy. This approach works exceptional for us in the BI reporting space where you primarily aggregate data.

However as soon as you move out of the CRUD space to more complex backend logic, extracting the logic to a single interface again simplified the implementation a lot, in fact apps very quickly becomes hard to maintain in my experience.

This does not mean that there is no place for easy CRUD dev tools like OP, but I do believe that an API like solution is required when life gets more complex or even just transactional. But there is also more creative ways to solve this problem.

[0] - https://github.com/lowdefy/lowdefy [1] - https://github.com/knex/knex

Re: Don’t we all just want to use SQL on the front end?

#149

Post by ipnon »

neonological wrote: post #132
ipnon wrote: post #87

Earlier quoted context omitted.

It seems that the typical software engineer doesn't give security a single thought.

I mean the guy is front end. Front end development doesn't involve any security.

I think you would be surprised how quickly and easily an attacker can automatically export vulnerabilities in web applications with programs such as Ffuf and SQLmap.

Re: Don’t we all just want to use SQL on the front end?

#150

Post by aboodman »

raihansaputra wrote: post #146
aboodman wrote: post #61

Everybody is focused on literally replicating the data model and using SQL which obviously won't work. But the idea is directionally correct. Replicate the subset of data the user has access to and wants locally and work on it disconnected, then sync changes asynchronously to server. This is difficult, but necessary for fully responsive and collaborative applications. Check out https://replicache.dev for a productiza…

I’ve seen replicache before and definitely very interested to use it. Will replicache be self-hostable in the future?

As of a month or so, it's even better: Replicache has no server side component at all. It's client-side software that talks directly to your server. See: https://twitter.com/replicache/status/1359690468892626944?s=... for more.

(We've shipped this now, but not re-announced it yet).

Post reply on HN