4 ms·

Btw Traefik is an excellent proxy: https://traefik.io/traefik https://traefik.io/traefik Far too few people know about it IMO

razemio 4y ago
Really? I believe it is one of the most known proxies besides Nginx and apache. Especially in docker environments.
- whitemary 4y ago
  Yes, really. I was interviewing last year and used it in one of the projects on my resume. Almost nobody knew what it was. In fact, exactly 1 out of 25-30 people I discussed the project with knew what Traefik was..
  - razemio 4y ago
    Sad days. I am fairly active in the self hosting scene. Traefik is a superstar there right after caddy.
    - yunohn 4y ago
      > fairly active in the self hosting scene Though that is probably why - Traefik is popular for self-hosting, while Caddy is more generally mainstream.
      - ricardobeat 4y ago
        Isn't it the opposite? Traefik is more common in the enterprise as an nginx replacement for k8s, while Caddy is easier to setup and great for self-hosting - I've never seen it used in enterprise environments.
        yunohn 4y ago
        You could be right - I’ve only heard of Traefik in self-hosting contexts.
tarellel 4y ago
I wish I could upvote this more! Traefik is absolutely amazing! And it seems like in the development community every wants to use nginx. But in my experience traefik is absolutely perfect for proxying with container deployed applications.
berkle4455 4y ago
I want to learn Traefik but it yet again has another overly verbose config file. They could learn a lot from caddy. Is it better enough to deal with learning a new DSL?
- conqrr 4y ago
  I'd stick to Caddy. I deprecated my old traefik reverse proxy and tls config which took me days to get right earlier mostly due to my lack of understanding, but the config and DSL is a little tricky too. With Caddy its literally 4 lines of code. Sane defaults are really powerful. I don't have any comments on performance etc as these are hobby projects, I did like traefik's dashboard though.
- hardwaresofton 3y ago
  I find traefik does really well in dynamic, more complex environments (like kubernetes). It also really depends on what you want out of the proxy. Probably makes sense to try caddy first for simpler use cases and graduate to traefik if you find some features you want to have (like l4 traffic that isn’t alpha:beta)
mattjaynes 4y ago
I'm one of the many who hadn't heard of Traefic until MRSK mentioned it. The marketing seems very (overly?) targetted at cloud microservices and container-specific tech[1]. Is that just marketing, or is it really not a good fit for monoliths on bare-metal? [1] https://github.com/traefik/traefik https://github.com/traefik/traefik "Traefik (pronounced traffic) is a modern HTTP reverse proxy and load balancer that makes deploying microservices easy. Traefik integrates with your existing infrastructure components (Docker, Swarm mode, Kubernetes, Consul, Etcd, Rancher v2, Amazon ECS, ...) and configures itself automatically and dynamically. Pointing Traefik at your orchestrator should be the only configuration step you need."
klabb3 4y ago
I’ve been trying out many reverse proxies for stateful, low-traffic websocket connections, but unfortunately they all eat so much ram. Even nginx, with tuning, use at least 10x ram/conn of a well tuned naked uWebSocket deployment with TLS. Traefik was much more ram hungry than nginx, and iirc Caddy as well (at least 2 goroutines per conn). It’s probably fine (and worth it) for the vast majority of request-response web apps, but all of these extra layers have a cost. And that’s still nothing compared to the overhead of say k8s with all bells and whistles. Anyway, as someone who’s been out of the loop on backend for many years, I am quite shocked at the level of resource waste, even among the projects with a strong reputation. You always hear the complaints about frontend bloat, but these days backend seem to have caught up.
- hardwaresofton 3y ago
  Yeah I’m personally of the opinion that the performance loss for regular web services is worth it 99% of the time. RAM is cheap, human time is not. That said I definitely believe your characterization of resource hunger between nginx and traefik. You are the second person to mention using websockets for requests in as many days… How do you deal with scale out? Sticky cookie routing seems like almost a requirement if you don’t want to deploy a redis-alike. Also just out of curiosity, do you use hyper-express[0]? [0]: https://github.com/kartikk221/hyper-express https://github.com/kartikk221/hyper-express

