DEV Community: Wael Habbal

Next.js and the Edge Runtime: A Guide for Full-Stack Developers

Wael Habbal — Wed, 01 Oct 2025 10:33:41 +0000

The world of web development is constantly evolving, and the concept of Edge Computing is one of the most significant recent shifts. Next.js, built by Vercel, has been at the forefront of this change, largely by integrating the Edge Runtime. This post will demystify the Edge Runtime, explain its purpose, highlight its limitations, and discuss the recent developments in Next.js regarding Node.js support in Middleware.

What is the Edge Runtime?

The Edge Runtime is a lightweight, high-performance JavaScript execution environment designed to run code closer to your users—at the "edge" of the network, typically on a Content Delivery Network (CDN).

Key Characteristics

Lightweight: It's built on the V8 engine (the same engine that powers Google Chrome and Node.js) but runs in isolated execution environments called V8 isolates, not full operating system containers or virtual machines. This design makes it incredibly fast, leading to near-zero "cold start" times (the delay before a serverless function executes).
Web Standards Compliant: The Edge Runtime primarily supports a subset of Web APIs (like fetch, Request, and Response) instead of the full set of Node.js APIs. This makes the code highly portable across different "edge" platforms.
Deployment: When deploying a Next.js application on Vercel, components configured to use the Edge Runtime (like Middleware or Edge Functions) are automatically deployed globally across Vercel's Edge Network.

Why Vercel Created the Edge Runtime

Vercel created the Edge Runtime to achieve two primary goals for modern web applications: performance and developer experience.

Lower Latency and Improved Performance: The fundamental benefit of the Edge Runtime is speed. By running code geographically closer to the end-user, it dramatically reduces the time a request has to travel. This is crucial for:
- Middleware: Allowing logic like authentication, redirects, and A/B testing to execute extremely fast, before the request even hits your main server or cache.
- Edge Functions: Providing ultra-low latency for specific API calls or dynamic content generation.
Bridging Frontend and Backend: By adhering to Web Standards, the Edge Runtime makes it easier for front-end developers to write server-side code using familiar APIs. This streamlines the full-stack development experience within the Next.js framework.
Cost and Efficiency: V8 isolates are much more memory-efficient and faster to boot up than traditional Node.js serverless containers. This can lead to lower operational costs and better resource utilization.

Limitations of the Edge Runtime

To achieve its speed and lightweight nature, the Edge Runtime imposes strict limitations:

Limited API Access: It does not support the full Node.js API. Critical Node.js modules like fs (File System), path, process, and certain parts of crypto are unavailable.
No Long-Running Processes: Edge functions are designed for quick execution. They have a very short maximum execution time (e.g., typically under 5 seconds on Vercel) and limited memory. They are unsuitable for heavy computation, file uploads, or complex background jobs.
Module Incompatibility: Any third-party npm package that relies on Node.js-specific APIs will not work in the Edge Runtime. Developers often need to use "edge-compatible" alternatives (e.g., using the jose library instead of jsonwebtoken for JWTs).
Bundle Size: Edge Functions and Middleware have a strict size limit for the final bundled code (typically 1MB).

Next.js Middleware: The Runtime Evolution (Next.js 15.x)

Middleware in Next.js acts as a gatekeeper, allowing you to run code before a request is fully processed. Historically, Next.js Middleware only ran on the Edge Runtime.

The New Node.js Support in Middleware

In recent Next.js versions, such as Next.js 15.5, Vercel introduced stable support for the Node.js runtime in Middleware. This is a significant development motivated by community feedback regarding the limitations of the Edge Runtime.

When to Use Edge Runtime in Middleware

The Edge Runtime should remain your default choice for Middleware because of its performance benefits.

✅ Use Edge Runtime When...	Reason
You need the lowest possible latency.	Ideal for redirects, rewrites, bot protection, and simple header manipulation.
Your logic is lightweight and uses Web APIs.	Authentication checks using modern Web Crypto APIs or simple cookie manipulation.
You want the code to execute globally.	Ensuring the fastest response time for users all over the world.

When to Use Node.js Runtime in Middleware

You should opt-in to the Node.js runtime for Middleware only when your use case explicitly requires a full Node.js environment.

⚠️ Use Node.js Runtime When...	Reason
You need access to Node.js built-in modules.	For example, using the `fs` module (though not generally recommended in Middleware) or complex file-based operations.
You must use a third-party library that relies on Node.js APIs.	For example, connecting to certain databases, using complex logging libraries, or legacy authentication packages that require Node.js-specific features.

How to Use It:
To use the Node.js runtime for a specific function (like an API Route or Middleware), you typically export a configuration object, although the exact implementation details for Node.js Middleware may involve a configuration flag in next.config.js or a specific export in the middleware file, depending on the current Next.js version's stable API. For Next.js Middleware, the Edge Runtime remains the default, and you would need to configure it specifically to use Node.js if required.

The key takeaway is that the Node.js runtime gives you power and compatibility but sacrifices the global low latency and lightweight nature of the Edge Runtime. Choosing the right runtime is a critical architectural decision based on the specific needs of your logic.

How We Reimagined SQL Query Building to Be Smarter, Safer, and Simpler (Introducing `mysql2-dx` v1.1.0)

Wael Habbal — Mon, 15 Sep 2025 11:14:05 +0000

Hello, dev community!

If you've ever built a Node.js application that interacts with a MySQL database, you know the power and flexibility of mysql2. But you also know the challenges:

String concatenation hell: Building complex WHERE clauses often involves messy string manipulation, leading to unreadable code and, worse, potential SQL injection vulnerabilities.
Batch operation anxiety: Trying to run multiple INSERT or UPDATE statements in a single transaction can feel risky. Did you escape every value? Is the transaction truly atomic?
Configuration guesswork: Relying on environment variables can make your code's behavior unpredictable and difficult to test across different environments.

These were the core frustrations that led me to create mysql2-dx. It's not a new ORM; it's a "developer experience" layer built on top of mysql2 designed to solve these very problems. And today, I'm thrilled to announce a major leap forward with version 1.1.0.

