Live data from Hacker News

Apache Apisix: Open-Source API Gateway and API Management Platform

apisix.apache.org

51–60 of 64 posts

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#51
post #50
post #9

“envoy” is another popular option and they are building a gateway solution for API/inbound traffic https://github.com/envoyproxy/gateway

Envoy is great, but it's written in C++ instead of Rust, and it feels like such a missed opportunity. Years ago we were going to write an extension to Envoy to decode our side channel session info so we could do without per-language client intelligence and additional service calls. We didn't want to blow up production traffic - millions of dollars of transactions - because of stupid memory management and pointer blun…

> Envoy is great, but it's written in C++ instead of Rust, and it feels like such a missed opportunity.

This comment sounds too cargo-cultish to be taken seriously.

> We didn't want to blow up production traffic - millions of dollars of transactions - because of stupid memory management and pointer blunders.

You might be surprised to learn that C++ is the tool of the trade of the high frequency trading sector. The key factor is that people who actually work on millions of dollars of transactions do make technicalll decisions instead of blindly going the fanboy path.

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#52
post #20

What is the main benefit to running a gateway? Auth should already be handled by the api and adding things like rate limiting, ip address filtering ,caching and so on are ridiculously trivial..

Most of the time an "API Gateway" provides nothing. Usually this kind of service is just looking at the request path and maybe the Authorization header. In general it's just a useless hop in the TCP connection chain from the client to the server.

> Most of the time an "API Gateway" provides nothing.

This personal assertion only holds if you somehow chose to adopt a component that you need, or blindly adopt components even though you have no idea what you're doing. Discussing these scenarios is pointless and a waste of time though.

Meanwhile, reverse proxies and ingress controllers are fundamental components in any service that outgrows a box under the desk, and a API Gateway is nothing more than a specialized reverse proxy whigh offers some high level features as part of it's happy path.

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#53
The selling point for me was ability to configure it using Kubernetes CRD's and future support of the Gateway API (under development - https://gateway-api.sigs.k8s.io/>).

Developers can version their API now within helm charts or even yaml templates held along the code in their repositories.

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#55
post #51
post #50

Earlier quoted context omitted.

Envoy is great, but it's written in C++ instead of Rust, and it feels like such a missed opportunity. Years ago we were going to write an extension to Envoy to decode our side channel session info so we could do without per-language client intelligence and additional service calls. We didn't want to blow up production traffic - millions of dollars of transactions - because of stupid memory management and pointer blun…

> Envoy is great, but it's written in C++ instead of Rust, and it feels like such a missed opportunity. This comment sounds too cargo-cultish to be taken seriously. > We didn't want to blow up production traffic - millions of dollars of transactions - because of stupid memory management and pointer blunders. You might be surprised to learn that C++ is the tool of the trade of the high frequency trading sector. The ke…

> people who actually work on millions of dollars of transactions

Your attitude is incredibly rude and dismissive. Far worse than whatever you're accusing me of.

We do incredible volume and felt this was a risk to our customers.

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#56

I had to investigate a bit various options and settled on krakend mostly since it's simple and easy to write custom Middleware.

I was trying to look up the license for that project and the repo linked from the footer of their website is https://github.com/krakendio/krakend-ce#readme (Apache 2), but because I just did a web search for krakend there is also https://github.com/luraproject/lura#readme which says it's from the Linux Foundation (also Apache 2)

Is KrakenD some kind of generic term, or does that project just have a complex history?

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#57
post #55
post #51

Earlier quoted context omitted.

> Envoy is great, but it's written in C++ instead of Rust, and it feels like such a missed opportunity. This comment sounds too cargo-cultish to be taken seriously. > We didn't want to blow up production traffic - millions of dollars of transactions - because of stupid memory management and pointer blunders. You might be surprised to learn that C++ is the tool of the trade of the high frequency trading sector. The ke…

> people who actually work on millions of dollars of transactions Your attitude is incredibly rude and dismissive. Far worse than whatever you're accusing me of. We do incredible volume and felt this was a risk to our customers.

> Your attitude is incredibly rude and dismissive.

My attitude is to point out the mistakes of succumbing to fanboyism and blindly going with cargo cult beliefs that make no sense and have no bearing in reality. Complaining that pointing out the fact that the high frequency trading sector is built upon C++ is dismissive says more about your personal beliefs than anything else.

> We do incredible volume and felt this was a risk to our customers.

I really doubt you do more transactions per second than any high frequency trading company running a C++ stack. The likes of Optiver are doing just fine with C++.

Just be honest and humble and state that your expertise lies elsewhere, and your choice had zero to do with technical reasons.

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#58
post #20

What is the main benefit to running a gateway? Auth should already be handled by the api and adding things like rate limiting, ip address filtering ,caching and so on are ridiculously trivial..

> rate limiting, ip address filtering ,caching and so on are ridiculously trivial Maybe if you're running one instance of your API server. But if you're not then API Gateways end up being significantly simpler.

It's really interesting. I just sync state and store short term cache in redis, it's what I do when building any internal API anyway, so why any different with an external API. API servers sit behind a load balancer.

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#59
post #57
post #55

Earlier quoted context omitted.

> people who actually work on millions of dollars of transactions Your attitude is incredibly rude and dismissive. Far worse than whatever you're accusing me of. We do incredible volume and felt this was a risk to our customers.

> Your attitude is incredibly rude and dismissive. My attitude is to point out the mistakes of succumbing to fanboyism and blindly going with cargo cult beliefs that make no sense and have no bearing in reality. Complaining that pointing out the fact that the high frequency trading sector is built upon C++ is dismissive says more about your personal beliefs than anything else. > We do incredible volume and felt this…

A billion dollars a day in gross processing volume. You're just rude and keep doubling down with your arrogance, throwing around words like "blind" when we ran disciplined SPADE processes across senior engineering.

I'm done with this conversation.

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#60
post #15

What is the advantage of using this compared to plain Nginx or Envoy? Is it just static vs. dynamic config for routing?

Apache APISIX also has several security features to help reinforce API security. For instance: 1. It can dynamically manage lots of TLS certificates and do the TLS/SSL terminate or use mTLS to communicate with the upstream; 2. Plugins like ACL, IP Restriction, CSRF, and Referrer Restriction restrict API access in different dimensions.

Is it possible to perform mTLS from client->APISIX gateway and pass on the verified certificate details to the upstream (e.g. via headers)?

Or is mTLS only possible with client->pass through APISIX->upstream? It's not quite clear from the docs.

Post reply on HN