DRY is an important principle in software development. This post will show you how to apply it to Apache APISIX configuration. The DRY principle 'Don’t repeat yourself' (DRY) is a principle of software development aimed at reducing repetition of information which is likely to change, replacing it with abstractions that are less likely to change, or using data normalization which avoids redundancy in the first place.

When I introduce Apache APISIX in my talks, I mention the massive number of existing plugins, and that each of them implements a specific feature. One of the key features of Apache APISIX is its flexibility. If a feature is missing, you can create your own plugin in Lua or a language compiled into Wasm, showcasing the platform’s adaptability to your specific needs.

Lots of service providers offer a free tier of their service. The idea is to let you kick their service’s tires freely. If you need to go above the free tier at any point, you’ll likely stay on the service and pay. In this day and age, most services are online and accessible via an API. Today, we will implement a free tier with Apache APISIX. A naive approach I implemented a free tier in my post Evolving your RESTful APIs, a step-by-step approach, albeit in a very naive way.

In my talk Evolving your APIs, I mention that an API Gateways is a Reverse Proxy 'on steroids'. One key difference between the former and the latter is that the API Gateway is not unfriendly to business logic. The poster child is rate-limiting. Rate-limiting is an age-old Reverse Proxy feature focused on protecting against DDoS attacks. It treats all clients the same and is purely technical.

I spoke at Swiss PgDay in Switzerland in late June. The talk was about how to create a no-code API with the famous PostgreSQL database, the related PostgREST, and Apache APISIX, of course. I already wrote about the idea in a previous post. However, I wanted to improve it, if only slightly. PostgREST offers a powerful SELECT mechanism. To list all entities with a column equal to a value, you need the following command: curl /products?id=eq.1 id is the columneq.

Last week, I described how to add a dynamic watermark to your images on the JVM. I didn’t find any library, so I had to develop the feature, or, more precisely, an embryo of a feature, by myself. Depending on your tech stack, you must search for an existing library or roll up your sleeves. For example, Rust offers such an out-of-the-box library. Worse, this approach might be impossible to implement if you don’t have access to the source image.

My ideas for blog posts inevitably start to dry up after over two years at Apache APISIX. Hence, I did some triage on the APISIX repo. I stumbled upon this one question: We have a requirement to use a plugin, where we need to route the traffic on percentage basis. I’ll give an example for better understanding. We have an URL https://xyz.com/ca/fr/index.html where ca is country (canada) and fr is french language. Now the traffic needs to routed 10% to https://xyz.com/ca/en/index.

I continue to work on my Opentelemetry demo. Its main idea is to showcase traces across various technology stacks, including asynchronous communication via an MQTT queue. This week, I added a couple of components and changed the architecture. Here are some noteworthy learnings; note that some of them might not be entirely connected to OpenTelemetry. Here’s an updated diagram. New components appear in violet, and updated components appear in green.

Once in a while, I write non-technical blog posts when I’ve something worth sharing. Today, I’d like to write about my North America 'Tour' across several conferences and user groups. The first leg of my journey started in Oakland, California, with Developer Week. Developer Week is an established conference with different editions in several locations and online during the year.

Last week, we listed 16 practices to help secure one’s APIs and described how to implement them with Apache APISIX. Authentication 🕵️️ - Verifies the identity of users accessing APIs.Authorization 🚦 - Determines permissions of authenticated users.Data Redaction 🖍️ - Obscures sensitive data for protection.Encryption 🔒 - Encodes data so only authorized parties can decode it.Error Handling ❌ - Manages responses when things go wrong, avoiding revealing sensitive info.

A couple of months ago, I stumbled upon this list of Secure your API with these 16 practices to secure your API: Authentication 🕵️️ - Verifies the identity of users accessing APIs.Authorization 🚦 - Determines permissions of authenticated users.Data Redaction 🖍️ - Obscures sensitive data for protection.Encryption 🔒 - Encodes data so only authorized parties can decode it.Error Handling ❌ - Manages responses when things go wrong, avoiding revealing sensitive info.

A couple of months ago, I stumbled upon this list of 16 practices to secure your API: Authentication 🕵️️ - Verifies the identity of users accessing APIs.Authorization 🚦 - Determines permissions of authenticated users.Data Redaction 🖍️ - Obscures sensitive data for protection.Encryption 🔒 - Encodes data so only authorized parties can decode it.Error Handling ❌ - Manages responses when things go wrong, avoiding revealing sensitive info.

The OWASP stands for Open Worldwide Application Security Project: The Open Worldwide Application Security Project is an online community that produces freely available articles, methodologies, documentation, tools, and technologies in the fields of IoT, system software and web application security. The OWASP provides free and open resources. It is led by a non-profit called The OWASP Foundation.

In a few words, the idea of canary releases is to deliver a new software version to only a fraction of the users, analyze the results, and decide whether to proceed further or not. If results are not aligned with expectations, roll back; if they are, increase the number of users exposed until all users benefit from the new version. In this post, I’d like to detail this introduction briefly, explain different ways to define the fraction, and show how to execute it with Apache APISIX.

As a web architect, one of the many issues is asset management. And the most significant issue in assets is images. A naive approach would be to set an image and let the browser resize the image via CSS: img { height: 100%; width: 100%; object-fit: contain; } However, it means that you download the original image. It entails two problems: the size of the original image and the suboptimal browser-based resizing.

