Coder Legion - Recent posts tagged advanced

Resolving Kubernetes Ingress Issues: Limitations and Gateway Insights

Fri, 13 Feb 2026 03:54:50 +0000

Introduction

Ingresses have been, since the early versions of Kubernetes, the most common way to expose applications to the outside. Although their initial design was simple and elegant, the success of Kubernetes and the growing complexity of use cases have turned Ingress into a problematic piece: limited, inconsistent between vendors, and difficult to govern in enterprise environments.

In this article, we analyze why Ingresses have become a constant source of friction, how different Ingress Controllers have influenced this situation, and why more and more organizations are considering alternatives like Gateway API.

What Ingresses are and why they were designed this way

The Ingress ecosystem revolves around two main resources:

IngressClass

Defines which controller will manage the associated Ingresses. Its scope is cluster-wide, so it is usually managed by the platform team.

Ingress

It is the resource that developers use to expose a service. It allows defining routes, domains, TLS certificates, and little more.

Its specification is minimal by design, which allowed for rapid adoption, but also laid the foundation for current problems.

The problem: a standard too simple for complex needs

As Kubernetes became an enterprise standard, users wanted to replicate advanced configurations of traditional proxies: rewrites, timeouts, custom headers, CORS, etc.
But Ingress did not provide native support for all this.

Vendors reacted… and chaos was born.

Annotations vs CRDs: two incompatible paths

Different Ingress Controllers have taken very different paths to add advanced capabilities:

Annotations (NGINX, HAProxy…)

Advantages:

Flexible and easy to use
Directly in the Ingress resource

Disadvantages:

Hundreds of proprietary annotations
Fragmented documentation
Non-portable configurations between vendors

Custom CRDs (Traefik, Kong…)

Advantages:

More structured and powerful
Better validation and control

Disadvantages:

Adds new non-standard objects
Requires installation and management
Less interoperability

Result?
Infrastructures deeply coupled to a vendor, complicating migrations, audits, and automation.

The complexity for development teams

The design of Ingress implies two very different responsibilities:

Platform: defines IngressClass
Application: defines Ingress

But the reality is that the developer ends up making decisions that should be the responsibility of the platform area:

Certificates
Security policies
Rewrite rules
CORS
Timeouts
Corporate naming practices

This causes:

Inconsistent configurations
Bottlenecks in reviews
Constant dependency between teams
Lack of effective standardization

In large companies, where security and governance are critical, this is especially problematic.

NGINX Ingress: the decommissioning that reignited the debate

The recent decommissioning of the NGINX Ingress Controller has highlighted the fragility of the ecosystem:

Thousands of clusters depend on it
Multiple projects use its annotations
Migrating involves rewriting entire configurations

This has reignited the conversation about the need for a real standard… and there appears Gateway API.

Gateway API: a promising alternative (but not perfect)

Gateway API was born to solve many of the limitations of Ingress:

Clear separation of responsibilities (infrastructure vs application)
Standardized extensibility
More types of routes (HTTPRoute, TCPRoute…)
Greater expressiveness without relying on proprietary annotations

But it also brings challenges:

Requires gradual adoption
Not all vendors implement the same
Migration is not trivial

Even so, it is shaping up to be the future of traffic management in Kubernetes.

Conclusion

Ingresses have been fundamental to the success of Kubernetes, but their own simplicity has led them to become a bottleneck. The lack of interoperability, differences between vendors, and complex governance in enterprise environments make it clear that it is time to adopt more mature models.

Gateway API is not perfect, but it moves in the right direction.
Organizations that want future stability should start planning their transition.

Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Parser types

Wed, 14 Jan 2026 08:55:06 +0000

Intro — formal languages and parsing

All programming languages are specified by a grammar. A grammar tells us whether a piece of text is a valid sentence in that language. A parser generator can take such a grammar and produce a parser. Parsing is the “front end” of compilation: it turns raw text into structure. That’s the basis of how formal languages work.

Simplistic grammar example:

%token <int> NUMBER

expression: expression '+' expression
          | expression '-' expression
          | expression '*' expression
          | expression '/' expression
          | '(' expression ')'
          | NUMBER
          ;