This isn't just a bug fix release—it's a refactoring based on deep reflection and feedback from the community. We've focused on three key areas to make your data-layer code more robust and enjoyable to write.

1. Building Intelligent `WHERE` Clauses, Inspired by Prisma

Let's face it: writing conditional logic for a SQL WHERE clause can get complicated, fast. You might need a combination of AND and OR conditions, possibly nested several levels deep.

In mysql2-dx v1.0, we had a solution, but it wasn't as intuitive as it could be. For v1.1.0, we looked at how modern ORMs like Prisma handle this problem with elegance. We built a new, object-based API for WHERE clauses.

Old way (for WHERE (status = 'active' AND type = 'premium') OR (plan = 'free'))

// A hypothetical, less-than-ideal way
const sql = `WHERE status = ? AND type = ? OR plan = ?`;
const values = ['active', 'premium', 'free'];

This is fine, but it doesn't scale. What about nested OR conditions? You'd have to manage parentheses yourself, which is a recipe for bugs.

New, object-oriented way with mysql2-dx v1.1.0

import { where } from 'mysql2-dx';

const conditions = where({
  OR: [
    { status: 'active', type: 'premium' },
    { plan: 'free' }
  ]
});

// `conditions` now contains the SQL string and values, safely
// and intelligently generated.

This new approach is declarative and type-safe (especially with TypeScript!). It allows you to express your intent clearly, and the library handles the complex, error-prone task of generating the correct SQL and safely binding the parameters.

2. Atomic Batch Operations: Security and Integrity by Design

Handling multiple INSERT, UPDATE, or DELETE statements in a single operation can be a nightmare. In previous versions, while we had a batch function, it had a potential vulnerability related to parameter passing.

With this update, we completely rebuilt the batch processing mechanism. Now, every single batch operation is wrapped in a secure and atomic transaction.

This means that mysql2-dx guarantees that either all of your operations within the batch succeed, or none of them do. This is the "A" in ACID, and it's a fundamental pillar of data integrity. You can sleep better at night knowing that an error mid-way through a batch operation won't leave your database in an inconsistent state.

3. Full Control: Bidding Farewell to Implicit `env` Variables

A key principle in modern software development is predictability. The behavior of your code should be explicit and transparent.

In the past, mysql2-dx had a "magic" feature where it would automatically read database connection settings from your .env file if you didn't provide them explicitly. While this seemed convenient, it created an invisible dependency and made it difficult to reason about and test your application in different environments (e.g., CI/CD, production).

In version 1.1.0, we have removed this implicit behavior. You now must provide your connection configuration explicitly when you initialize the client.

import { createConnection } from 'mysql2-dx';

const connection = createConnection({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  // etc...
});

This change gives you 100% control over how your application connects to the database, eliminating surprises and making your code more robust and testable.

What's Next?

This release is a testament to the idea that true improvement often lies in refining the fundamentals. We didn't just add new features; we analyzed the existing ones and asked, "Can this be better? Simpler? Safer?"

I'm incredibly proud of the work that has gone into mysql2-dx v1.1.0 and I'm confident it will make your daily development work with MySQL much more efficient and secure.

I invite you to try out the new version and share your feedback. Your insights are what drive this project forward.

Check out the package for the full details and documentation! mysql2-dx on npm

#mysql
#nodejs
#database
#typescript
#opensource
#tutorial

CSS Layers: A New Frontier for Style Management

Wael Habbal — Mon, 19 Aug 2024 18:53:45 +0000

Introduction

While understanding specificity is essential, CSS Layers offer a fresh approach to managing styles. Think of layers as stacked sheets of paper, where the top sheet always takes precedence. This post explores the concept of CSS Layers, how they work, and how they can improve your CSS architecture.

Understanding CSS Layers

CSS Layers introduce a hierarchical structure to your stylesheets. Each layer is a distinct scope where styles are defined. When multiple layers affect an element, the style from the topmost layer takes precedence.

The Three Default Layers

Browsers typically have three default layers:

User Agent Layer: This layer contains default styles applied by the browser. You can override these styles with higher specificity selectors.
User Layer: This layer allows users to customize the appearance of websites. It's often used for accessibility or personal preferences.
Author Layer: This is where your stylesheets reside. You have full control over this layer.

Creating Author Layers

While browser support for author layers is still evolving, the concept is valuable for understanding how layers work. Imagine defining different layers using a hypothetical @layer at-rule:

@layer base {
  /* Base styles */
}

@layer components {
  /* Component-specific styles */
}

@layer utilities {
  /* Utility classes */
}

This structure allows you to organize your styles based on different concerns. Styles in higher layers override those in lower layers.

How Layers Impact Specificity

Layers add another dimension to specificity. A style in a higher layer will always override a style in a lower layer, regardless of specificity within the layer. This can simplify style management and reduce the need for extremely specific selectors.

Benefits of Using Layers

Improved organization: Clearly separate concerns within your CSS.
Enhanced maintainability: Isolate changes to specific layers.
Reduced specificity: Avoid overly specific selectors.
Potential performance benefits: Browsers might optimize layer-based CSS in the future.

Conclusion

CSS Layers represent a promising approach to style management. While browser support is still maturing, understanding the concept can help you write better CSS today. By combining layers with a solid grasp of specificity, you can create more organized, maintainable, and potentially performant stylesheets.

Would you like to explore other CSS-related topics?

CSS Specificity: The Weight Behind Your Styles

Wael Habbal — Mon, 19 Aug 2024 18:53:24 +0000

Introduction

Imagine CSS as a fashion show where different styles compete for attention. The winner? The style with the most "weight" or specificity. In this post, we'll unravel the mystery behind CSS specificity, explaining how it works and why it matters.

Understanding CSS Specificity

Specificity is a numerical value assigned to each CSS selector. It determines which style rule wins when multiple styles are applied to the same element. Think of it as a fashion contest where the most stylish outfit takes the spotlight.

How to Calculate Specificity

Specificity is calculated based on four factors:

