Why not?

We did that for a Plotly dashboard in Python. We copied the database into a read-only in-memory sqlite database (it is quite small, only a couple thousand entries) to prevent any damages outside the dashboard. The data only gets updated every couple of days. You could skip this step. Then with sqlite you can restrict what action a query can use (SELECT, JSON, etc.) and you can restrict the instructions per query to prevent denial of service. It works like a charm and is much simpler than providing a REST API. Also the user might already know SQL.

I am actually planning something similar for a task management web app I am building at the moment (additionally to providing a REST API). No need to learn another query language like in Jira.

I did this just to reduce network latency. It's not for public use, and tbh, I don't think you can even get at it from outside the VPN.

I got dumped with fixing some bugs in a project written by a contractor who had literally done this but with extra steps.

Backend was sql server and c#/asp.

There was an api endpoint that took json, used xslt to transform to xml. Then called the stored procedure specified in request passing the xml as a parameter.

The stored procedure then queried the xml for parameters, executed the query, and returned results as xml.

Another xslt transformed that to json and returned to the client.

It was impressive how little c# there was.

Despite holding all the business logic, the sql was not in source control.

What could possibly go wrong. Little Bobby Tables would be proud.

Stop over-engineering shit, just do everything client-side like McDonald's: https://bobdahacker.com/blog/mcdonalds-security-vulnerabilities

GraphQL:

Lmfao

Exposed deprecated cred-inclusion URI format, wheeeee

And the db name is short for “analysis”, of course

🤓🫠

This is still over engineered. Just connect directly to the database from the client instead of having an API endpoint.

grapql in a nutshell

Does ReST mean anything anymore? It was originally a set of principles guiding the development of the HTTP 1.1 spec. Then it meant mapping CRUD to HTTP verbs so application-agnostic load balancers could work right. And now I guess it’s just HTTP+JSON?

/anal

it's called microservice

Great idea. How can we submit this to all AI scrapers?

/cybersec red teamer

Hilariously enough, just today I read a blog post about a service where the client interacts with the database directly - https://clickhouse.com/blog/building-a-paste-service-with-clickhouse. While it's not your traditional OLTP database, it still kinda fits.

also stop putting in extra work to handle queries; the user knows what they want so let them enter the queries themselves and save development time. database sanitization is just pointless busywork.

I wish I could go back to rest apis. My company is all in on graphql and it fucking sucks so much ass.

It's not that bad that you might think, the db user just need to have readonly access permissions to specific database tables.

Ofc all data in tables ofc need to be public, so more like simple public facing page, app should not have any notion of users in any way, data probably populated by some automated system, and UI just to make it easier for anonymouse users to view that data in a friendly way.

On top of that it will be a hell for the sysops as they will need to know the whole db structure and such of even a single part of db would contain non-public data, but that overall the best guy to handle security in the first place.

And because all data is totally public in the first place you could give the task of creating frontend to any junior or LLM and it will be still secure.

But in truth it is very bad idea (even it it is possible), because most likely the database connections would be reused so you could for example change current connection session timezone or other params and that ofc would nit change the data in db but still could affect other users by showing wrongly formatted or shifted data.

I'm 100% for this. Because we'll find out VERY quickly what sites are dumb enough to do this. And then we know to stay away from them! :-D

I mean…. Let’s say you set up a Postgres user for all of your application users, with appropriate roles and row level security policies, you could actually do it without Bobby tables issues. I think.

I knew a person that did this

Hehehehe

You absolutely won't be disappointed by explosing your database to SQL directly from the API.

It's just like using MongoDB instead of a structured database!

only good things could be happening in the anal database

This would eventually become graphql.

No one gonna make an anal joke?

I would honestly prefer it if more websites just did that and gave you access to whatever they have about you in their database. Would be much easier to figure out which data they actually store about me. If you set up the access lsits appropriately it could be OK from the security perspective too (of course better to do it over something other than SQL, but who am I to judge).

Isn't this Firebase?

Programmer Shitposting

Heh. Netsuite does this and it's terrible.

Chan I use different database name?