Anyone who writes Go does not need any of this. And those who do not write Go, can still write their own in no time because it is literally couple of lines of code. No harder than running a webserver in Go(two lines of code).
https://github.com/andrearaponi/dito/blob/a57d396476cc618678...
The OSI Deprogrammer
Before seeing this here, I went down a rabbit hole on why-anyone-cares about the OSI model, especially as a descriptor for their golang project. It seems to be just a classification that one person found useful, and people treat like an interesting thing.
Separately, we need more deprogrammers in the world.
And then there is quic, which is a transport protocol, so kinda layer 4, but it is higher than udp, but it also has TLS built into it.
As others have said, "processing layers" in contemporary network service architecture don't align that well with OSI layers anymore, though.
To rectify this most grievous transgression, I now unveil a device of eternal ingenuity and enchanting craftsmanship, a veritable marvel, which shall restore order to the realm of networking with unparalleled precision and grace: «Whispering X.Gate», a X.25 API Gateway – https://pastebin.com/S11LRJNS
I blame frameworks that encourage the user to just use their "obvious" specific directory structure that works for 80% but people still make up the other 20%
And no need for documentation, since is "obvious" [...to anyone who has invested dozens of hours working with that specific framework]
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.
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
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.
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?
Use something off the shelf that’s mature and tested until you encounter such complexity that it’s no longer feasible or practical.
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.
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.
- 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!
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!
And of course it's not just about avoid recompilation, there are a lot of features I want to add.
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).
That's why containers exist.
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.
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.
You sound like a helpful person. Maybe you're volunteering to create a site to do just that?
I also don't want to commission something for another project. They should get creative control in the process, else it just feels weird.
Where are you finding skilled graphic artists willing to do a project like that of $20? Having hired freelance graphic artists for projects for work, even the smallest things costs hundreds of dollars.
Here, here's someone I'm commissioning now, a basic sketch is $10 https://www.shiroganestudios.com/work/commissions
Given the project is FOSS, they'd probably be fine with that price still.
I could go through a list of literally hundreds of artists where $20 is within budget. The quality of simple logo like is needed here is about on part with what many would do for a telegram sticker, which are often about $5/piece.
Hundreds of dollars is totally reasonable if commercial. This isn't.
We use a mix of Traefik and Envoy for complex + dynamic LB configurations. Doing anything related to custom middleware, dynamic configuration, and caching feels archaic on Traefik and requires a non-trivial amount of code on Envoy. I hope Dito becomes the next gold standard for load balancing.
One caveat — one of my biggest complaints with Traefik is the memory usage, which makes it difficult to run as an mTLS proxy between services. We use Envoy for these use cases instead. I’m curious to see how Dito compares on memory usage, despite also being written in Go.