3 ms·
With a persistent OS-level network tunnel (ex. wireguard) that exists when the app starts, you wouldn't need HTTP, WebSockets, TLS, etc. The app could open a si
by 0xbadcafebee 4y ago
With a persistent OS-level network tunnel (ex. wireguard) that exists when the app starts, you wouldn't need HTTP, WebSockets, TLS, etc. The app could open a single TCP connection to a sql connection pool and send its request, and it would be tunneled securely from point to point, with no additional round trips or protocols.
The idealist in me would rather this kind of thing become a standardized extension of address + transport protocols. But every person I talk to would rather stack 12 protocols on top of each other than work on improving the existing status quo. It feels like a truism of human societies; everyone wants improvement, but nobody wants fundamental reform.
- flumpcakes 4y agoThis article is mainly focusing on serverless architectures where there can be no persistent connection for pooling.
- deleted 4y ago[deleted]
- e12e 4y agoThey most definitely run some network hardware/software in front though - you could definitely spin up workers behind a vpn? They are assigned a network interface, after all? Ed: oh, i see - the usecase is going from a serveless app to pg? I suppose any vm-like serveless node could be made to speak witeguard, too...
- chatmasta 4y agoIt's worth noting that Wireguard doesn't use any persistent connection (although you can configure clients to send Keepalive packets). It sends UDP packets only as long as you're opening connections to remote endpoints over its network interface, and lazily sends handshakes only when it determines it hasn't sent one in a while. In the normal setup, that network interface is "persistent," but only in the sense it has an entry in the routing table, etc.; by default there is no daemon sending any packets over it (unlike say, OpenVPN for example), because the nature of UDP means there is no connection to maintain.