Announcing the Cloudflare API Gateway

(blog.cloudflare.com)

Over the past decade, the Internet has experienced a tectonic shift. It used to be composed of static websites: with text, images, and the occasional embedded movie. But the Internet has grown enormously. We now rely on API-driven applications to help with almost every aspect of life. Rather than just download files, we are able to engage with apps by exchanging rich data. We track workouts and send the results to the cloud. We use smart locks and all kinds of IoT devices. And we interact with our friends online.

Okay …

This is all wonderful, but it comes with an explosion of complexity on the back end. Why? Developers need to manage APIs in order to support this functionality. They need to monitor and authenticate every single request. And because these tasks are so difficult, they’re usually outsourced to an API gateway provider.

Umm … so? How is this any different from any other authenticated service? It's not complicated … unless you're a complete n00b to software development who has never had to consider how to work with streams of data rather than files. I have never outsourced this to an API provider, even when I was just starting out with API development. It has always been done wholly in-house and, thanks to 10+ years of experience with API development, the Midori Core framework that I've built handles everything in absolute split seconds. Authenticated and unauthenticated requests operate at damn near the exact same speed.

Unfortunately, today’s gateways leave a lot to be desired. First: they’re not cheap. Then there’s the performance impact. And finally, there’s a data and privacy risk, since more than 50% of traffic reaches APIs (and is presumably sent through a third party gateway). What a mess.

The only mess is this marketing-written puff piece about a Cloudflare service that will further lock people into their systems, making anything written for the service a legacy project right off the bat. Vendor lock-in is very real, and should be avoided at all costs.

Reading through the complete article, I can see why they're offering this service: "developers" are lazy as hell. However, the solution always seems to be "more tech" rather than "better developers". If programmers actually sat down to think about the needs of the project, then people would ask better questions on StackOverflow, learn how to write better systems, and – with any luck – ensure the web remains free and federated.

Less tech. More education. That's the way forward.