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

71–80 of 184 posts

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

#71

Post by villasv »

nromiun wrote: post #30

How many people are actually using raw SQL on the backend? I thought people got tired of maintaining strings of raw SQL and migrated to query builders or ORMs. > I usually end up with a bunch of Lodash (groupBy, filter, map, reduce) to shape the data I get from the server. I mean, we are also doing the same thing with ORMs on the backend.

It's pretty rare for an ORM to cover all possible scenarios. I just introduced another raw query to our database because our ORM isn't able to generate `insert into ... select ... where not exists (select ...)` which is crucial for one critical bit that needs to handle idempotent writes.

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

#72

Post by cblconfederate »

EMM_386 wrote: post #67
cblconfederate wrote: post #16

each passing year, the web dev world is getting closer to reinventing PHP

PHP doesn't run in the browser. This is about client-side SQL.

yep, the invention of 'server-side client cache' is ahead of us

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

#74

Post by rattray »

Actual, a budgeting app built by @jlongster (creator of Prettier), is a local-first webapp built with in-browser SQLite. It uses CRDT's to sync state to the server.

A tweet storm: https://twitter.com/jlongster/status/1341586372252078083

A blog post which mentions some of how it works: https://actualbudget.com/blog/porting-local-app-web

A more recent tech talk (which I haven't watched): https://blog.fission.codes/building-actual-budget-with-james...

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

#75

Post by throwawaygh »

dane-pgp wrote: post #53
throwawaygh wrote: post #39

Earlier quoted context omitted.

This is a really interesting interface design, but seems like for any non-trivial database it would be too easy to make mistakes and give the client too much access. Also seems like it's be really easy to end up with performance issues. Also, there's basically zero information hiding. The database is your interface. Changing the schema in any way whatsoever is a breaking change to the API! You haven't really saved yo…

> You haven't really saved yourself from the hassle of designing and maintaining backward compatibility for the API. Another way to look at it is that changing the database schema is already a problem for the API which has to talk to it, so you're not really saving yourself any work by putting an extra layer between the frontend and the database. In fact, if anything, you're doubling the amount of work, because there…

Yes. The decision calculus here really boils down to how many clients the API has and how much you care about those clients.

If you have 100 other teams each with 5+ developers consuming your API -- or especially if your API is a product -- then keeping the API to frontend interface relatively stable with rare breaking changes is much more valuable than saving yourself even a major time commitment on DB to API work.

On the other hand, if you have relatively few clients -- or if the clients are "lower status"/"cheaper" teams -- saving time on the DB to API work a the expense of client teams might make sense.

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

#76

Post by starik36 »

Yes. My point of pain has been ElasticSearch. The Json happy queries with far too many squiggly braces and square braces are just difficult to read.

A simple statement like SELECT Age FROM Employee WHERE name = 'Frank' turns into a monstrosity like

POST Employee/_search { "query": { "bool": { "must": [ { "match": { "name": "Frank" } } ] } }, "fields": [ "Age" ] }

Thankfully they added rudimentary SQL support so I could use it in ad-hoc queries.

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

#77

Post by kortex »

Smells like an XY problem. What they want isn't "SQL on the front end", it's an abstract machine that both the frontend and programmatic server-side systems interact with, and that abstract machine brokers the flow between these clients and the backend. Let that machine handle permissions, caching, etc, since that's hard, tedious, error prone, and less secure for humans to do. Just like how we stopped writing assembly.

I have to look into it, but some posters mention blitz.js, this may be just such a thing.

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

#78

Post by debacle »

Having worked with thick clients in the past, yes and no. There are a lot of caveats to data manipulation on client machines. You lose the luxury of caching, etc. Paging becomes more problematic, and there are a host of other issues.

A better solution would be a GraphQL like API that leverages SQL.

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

#80

Post by vaughan »

rattray wrote: post #65
recursive4 wrote: post #55

For those not familiar, check out Postgraphile.

Came here to say this. To expound a bit, you can use it as a highly pluggable/extensible express plugin which you can point at any postgres db and get all CRUD and other operations exposed in GraphQL, without writing any code. You can easily hide or rename fields that you don't want exposed, override their behavior in Node, and add generated columns or fancy SQL mutations either in JS or directly in your DB and have…

But what about optimistic UI updates or offline support in the client. The frontend has no notion of the relationships between the entities, which means you will be making a lot more queries than you need to, or just ignoring optimistic updates (we may be fine for some apps).
Post reply on HN