quic-go VS kawipiko

2023/05/04 11:38:37 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details.

2023-02-12T15:29:22Z INF Starting tunnel tunnelID=f0cc67d9-973b-44bd-ae58-d7c9e3b112f0 2023-02-12T15:29:22Z INF Version 2023.2.1 2023-02-12T15:29:22Z INF GOOS: linux, GOVersion: go1.19.5, GoArch: amd64 2023-02-12T15:29:22Z INF Settings: map[no-autoupdate:true token:*****] 2023-02-12T15:29:23Z INF Generated Connector ID: 0550ea9c-1c9e-4e48-9d85-defcdc33a31c 2023-02-12T15:29:23Z INF Will be fetching remotely managed configuration from Cloudflare API. Defaulting to protocol: quic 2023-02-12T15:29:23Z INF Initial protocol quic 2023-02-12T15:29:23Z INF ICMP proxy will use 172.17.0.2 as source for IPv4 2023-02-12T15:29:23Z INF ICMP proxy will use :: as source for IPv6 2023-02-12T15:29:23Z INF Starting metrics server on 127.0.0.1:45807/metrics 2023/02/12 15:29:23 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details. 2023-02-12T15:29:23Z INF Connection c81366ed-3bb8-479a-a832-243451980ad3 registered with protocol: quic connIndex=0 ip=198.41.192.227 location=MSP 2023-02-12T15:29:24Z INF Connection 8f2804c5-2dd7-4b2f-8400-e103c2165a80 registered with protocol: quic connIndex=1 ip=198.41.200.43 location=ORD 2023-02-12T15:29:24Z INF Updated to new configuration config="{\"ingress\":[{\"hostname\":\"portainer.mydomain.com\",\"originRequest\":{},\"service\":\"http://my-public-ip:9000\"},{\"hostname\":\"homeassistant.mydomain.com\",\"originRequest\":{},\"service\":\"http://my-public-ip:8123\"},{\"hostname\":\"frigate.mydomain.com\",\"originRequest\":{},\"service\":\"http://my-public-ip:5000\"},{\"hostname\":\"mosquitto.mydomain.com\",\"originRequest\":{},\"service\":\"http://my-public-ip:1883\"},{\"hostname\":\"ra.mydomain.com\",\"originRequest\":{},\"service\":\"http://my-public-ip:8124\"},{\"service\":\"http_status:404\"}],\"warp-routing\":{\"enabled\":false}}" version=28 2023-02-12T15:29:25Z INF Connection f5847632-f534-4cae-a4df-02e11447406e registered with protocol: quic connIndex=2 ip=198.41.192.107 location=MSP 2023-02-12T15:29:25Z INF Connection 664d6d41-b0ac-499d-894d-42e38e5bd475 registered with protocol: quic connIndex=3 ip=198.41.200.193 location=ORD 2023-02-12T15:30:16Z ERR error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: dial tcp my-public-ip:5000: connect: connection refused" cfRay=79865d4d2bdd62bd-ORD ingressRule=2 originService=http://my-public-ip:5000 2023-02-12T15:30:16Z ERR Request failed error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: dial tcp my-public-ip:5000: connect: connection refused" connIndex=1 dest=http://frigate.mydomain.com/api/stats ip=198.41.200.43 type=http 2023-02-12T15:31:37Z ERR error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: dial tcp my-public-ip:5000: connect: connection refused" cfRay=79865f497bb98101-ORD ingressRule=2 originService=http://my-public-ip:5000 2023-02-12T15:31:37Z ERR Request failed error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: dial tcp my-public-ip:5000: connect: connection refused" connIndex=1 dest=http://frigate.mydomain.com/api/stats ip=198.41.200.43 type=http

[the author here] Indeed didn't mention anything about the shared webhosting solutions, just as I didn't mention anything about S3 + CloudFront, or Backblaze B2 + a CDN in front, or Cloudflare + WebWorkers, or AWS Lambda, or any other thousand ways to do it... (Like for example there is <https://redbean.dev/> which I find just so intriguing, and not far from my own <https://github.com/volution/kawipiko> proposal.)

Although shared webhosting is part of our web history -- and still a viable choice especially if you have something in PHP or something that requires a little-bit of dynamic content -- I don't think it's still a common choice for today.

It's somewhere in between dedicated cloud-hosting, because although you have an actual HTTP server (usually Apache or Nginx) that you can't configure it much because it's managed by the provider, thus it gives you the same features (and limitations) as an a proper cloud-hosted static site solution (such as Netlify); and between self-hosting because of the same reasons, having an actual full-blown HTTP server, but one you can't fully control, thus it gives you fewer features than a self-managed VM in a cloud provider or self-hosted machine. Thus unless you need PHP, or `htaccess`, I think the other two alternatives make a better choice.

The issue with "static sites", due to the de-facto requirements in 2022 imposed by the the internet "gatekeepers" (mainly search engines), is that they aren't "just a bunch of files on disk that we can just serve with proper `Content-Type`, `Last-Modified` or `ETag`, and perhaps compressed"; we now need (in order to meet the latest hoops the gatekeepers want us to jump through) to also do a bunch of things that aren't quite possible (or certainly not easily) with current web servers. For example:

* minification (which I've cited in my article) -- besides compression, one should also employ HTML / CSS / JS and other asset minification; none of the classical web servers support this; there is something like <https://www.modpagespeed.com/>, but it's far from straightforward to deploy (let alone on a shared web-host;)

* when it comes to headers (be it the ones for CSP and other security related ones) or even `Link` headers for preloading, these aren't easy to configure, especially if you need those `Link` headers only for some HTML pages and not all resources; in this regard I don't know how many shared webhosts actually allow you to tinker with these;

The point I was trying to make is that if you want to deploy a professional (as in performant) static web site, just throwing some files in a folder and pointing Apache or Nginx at them isn't enough. If the performance you are getting by default from such a setup is enough for you, then perfect! If not there is a lot of pain getting everything to work properly.