Please enable H2O HTTP/2 server projects. A Docker image is readily maintained and available by the core H2O development team.
H2O Website
H2O GitHub Repo
H2O by itself can improve performance in serving static Glitch projects.
H2O along with Redis can improve performance of Node.js based Glitch projects through high performance serving of cached assets while acting as a front-end proxy.
There’s one slight problem to this approach. Glitch is designed to run Node.js apps. H2O is a C app. Also, Glitch uses Amazon AWS instances/VMs to run projects in so Glitch is kind of limited.
I would like to see Glitch form a culture supporting “full-stack” devs in their expansion to designing and managing small container clusters. Like you said, Glitch is using Amazon. It doesn’t take much to formulate something like a simple 4 container cluster with a front-facing container to provide proxying, load balancing and caching and 3 service containers providing the same or different application services. This kind of playful tinkering on Glitch, “Glitching”, can open the minds of developers to comprehend and design for a wider variety of real world applications. I work with H2O on my own servers and find it a great fit for handling proxying and integrating with REDIS for cache. It doesn’t take much to churn through a bit of C++ to set up proxying logic for the right endpoints and logic to grab and store fresh cache. As a result of this effort you have a much more performant system. Glitch could introduce a mini-cluster project to handle this very practical growth enhancing learning opportunity for the masses.