Inline styles: Styles directly applied to an element using the style attribute. These have the highest specificity (1, 0, 0, 0).
IDs: Selectors using the #id syntax. Each ID contributes 100 points (0, 1, 0, 0).
Classes, attributes, and pseudo-classes: Selectors using .class, [attribute], or :pseudo-class contribute 10 points each (0, 0, 1, 0).
Elements and pseudo-elements: Selectors targeting elements (like p, div) or pseudo-elements (like ::before, ::after) contribute 1 point each (0, 0, 0, 1).

Example:

#my-id .my-class:hover has a specificity of (0, 1, 1, 0) or 110 points.
.my-class p has a specificity of (0, 0, 1, 1) or 11 points.

The rule with the highest specificity wins.

The Impact of Specificity

Overriding styles: More specific selectors can override less specific ones. For example, an inline style will always override a style defined in a stylesheet.
Unintended consequences: High specificity can make it difficult to override styles, leading to unexpected results.
Debugging: Understanding specificity helps pinpoint style conflicts and resolve them efficiently.

Real-world Examples

Let's say you have a button with the following styles:

button {
  color: blue;
}

.primary-button {
  color: red;
}

#important-button {
  color: green;
}

If the button has the classes primary-button and the ID important-button, the green color from the ID will be applied because it has the highest specificity.

Conclusion

CSS specificity can be a complex topic, but understanding it is crucial for mastering CSS. By grasping how specificity is calculated and its impact on style application, you'll be better equipped to create well-structured and predictable styles.

In the next post, we'll dive deeper into CSS layers, a powerful tool for managing specificity and improving your CSS architecture.

Partial Interface Implementation in C# Base/Abstract Classes

Wael Habbal — Wed, 07 Aug 2024 10:32:41 +0000

Understanding the Concept

Partial interface implementation involves an abstract class implementing an interface, providing concrete implementations for some interface members while leaving others abstract. This approach offers a balance between shared behavior and flexibility.

Key Benefits

Enforces a Common Contract: All derived classes must adhere to the interface's contract, ensuring consistency and predictability.
Promotes Code Reusability: Shared logic can be encapsulated in the base class, reducing redundancy.
Increases Flexibility: Abstract methods allow derived classes to provide specific implementations based on their requirements.
Improves Code Organization: Clear separation of concerns between shared and specific behavior.

Best Practices

