This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-04
Channels
- # announcements (27)
- # babashka (1)
- # beginners (70)
- # calva (3)
- # cljfx (4)
- # clojure (37)
- # clojure-australia (1)
- # clojure-europe (1)
- # clojure-germany (6)
- # clojurescript (5)
- # conjure (4)
- # cursive (2)
- # data-science (3)
- # datomic (20)
- # events (1)
- # fulcro (9)
- # graalvm (7)
- # jobs-discuss (3)
- # joker (1)
- # malli (2)
- # pathom (2)
- # re-frame (8)
- # reitit (1)
- # shadow-cljs (44)
- # sql (16)
- # xtdb (8)
Wouldn't it make sense to use FastCGI as interface instead of HTTP for server-side, web content-serving programs that you want to compile with GraalVM? Since it is a so much simpler, more straightforward protocol that doesn't rely on massive and/or complicated Java libraries like Jetty or Apache HTTP
I would be curious to hear what the benefits of FastCGI are over httpkit. I have used it too little to know
FastCGI is a much more lightweight protocol that has been made for applications running behind an HTTP server. That's basically it. The idea being that it is silly that each application spins up its own HTTP server when they'll all going to be behind an actual, web-facing one.
Ah yeah I see, thanks
@zilti Sure, but note that the httpkit webserver is already compatible with GraalVM and quite small in binary size and in terms of memory usage during compilation. It's part of babashka today
@zilti If you want to go down that road: you'll need httpkit with this commit: https://github.com/http-kit/http-kit/commit/6a03df3ecc61be4dcc01d12712346e051620f8b4 or do something like this: https://github.com/borkdude/babashka/blob/master/feature-httpkit-server/babashka/impl/httpkit_server.clj to prevent the runtime require reference, which tends to bloat binaries / spike compile time