support neon's sql-over-websocket protocol #955
Conversation
| tcp.readyState = "opening"; | ||
| const rootURL = host + "/v2" + "?address=" + host + ":" + port; | ||
| const socketURL = "wss://" + rootURL; | ||
| tcp.ws = new WebSocket(socketURL); |
There was a problem hiding this comment.
Obviously, the big change here is that we're using WebSocket instead of cloudflare's "connect" utility.
| } | ||
|
|
||
| async function startTls(host) { | ||
| throw new Error("Postgres SSL connections are not supported yet"); |
There was a problem hiding this comment.
The connection goes over secure web sockets (wss://) so we don't need to double encrypt the content. As such, we don't support tls from postgres.
| keep_alive && socket.setKeepAlive && socket.setKeepAlive(true, 1000 * keep_alive) | ||
| const s = StartupMessage() | ||
| write(s) | ||
| AuthenticationCleartextPassword() |
There was a problem hiding this comment.
This utilizes neon's support for "pipelining" these initial messages to the db. We send the cleartext password and ready for query events before the database actually requests those messages. This cuts down the number of round trips needed to the initialize the connection.
You read more about this here: https://neon.tech/blog/quicker-serverless-postgres
| x === 49 ? ParseComplete : // 1 | ||
| x === 116 ? ParameterDescription : // t | ||
| x === 84 ? RowDescription : // T | ||
| x === 82 ? noop : // R |
There was a problem hiding this comment.
We can safely ignore the "Authentication" request because we've already sent the cleartext password.
Neon is a popular postgres provider that is an open source alternative to AWS Aurora. In order to support connecting to their database in more runtimes (like cloudflare workers), they have implemented a "sql-over-websocket" protocol that these runtimes can use to connect to their database with less "cold-start" latency than other approaches (like hyperdrive).
If you're open to landing this change in this repo, that would be awesome! That said, I understand that this use-case might be niche enough that you may not want to sign up for the ongoing maintenance. If that is the case, I will likely just publish a fork to our own npm namespace to support this use-case.
Notes
Potential future work