Clear Separation of Concerns: Distinguish between shared and specific implementations.
Use virtual and abstract Keywords Wisely: Employ virtual for potentially overridable methods and abstract for mandatory overrides.
Consider Default Interface Methods (C# 8.0+): Provide default implementations for optional behavior.
Avoid Unnecessary Abstract Methods: Use abstract methods judiciously to prevent over-complex hierarchies.
Leverage Protected Members: Share implementation details among derived classes using protected members.
Thorough Testing: Verify correct behavior in both base and derived classes.

Real-World Example: Shape Hierarchy

interface IShape
{
    double CalculateArea();
    void Display();
}

abstract class Shape : IShape
{
    protected double Width { get; set; }
    protected double Height { get; set; }

    public Shape(double width, double height)
    {
        Width = width;
        Height = height;
    }

    public abstract double CalculateArea();

    public virtual void Display()
    {
        Console.WriteLine($"Width: {Width}, Height: {Height}");
    }
}

class Rectangle : Shape
{
    public Rectangle(double width, double height) : base(width, height) { }

    public override double CalculateArea() => Width * Height;
}

class Circle : Shape
{
    public override double CalculateArea() => Math.PI * Radius * Radius;
}

Additional Considerations

Interface Segregation Principle: Break down large interfaces into smaller, focused ones.
Dependency Injection: Manage dependencies effectively for testability.
Design Patterns: Explore patterns like Template Method or Strategy for complex scenarios.

By following these guidelines and understanding the underlying principles, you can effectively leverage partial interface implementation to create well-structured, maintainable, and flexible C# code.

C# 6 and Beyond: Revolutionizing Case Analysis with Pattern Matching

Wael Habbal — Wed, 24 Jul 2024 10:22:46 +0000

Introduction

C# has evolved significantly over the years, and one of the most impactful changes came with the introduction of pattern matching in C# 6. This feature, coupled with the enhanced switch expression in later versions, has dramatically improved the syntax, readability, and expressiveness of case analysis in C# code.

In this post, we'll delve deep into the world of pattern matching, exploring how it works, its various forms, and how it can be effectively used to write cleaner, more maintainable code.

The `is` Operator: A First Step

Before we dive into switch statements, let's understand the is operator, which laid the groundwork for pattern matching.

The is operator checks if an expression is compatible with a given type. If it is, it can optionally declare a variable of that type.

object shape = new Circle();
if (shape is Circle circle)
{
    // We can use 'circle' here, which is of type Circle
    Console.WriteLine($"Circle radius: {circle.Radius}");
}

This code checks if shape is a Circle. If so, it declares a new variable circle of type Circle and assigns the converted value to it.

The `switch` Statement: A New Era

C# 7 introduced significant improvements to the switch statement, allowing it to work with any type, not just integral types and strings. This, combined with pattern matching, opened up new possibilities.

object shape = new Rectangle();
switch (shape)
{
    case Circle c:
        Console.WriteLine($"Circle radius: {c.Radius}");
        break;
    case Rectangle r:
        Console.WriteLine($"Rectangle width: {r.Width}, height: {r.Height}");
        break;
    default:
        Console.WriteLine("Unknown shape");
        break;
}

In this example, the switch statement efficiently determines the type of the shape object and executes the appropriate code block.

Pattern Matching with the `switch` Expression

C# 8 introduced the switch expression, providing a more concise and functional-style syntax for pattern matching.

object shape = new Circle();
string result = shape switch
{
    Circle c => $"Circle with radius {c.Radius}",
    Rectangle r => $"Rectangle with width {r.Width} and height {r.Height}",
    _ => "Unknown shape"
};

The switch expression evaluates to a value based on the matched pattern.

Types of Patterns

C# supports various patterns, including:

Constant patterns: Match literal values.
Type patterns: Match types.
Var patterns: Match any type.
Discard patterns: Match any value and discard it.
Property patterns: Match property values.
Tuple patterns: Match tuple elements.
Positional patterns: Match elements by position.
Logical patterns: Combine patterns using and, or, and not.

Example: Using Different Patterns

int age = 25;
string message = age switch
{
    < 18 => "Minor",
    >= 18 and < 65 => "Adult",
    _ => "Senior"
};

This example demonstrates the use of constant, relational, and logical patterns.

Deconstruction and Pattern Matching

C# supports deconstruction, which can be combined with pattern matching to extract values from objects.

(int x, int y) point = (3, 4);
int result = point switch
{
    (0, 0) => 0,
    (var x, var y) when x == y => x * 2,
    (var x, var y) => x + y
};

Additional Features

Guard clauses: Use when to add conditions to patterns.
Multiple case labels: Combine multiple patterns with the same result.
Default case: Handle unmatched cases with the _ pattern.

Conclusion

Pattern matching is a powerful feature that significantly enhances C# code readability and maintainability. By understanding the different types of patterns and how to use them effectively, you can write cleaner, more expressive, and less error-prone code.

Remember: The key to mastering pattern matching is practice. Experiment with different patterns and scenarios to fully grasp its potential.

Would you like to explore specific use cases or dive deeper into any particular aspect of pattern matching?

C# String Interning: A Deep Dive

Wael Habbal — Tue, 23 Jul 2024 14:59:20 +0000

Understanding Strings as Reference Types

In C#, strings are fundamentally reference types. This means that a string variable doesn't directly hold the character data; instead, it holds a reference to an object in memory that represents the string. This characteristic has significant implications for string manipulation and memory usage.

The Magic of String Interning

String interning is an optimization technique employed by the C# runtime to conserve memory. It involves storing only one copy of each unique string literal in memory, rather than creating multiple instances. When you declare string literals within your code, the compiler typically interns them. This means that multiple variables can reference the same underlying string object.

How String Interning Impacts Memory

Memory Efficiency: By sharing a single instance of a string, interning significantly reduces memory consumption, especially in applications that heavily utilize strings.
Performance Implications: While interning can improve performance for string comparisons, it's essential to understand that the interning process itself has overhead. For dynamically generated strings, the benefits might not outweigh the costs.

The Interning Algorithm: A Closer Look

The exact implementation details of the string interning algorithm can vary across different .NET runtimes. However, the general idea is to maintain a hash table or similar data structure to store references to unique string objects. When a string is encountered, its hash code is calculated, and the intern pool is searched for a matching string. If found, the existing reference is returned; otherwise, a new string object is created and added to the pool.

When Does the Compiler Create a New String?

A new string object is created in the following scenarios:

String Concatenation: When you use the + operator to combine strings, a new string instance is always created (When both operands of the + operator for string concatenation are constant expressions, the C# compiler can indeed perform a compile-time concatenation and intern the resulting string. This optimization avoids creating a new string object at runtime, enhancing performance and memory efficiency).
String Modification Methods: Methods like Substring, ToUpper, ToLower, etc., return new string objects as strings are immutable.
Dynamically Created Strings: Strings constructed at runtime, for example, using StringBuilder or string formatting, are typically not interned.

String Comparisons and Interning

Comparing strings in C# involves reference equality and value equality.

Reference Equality: Using ReferenceEquals checks if two string variables refer to the same object in memory. For interned strings, this is equivalent to value equality.
Value Equality: The == operator performs a character-by-character comparison. For interned strings, this is often optimized due to sharing the same underlying object.

Immutability and String Behavior

C# strings are immutable, meaning their content cannot be changed after creation. Any operation that appears to modify a string actually creates a new string object. This immutability, combined with interning, ensures that string operations are thread-safe and predictable.

Example: Understanding String Behavior

string keep = "keep";
string coding = "coding";

string str1 = "keep coding";
string str2 = "keep coding";
string str3 = "keep" + " " + "coding";

string str4 = keep  + " "  + coding;
string str5 = keep  + " "  + coding;

Console.WriteLine(str1 == str2); //true
Console.WriteLine(str1 == str3); //true
Console.WriteLine(ReferenceEquals(str1, str2)); //true
Console.WriteLine(ReferenceEquals(str1, str3)); //true

Console.WriteLine(str1 == str5); //true
Console.WriteLine(str1 == str5); //true
Console.WriteLine(ReferenceEquals(str1, str5)); //false
Console.WriteLine(ReferenceEquals(str1, str5)); //false

Console.WriteLine(str4 == str5); //true
Console.WriteLine(str4 == str5); //true
Console.WriteLine(ReferenceEquals(str4, str5)); //false
Console.WriteLine(ReferenceEquals(str4, str5)); //false

Conclusion

Understanding string interning is crucial for writing efficient and memory-conscious C# code. By grasping the concepts of reference types, immutability, and the interning mechanism, you can make informed decisions about string manipulation and optimization.

Zero-Length Arrays: A Cornerstone of C# Development

Wael Habbal — Sun, 21 Jul 2024 17:57:05 +0000

In the rich tapestry of C# development, often overlooked but profoundly impactful is the seemingly innocuous zero-length array. While it might appear counterintuitive to have an array with no elements, it is a versatile tool that can significantly enhance code efficiency, readability, and maintainability. In this exploration, we will delve into the subtleties of zero-length arrays, uncovering their practical applications and the nuanced considerations surrounding their usage.

Understanding the Zero-Length Array

A zero-length array is a fixed-size collection that, by definition, contains no elements. It is declared like any other array, but with a length of zero:

int[] emptyArray = new int[0];

While it may seem trivial, this construct offers a foundation for several powerful programming paradigms.

Why Use a Zero-Length Array?

Immutable Empty Collection:
- Efficiency: Zero-length arrays can be reused indefinitely without incurring memory allocation overhead. This is particularly beneficial in scenarios where empty collections are frequently required, such as returning empty results from methods or properties.
- Immutability: Since arrays are inherently mutable, a zero-length array provides a convenient way to create an immutable empty collection. This can enhance thread safety and prevent accidental modifications.
Placeholder for Later Initialization:
- Deferred Allocation: In certain cases, the exact size of an array might not be known upfront. A zero-length array can serve as a placeholder, allowing for deferred allocation based on runtime conditions. This can optimize memory usage and prevent unnecessary allocations.
- Lazy Initialization: Combined with lazy evaluation techniques, zero-length arrays can be used to implement lazy initialization patterns, where array elements are populated only when needed. This can improve performance by avoiding unnecessary computations.
Method Signatures and Overloading:
- Flexibility: Method overloads that accept arrays can benefit from using a zero-length array as a default parameter value. This provides flexibility in calling the method with or without arguments.
- Consistent Return Types: When a method might return an array with varying lengths, including an empty array, using a zero-length array as the return type ensures consistency and avoids null checks.
Defensive Programming:
- Null Checks: By returning a zero-length array instead of null, you can eliminate potential NullReferenceExceptions. This improves code robustness and reduces the likelihood of runtime errors.
- Error Handling: In scenarios where an operation might fail to produce results, returning a zero-length array can signal an empty result set gracefully, without resorting to exceptions.

Real-World Use Cases

Data Structures: Zero-length arrays can be used as building blocks for more complex data structures, such as sparse matrices or custom collections.
Configuration Management: When loading configuration data from external sources, a zero-length array can represent an empty configuration.
Caching: In caching mechanisms, a zero-length array can indicate a cache miss or an empty cache entry.
Asynchronous Programming: In asynchronous operations, a zero-length array can be used as a placeholder for results that might be available later.
Unit Testing: Zero-length arrays can be employed to create test cases with various input conditions, including empty arrays.

Beyond the Basics: Considerations and Best Practices

Performance: While zero-length arrays are generally efficient, it's essential to profile your code to identify performance bottlenecks. In some cases, using Array.Empty<T>() might offer additional performance benefits.
Clarity: While zero-length arrays can be powerful, use them judiciously to avoid obscuring code readability. Clearly document the intent behind their usage.
Alternatives: Consider alternative data structures like List<T> or IEnumerable<T> if dynamic resizing or functional-style operations are required.

Conclusion

The zero-length array, often overlooked, is a versatile tool in the C# developer's arsenal. By understanding its nuances and applications, you can write more efficient, robust, and expressive code. By embracing this seemingly simple construct, you can unlock new possibilities and elevate your C# development to new heights.

Would you like to explore specific use cases or delve deeper into any particular aspect of zero-length arrays?

Records in C#: A Deep Dive

Wael Habbal — Wed, 17 Jul 2024 16:36:30 +0000

Understanding Records

Introduced in C# 9, records provide a concise and immutable syntax for creating data-oriented types. Unlike classes, records are primarily focused on data encapsulation rather than behavior. They offer a powerful mechanism for modeling entities with well-defined properties.

Record vs. Record Struct

At their core, records and record structs share similar syntax and immutability. However, they differ significantly in terms of value semantics and memory management:

Record Struct: Represents a value type, similar to structs. Each instance occupies its own memory space, and assignments create copies. They are ideal for small, immutable data structures.
Record: Represents a reference type, similar to classes. Instances share a reference, and assignments create aliases. They are suitable for larger, complex data structures.

Readonly Record and Ref Readonly Record

To further refine the behavior of records, C# provides two additional modifiers:

Readonly Record: Guarantees that the record instance itself cannot be modified after creation. However, its properties can still be mutable if they are reference types.
Ref Readonly Record: Ensures both the record instance and its properties are immutable. This provides the highest level of immutability.

Implementation Details: IL Perspective

Under the hood, records and record structs are compiled into IL (Intermediate Language) with distinct characteristics:

Record Structs: Compiled as value types, similar to regular structs. They support value semantics and are directly inlined in method calls for performance optimization.
Records: Compiled as reference types, similar to classes. They have additional metadata to support equality, deconstruction, and other record-specific features.

Real-World Use Cases

Record Structs:
- Small, immutable data structures like points, vectors, colors.
- Performance-critical calculations where value semantics are essential.
Records:
- Complex data models with hierarchical relationships.
- Immutable domain entities in DDD (Domain-Driven Design).
- Configuration objects.
Readonly Records:
- Immutable configuration settings.
- Data transfer objects (DTOs) to prevent accidental modifications.
Ref Readonly Records:
- Immutable data structures shared across threads without synchronization.
- High-performance computations where immutability is critical.

Key Considerations

Performance: Record structs generally offer better performance due to value semantics and inlining.
Immutability: Readonly and ref readonly records provide varying levels of immutability based on your requirements.
Memory Usage: Record structs are more memory-efficient due to value semantics.
Complexity: Records offer more features and flexibility compared to record structs.

Specific Use Cases for Records and Record Structs

Record Structs: Ideal for Value Types

Geometry:
- Points, vectors, and other geometric primitives are excellent candidates for record structs due to their value semantics and performance implications.
- Example:
```
public record struct Point(double X, double Y);
```
Color Representations:
- RGB, HSV, or CMYK color models can be efficiently represented as record structs.
- Example:
```
public record struct Color(byte R, byte G, byte B);
```
Immutable Data Transfer Objects (DTOs):
- For small, immutable data structures passed between components, record structs can be used to enhance performance.
- Example:
```
public record struct Address(string Street, string City, string ZipCode);
```

Records: Ideal for Reference Types

Domain Models:
- In Domain-Driven Design (DDD), records can represent entities and value objects effectively.
- Example:
```
public record Order(int OrderId, DateTime OrderDate, List<OrderItem> Items);
```
Configuration Objects:
- Records can be used to encapsulate application settings with immutability.
- Example:
```
public record AppSettings(string ConnectionString, int MaxConnections);
```
Immutable Data Transfer Objects (DTOs):
- For larger, complex data structures, records provide a suitable option.
- Example:
```
public record Customer(int CustomerId, string Name, Address Address);
```
Event Sourcing:
- Records can represent events in an event-sourced system, ensuring immutability.
- Example:
```
public record OrderPlaced(int OrderId, decimal Total);
```

Readonly Records: Enforcing Immutability

Configuration Objects:
- To prevent accidental modifications to configuration settings.
- Example:
```
public readonly record AppSettings(string ConnectionString, int MaxConnections);
```
DTO Contracts:
- To ensure that data transferred between components remains unchanged.
- Example:
```
public readonly record CustomerDto(int Id, string Name);
```

Ref Readonly Records: Ultimate Immutability

Shared Immutable Data:
- For scenarios where data needs to be shared across threads without synchronization, ref readonly records provide a safe and efficient option.
- Example:
```
public ref readonly record struct Point(double X, double Y);
```

Remember:

Choose record structs for small, value-type-like data structures where performance is critical.
Use records for reference type-like data structures with richer behavior.
Employ readonly and ref readonly modifiers for specific immutability requirements.

By carefully considering these use cases and the underlying characteristics of records and record structs, you can make informed decisions about their application in your C# code.

Specific Scenarios and Challenges with Records

Complex Data Structures and Immutability

Deeply nested records: When dealing with complex hierarchical data structures, using records can become challenging due to the inherent immutability. Consider using a combination of records and mutable collections within them for flexibility.
- Example: A Product record with a List<Review> property. The Product itself is immutable, but the List<Review> can be modified.
Performance implications: While immutability offers benefits, it can impact performance in certain scenarios, especially when creating new instances frequently. Consider using with expressions for efficient updates.
- Example: Updating a Product's price:
```
var updatedProduct = product with { Price = newPrice };
```

Inheritance and Polymorphism

Record inheritance limitations: Unlike classes, records have limited inheritance capabilities. Consider using interfaces or composition for achieving polymorphic behavior.
- Example: Using interfaces to define common properties and methods for different record types.
Virtual methods and overrides: Records cannot have virtual methods, which can restrict certain design patterns. Explore alternative approaches like interfaces or extension methods.

Equality and Comparison

Custom equality logic: While records provide default equality based on property values, you might need to implement custom equality logic in specific cases.
- Example: Implementing IEquatable<T> for custom comparison logic.
Performance considerations: Be aware of potential performance implications when comparing complex record instances. Consider using IEquatable<T> and optimizing equality checks.

Null Reference Exceptions

Null propagation operator: Use the null-conditional operator (?.), null-coalescing operator (??), and null-conditional member access (?.Member) to handle potential null values gracefully.
- Example: customer?.Address?.City

Serialization and Deserialization

Custom serialization: For complex record structures, custom serialization might be required to control the serialization process.
- Example: Implementing ISerializable or using a custom JSON converter.

When to Avoid Records

Performance-critical scenarios: If performance is paramount and frequent object creation is a bottleneck, consider using structs or value types instead of records.
Mutable state: If the data model requires frequent modifications, records might not be the best fit. Consider using mutable classes or structs.

Best Practices

Use records for data-centric types with immutable properties.
Consider using record structs for small, value-type-like data structures.
Leverage with expressions for efficient updates.
Be mindful of performance implications when creating numerous record instances.
Implement custom equality logic when necessary.
Handle null references carefully.
Test your record-based code thoroughly.

Conclusion

Records and record structs are powerful additions to the C# language, providing a concise and efficient way to model data. By understanding the differences between them and the available modifiers, you can make informed decisions about when to use each type in your applications.

Mastering C# Switch Expressions and Pattern Matching: A Practical Guide

Wael Habbal — Tue, 16 Jul 2024 15:10:45 +0000

Introduction

As seasoned C# developers, we've all used switch statements to make decisions based on values. C# 7.0 introduced pattern matching, and C# 12 took it a step further with switch expressions. This powerful combination enhances code readability, maintainability, and expressiveness, especially when dealing with complex logic and diverse input types.

Demystifying Switch Expressions and Pattern Matching

Switch Expressions

Switch expressions are a concise and expressive alternative to traditional switch statements. They allow you to return a value directly from a case, making them ideal for scenarios where you need a result based on the matched pattern. Here's the basic syntax:

expression switch
{
    pattern1 => value1,
    pattern2 => value2,
    // ... more patterns
    _ => default  // Optional default case
}

expression: The value to be matched against the patterns.
pattern: A pattern that specifies the conditions for a case to match.
value: The value to return if the expression matches the pattern.
_: The discard pattern, used as a catch-all for unmatched cases.
default: An optional default case that executes if no pattern matches.

Pattern Matching

Pattern matching is the core concept at play here. It allows you to compare an expression against different patterns and take corresponding actions. C# supports a rich set of patterns, including:

Constant Pattern: Matches against a specific constant value.

dayOfWeek switch
{
    DayOfWeek.Monday => "Start of the week blues",
    DayOfWeek.Friday => "TGIF!",
    // ... other weekdays
}

Type Pattern: Matches against a specific type.

object obj = "...";
if (obj is string str)
{
    Console.WriteLine($"String value: {str}");
}
else if (obj is int i)
{
    Console.WriteLine($"Integer value: {i}");
}

Relational Pattern: Matches based on a relational operator (<, >, <=, >=, ==, !=).

int age = 25;
switch (age)
{
    case < 18:
        Console.WriteLine("Not eligible to vote");
        break;
    case >= 18:
        Console.WriteLine("Eligible to vote");
        break;
}

Property Pattern: Matches based on the value of a property.

class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

Person person = new Person { Name = "Alice", Age = 30 };
switch (person)
{
    case Person p when p.Age >= 18:
        Console.WriteLine($"{p.Name} is an adult");
        break;
    default:
        Console.WriteLine($"{person.Name} is not an adult");
        break;
}

Discard Pattern (_): Captures a value but doesn't use it (useful for cases where the value isn't needed).

switch (Console.ReadLine())
{
    case _:  // Handle any input
        Console.WriteLine("Input received");
        break;
}

Logical AND (&), OR (|), and NOT (!): Combine patterns for complex matching.

string input = "...";
switch (input)
{
    case string s when s.StartsWith("Hello") && s.EndsWith("World"):
        Console.WriteLine("Greeting received");
        break;
    case string s when s.Length > 10 | s.Contains("!"):
        Console.WriteLine("Long or emphatic input");
        break;
}

Real-World Use Cases of C# Switch Expressions and Pattern Matching

In the realm of practical C# development, switch expressions and pattern matching shine in various scenarios. Let's delve into some compelling examples:

1. Data Validation and Processing

Robust Input Handling: When dealing with user input, you can leverage switch expressions to ensure data integrity. Validate input types and extract meaningful values:

  string input = Console.ReadLine();
  switch (input)
  {
      case int i:
          Console.WriteLine($"Integer value: {i}");
          // Perform integer-specific operations
          break;
      case double d:
          Console.WriteLine($"Double value: {d}");
          // Perform double-specific operations
          break;
      case string s when s.Length > 0:  // Handle non-empty strings
          Console.WriteLine($"String value: {s}");
          // Perform string-specific operations
          break;
      default:
          Console.WriteLine("Invalid input. Please enter a number or a string.");
          break;
  }

Complex Data Structures: When working with complex data structures like enum or custom types, pattern matching allows for concise and readable validation and processing:

  enum FileOperation
  {
      Create,
      Read,
      Update,
      Delete
  }

  FileOperation operation = GetFileOperationFromUser();  // Function to get user input

  switch (operation)
  {
      case FileOperation.Create:
          CreateFile();
          break;
      case FileOperation.Read:
          ReadFile();
          break;
      case FileOperation.Update: when CanUpdateFile():  // Conditional update
          UpdateFile();
          break;
      case FileOperation.Delete:
          DeleteFile();
          break;
      default:
          Console.WriteLine("Invalid operation selected.");
          break;
  }

2. State Management and Flow Control

Encapsulated State Machines: Simplify state management logic by utilizing switch expressions for transitions based on events or conditions:

  enum GameState
  {
      StartMenu,
      Playing,
      GameOver
  }

  GameState currentState = GameState.StartMenu;

  while (true)
  {
      GameState nextState = currentState;
      switch (currentState)
      {
          case GameState.StartMenu:
              if (HandleStartMenuInput())
              {
                  nextState = GameState.Playing;
              }
              break;
          case GameState.Playing:
              if (IsGameOver())
              {
                  nextState = GameState.GameOver;
              }
              // ... handle game logic
              break;
          case GameState.GameOver:
              if (HandleGameOverInput())
              {
                  nextState = GameState.StartMenu; // Or other options
              }
              break;
      }

      currentState = nextState;
  }

3. Configuration Parsing and Deserialization

Flexible Configuration Handling: When parsing configuration files or deserializing data, switch expressions offer a clean way to handle different data formats or missing values:

  IConfiguration config = LoadConfiguration();

  switch (config)
  {
      case IConfigurationSection section:
          string value = section.Value;  // Access configuration values
          break;
      case null:
          Console.WriteLine("Configuration not found.");
          break;
      default:
          Console.WriteLine("Invalid configuration format.");
          break;
  }

By effectively combining switch expressions and pattern matching, you can create more readable, maintainable, and expressive code in various C# applications.

Demystifying C# Data Structures: A Veteran Developer's Guide

Wael Habbal — Mon, 08 Jul 2024 11:58:17 +0000

Greetings, fellow coders! In the ever-evolving realm of C#, choosing the right data structure can feel like navigating a labyrinth. Fear not, for I, a seasoned developer with countless lines of code under my belt, am here to illuminate the intricacies of classes, structs, records, readonly structs, and readonly ref structs. Buckle up, and prepare to have your understanding of C# data structures reach new heights!

The Classic Contender: The Class

Ah, the class – the cornerstone of object-oriented programming. Classes are like blueprints, defining the properties (data) and methods (behaviors) that objects of that class will possess. Think of them as blueprints for houses: you define the rooms (properties) and what happens in those rooms (methods), and then you can create multiple houses (objects) based on that blueprint.

Real-World Use Case: Imagine a Customer class. It would have properties like Name, Address, and Email, and methods like PlaceOrder and UpdateProfile. Each Customer object would then hold specific information for a particular customer.

When to Choose a Class:

When you need inheritance – classes can inherit properties and methods from other classes, promoting code reuse.
When you need reference semantics – classes are stored on the heap, meaning changes to one object don't affect others (unlike structs, which we'll discuss next).
When you need complex behavior – classes excel at encapsulating data and logic, making them ideal for representing real-world entities.

