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

171–180 of 184 posts

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

#171

Post by aragilar »

kpmah wrote: post #161

The discussion here is frustrating because people are assuming that you'd pass the SQL directly to your database backend and expose your entire schema and all your data. SQL is just a query language, just like GraphQL, and is no less 'secure'. You can still have a layer between the front end and application database. A practical way to use SQL would be to expose the subset of data that is visible to the user and allo…

Astronomy has been doing that for just over a decade: https://www.ivoa.net/documents/TAP/20100327/

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

#172

Post by 1shooner »

jokethrowaway wrote: post #169

Unpopular opinion: I'd like to have no code or as little code as possible on the frontend (think a tiny library - or a minimal browser) and define application flow / logic on the backend. I don't want to have SQL on the frontend, I want to have no-frontend. I'm not advocating to the good old days of backend + HTML and full page refresh, a small layer which smartly dynamically load different pages / submit requests wo…

I think this is the general philosophy of liveview / livewire.

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

#173

Post by johnatwork »

I'm at a place where we've acquired a company that does something similar but through PHP/jQuery, and it's been a herculean effort to make any changes or improvements as there were no abstractions at hand. After many failed attempts at a re-tool/re-build, we've settled on showing a blank page that we then hijack to show a React page that's build on top.

New FE devs that come in now have a 6 month period where they must learn a new proprietary tech just so that we can circumvent what's already there, I would say that it's not a great idea if you have to work with other FE devs (who are not Full-stack) and if your app is of a significant size (YMMV I guess, we've had our own issues with GraphQL too).

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

#174

Post by TheCoelacanth »

ainiriand wrote: post #164
conrs wrote: post #90

I think we've all wondered this at some point in our careers. It's something you should never do. Off the top of my head: 1) Security (as has been beaten to death here) 2) Interface versioning. If you expose a generalized SQL interface to your consumers directly, good luck ever making a change to your database schema. You'll have no idea whose workflows you break. This high coupling becomes very painful very fast. 3)…

Totally valid points. I think this can be solved by a change of layout. If you do use sql queries in the frontend but have a layer between your front and your database to map which queries are valid and how to map your queries to your own DB representation. You solve a big chunk of your problems that way.

That sounds way harder than just defining an API for the front-end to use.

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

#175

Post by callesgg »

My dream is:

* Every user in the web interface gets a sql database user.

* A change in the database schema should reflect an instant change in the AP GUI.

A dream that I have worked towards step by step in a few different projects. I am not sure about how it scales to millions of users. But if you have a a few 100 to a thousand users. It should be fine. Main problem i have found is row level security. The app should basically just be a graphical interface that can be configured. Through a config file.

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

#176

Post by vlucas »

Yes. Last year I made an app that _kinda_ does this ( https://www.seamless.cloud ).

It solves the security issue by making you define the query first in Seamless, and then you get a REST API endpoint to run that query, with optional parameters that are run in a prepared statement.

Query (in the Seamless backend)

> SELECT * FROM posts WHERE author_id = ${author_id} LIMIT 50

And corresponding REST endpoint for that:

> GET https://primary.dbapi.seamless.cloud/somecompany/queries/run...

I dogfooded it while writing the serverless backend for BudgetSheet, and in practice I got tired of having to pre-define each query up front in the app before I could run it from the app. It was kinda painful to switch back and forth vs. just having the queries in the codebase. So... I have definitely been thinking a lot more about how to move the SQL to the client, but in a secure way (perhaps in cobination with the Seamless app that only allows "verified" queries to run in production, etc.) There is definitely some room here for a little innovation.

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

#177

Post by CrazyPyroLinux »

Not SQL, but https://pouchdb.com/ looks like a better version of this.

Also not SQL, IndexedDB [0] Seems like a well-supported [1] document database built into the browser would beat LocalStorage in almost every way. That's what I've found in my experience at least.

Maybe SQL just isn't the right tool on either the frontend or the backend?

[0] https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A... [1] https://caniuse.com/indexeddb

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

#178

Post by miguelsm »

This is already a thing in Clojure/Script, using datalog instead of SQL. Syncing datoms between Datascript (and/or Datahike [0]) on the front-end and Datomic on the back-end can be almost trivial, and there are libraries like Datsync for that [1].

[0] https://lambdaforge.io/2021/03/03/datahike-clojurescript.htm... [1] https://github.com/metasoarous/datsync

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

#179

Post by jgwil2 »

kpmah wrote: post #161

The discussion here is frustrating because people are assuming that you'd pass the SQL directly to your database backend and expose your entire schema and all your data. SQL is just a query language, just like GraphQL, and is no less 'secure'. You can still have a layer between the front end and application database. A practical way to use SQL would be to expose the subset of data that is visible to the user and allo…

Okay, but what about the performance question? I assume this would apply to any language wrapping SQL. How does GraphQL prevent people from sending pathological queries that would wreck DB performance?

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

#180

Post by BackBlast »

CrazyPyroLinux wrote: post #177

Not SQL, but https://pouchdb.com/ looks like a better version of this. Also not SQL, IndexedDB [0] Seems like a well-supported [1] document database built into the browser would beat LocalStorage in almost every way. That's what I've found in my experience at least. Maybe SQL just isn't the right tool on either the frontend or the backend? [0] https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A ... [1] https…

I use PouchDB for this exact use case and it works great. It solves the storage and replication problems both.

If you build it upon SQL, you would also need to create a CRDT schema to make replication sound. That's probably more work than just using REST/GraphQL/RPC.

Local data is king. Especially as the network connection degrades.

Post reply on HN