This grammar can generate a parser for simple arithmetic. Before parsing, the input is just text. After parsing, we both

(a) know whether it’s valid under this grammar and
(b) obtain a structured representation of it.

Input:

1 + 2 * (3 - 4)

Parsed tree:

Operator precedence and associativity are encoded in how the tree “leans.” This is an Abstract Syntax Tree (AST). Every program you’ve ever written is, at some level, an AST.

Declarative vs. imperative (why we like trees-as-data)

An AST is a tree, and a tree is data. Code can be seen as data laid out in a shape that captures meaning. The tree is a constant shape that other parts of the system can consume. That’s powerful.

Take an Express router:

router.get('/users', (req, res) => {
  res.send('Users list');
});

You’re not imperatively pushing bytes through sockets; you declare what should happen on /users. The framework consumes that declaration at the right time.

Declarative style usually means: you state what you want; the machinery figures out how. The more capable the machinery, the richer the configuration language must be.

Parser types

Configurations aren’t always free-form; values often depend on each other. Not every config that “type-checks” at the top level is semantically valid. Think of a configuration as:

a constant value that must satisfy a language (expressed as an AST)

If that clicks, good. TypeScript lets us enforce such languages at compile time. I call these parser types: recursive TS types that act like a grammar. They don’t parse tokens; they constrain shape the way a grammar constrains sentences.

Consider:

type Test = Record<string, Test> // ❌ can't do

TS sees a naked, non-terminating recursion and bails.

Even:

type Test = Record<string, Test | string>

still trips the checker.

But:

type Test = { 
  [key: string]: Test | string // ✅ can do
}

works. The index signature form delays evaluation enough for TS to accept the recursion. That’s our recursive hook. Depth is unbounded (until compiler limits), so it can “eat” arbitrarily deep objects. The remaining task is to encode your language rules with unions and recursion.

TypeScript even nudges us syntactically—the leading pipes look exactly like grammar alternatives:

type Literal =
  | string
  | number
  | boolean
  ;

Now, your arithmetic example as a type-level grammar:

type Literal_t = 'number';
const ops = ['+', '-', '*', '/'] as const;
type Op = typeof ops[number];

// 1) leaf
interface NumberLiteral {
  type: 'number';
  value: number;
}

// 2) binary
interface BinaryExpr {
  type: 'binary';
  op: Op;
  left: Expression;
  right: Expression;
}

// 3) grouping
interface ParenExpr {
  type: 'group';
  expression: Expression;
}

// 4) the one non-recursive alias
export type Expression =
  | NumberLiteral
  | BinaryExpr
  | ParenExpr
  ;

// type annotation assures the object matches the grammar as AST
const ast: Expression = {
  type: 'binary',
  op: '+',
  left: { type: 'number', value: 1 },
  right: {
    type: 'binary',
    test: 'asdf', // ❌ type error
    op: '*',
    left: { type: 'number', value: 2 },
    right: { type: 'number', value: 3 },
  }
};

That stray test: 'asdf' is illegal under the grammar and TypeScript tells you immediately. Bonus: editor autocomplete now “knows” exactly what belongs where in your config/AST.

Why would you care?

Already mentioned: grammar can check more then any type union can.
But another area is COMPOSITE PATTERN constants. IE JSX is composite.
Child of a node is again JSX node. Composite patterns are omnipresent yet
constants of composite patterns are very error prone. Especially written by hand
without assistance of language server. Now JSX is solved as it is. Syntax sugar
for function calls. Thats runtime in essence and not a constant.

I'll hint another example of composite that with some effort of defining
proper "parser type", we can declare as constants with full type support.
Server routers. They are composable. and leafs are controllers.
Such constant would be SSOT which is effectively shared contract between server and client.
Out of the box both api client and controller functions would have full type support.
You can say, well we can use open API spec for that. But such a type would
allow full type support just out of declaration and nothing more. No generate types
step, code gen, eventual DRY hell retyping schemas and so on.
In next post I'll show how to do that with a real example. Stay tuned.