The Lightweight Champion: The Struct

Structs are value types, meaning they hold their data directly within the variable itself. Think of them as self-contained units, like coins in your pocket. Unlike classes, structs live on the stack, a faster-access memory region.

Real-World Use Case: A Point struct could hold X and Y coordinates, perfect for representing a point in 2D space.

When to Choose a Struct:

When you need small, efficient data containers – structs are ideal for simple data like points, colors, or coordinates.
When you need value semantics – changes to one struct variable don't affect others, as they're separate copies.
When performance is critical – stack allocation for structs can be faster than heap allocation for classes.

The New Kid on the Block: The Record

C# 9 introduced records, a game-changer for value types. Records combine the best of both worlds: they offer value semantics like structs but come with built-in functionality for equality comparison, immutability (by default), and deconstruction. It's like having a pre-packaged value type with all the bells and whistles!

Real-World Use Case: A Person record could hold Name, Age, and a calculated IsAdult property. Records are perfect for immutable data that needs these built-in features.

When to Choose a Record:

When you need value semantics with built-in functionality – records provide a clean and efficient way to handle data that doesn't need to change.
When you want immutability by default – records are immutable unless you explicitly define setters.
When you need deconstruction – records provide a convenient way to unpack their properties into variables.

The Efficiency Enhancer: The Readonly Struct

