4 ms·
I suppose the use case is for when it's not practical or desirable to do the legwork of setting up a full connection, with libraries and everything. You could
by mseebach 9y ago
I suppose the use case is for when it's not practical or desirable to do the legwork of setting up a full connection, with libraries and everything.
You could imagine a "(web)serverless" web app with Javascript querying the DB directly over REST. Or embedded devices saving telemetry directly in a DB.
- setr 9y agoIm still suggesting the webapp exists, just in the form of webapp.com/db, to which you POST with the field query=SELECT%20*%20FROM%20table So the one page takes any arbitrary query, and forwards the query on the client's behalf, and returns the dataset to the client. Im not sure how the provided api is better than what ive suggested; they seem to me equivalent, but xmysql a lot more annoying to write, and xmysql is doing a lot more work for what looks like no benefit
- ruslan_talpa 9y agoam not sure exactly what operations xmysql allows but in the context of PostgREST (which is similar) the advantage over your method is that it does not allow "any query", thus, you can safely expose this api to the open web, while in the method you propose, i can run this query (i need zero db permissions) and kill your db SELECT crypt( encode(digest(gen_random_bytes(1024), 'sha512'), 'base64'), gen_salt('bf', 20) ) FROM generate_series(1, 1000000)
- rco8786 9y ago> xmysql a lot more annoying to write That's pretty subjective. Personally, I'd much rather write "api/foo/:id/bar?_sort=field1" than "select * from foo inner join bar on foo.id = bar.foo_id order by field1". Not to mention that this enables people who are not as familiar with writing raw SQL to move a lot faster, which is the point when you're prototyping/hacking.