Regular Expression - A Comprehensive Guide

Mon, 02 Jun 2025 23:03:31 +0000

(Originally posted on Methodox Wiki, visit the page for a live tester!)

Contents

Introduction
Live Tester
Practical Syntax
Comprehensive Reference
Conclusion

(Due to CoderLegion content length limit, section 4 is ommitted)

1. Introduction

Text - whether it’s log files, configuration data, user input, or documents - is everywhere in programming. From simple scripts to full-blown applications, developers frequently need to search, validate, extract, or transform pieces of text. While many IDEs and editors (like Notepad++, VS Code, or Sublime Text) offer basic find-and-replace functionality, they quickly reach their limits when you need to handle patterns, conditional logic, or repeated structures. That’s where regular expressions (regex) come in.

At its core, a regular expression is a compact, declarative way to describe a set of strings. Instead of manually scanning through text to find, say, all warning messages in a log, you can write a single pattern that matches timestamps, log levels, filenames, email addresses, URLs - you name it. Once you understand the fundamentals, regex can become one of the most powerful “weapons” in your developer toolbox.

Consider a typical log snippet:

2025-05-31 14:23:48 [Info] Starting application...
2025-05-31 14:23:50 [Info] Loading application data...
2025-05-31 14:23:55 [Warning] Missing font file: New Times Roman.
2025-05-31 14:24:22 [Info] The application has started, with 1 warning.
2025-05-31 14:25:01 [Error] Unhandled exception: NullReferenceException.

If you want to answer questions like:

“What warnings were emitted, and when?”
“Which lines contain error messages?”
“How many times did the application start?”

You could write a script in your favorite language that splits on spaces, checks tokens, and does string comparisons. But that quickly becomes tedious: parsing variability in timestamps, handling optional fields, or ignoring whitespace quirks can make your code fragile.

With a well-crafted regex, however, you can match on the entire log line, capture the timestamp, the log level, and the rest of the message - all in one pattern. More importantly, regex can handle any text-based format for which there’s a consistent structure: CSV files, HTML/XML tags, custom configuration formats, and so on.

By the end of this article, you will:

Understand the basic motivation behind regular expressions.
See practical syntax elements and examples for day-to-day tasks.
Have a handy reference that summarizes the most commonly used regex constructs.

Whether you’ve done a bit of “find and replace” in an editor, or you’ve written simple string processing code, this guide will bridge the gap and show you how to level up with regular expressions.

2. Live Tester

See original post.

3. Practical Syntax

In this section, we’ll cover the core building blocks of regex patterns. Each subsection introduces a concept, followed by real-world examples - some based on log processing, others on everyday tasks like validating email addresses or extracting numbers from text.

3.1 Literal Characters and Simple Matches

At the simplest level, a regex can be just literal characters. For example:

Pattern Error will match any occurrence of the substring “Error” in a text.
Pattern 2025-05-31 will match that exact date string.

However, real-world text rarely lines up perfectly. Log messages, for instance, include varying timestamps and different log levels. To match them in a generic way, you need metacharacters.

Key Point: Most characters in a regex match themselves literally, except for special metacharacters (like ., *, ?, \, etc.). To match a literal period, bracket, or other metacharacter, you must “escape” it with a backslash (\. to match a literal dot, \[ to match a literal left bracket, and so on).

3.2 Character Classes (`[]`) and Ranges

A character class is a bracketed set of characters that match exactly one character from the set. For example:

[AEIOU] matches any single uppercase vowel.
[0-9] matches any digit from 0 through 9.
[A-Za-z0-9_] matches a typical word character (letter, digit, or underscore).

Example 1: Matching a Four-Digit Year

Suppose you want to match any year between 1900 and 2099:

^(19|20)[0-9]{2}$

^ and $ are anchors (we’ll cover them in a moment).
(19|20) matches either “19” or “20”.
[0-9]{2} matches exactly two digits.
Altogether, this matches “1900” through “2099”.

Example 2: Extracting Log Levels

Given a log line like:

2025-05-31 14:23:55 [Warning] Missing font file: New Times Roman.

You can match the log level (Info, Warning, Error, etc.) with:

\[(Info|Warning|Error|Debug)\]

\[` and `\] match literal square brackets.
(Info|Warning|Error|Debug) matches one of those four words.

If you expect additional levels (e.g., Trace or Fatal), you can add them inside the parentheses:

\[(?:Info|Warning|Error|Debug|Trace|Fatal)\]

Here we’ve used (?: … ) to create a non-capturing group (we’ll talk about groups more in section 5).

3.3 Quantifiers: Repetition Control

Quantifiers specify how many times the preceding element should match. The most common quantifiers are:

* – Match zero or more times (greedy).
+ – Match one or more times (greedy).
? – Match zero or one time (makes the preceding token optional).
{n} – Match exactly n times.
{n,m} – Match between n and m times (inclusive).
{n,} – Match n or more times.

Example 3: Matching Timestamps

A timestamp like 2025-05-31 14:23:48 can be matched with:

\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2}

