Java introduced the concept of checked exceptions. The idea of forcing developers to manage exceptions was revolutionary compared to the earlier approaches. Nowadays, Java remains the only widespread language to offer checked exceptions. For example, every exception in Kotlin is unchecked. Even in Java, new features are at odds with checked exceptions: the signature of Java’s built-in functional interfaces doesn’t use exceptions.

I’m still working on learning Rust. Beyond syntax, learning a language requires familiarizing oneself with its idioms and ecosystem. I’m at a point where I want to explore testing in Rust. The initial problem We have used Dependency Injection a lot - for ages on the JVM. Even if you’re not using a framework, Dependency Injection helps decouple components. Here’s a basic example: class Car(private val engine: Engine) { fun start() { engine.

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.

Kubernetes offers a lot of benefits: an enormous ecosystem with plenty of actors, self-healing capabilities, etc. There’s no free lunch, though. It also comes with downsides, chief among them its complexity and operating costs. However, the more I work with Kubernetes, the more I think its most significant asset is extensibility. If you need something that the platform doesn’t provide by default, there’s an option to develop it yourself and integrate it.

For over 20 years, I’ve developed code for the JVM, first in Java, then in Kotlin. However, the JVM is not a silver bullet, e.g., in scripts: Virtual machines incur additional memory requirementsIn many cases, the script doesn’t run long enough to gain any benefit performance-wise. The bytecode is interpreted and never compiles to native code. For these reasons, I now write my scripts in Python.

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.

Whether you implement or not microservices (and you probably shouldn’t), your system is most probably composed of multiple components. The most straightforward system is probably made of a reverse proxy, an app, and a database. In this case, monitoring is not only a good idea; it’s a requirement. The higher the number of components through which a request may flow, the strongest the requirement. However, monitoring is only the beginning of the journey.