Readonly structs are a variation of structs specifically designed for scenarios where you know the data won't change after initialization. They offer the same benefits as structs (value semantics, stack allocation) but prevent accidental modifications.

Real-World Use Case: A Rectangle struct could be marked as readonly, ensuring its dimensions remain fixed after creation.

When to Choose a Readonly Struct:

When you have data that shouldn't be modified after creation – readonly structs enforce immutability, preventing unintended side effects.
When you want to optimize performance – readonly structs avoid the overhead of checking for modifications, potentially leading to slight performance gains.

The Speedy Specialist: The Readonly Ref Struct

Readonly ref structs, introduced in C# 7.2, are a powerful but niche concept. They offer the benefits of readonly structs (value semantics, immutability) with the ability to be passed to functions by reference. This can be particularly useful for performance-critical scenarios where avoiding unnecessary copies is paramount.

Real-World Use Case: A large Matrix struct could be marked as readonly ref, allowing functions to operate on the data directly without creating copies, potentially improving performance.

When to Choose a Readonly Ref Struct:

When you need to pass large, immutable data by reference – readonly ref structs provide a way to avoid copying while maintaining immutability.
When performance is absolutely critical – understanding the intricacies of readonly ref

Decoding the Conversation: A Deep Dive into Request and Response Objects in JavaScript