\d is shorthand for [0-9].
\d{4} matches exactly four digits (the year).
- matches a literal hyphen.
\d{2} matches two digits (month and day).
\s+ matches one or more whitespace characters (space, tab).
\d{2}:\d{2}:\d{2} matches HH:MM:SS.

If you’re sure there’s exactly one space between date and time, you could use \s instead of \s+.

Example 4: Optional File Extension

Suppose you have filenames like report.txt or report. To match both, you could use:

^report(?:\.txt)?$

^ and $ ensure we match the entire string.
(?:\.txt)? means “optionally match ‘.txt’”.
- \. matches a literal dot.
- txt matches “txt”.
- The ? after the group makes it optional.

3.4 Anchors: Positioning Matches

Anchors specify positions in the text rather than actual characters:

^ – Start of the line/string.
$ – End of the line/string.
\b – Word boundary (between \w and \W).
\B – Non-word boundary.

Example 5: Lines Starting with “Error”

If you want to catch any line that begins with the word “Error” (as a standalone word), you can write:

^Error\b.*$

^Error ensures the line starts with “Error”.
\b asserts a word boundary so that “Errors” or “ErrorCode” are not matched.
.* matches the rest of the line (any character, zero or more times).
$ anchors the end of line.

3.5 Groups and Capturing

Parentheses ( and ) serve two main purposes:

Grouping: Treat multiple tokens as a single unit (often used with quantifiers or alternation).
Capturing: Store the text matched by that group for later retrieval (in code or in a replacement string).

Example 6: Capturing Timestamps and Levels

Given:

2025-05-31 14:23:55 [Warning] Missing font...

You might write:

^(\d{4}-\d{2}-\d{2})\s+(\d{2}:\d{2}:\d{2})\s+\[(Info|Warning|Error|Debug)\]\s+(.*)$

(\d{4}-\d{2}-\d{2}) captures the date (Group 1).
(\d{2}:\d{2}:\d{2}) captures the time (Group 2).
(Info|Warning|Error|Debug) captures the log level (Group 3).
(.*) captures the rest of the message (Group 4).
In most languages, after matching, you can extract Group 1, Group 2, etc.:
- e.g., in C#: match.Groups[1].Value gives the date.

If you want to group without capturing (for alternation or quantifier purposes), use (?: … ). For instance:

(?:Info|Warning|Error|Debug)

does not create a numbered backreference.

3.6 Common Metacharacters and Escape Sequences

Some of the most frequently used shorthand and metacharacters include:

. – Matches any character except newline (in most flavors; some allow a “dotall” mode to match newline).
\d – Digit (equivalent to [0-9]).
\D – Non-digit (equivalent to [^0-9]).
\w – Word character (letter, digit, underscore; [A-Za-z0-9_]).
\W – Non-word character (anything not in \w).
\s – Whitespace character (space, tab, newline, etc.).
\S – Non-whitespace character.
\t, \n, \r – Tab, newline, carriage return.

Tip: When writing regexes in code, you often need to escape backslashes. For instance, in C# you can use verbatim string literals (@"\d{4}-\d{2}-\d{2}") to avoid double escapes.

