bun
bun copied to clipboard
oven-sh
Implement HTTP2 server support to enable gRPC
What is the problem this feature would solve?
As described in #887, HTTP2 support is mandatory for gRPC to work. We appreciate the bun team for successfully implementing HTTP2 client-side support, enabling connectivity to gRPC servers.
However, on the server side, the issue persists, preventing the operation of gRPC servers. Unfortunately, there seems to be a lack of prioritization for server support, evident from the absence of an ETA and limited developer replies on the issue.
So I assumed that the team determines feature implementation priority based on the upvotes received for an issue. Given that #887 may be deemed partially resolved, it's possible that its upvotes no longer influence the priority of the ongoing server-side concern.
This new issue is raised to emphasize the continued importance of server-side HTTP2 support. We hope to bring back the attention by collecting upvotes here. Thank you.
What is the feature you are proposing to solve the problem?
Implement HTTP2 server support in Bun.
What alternatives have you considered?
No response
Tags to make the ticket searchable: http2.createServer, http2.createSecureServer, createServer, createSecureServer
I'm dying for this to land so I can finally move on from node once and for all
Same - can't use backend integrations for Auth0, Stripe etc. without it, because they strictly require http2 w/ https even in localhost using their dev mode APIs.
10th most requested features in less than a week.
@Electroid , there is a picture forming that the http2 client release only satisfied a minority of the people reacting to the other ticket. I imagine Windows support draw all resources now (and rightly so!), but any updates or plans for this will be appreciated.
Yes, it's clear that folks need this. I think most realistic would be between 1.1 and 1.2, but we don't have specific dates right now.
This has become the 22th most upvoted ticket in just 1 day, which I find to be highly unusual.
Another dev here who has to use JS/TS and refuses to build "yet another JSON REST API microservice" when everyone knows gRPC is the better option.
Probably Bun is being avoid to be used due http2 not in. After this implementation will be some issues related to it, so until there me and my pals gonna stay with node.
Because of this I'm unable to use Firebase SDK and Even GCP SDKs. Majority of our code is based on the SDKs.
If this is solved, then we can adopt this completely for our internal usage
Me and the gang waiting for this to dropped so we can finally ditch node
Also for running vite with https locally it is required, trying to use the "vite-plugin-mkcert";
Also for running vite with https locally it is required, trying to use the "vite-plugin-mkcert";
Exactly, missing this breaks all frameworks but Next.js through mkcert, and maybe Next too through a similar issue.
Also for running vite with https locally it is required, trying to use the "vite-plugin-mkcert";
I'm pretty sure this is related, but just FYI, when running Vite 4.5 and have basicSsl() plugin included in config (from @vitejs/plugin-basic-ssl) the error message is very misleading:
% bun --bun vite
error when starting dev server:
TypeError: Invalid path string: path is too long (max: 1024)
at readFile (native)
at <anonymous> (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:54807:11)
at readFileIfExists (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:22374:33)
at <anonymous> (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:22368:21)
at resolveHttpsConfig (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:22361:35)
at <anonymous> (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:24928:142)
at processTicksAndRejections (:12:39)
For anyone stumbling into this issue while getting @httptoolkit/httpolyglot to run in bun (required e.g. for mockttp):
We created a fork which removes http2.createServer calls. With this, you can run mockttp just fine. Once bun supports this, the fork of course will be deprecated.
https://github.com/esome/httpolyglot-bun
Others have mentioned it but this issue absolutely cripples anyone using GCP libraries, including firebase-admin. We need this so bad
@zachsents I agree, I had to use different firebase-functions to execute Firestore queries and maintain a 2nd API, which is not desirable @Jarred-Sumner
Hope this gets fixed, so that I can move it to the main Bun + Elysia.js API
The one feature my team needs to ditch node. I hope this gets implemented sooner than later!
Looks like Bun v1.1 got support for this https://bun.sh/blog/bun-v1.1#http-2-client
@rhuanbarreto that seems to be about an HTTP2 client (making HTTP2 calls from Bun) not a server.
Yes, it's clear that folks need this. I think most realistic would be between 1.1 and 1.2, but we don't have specific dates right now.
I think we approached that timeframe now. Is there any chance to get an ETA on this? Me and my team are basically on the fence to adopt bun, but this is just a hard blocker for us. I think this is also one of the most awaited features by now.
Keep in mind deno (or node) can be used for this. Both support full-duplex streaming using fetch(). deno has a built-in WebSocket server. There's no reason why the modern JavaScript programmer can't use bun, deno, and node, and other JavaScript runtimes, at the same time.
@TomasHubelbauer If you are confused by my last comment, see my technical reasoning here Why I use node, deno, bun, qjs, tjs at the same time.
@TomasHubelbauer If you are confused by my last comment, see my technical reasoning here Why I use
node,deno,bun,qjs,tjsat the same time.
Very interesting, thanks! But that doesn't mean bun shouldn't implement an http2 server
@movva-gpu
But that doesn't mean bun shouldn't implement an http2 server
Correct. I just ain't waiting around for Bun to do this when I have other options I can use right now.
@movva-gpu Other than Node.js's Undici fetch() implementation not supporting file: protocol, which we can fix ourselves https://gist.github.com/guest271314/a4f005d9a6b5b433ae6d6e6c5c6d7595 Bun's fetch() implementation does not support half duplex or full duplex streaming as both node and deno do, see https://github.com/oven-sh/bun/issues/7206. So I can't do this https://github.com/guest271314/native-messaging-deno/tree/fetch-duplex which I do using deno or this https://github.com/guest271314/native-messaging-nodejs/tree/full-duplex whih I do with node with bun. For starters Bun could do whatever Undici does - save for the not allowing file: protocol case - fetch().
Same thing with the server. Here's a full-duplex deno server that you can test for yourself https://gist.github.com/guest271314/d20b2a2924d0e2e0c333c01d8b8acace.
So one runtime not having this or that implemented don't stop my projects because I don't entertain a preference for any single JavaScript runtime and regularly use at least 5 JvaScript runtimes to exploit the respective features they have for projects. Nothing is stopping anybody from using deno for a full-duplex server until bun get's their own gear working. Or, don't, nd wait for Bun. I ain't doing that.
@guest271314 Not waiting for Bun to add stuff it currently doesn't have is great! Anyone can mix and match what's at their disposal at any one time. This ticket is about adding HTTP2 to Bun though, so presumably most people subscribed to it are actually waiting for Bun to add this and sharing relevant details (like the recent HTTP2 client support) in the meanwhile. There is value in not having to complicate one's deployment and infrastructure and this value may be worth the wait to many.