No. Really. Don't.
Don’t we all just want to use SQL on the front end?
91–100 of 184 posts
Re: Don’t we all just want to use SQL on the front end?
#92Abstraction exists for a reason. It comes with trade-offs. Often they are worth it. To me, abstracting the DB layer seems like a no-brainer so often but I’ll admit that may be a bias due to getting minor heartburn when dealing with the DB layer in general...
You can abstract at the DB layer with views + stored procedures[1].
[1]: https://postgrest.org/en/stable/schema_structure.html#schema...
Re: Don’t we all just want to use SQL on the front end?
#93SQL on the front end? As a security engineer, this video sums up my thoughts precisely: https://youtu.be/31g0YE61PLQ
I'd want to call it "SQL Injection as a Service", but is it even injection anymore when the client can just send whatever SQL they want? Trying to filter and validate the SQL on the backend to restrict what a client can do would be an absolute minefield and would be so difficult to get right that you wouldn't save any time.
Re: Don’t we all just want to use SQL on the front end?
#94There's nothing wrong with using SQL "on the front end", just be sure to render the front end, server side... like like they did in the olden days.
Re: Don’t we all just want to use SQL on the front end?
#95This is, effectively, what Meteor (JS) does; just with MongoDB instead of SQL. It embeds a mini-MongoDB JS client on the frontend to store cached data, queries are ran against that, and missing data is requested, streamed, and rendered asynchronously. I'll scream from the rooftops: Yes. Meteor has its shortcomings, MongoDB being a big one, but this pattern of unification is so fantastic for every party involved that…
We are collectively off in the wilderness at the moment.
Apollo GraphQL is the same company that brought us Meteor by the way.
If you take a look at what you need to write to get good optimistic UI updates it is crazy compared to what Meteor was.
https://www.apollographql.com/docs/react/performance/optimis...
But as you said, if you need optimistic UI updates and you have 200 engineers you will get it done, but developer efficiency seems to not be popular at the moment.
Re: Don’t we all just want to use SQL on the front end?
#96As many SQL Injection issues (and various other injection forms, including Javascript) as we have with backend code, fuck no we don't want SQL being issued from the frontend. For one, permissions around SQL are already crap. It takes the smallest screwup to expose data in co-mingled databases. No need to make it even worse. For two, at least if the SQL is on the backend, a fix for an exponential query DDOSing your DB…
Not to mention:
- super hard to cache if any client can basically generate an infinite number of different queries.
- which dialect of SQL ? If you change DB or upgrade version, do your ask all clients to change as well ?
- how do you do query that involves several data sources ? Some response data come from redis + elastic search + postgres. That's why FB created graphql. That's also why it's so limited in scope, so that complexity is manageable.
- do you want to expose clients to implementation details such as OUTER JOIN vs INNER JOIN vs an array ? Or let them figure out tricky queries involving HAVING, DISTINCT, COUNT or subqueries ?
Re: Don’t we all just want to use SQL on the front end?
#97There is PostgREST, which is just a thin wrapper REST api around a Postgres database: https://postgrest.org/en/stable/
This is such a useful abstraction.
I love working with PostGREST and have used it quite often for quick services (e.g. a vote button on a static site), internal tools (recently a covid checkin-screener), and for Proof of Concepts (postgres+postgis-powered full text search for address lookups in a webmap without using an external geocoder).
I personally have yet to use it for something with more than 200 users, but it sounds like others certainly have successfully. Supabase (https://supabase.io/) uses this for parts of their backend.
Re: Don’t we all just want to use SQL on the front end?
#98How 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.
for my latest contracted small web app project, I didn't see the need to get an ORM set up—I opted instead to just go for plain SQL statements in a single PHP file, even going so far as to use `?> ... <?` for "templating" HTML blocks, and a fat query string switch for the different subpages/GET/POST actions on the site. I'm sure almost everyone here, especially web developers, would absolutely cringe at what I've done, but for the scope of this small project it works extremely well. after my last job at a remote django/react shop, it was a breath of fresh air to build something "from scratch" without setting up and configuring large amounts of boilerplate, class structures, etc.—instead, the website is quite procedural, just like I would've written when I was teaching myself web development in high school in the mid 00s (except, without the gaping SQL injection holes). designing the web app this way let me build it quickly and rapidly iterate on features as the client requested, and he ended up extremely happy with the results.
Re: Don’t we all just want to use SQL on the front end?
#99For a company we planned to acquire and integrate, one of our devs was wondering why the search requests the frontend made to their API suspiciously looked like raw ElasticSearch queries.
Two hours later that dev sent me a screenshot with our competitor’s production catalogue consisting of memes.
I told him to delete them so we could sign the purchase agreement without further ado.
To this day they don‘t know and I sometimes wonder how they ever got so far.
And this, ladies and gentlemen, is why you leave backend query languages to backends and just use GraphQL...
Re: Don’t we all just want to use SQL on the front end?
#100How 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.
This is true, and there is definitely a place for raw sql, but in my experience ORMs cover most cases and I only have to write SQL queries for special cases.