3.7 Practical Example: Extracting Email Addresses

Say you have a document or a configuration file and need to pull out all email addresses. A simple - but not fully RFC‑compliant - pattern is:

\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b

\b – Ensure we start at a word boundary.
[A-Za-z0-9._%+-]+ – One or more letters, digits, dots, underscores, percent signs, plus, or hyphens (the local part before the @).
@ – Literal “@” symbol.
[A-Za-z0-9.-]+ – One or more letters, digits, dots, or hyphens (domain).
\. – Literal dot.
[A-Za-z]{2,} – At least two letters for the TLD (e.g., “com”, “org”, “io”).
\b – End at a word boundary to prevent partial matches (so we don’t match trailing punctuation).

Testing It

Given:

Please contact *Emails are not allowed* or *Emails are not allowed* for more info. Alternatively, reach out to admin@localhost if testing locally.

*Emails are not allowed* matches.
*Emails are not allowed* matches.
admin@localhost does not match because localhost has no “. + two-or-more-letters” TLD.

3.8 Practical Example: Validating North American Phone Numbers

North American Numbering Plan (NANP) phone numbers often look like:

123-456-7890
(123) 456-7890
123.456.7890
+1 (123) 456-7890

A practical regex might be:

^(\+1\s?)?           # Optional country code +1 and a space
(?:\(\d{3}\)|\d{3})  # Either (123) or 123
[ .-]?               # Separator: space, dot, or hyphen (optional)
\d{3}                # Next three digits
[ .-]?               # Separator again (optional)
\d{4}$               # Last four digits

When compacted (and removing whitespace/comments):

^(\+1\s?)?(?:\(\d{3}\)|\d{3})[ .-]?\d{3}[ .-]?\d{4}$

^ and $ anchor the pattern to the entire string.
(\+1\s?)? – Optionally match “+1” followed by an optional space.
(?:$\d{3}$|\d{3}) – Either three digits inside parentheses or three digits without.
[ .-]? – Optionally match a space, a dot, or a hyphen.
\d{3} – Three digits.
[ .-]? – Separator again.
\d{4} – Four digits.

This pattern will match most common North American formats. By tweaking the groups and quantifiers, you can adapt it for other regions or stricter/looser rules.

3.9 Practical Example: Parsing Log Files

Returning to our log example, suppose you want to extract only the warning messages and their timestamps. You might apply a regex like:

^(\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})\s+\[Warning\]\s+(.*)$

Group 1 captures the timestamp (2025-05-31 14:23:55).
Group 2 captures the message itself (Missing font file: New Times Roman.).

In most programming languages:

C# (using System.Text.RegularExpressions):

var pattern = @"^(\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})\s+\[Warning\]\s+(.*)$";
var matches = Regex.Matches(logContents, pattern, RegexOptions.Multiline);
foreach (Match m in matches) {
    string timestamp = m.Groups[1].Value;
    string message   = m.Groups[2].Value;
    Console.WriteLine($"[{timestamp}] Warning: {message}");
}

Python (using the re module):

import re

pattern = r'^(\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})\s+\[Warning\]\s+(.*)$'
for line in log_contents.splitlines():
    m = re.match(pattern, line)
    if m:
        timestamp = m.group(1)
        message   = m.group(2)
        print(f"[{timestamp}] Warning: {message}")

Even if you’ve only ever clicked “Replace” in an editor, these examples should give you a clear sense of how powerful a single regex can be. You define “match everything up until [Warning], then capture whatever comes next”, and you get exactly the data you want.

3.10 Testing and Debugging Regex

When you’re new to regex, it’s easy to overlook small mistakes - missing an escape, misplacing a quantifier, forgetting an anchor. Here are a few tips:

Use an Online Tester
Websites like regex101.com (PCRE, JavaScript, Python), RegexStorm (for .NET), or regexr.com let you type your pattern, paste test text, and see matches/highlights in real time.
Start Simple, Then Grow
If you need a complex pattern, start with a small piece. For instance, test just \d{4}-\d{2}-\d{2} on the date first, then add time, then add log level, etc.

