https://supabase.io/ ?
MongoDB stitch?
Don’t we all just want to use SQL on the front end?
41–50 of 184 posts
Re: Don’t we all just want to use SQL on the front end?
#42I'm in the "no" camp. First, I don't want to couple my data model to the front-end. Second, the front end applications I worked on, have a relatively small contact surface with the database. Mostly, they retrieve a bunch of records with a common property. There's no need to expose the full power of a query language. Third, the thought of uncontrolled, expensive queries should make every sysadmin break out in sweat.
I also expect fans of Django and the like to be opposed...
Re: Don’t we all just want to use SQL on the front end?
#43I noticed when developing a Single-Page Application that a lot of the backend code seemed to be merely taking requests from the app and reformatting them into database queries.
It wasn't always clear whether any given piece of processing logic belonged in the frontend or backend code, and trying to manage the contract between the two seemed like unnecessary busywork when there was already a well-designed interface between the backend and the database.
In the end this 3-moving-parts design did work, but I wished I had tried something like AWS AppSync[0] which is basically "managed GraphQL".
Re: Don’t we all just want to use SQL on the front end?
#44You can access your database directly from your view-code in ASP.NET Core Blazor. Best technology for the web ever created, period.
Re: Don’t we all just want to use SQL on the front end?
#45Yes we do. Yes, it has been tried.
Fundamentally SQL the language is not designed for the added complexity and and I'm not aware of anything closer than GraphQL.
There are security, transnational, caching and computational questions to solve.
Edit: Maybe FirebaseDB et al are better analogs, actually.
Re: Don’t we all just want to use SQL on the front end?
#46> we should have an SQL database in the frontend
Although not SQL, this is essentially the approach Meteor takes where you have your same DB on the front and back end https://www.meteor.com/
Re: Don’t we all just want to use SQL on the front end?
#47If you have a brand new SaaS app where there is very little data (kilobytes to megabytes) and each user/team is separated from the others, you could have:
- a sqlite database for each user on the backend
- then on page load, have them download their whole sqlite db on the frontend
- sync the two with something like litestream.io compiled for webassembly
Re: Don’t we all just want to use SQL on the front end?
#48There is PostgREST, which is just a thin wrapper REST api around a Postgres database:
Re: Don’t we all just want to use SQL on the front end?
#49I'm in the "no" camp. First, I don't want to couple my data model to the front-end. Second, the front end applications I worked on, have a relatively small contact surface with the database. Mostly, they retrieve a bunch of records with a common property. There's no need to expose the full power of a query language. Third, the thought of uncontrolled, expensive queries should make every sysadmin break out in sweat. I…
No one said it had to be coupled. You could, in theory, expose your API as a view of some kind.
Re: Don’t we all just want to use SQL on the front end?
#50I think when you look at this problem from the viewpoint of local first software - with decentralized sharing and materialized views with a set of private/public relational event source logs - it really comes together well.
It doesn't exist yet, but when the tooling is there it's really going to make a splash.