Wael Habbal — Sun, 07 Jul 2024 12:47:14 +0000

Imagine a lively exchange between a user and your web application. The user interacts with the interface, their actions sparking a conversation behind the scenes. This communication happens through Request and Response objects, the unsung heroes of web development.

Initiating the Dialogue: The Request Object

Think of the request object as the user raising their hand and asking a question. It carries details about what they want from the server:

The URL (required): This is the specific address on the server, like a room number in a building (e.g., https://api.example.com/data).
The Method (required): This tells the server what kind of action the user is requesting:
- GET: Asking a question, requesting information (e.g., fetching data).
- POST: Making a statement, sending new data (e.g., submitting a form).
- PUT: Updating something specific, modifying existing data.
- DELETE: Throwing something away, removing data from the server.
The Headers (optional): Additional details that provide context, like side notes or instructions. Some common headers include:
- Content-Type: Telling the server what kind of data is being sent (e.g., text, JSON).
- Authorization: Checking if the user has permission to access certain resources.
The Body (optional): For actions like POST and PUT, the user might send additional data (e.g., form submission details).

Crafting the Request Object:

In modern JavaScript, we often use the fetch API to construct the request object, specifying the URL, method, headers, and body in a clear way.

Example: Fetching Data from a Server

fetch('https://api.example.com/data', {
  method: 'GET',
  headers: {
    'Content-Type': 'application/json'
  }
})
.then(response => response.json()) // Parse response as JSON (if applicable)
.then(data => {
  // Process the received data (e.g., update the user interface)
})
.catch(error => {
  // Handle errors, like network issues or server errors
});

The Server Responds: The Response Object

The server receives the request object, processes it, and sends a response object back to the user's browser. This response is the server's answer or reaction:

The Status Code: A three-digit number indicating the request's outcome:
- 200 OK: Success, the server has data to send back.
- 404 Not Found: The requested resource couldn't be found.
- 500 Internal Server Error: An error occurred on the server.
The Headers: Additional information from the server, like instructions for the browser.
The Body (optional): Depending on the request and response, the body might contain:
- Requested data (e.g., fetched information).
- An error message.
- A redirect instruction telling the browser to go to a different location.

Understanding the Response Object:

On the frontend, we typically use the then and catch methods of the fetch promise to process the response object. We can check the status code, access any headers, and parse the body (often as JSON) to extract the data or handle errors.

Key Takeaways:

Requests and responses are the foundation of web communication.
Understand the different parts of these objects for meaningful interactions.
Focus on common methods, headers, and status codes for efficient communication.
Practice with examples to solidify your understanding.

Remember: By mastering these concepts, you'll be well-equipped to build web applications that seamlessly communicate with servers in JavaScript!

DEV Community: Wael Habbal

Next.js and the Edge Runtime: A Guide for Full-Stack Developers

What is the Edge Runtime?

Key Characteristics

Why Vercel Created the Edge Runtime

Limitations of the Edge Runtime

Next.js Middleware: The Runtime Evolution (Next.js 15.x)

The New Node.js Support in Middleware

When to Use Edge Runtime in Middleware

When to Use Node.js Runtime in Middleware

How We Reimagined SQL Query Building to Be Smarter, Safer, and Simpler (Introducing `mysql2-dx` v1.1.0)

1. Building Intelligent WHERE Clauses, Inspired by Prisma

2. Atomic Batch Operations: Security and Integrity by Design

3. Full Control: Bidding Farewell to Implicit env Variables

What's Next?

CSS Layers: A New Frontier for Style Management

Introduction

Understanding CSS Layers

The Three Default Layers

Creating Author Layers

How Layers Impact Specificity

Benefits of Using Layers

Conclusion

CSS Specificity: The Weight Behind Your Styles

Introduction

Understanding CSS Specificity

How to Calculate Specificity

The Impact of Specificity

Real-world Examples

Conclusion

Partial Interface Implementation in C# Base/Abstract Classes

Understanding the Concept

Key Benefits

Best Practices

Real-World Example: Shape Hierarchy

Additional Considerations

C# 6 and Beyond: Revolutionizing Case Analysis with Pattern Matching

Introduction

The is Operator: A First Step

The switch Statement: A New Era

Pattern Matching with the switch Expression

Types of Patterns

Example: Using Different Patterns

Deconstruction and Pattern Matching

Additional Features

Conclusion

C# String Interning: A Deep Dive

Understanding Strings as Reference Types

The Magic of String Interning

How String Interning Impacts Memory

The Interning Algorithm: A Closer Look

When Does the Compiler Create a New String?

String Comparisons and Interning

Immutability and String Behavior

Example: Understanding String Behavior

Conclusion

Zero-Length Arrays: A Cornerstone of C# Development

Understanding the Zero-Length Array

Why Use a Zero-Length Array?

Real-World Use Cases

Beyond the Basics: Considerations and Best Practices

Conclusion

Records in C#: A Deep Dive

Understanding Records

Record vs. Record Struct

Readonly Record and Ref Readonly Record

Implementation Details: IL Perspective

Real-World Use Cases

Key Considerations

Specific Use Cases for Records and Record Structs

Record Structs: Ideal for Value Types

Records: Ideal for Reference Types

Readonly Records: Enforcing Immutability

Ref Readonly Records: Ultimate Immutability

Specific Scenarios and Challenges with Records

Complex Data Structures and Immutability

Inheritance and Polymorphism

Equality and Comparison

Null Reference Exceptions

Serialization and Deserialization

1. Building Intelligent `WHERE` Clauses, Inspired by Prisma

3. Full Control: Bidding Farewell to Implicit `env` Variables

The `is` Operator: A First Step

The `switch` Statement: A New Era

Pattern Matching with the `switch` Expression