131–140 of 184 posts
Let your backend application worry about the SQL.
As 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…
It seems that the typical software engineer doesn't give security a single thought.
I personally know how to mitigate the risks better in a middle-tier GraphQL server than in a database, but I'm open to the idea that database security controls might be up to the job, too, if not now, then maybe in the future.
I think there's a lot of naiveté in this post, but I appreciate where the naiveté is taking us.
So, no thanks.
Well, back in the "olden days" in the late 90's, this was actually pretty common: ColdFusion allowed SQL statements to be embedded in the templates, and JSP had sql tags. IIRC, most people moved away from that model primarily for flexibility and maintainability: having SQL statements mixed in with the presentation led to a lot of code duplication and made putting a different front-end (say, a third party API) nearly…
I use to build sites in PHP where the front and backend were basically the same thing, with only the database existing outside the single codebase. It was definitely common for there to be sql injection vulnerabilities and years later i shuttered at the thought of some of those companies still writing code I wrote when I was young and knew almost nothing I’d security. Luckily now days most of them have switched to ne…
Earlier quoted context omitted.
I wish someone took the SQLite query parser and used it to output Elasticsearch's horrid language so that we could write queries in a language that our devs don't universally loathe.
Ask and you shell receive. https://sqltoelasticsearch.azurewebsites.net/
As 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…
In practice, you would use something like SPARQL (which is already a W3C standard) as opposed to literally feeding raw SQL to the backend database. And SPARQL is designed for reasonable complexity, while still being more flexible than some purely ad-hoc thing like GraphQL (which only really deals well with tree-like hierarchies of data, not anything more general).
SPARQL is really nice for querying graph data, but I'd argue that for most applications tree-like hierarchies are good enough. Also GraphQL and associated frontend libraries are written to be consumed by browsers and results are much easier to handle than results from a SPARQL query, JSON+LD is not the easiest format to handle. The tooling around SPARQL is not great compared to GraphQL either.
Furthermore I'd argue that SPARQL queries are really hard to statically analyze / optimize on the Backend. Different SPARQL engines behave differently and whether you run your query against e.g. Stardog or Virtuoso can have vast performance differences. SPARQL being hard to analyze statically actually becomes apparent once you start thinking about authorization of resources, it is not a trivial problem to know to which resources a client should have access to or not.
And while it is true that you can model provenance, authorization and all kind of other niceties in SPARQL as well, you will likely be on your own building all those tools yourself.
I believe SPARQL is a great query language for public / open data, e.g. Wiki Data, Government data, etc, but in a business context I'd rather choose REST or GraphQL over it.
This 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…
The amount of spaghetti react, redux, rxjs, custom form libraries etc is crazy. Validations fail everywhere, what we do in the frontend is inconsistent with what we do in the backend. Many screens have no url so you cannot share them. Despite just being forms it is incredibly slow and feels "heavy". Doing any change takes ages despite all the testing we have in place.
I know things can be done right with the SPA approach, but it takes a ton more effort.
I miss using rails/django, specially when the use case screams for it. But people want to have fun and do what facebook and google do, only problem is we have 0.001% of their resources.
Earlier quoted context omitted.
I think ActiveRecord beats this, since the code ends up more readable, but you can still run it in the rails repl, and the generated SQL syntax is printed in both the webserver logs and the repl output.
> ActiveRecord beats this, since the code ends up more readable It's subjective and I tend to disagree. Especially for very simple and very complex queries. Also, unless you are a following a "code-first" approach and doing all your schema migrations through the ORM, you have to redefine your tables, columns and relationships a second time and keep them up-to-date with every change, which is a huge hassle. Obviously…
In fact, I'd argue that the "code-first" approach as you call it is actually more useful, because rails gives you bindings for before/after commit hooks, validators that aren't supported by SQL, etc.
> Also, unless you are a following a "code-first" approach and doing all your schema migrations through the ORM
I've literally never heard of a rails team migrating their DBs manually. Everyone uses ActiveRecord because it's a joy to use and very well supported and documented.
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…
Security problems aside, testing is a much more present and pragmatic reason to say "This is a terrible idea."