3 ms·

Excellent suggestion! I've typically done this in the past; however, targeting Kubernetes deployments, having a single point of ingress has been a major factor

Excellent suggestion! I've typically done this in the past; however, targeting Kubernetes deployments, having a single point of ingress has been a major factor of keeping costs down. But no doubt, multi-ingress would speed things up. There's also a whole Media subsection of the app that uses an internal S3 instance, which would obviously be more efficiently served from its own ingress/egress. If you have some ideas for how I could handle automatically rolling out updated HTML/JS to such a CDN from the K8s cluster, I'd definitely be interested. PRs/code would be best, but even just walking me through any good solutions you know would be immense :)

ramesh31 3y ago
Take a look at Cloudflare: https://developers.cloudflare.com/cache/ https://developers.cloudflare.com/cache/ It's completely agnostic to your setup. Just point your domain to their nameservers, define the routes you want cached, and that's it. There's also an API where you can do your invalidations on deploy: https://developers.cloudflare.com/workers/learning/how-the-cache-works/ https://developers.cloudflare.com/workers/learning/how-the-c...
- pseudocomposer 3y ago
  Yes, I use Cloudflare for the website for https://beatscratch.io https://beatscratch.io. However, I want to have a TLS-secured gRPC server also available on the same domain, which means using Cert-Manager, which is definitely easier if your DNS provider also does your Kubernetes service. I've been hopeful that I can keep all the things behind a single ingress and ideally served from a single Rust binary, but I'd love to see folks submit better solutions :)
  - ramesh31 3y ago
    >However, I want to have a TLS-secured gRPC server also available on the same domain Now this is getting into opinion, but I don't believe gRPC was ever intended to talk to browsers. And with TLS termination in the mix, are you really even saving anything versus just translating to HTTP(S) and Gzipping for the clients? A typical setup is Backend -> protobuff grpc -> GQL/Auth server -> HTTPS -> client With the backend and GQL server in a VPC, so no need for TLS.
    - pseudocomposer 3y ago
      Yeah, I’m just eliminating the GQL server as it’s a bit redundant :) I’d argue that for what I want to do (single ingress everything), gRPC’s various language-specific frameworks handle TLS better than most (obviously not all) HTTP frameworks. Most HTTP frameworks just expect you to put them unsecured behind a separate ingress to do the TLS. For instance, as we can see with my own deploy here, Tonic (the Rust gRPC server) has handled TLS much better than Rocket (the Rust HTTP server).

ramesh31 3y ago

Take a look at Cloudflare: https://developers.cloudflare.com/cache/ https://developers.cloudflare.com/cache/ It's completely agnostic to your setup. Just point your domain to their nameservers, define the routes you want cached, and that's it. There's also an API where you can do your invalidations on deploy: https://developers.cloudflare.com/workers/learning/how-the-cache-works/ https://developers.cloudflare.com/workers/learning/how-the-c...

pseudocomposer 3y ago
Yes, I use Cloudflare for the website for https://beatscratch.io https://beatscratch.io. However, I want to have a TLS-secured gRPC server also available on the same domain, which means using Cert-Manager, which is definitely easier if your DNS provider also does your Kubernetes service. I've been hopeful that I can keep all the things behind a single ingress and ideally served from a single Rust binary, but I'd love to see folks submit better solutions :)
- ramesh31 3y ago
  >However, I want to have a TLS-secured gRPC server also available on the same domain Now this is getting into opinion, but I don't believe gRPC was ever intended to talk to browsers. And with TLS termination in the mix, are you really even saving anything versus just translating to HTTP(S) and Gzipping for the clients? A typical setup is Backend -> protobuff grpc -> GQL/Auth server -> HTTPS -> client With the backend and GQL server in a VPC, so no need for TLS.
  - pseudocomposer 3y ago
    Yeah, I’m just eliminating the GQL server as it’s a bit redundant :) I’d argue that for what I want to do (single ingress everything), gRPC’s various language-specific frameworks handle TLS better than most (obviously not all) HTTP frameworks. Most HTTP frameworks just expect you to put them unsecured behind a separate ingress to do the TLS. For instance, as we can see with my own deploy here, Tonic (the Rust gRPC server) has handled TLS much better than Rocket (the Rust HTTP server).