Unnecessary battles

Sometimes, I come across open-source projects where even simple changes can take an unexpectedly long time to get reviewed.

Today's story is about APISIX. Starting from its third major release, APISIX introduced a standalone mode (i.e., running without etcd), which I found super convenient. This feature suits my current needs perfectly since I don’t plan to create many gateway rules for my project just yet, and having a simple configuration file at this stage is much more manageable.

So, standalone mode it is! I followed the setup instructions, but something felt off. On startup, APISIX threw an error, complaining it couldn’t modify a configuration file. I thought: “Why do you need to modify it, my friend?”

It turns out, the entrypoint script was written quite creatively (see it here) and takes the liberty of editing the config file for you (read: preventing you from doing it yourself). Combine that with limited configuration customization and some questionable practices (like this one) in their Docker setup, and I felt compelled to take matters into my own hands and rewrite the entrypoint.

Surely, no one can resist such an ultimate challenge! Or so I thought. Naively, I wrote a simple entrypoint script, ran the app, and immediately got another error. APISIX once again demanded to modify the config file itself. Here we go again! After more digging (like this code snippet), I reluctantly added an admin key directly to the config file. Finally, it worked.

Exhausted by this unexpected adventure with Apache, I took a break to explore open PRs. That’s when I stumbled upon this PR by another brave soul. It fixes the very issue that forced me to dive into APISIX's codebase to make it work in standalone mode. However, this PR has been sitting unreviewed for over four months! That realization hit me hard - so much unnecessary effort for something that could’ve been resolved sooner.

Lessons learned:

• Don’t modify configs during application startup - fail gracefully and provide meaningful errors instead.
• If you participate in open-source communities, please review PRs promptly. It makes a big difference for contributors.