My demo, Evolving your APIs, features a custom Apache APISIX plugin. I believe that the process of creating a custom plugin is relatively well-documented. However, I wanted to check the parameters of the _M.access(conf, ctx) function, especially the ctx one. The documentation states: The ctx parameter caches data information related to the request. You can use core.log.warn(core.json.encode(ctx, true)) to output it to error.log for viewing. Unfortunately, core.

Though I always worked on the Dev side of IT, I was also interested in the Ops side. I even had a short experience being a WebSphere admin: I used it several times, helping Ops deal with the Admin console while being a developer. Providing a single package that Ops can configure and deploy in different environments is very important.

When exposing an application to the outside world, consider a Reverse-Proxy or an API Gateway to protect it from attacks. Rate Limiting comes to mind first, but it shouldn’t stop there. We can factor many features in the API Gateway and should be bold in moving them from our apps. In this post, I’ll show how to implement authentication at the Gateway API stage.

etcd is an excellent key-value distributed database used internally by Kubernetes and managed by the CNCF. It’s a great option, and that’s the reason why Apache APISIX uses it too. Yet, it’s not devoid of issues. First, some mention scalability, but one can expect this from a distributed data store that values consistency. Another issue may be the need for more familiarity with etcd.

Last week, we described the concept behind sticky sessions: you forward a request to the same upstream because there’s context data associated with the session on that node. However, if necessary, you should replicate the data to other upstreams because this one might go down. In this post, we are going to illustrate it with a demo. The overall design Design options are limitless. I’ll keep myself to a familiar stack, the JVM.

Sticky sessions, also known as session affinity, is a mechanism by which a routing component that acts as a facade always routes a request to the same underlying upstream node. In this post, I’ll describe the reason behind sticky sessions, available alternatives, and how to implement them via Apache APISIX. Why sticky sessions? Sticky sessions became popular when we stored the state on the upstream node, not the database.

Given the number of API Gateways available on the market, I’m regularly asked which is better. Better is a very subjective term. However, there’s no denying that if you’re advocating for a product, you should know your product and its competitors. In this post, I’d like to share my understanding of Spring Cloud Gateway and how it compares to Apache APISIX. I’m cautious when comparing products because most comparisons I read are heavily biased.

I explained the concepts and theory behind Data Residency in a previous post. It’s time to get our hands dirty and implement it in a simple demo. The sample architecture In the last section of the previous post, I proposed a sample architecture where location-based routing happened at two different stages: The API Gateway checks for an existing X-Country header.

Cloud computing has opened a Pandora’s Box of many original issues compared to sound old on-premise systems. I believe that chief among them is Data Residency, or Data Location: Data localization or data residency law requires data about a nation’s citizens or residents to be collected, processed, and/or stored inside the country, often before being transferred internationally.

Most inter-systems communication components that use REST serialize their payload in JSON. As of now, JSON lacks a widely-used schema validation standard: JSON Schema is not widespread. Standard schema validation allows delegating the validation to a third-party library and being done with it. Without one, we must fall back to manual validation in the code. Worse, we must keep the validation code in sync with the schema.

Lots of companies are eager to provide their identity provider: Twitter, Facebook, Google, etc. For smaller businesses, not having to manage identities is a benefit. However, we want to avoid being locked into one provider. In this post, I want to demo how to use OpenID Connect using Google underneath and then switch to Azure. OpenID Connect The idea of an authorization open standard started with OAuth around 2006. Because of a security issue, OAuth 2.0 superseded the initial version.

API Gateways are critical components in one’s infrastructure. If an attacker could change the configuration of routes, they could direct traffic to their infrastructure. Consequences could range from data theft to financial losses. Worse, data theft could only be noticed after a long time by mirroring the load. Hence, protecting your API Gateway is of utmost importance. In this short blog post, I’ll list a couple of ways to secure your Apache APISIX admin access.

Creating a full-fledged API requires resources, both time and money. You need to think about the model, the design, the REST principles, etc., without writing a single line of code. Most of the time, you don’t know whether it’s worth it: you’d like to offer a Minimum Viable Product and iterate from there. I want to show how you can achieve it without writing a single line of code. The solution The main requirement of the solution is to use the PostgreSQL database.

Last week, I described the basics on how to develop and deploy a Rust plugin for Apache APISIX. The plugin just logged a message when it received the request. Today, I want to leverage what we learned to create something more valuable: write part of the response-rewrite plugin with Rust. Adding a hard-coded header Let’s start small and add a hard-coded response header. Last week, we used the on_http_request_headers() function.

Apache APISIX is built upon the shoulders of two giants: NGINX, a widespread Open Source reverse-proxyOpenResty, a platform that allows scripting NGINX with the Lua programming language via LuaJIT This approach allows APISIX to provide out-of-the-box Lua plugins that should fit most business requirements. But it always comes a time when generic plugins don’t fit your requirements. In this case, you can write your own Lua plugin.

In one of my recent blog posts, I described several ways to access Kubernetes pods. One can access a pod through its IP, but pods are naturally transient. The nominal way is to configure a Service: its IP is stable, and Kubernetes' job is to keep the mapping between a Service and its underlying pods up-to-date.

API Gateways in general, and Apache APISIX in particular, provide a single entry point into one’s information system. This architecture allows for managing load balancing and failover over similar nodes.

API management solutions, also known as API gateways, are a must in the day and age of APIs. However, once you’ve set up such a gateway, you can use it for different purposes unrelated to APIs. Today, I want to show you how to improve the security of web apps. Prevent sniffing Browsers are fantastic pieces of technology that try to make the life of users as comfortable as possible.