Skip to content

comparisons.md

Latest commit

 

History

History
94 lines (65 loc) · 3.38 KB

comparisons.md

File metadata and controls

94 lines (65 loc) · 3.38 KB

Comparisons

This page explains where proxykit sits relative to well-known Go proxy projects.

Short version

proxykit is strongest when you want:

  • an embeddable library, not a full platform
  • one foundation for reverse HTTP, forward HTTP, CONNECT, and WebSocket
  • explicit boundaries between transport and product-specific API layers

It is not trying to be:

  • a gateway platform like Traefik or Skipper
  • a full programmable policy engine with its own domain-specific routing model

Against goproxy

Official repo: elazarl/goproxy

Topic goproxy proxykit
Main shape Mature programmable HTTP/HTTPS proxy Composable transport foundation
Forward proxy Strong Strong
CONNECT Strong Strong
MITM Strong Optional helper package
Reverse proxy story Not the main focus First-class
WebSocket story Available, but not the main identity First-class package
Architecture style More monolithic proxy object Smaller packages with explicit seams

Choose proxykit over goproxy when you care more about clean package boundaries and multi-transport composition than about inheriting a long-standing all-in-one proxy abstraction.

Against oxy

Official repo: vulcand/oxy

Topic oxy proxykit
Main shape HTTP reverse-proxy middleware toolkit Multi-transport proxy foundation
Reverse proxy Excellent Strong
Forward proxy Not the focus First-class
CONNECT Not the focus First-class
WebSocket Limited compared to proxykit scope First-class
Listener runtime External concern Included via proxyruntime

Choose proxykit over oxy when your application is not only a reverse proxy and you want forward, CONNECT, and WebSocket handled under the same library family.

Against martian

Official repo: google/martian

Topic martian proxykit
Main shape Powerful modifier-based HTTP/S proxy library Practical transport foundation
HTTP mutation Very strong Strong enough for adapter-driven apps
Reverse proxy Not the main shape First-class
WebSocket Not the main focus First-class
Mental model Rich modifier graph Small packages and explicit hooks

Choose proxykit when you want simpler integration and broader transport coverage, not a deep modifier framework.

Against gateway products

Examples:

These are better when you want:

  • a production gateway platform
  • service discovery
  • ingress control
  • platform-level routing and deployment features

proxykit is better when you want:

  • a library you embed in your own Go process
  • full control over storage and app protocol
  • no gateway control plane
  • a narrower surface area

Where proxykit is currently weaker

Be honest about current trade-offs:

  • fewer examples than older incumbents
  • less ecosystem recognition
  • fewer third-party integrations
  • much newer public identity

That is why this docs site exists: the code is already cleaner than many incumbent alternatives for certain use cases, but the documentation now needs to make that clear quickly.