Nicolas Fränkel

Apache APISIX is an API Gateway, which builds upon the OpenResty reverse-proxy to offer a plugin-based architecture. The main benefit of such an architecture is that it brings structure to the configuration of routes. It’s a help at scale, when managing hundreds or thousands of routes. In this post, I’d like to describe how plugins, priority, and phases play together and what pitfalls you must be aware of.

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.

In my previous post Chopping the Monolith, I explained that some parts of a monolith are pretty stable and only the fast-changing parts are worth being 'chopped.' I turned the post into a talk and presented it at several conferences. I think it’s pretty well received; I believe it’s because most developers understand, or have direct experience, that microservices are not a good fit for traditional organizations, as per Conway’s Law.

The OpenTelemetry Collector sits at the center of the OpenTelemetry architecture but is unrelated to the W3C Trace Context. In my tracing demo, I use Jaeger instead of the Collector. Yet, it’s ubiquitous, as in every OpenTelemetry-related post. I wanted to explore it further.

In my previous post Evolving your APIs, I mention the main API versioning approaches. During the talk of the same name, I sometimes get some questions on the subject. In this post, I’ll detail each of them. I assume readers know the reasons behind versioning, semantic versioning, and product lifecycle. If not, I encourage you to read a bit about these themes; in particular, chapter 24 of the excellent API Design Patterns book focuses on them.

I got plenty of feedback on my post about Calling Rust from Python: Hacker News/r/python/r/rust Many comments mentioned pyo3, and I should use it instead of cooking my own. Thanks to the authors, I checked: in this post, I explain what it is and how I migrated my code. What is pyo3? Rust bindings for Python, including tools for creating native Python extension modules. Running and interacting with Python code from a Rust binary is also supported.

Let’s continue our exploration of Python’s magic methods in this second part of the series. This part will focus on numbers and containers, i.e., collections. You can read the first part here. Container-related methods Python provides the usual containers, e.g., lists, sets, and dictionaries. You can use the following methods when you want to implement your own. Common methods Containers have a size.

Java was the first language I used professionally and is the scale by which I measure other languages I learned afterward. It’s an OOP statically-typed language. Hence, Python feels a bit weird because of its dynamic typing approach. For example, Object offers methods equals(), hashCode(), and toString(). Because all other classes inherit from Object, directly or indirectly, all objects have these methods by definition.

I recently watched GOTO conferences' talk Calling Functions Across Languages by Richard Feldman. I’m afraid I have to disagree with using the term 'language' in this context. It’s a no-brainer to call Java from Kotlin or Scala or to call Java from Kotlin. Hence, in the rest, I’ll use 'stack'.