[HN Gopher] Dito - an advanced Layer 7 reverse proxy server writ...
___________________________________________________________________
Dito - an advanced Layer 7 reverse proxy server written in Go
Author : andrearaponi12
Score : 81 points
Date : 2024-10-09 17:44 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| vrosas wrote:
| Having an API gateway between the internet and your service(s) is
| a great idea and one I've implemented no less than 3 times. But
| you should really just roll your own. It's a few dozen lines of
| code with go's standard library reverse proxy and gives you way
| more flexibility than trying to yaml-configure someone else's.
| szarapka wrote:
| Unless you have a wild use-case that hasn't been tackled by
| what's out there, why on earth would rolling your own be a good
| idea? Building a proper, secure, and performant API gateway is
| NOT a few dozen lines of code.
|
| There are some super robust (and fast) Go API gateways that
| take care of all the things you didn't think about when trying
| to roll your own.
| vrosas wrote:
| I can absolutely assure you that building a fast and secure
| gateway is not as hard as you seem to be implying. This is,
| again, based on my real world experience.
| Aeolun wrote:
| But maybe your experience just means you've never had the
| same problems as the authors of the libraries?
| lfmunoz4 wrote:
| No idea why you would roll your own, easiest thing is run nginx
| in docker. No way writing your own is the first thing you
| should do.
| vrosas wrote:
| Until you want your gateway to handle some complex auth or
| routing rules and don't want to learn a whole new programming
| language to implement that.
| dingnuts wrote:
| this is such a wild take to me. why on earth are there
| complicated routing rules happening at the API gateway at
| all?
|
| In MY real world experience, the API gateway does some sort
| of very simple routing to various services and any complex
| auth or routing rules would be the service's
| responsibility.
|
| If the API gateway has your application logic in it it's
| not a separate component at all.
|
| How complex can you really get with HTTP requests anyway?
| alphabettsy wrote:
| Completely disagree.
|
| Use something off the shelf that's mature and tested until you
| encounter such complexity that it's no longer feasible or
| practical.
| nilptr wrote:
| Two sides of the same coin!
|
| Use something that solves 1000 use cases of which yours is
| one. Some would say that's simplicity while others would say
| that's complexity. When it breaks do you know why? Can you
| fix it properly or are just layering band-aid on a bigger
| problem inside the component.
|
| Or... build something that solves exactly your use-case but
| probably doesn't handle the other 1000 use-cases and needs to
| be put through trial-by-fire to fix all the little edge-cases
| you forgot about?
|
| Early in my career I opted for #1 but nowadays I generally
| reach for #2 and really try to nail the core problem I'm
| tackling and work around the gotchas I encounter.
| denysvitali wrote:
| > But you should really just roll your own
|
| As someone who already did this (because no other solution with
| our needs was available), I strongly disagree.
|
| Most of the time, NGINX, Caddy, Traefik or APISIX are enough.
| The only time I felt the need to implement an API Gateway from
| scratch was to support a very specific use case with a specific
| set of constraints. No matter how robust the Go standard
| library is, implementing an API Gateway from scratch is rarely
| a good idea.
| vrosas wrote:
| In my experience those specific sets of constraints come
| sooner or later. Someone is going to ask for some complex
| auth or routing rules and it's easier to just write it in go
| than it is to learn a whole new DSL or lua to implement it.
| denysvitali wrote:
| Complex Auth: https://doc.traefik.io/traefik/middlewares/ht
| tp/forwardauth/
|
| Complex routing rules:
| https://doc.traefik.io/traefik/routing/routers/
|
| If you need something more than this, you're either in a
| very specific situation (where an API Gateway written from
| scratch might be a good idea) or that someone is doing
| something wrong
| Aeolun wrote:
| I sort of agree with you, but only if you aren't in a
| position to say 'the software doesn't support it'.
| pachico wrote:
| I wish there was an alternative to Kong API gateway where I
| didn't need to write my plugins in Lua (the go and js sdks seem
| abandoned and are incomplete).
| null_deref wrote:
| I used kong on premise is there a use case for it when aws and
| the likes offer API gateway solutions?
| kryptn wrote:
| we're using the kong gateway controller on aws eks, it's
| pretty neat. I prefer to manage it via argocd/gitops over
| terraform.
| szarapka wrote:
| Have you tried KrakenD? https://www.krakend.io/ - plugins are
| written in Go
| dilyevsky wrote:
| What would you prefer to write plugins in?
| hrpnk wrote:
| Have you seen https://github.com/zalando/skipper? You can
| implement custom filters in Golang.
| matrix2003 wrote:
| Lua has some pretty neat sandbox-type features. I wonder if
| choosing it is related.
| whalesalad wrote:
| Assuming it is built on top of OpenResty
| https://github.com/openresty/openresty
| imiric wrote:
| It's good that this exists, but new projects that come into a
| well established space should make it clear how they
| differentiate themselves from existing solutions.
|
| For example, it's not clear to me why anyone would choose to use
| this instead of Caddy, which is a robust server that already has
| all these features, whether OOB or via plugins.
| galdor wrote:
| This space may be well established, but it still does not
| fullfill all needs. For my own:
|
| - NGINX does not support ACME, and I'm fed up with dealing with
| Lego and other external ACME clients. Also the interactions
| between locations has never been clear to me.
|
| - Caddy plugins mean I have to download xcaddy and rebuild the
| server. I _really_ do not want to rebuild services on my
| servers just because I need a simple layer 4 reverse proxy
| (e.g. so that I can terminate TLS connections in front of my
| IRC server).
|
| So I'm building my own server/reverse proxy
| (https://github.com/galdor/boulevard). Competition is good for
| everyone!
| ChocolateGod wrote:
| > Caddy plugins mean I have to download xcaddy and rebuild
| the server. I really do not want to rebuild services on my
| servers just because I need a simple layer 4 reverse proxy
|
| That's why containers exist.
| galdor wrote:
| You would be surprised by how many infrastructures have
| software running without any container :) I'm running
| FreeBSD on my servers so containers are out, but even if I
| was Linux, why would I use containers for base services?
| MrDarcy wrote:
| I think they meant use a container to build caddy with
| xcaddy.
|
| It is essentially a one liner to cross compile caddy for
| all your use cases as long as you have access to a
| container runtime to build it.
| ChocolateGod wrote:
| > why would I use containers for base services?
|
| This is a supported feature of podman which can generate
| systemd units to make system services.
|
| But, as for advantages (system has some of them too),
| sandboxing, resource constraints, ease of distribution,
| not being broken by system updates (glibc update on RHEL
| broke some Go binaries iirc).
|
| My rule of thumb is that only system software (e.g. DE,
| firewall, drivers, etc) belong on the base system,
| everything else is going in a container. This is very
| easy to do now on modern Linux distros.
| eikenberry wrote:
| DE?
| alphabettsy wrote:
| Boulevard has to be compiled at some point. Wouldn't it
| extremely simple to setup a GitHub Action to build Caddy in
| the way you desire?
| galdor wrote:
| Yes, it can be compiled and packaged so that I can one day
| install it as any other package, in my case on FreeBSD.
|
| And of course it's not just about avoid recompilation,
| there are a lot of features I want to add.
| CAP_NET_ADMIN wrote:
| Which Caddy plugins are you using?
| saurik wrote:
| FWIW, it doesn't handle _your_ use case of Layer 4, but for
| the people at Layer 7, another option is good ol ' Apache: it
| is so flexible and extensible it is almost a problem, people
| tend to not know it long ago went event-oriented with
| mpm_event, and it supports ACME internally (as a module, but
| a first-party module that is seamlessly integrated). (I do
| appreciate, though, that it is critically NOT written in a
| memory safe language, lol, but neither is nginx.)
| stackskipton wrote:
| Layer 4 and 7? HAProxy will do that no problem.
| stackskipton wrote:
| HA Proxy already exists and will do both. You can even
| redirect Layer 4 HTTP/HTTPS Ports to another reverse proxy
| server if you want to get inception levels of crazy.
| imiric wrote:
| Sure, but c'mon, HAProxy is the 800lb gorilla in this case
| when you just need something simple.
| imiric wrote:
| > Competition is good for everyone!
|
| Definitely!
|
| But see how in your project the very first paragraph explains
| why it exists, and what it does differently. This is what I
| think is missing from Dito. It doesn't have to be super in
| depth.
|
| I do disagree with your argument against Caddy, though. How
| often do you realistically rebuild your services? If it's
| anytime you would upgrade, then it seems manageable. xcaddy
| makes this trivial, anyway. Though you don't really need to
| use it. There's a convenient pro-tip[1] about doing this with
| a static main.go file instead.
|
| Good luck with your project!
|
| [1]: https://github.com/caddyserver/xcaddy#warning-pro-tip
| mholt wrote:
| > - Caddy plugins mean I have to download xcaddy and rebuild
| the server. I really do not want to rebuild services on my
| servers just because I need a simple layer 4 reverse proxy
| (e.g. so that I can terminate TLS connections in front of my
| IRC server).
|
| I mean, you don't havse to "rebuild services" -- if you need
| the plugin, just deploy the binary with the plugin. It's not
| like it changes (other than upgrades, which you'd do
| regardless of the plugin).
| deepsun wrote:
| It's written in Go. /s
| pipe01 wrote:
| So is caddy fwiw
| tomcam wrote:
| > new projects that come into a well established space should
| make it clear how they differentiate themselves from existing
| solutions.
|
| You sound like a helpful person. Maybe you're volunteering to
| create a site to do just that?
| artooro wrote:
| Already doing this kind of stuff with Caddy. Unclear why this
| would be any better.
| tedunangst wrote:
| It's funny that layer 7 remains in the vernacular. Nobody talks
| about layer 6 proxies. Or occasionally somebody will mention a
| layer 3 proxy. But never layer 5.
| campbel wrote:
| For folks in the networking space, differentiating between L4
| and L7 proxies is pretty important. And while you could call it
| an HTTP proxy in many circumstances, some proxies support other
| protocols e.g a mysql proxy.
| kjs3 wrote:
| We used to at least think about it, but noone seems to be
| running DECNet, GOSIP or the rest any more.
| dingnuts wrote:
| aren't SSH tunnels layer six proxies in essence?
| stonethrowaway wrote:
| Is this compatible with covering your tracks behind 7 reverse
| proxies in IRC? Asking for a friend.
___________________________________________________________________
(page generated 2024-10-09 23:00 UTC)