Comment Your Patterns (When Supported)
Some languages/flavors support the “extended” or “free-spacing” mode, where you can add whitespace and # comments inside your regex:

(?x)            # Enable free-spacing mode
^               # Start of line
(\d{4}-\d{2}-\d{2})   # Group 1: Date
\s+             # One or more spaces
(\d{2}:\d{2}:\d{2})   # Group 2: Time
\s+             # One or more spaces
\[Warning\]     # Literal [Warning]
\s+             # One or more spaces
(.*)            # Group 3: Message text
$

This makes maintenance and future edits easier, especially for complex regexes.

Escape Early
If you need to match special characters (., *, ?, +, [, ], (, ), |, ^, $, \), always escape them with a backslash unless you explicitly want their special behavior.

4. Comprehensive Reference

Omitted due to content length limit. Visit Methodox Wiki for more.

5. Conclusion

By now you should have a solid grasp of:

Why regular expressions are invaluable for text processing.
How to write basic patterns: literals, character classes, quantifiers, anchors.
How to use groups, lookarounds, and backreferences for more advanced matching.
Which tokens and constructs constitute the “core” of most practical regexes.
Where to look when you need to refresh your memory (the reference section above, or a site like regexstorm.net/reference).

With a few dozen minutes of practice - writing regexes against sample text - you’ll rapidly gain confidence. Remember:

Test early and often in an online tester or your IDE’s “Find in Files” - seeing the matches in real time is far more enlightening than manually eyeballing code.
Readability matters. If the pattern becomes unreadable, use the free-spacing mode ((?x)) and add comments.
Keep it simple for common tasks. You rarely need the most arcane syntax; matching log levels, dates, email addresses, or basic CSV fields can usually be done with straightforward character classes and quantifiers.

Once you’ve mastered the basics, you can explore more advanced topics like:

Atomic grouping and possessive quantifiers (for performance-critical patterns).
Recursive patterns (in PCRE or some advanced flavors) to match nested constructs.
Conditional subpatterns (in PCRE or .NET) where you test if a group has matched before deciding the next part of the pattern.

But those are topics for another day. For now, lean on the examples and reference sheet above, and try applying regex to your next text‑processing challenge. In no time, you’ll find yourself thinking in patterns - and you won’t look back.

Congratulations on starting your pattern crafting journey! Keep this guide handy, bookmark your favorite regex tester, and remember that a well‑written regular expression often turns hours of manual parsing into a single line of elegant code.

References

RegStorm for C#

Coder Legion - Recent posts tagged advanced

Resolving Kubernetes Ingress Issues: Limitations and Gateway Insights

Introduction

What Ingresses are and why they were designed this way

IngressClass

Ingress

The problem: a standard too simple for complex needs

Annotations vs CRDs: two incompatible paths

Annotations (NGINX, HAProxy…)

Custom CRDs (Traefik, Kong…)

The complexity for development teams

NGINX Ingress: the decommissioning that reignited the debate

Gateway API: a promising alternative (but not perfect)

Conclusion

Parser types

Intro — formal languages and parsing

Declarative vs. imperative (why we like trees-as-data)

Parser types

Why would you care?

Regular Expression - A Comprehensive Guide

1. Introduction

2. Live Tester

3. Practical Syntax

3.1 Literal Characters and Simple Matches

3.2 Character Classes ([]) and Ranges

Example 1: Matching a Four-Digit Year

Example 2: Extracting Log Levels

3.3 Quantifiers: Repetition Control

Example 3: Matching Timestamps

Example 4: Optional File Extension

3.4 Anchors: Positioning Matches

Example 5: Lines Starting with “Error”

3.5 Groups and Capturing

Example 6: Capturing Timestamps and Levels

3.6 Common Metacharacters and Escape Sequences

3.7 Practical Example: Extracting Email Addresses

Testing It

3.8 Practical Example: Validating North American Phone Numbers

3.9 Practical Example: Parsing Log Files

3.10 Testing and Debugging Regex

4. Comprehensive Reference

5. Conclusion

References

3.2 Character Classes (`[]`) and Ranges