razemio 4y ago

Really? I believe it is one of the most known proxies besides Nginx and apache. Especially in docker environments.

whitemary 4y ago
Yes, really. I was interviewing last year and used it in one of the projects on my resume. Almost nobody knew what it was. In fact, exactly 1 out of 25-30 people I discussed the project with knew what Traefik was..
- razemio 4y ago
  Sad days. I am fairly active in the self hosting scene. Traefik is a superstar there right after caddy.
  - yunohn 4y ago
    > fairly active in the self hosting scene Though that is probably why - Traefik is popular for self-hosting, while Caddy is more generally mainstream.
    - ricardobeat 4y ago
      Isn't it the opposite? Traefik is more common in the enterprise as an nginx replacement for k8s, while Caddy is easier to setup and great for self-hosting - I've never seen it used in enterprise environments.
      - yunohn 4y ago
        You could be right - I’ve only heard of Traefik in self-hosting contexts.

tarellel 4y ago

I wish I could upvote this more! Traefik is absolutely amazing! And it seems like in the development community every wants to use nginx. But in my experience traefik is absolutely perfect for proxying with container deployed applications.

berkle4455 4y ago

I want to learn Traefik but it yet again has another overly verbose config file. They could learn a lot from caddy. Is it better enough to deal with learning a new DSL?

conqrr 4y ago
I'd stick to Caddy. I deprecated my old traefik reverse proxy and tls config which took me days to get right earlier mostly due to my lack of understanding, but the config and DSL is a little tricky too. With Caddy its literally 4 lines of code. Sane defaults are really powerful. I don't have any comments on performance etc as these are hobby projects, I did like traefik's dashboard though.
hardwaresofton 3y ago
I find traefik does really well in dynamic, more complex environments (like kubernetes). It also really depends on what you want out of the proxy. Probably makes sense to try caddy first for simpler use cases and graduate to traefik if you find some features you want to have (like l4 traffic that isn’t alpha:beta)

mattjaynes 4y ago

I'm one of the many who hadn't heard of Traefic until MRSK mentioned it. The marketing seems very (overly?) targetted at cloud microservices and container-specific tech[1]. Is that just marketing, or is it really not a good fit for monoliths on bare-metal? [1] https://github.com/traefik/traefik https://github.com/traefik/traefik "Traefik (pronounced traffic) is a modern HTTP reverse proxy and load balancer that makes deploying microservices easy. Traefik integrates with your existing infrastructure components (Docker, Swarm mode, Kubernetes, Consul, Etcd, Rancher v2, Amazon ECS, ...) and configures itself automatically and dynamically. Pointing Traefik at your orchestrator should be the only configuration step you need."

klabb3 4y ago

I’ve been trying out many reverse proxies for stateful, low-traffic websocket connections, but unfortunately they all eat so much ram. Even nginx, with tuning, use at least 10x ram/conn of a well tuned naked uWebSocket deployment with TLS. Traefik was much more ram hungry than nginx, and iirc Caddy as well (at least 2 goroutines per conn). It’s probably fine (and worth it) for the vast majority of request-response web apps, but all of these extra layers have a cost. And that’s still nothing compared to the overhead of say k8s with all bells and whistles. Anyway, as someone who’s been out of the loop on backend for many years, I am quite shocked at the level of resource waste, even among the projects with a strong reputation. You always hear the complaints about frontend bloat, but these days backend seem to have caught up.

hardwaresofton 3y ago
Yeah I’m personally of the opinion that the performance loss for regular web services is worth it 99% of the time. RAM is cheap, human time is not. That said I definitely believe your characterization of resource hunger between nginx and traefik. You are the second person to mention using websockets for requests in as many days… How do you deal with scale out? Sticky cookie routing seems like almost a requirement if you don’t want to deploy a redis-alike. Also just out of curiosity, do you use hyper-express[0]? [0]: https://github.com/kartikk221/hyper-express https://github.com/kartikk221/hyper-express