Add support for queries over HTTP

[MarinPostma]

This PR adds support for queries over HTTP.

It is enabled by runnign the server with the --http-listen-addr <SOCKET_ADDR> option.

The server is responding to POST / with a payload json with the following shape:

{
        "statements": ["some SQL statement", "some other statement", ...]
    }

if the query should return rows, they are returned to the JSON format.

The BLOB rows are encoded in base64 with the standard alphabet and no padding.

unlike stateful connections that open a DB connection for every session, the HTTP approach uses a connection pool instead. The number of connections in the pool can scale up and down depending on load

I also added end variables for all cli args, to simplify configuration from docker-compose. Env vars are documented in the --help command for the binary.

[petehunt]

What does the response look like?

Additionally, I think it would be a good idea if I could provide placeholders in the SQL query. I'm thinking something like this in the request body:

{
  "query": "select email from users where user_id=:userId",
  "variables": {
    "userId": "1234"
  }
}

That way you wouldn't have to implement SQL escaping logic in your client if you don't want to.

Also - how would transactions work with this approach?

[MarinPostma]

Hey @petehunt !

The API is still very crude, the response is just an array of JSON objects representing the rows.

Taking inspiration from PlanetScale serverless driver, I expect parameter binding and transaction management to be handled at the driver level. This makes sense since the HTTP API is stateless, and interactive transactions are disallowed

[penberg]

@petehunt To add what @MarinPostma, the array of statements are run in a transaction similar to https://github.com/planetscale/database-js#transactions

[penberg]

@petehunt here's an example JSON output:

[penberg@turing ~]$ curl -d '{"statements": ["SELECT * FROM users"]}' localhost:8080
[{"email":"penberg@iki.fi"}] 

[petehunt]

Sweet! I think that is a great compromise for transactions.

I still think parameter binding would be pretty useful though. If you had that your DB driver implementation would be trivial and much easier to bring to every platform under the sun. I also like curl-ability for adhoc queries :)

[penberg]

@MarinPostma I think Pete's binding idea makes sense. We can work on that as a follow-up to this, of course.

[MarinPostma]

I'm not against it, we need to think a bit about the design

[haaawk]

I support the binding idea. Mostly because I think we should consider adding support for prepared statements and then binding parameters will be necessary.

[haaawk]

LGTM