1. JSON-based configuration files (e.g., appsettings.json)

2. Secrets stored in Azure Key Vault

3. Centralized configuration & feature flags in Azure App Configuration

Let’s look at exactly what works, what doesn’t, and the gotchas you need to know.

1. Hot-Reloading JSON Configuration Files (No App Restart Needed)

By default, most ASP.NET Core templates already enable hot reload for appsettings.json — you just have to use the right options pattern.

✅ How It Works Out of the Box

When you create a project with:

C#

var builder = WebApplication.CreateBuilder(args);

The default host builder automatically registers your JSON files with reloadOnChange: true:

C#

builder.Configuration
    .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
    .AddJsonFile($"appsettings.{builder.Environment.EnvironmentName}.json", optional: true, reloadOnChange: true);

This sets up a file system watcher. As soon as the file changes on disk, the IConfigurationRoot is refreshed.

✅ How to Read the Latest Values

You have two good options:

Example:

C#

public class MyService
{
    private readonly MySettings _settings;

    // Updates immediately when file changes
    public MyService(IOptionsMonitor<MySettings> settings)
    {
        _settings = settings.CurrentValue;

        // Optional: react to future changes
        settings.OnChange(updatedSettings => {
            _settings = updatedSettings;
            // Trigger whatever logic you need
        });
    }
}

❌ What Does NOT Work

Limitations of JSON Hot Reload

Only JSON files added via AddJsonFile(..., reloadOnChange: true) support this. The following sources are static (loaded once at startup):

• Environment variables

• Command-line arguments

• User secrets (in development)

• Most other providers (Azure App Configuration has its own mechanism, etc.)

2. Hot-Reloading Secrets from Azure Key Vault (Dynamic Refresh)

Storing secrets directly in appsettings.json or user secrets is convenient for development, but in production you usually want them in Azure Key Vault. The good news: you can make those secrets refresh automatically too.

✅ How to Enable Periodic Refresh

C#

builder.Configuration.AddAzureKeyVault(
    new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"),
    new DefaultAzureCredential(),
    new AzureKeyVaultConfigurationOptions
    {
        ReloadInterval = TimeSpan.FromMinutes(10),   // ← critical line
        Manager = new KeyVaultSecretManager()       // optional: prefix filtering, etc.
    });

The ReloadInterval property is what turns one-time loading into periodic polling.

How the Polling Works

• Every ReloadInterval, the provider queries Key Vault for the current version of each secret it previously loaded.

• Azure only transfers the secret value if the version has actually changed.

• When a new version is detected → the entire configuration root is refreshed → IOptionsMonitor<T> and IOptionsSnapshot<T> pick up the new values exactly like JSON file changes.

✅ Recommended Options Pattern.

Again, use IOptionsMonitor<T> for instant updates (great for background services that read secrets) or IOptionsSnapshot<T> for per-request freshness.

⚠️ Important Operational Considerations

❌ What Does NOT Refresh Automatically

3. Hot-Reloading Azure App Configuration (The Most Powerful Option)

Azure App Configuration is the go-to service for centralized config, feature flags, and Key Vault references. It supports true dynamic refresh without restarting your app — and it’s smarter than simple polling.

✅ How to Enable It

C#

builder.Configuration.AddAzureAppConfiguration(options =>
{
    options.Connect(connectionString)
           // Register keys you want to watch (or use a sentinel pattern)
           .ConfigureRefresh(refresh =>
           {
               // Option 1: Watch a single "sentinel" key (recommended)
               refresh.Register("Sentinel", refreshAll: true)
                      .SetCacheExpiration(TimeSpan.FromMinutes(5));

               // Option 2: Watch individual keys (less efficient)
               // refresh.Register("MyApp:Settings:BackgroundColor", refreshAll: false);
           });

    // Optional: trigger refresh on every request (web apps)
    // options.UseFeatureFlags();
});

For web apps, add the refresh middleware (triggers on each request):

C#

app.UseAzureAppConfiguration();

How the Sentinel Pattern Works (Best Practice)

1. Create a dummy key in App Configuration called Sentinel (value can be a version number or timestamp).

2. Your app checks this key periodically (based on cache expiration).

3. When you need to push a new config:

   • Update all your real keys first.

   • Finally update Sentinel → your app detects the change → reloads everything exactly once.

4. New values instantly appear via IOptionsMonitor<T> / IOptionsSnapshot<T>.

This avoids polling every single key and gives you atomic, consistent updates.

✅ Same Options Pattern Applies

Use IOptionsMonitor<T> (immediate) or IOptionsSnapshot<T> (per-request) — exactly like JSON and Key Vault.

⚠️ Important Notes

❌ What Does NOT Refresh

• Not registering any keys for refresh

• Forgetting app.UseAzureAppConfiguration() in web apps

• Using plain IConfiguration.GetValue<T>() without the options pattern

Quick Checklist: “Can I Change This Without a Restart?”

Final Thoughts

Hot-reloading configuration is one of those small features that has an outsized impact on operations and developer happiness.

• Most apps get JSON hot reload for free.

• Add one line for Key Vault polling when you need simple secret rotation.

• Switch to Azure App Configuration with the sentinel pattern when you want centralized config, feature flags, and atomic zero-downtime updates.

Pick the approach that fits your app — and never restart again just to change a setting or rotate a secret! 🚀

1. Request Body

The request body is where you typically put the bulk of the data you're sending to the server. It's common in methods like POST, PUT, and PATCH, which are used for creating or updating resources.

Example:

text

POST /api/users
Content-Type: application/json

{
  "name": "Kris",
  "email": "kris@example.com"
}

Common use:

• Sending structured or complex data, such as JSON objects, arrays, or files in create or update operations.

When to use:

• When you need to transmit detailed payloads that don't fit well in the URL.

• It keeps sensitive information out of the URL, which isn't visible in logs or browser history.

• Servers don't cache or log bodies by default, adding a layer of security.

When to avoid it:

• Don't use it with GET requests, as those are for retrieving data, not sending it. Some servers might even reject bodies in GETs.

2. Query Parameters

Query parameters go in the URL after a question mark (?). They're straightforward for adding extra details like filters or pagination.

Example:

text

GET /api/users?role=admin&page=2

Common use:

• Applying filters, handling pagination, or passing optional flags in read operations.

When to use:

• They're easy to implement, test, and modify—just tweak the URL.

• Great for optional values or small bits of information that refine a request.

When to avoid it:

• Skip them for sensitive data like passwords or API keys, since URLs can be logged or shared.

• Avoid them for large or nested data; URLs have length limits (around 2,000 characters in practice), and they can quickly become unreadable.

3. HTTP Headers

Headers provide metadata about the request itself, rather than the core data. They're commonly used for authentication, specifying formats, or other instructions.

Example:

text

GET /api/profile
Authorization: Bearer eyJhbGciOiJI...
Accept-Language: en-US

Common use:

• Handling authentication, content negotiation, or localization settings.

When to use:

• They separate control information from the main payload, keeping things organized.

• Essential for things like auth tokens, content types, or client preferences.

When to avoid it:

• Don't stuff application-specific data into headers; that's not their purpose and can complicate things.

• Stick to standard headers when possible—custom ones should only be added if they solve a specific problem.

4. Path Parameters

Path parameters are embedded right in the URL path, helping identify specific resources in a clean way. They align well with RESTful API designs.

Example:

text

GET /api/users/42

Common use:

• Specifying unique identifiers for resources in RESTful endpoints.

When to use:

• It makes the endpoint clear and human-readable, showing exactly what resource is being targeted.

• Perfect for required identifiers, like user IDs or product codes.

When to avoid it:

• Not for optional filters or search criteria—use query parameters for those.

• Keep them simple; too many can make routes hard to manage.

Choosing the Right Approach

Here's a quick reference table to help decide:

If you're unsure, consider the data's purpose:

• Does it specify the exact resource? → Path parameter.

• Is it an optional refinement? → Query parameter.

• Is it the actual content being sent? → Body.

• Does it provide instructions or context? → Header.

Final Notes

Well-designed APIs are straightforward and consistent, so developers (including future you) don't have to second-guess where things go. Sticking to these conventions not only makes your code cleaner but also simplifies documentation and integration with clients. If you're building or using an API, start with these basics and adjust based on your specific needs.

In my early days as a software engineer, I viewed coding as a superpower—a tool to transform ideas into reality with speed and precision. My enthusiasm often led me to dive headfirst into writing code, believing that more lines equaled better solutions. However, I quickly learned that this approach was flawed. Hours of coding sometimes resulted in minimal impact, leaving me frustrated and inefficient. This experience taught me a valuable lesson: understanding the problem and planning thoroughly before coding is the key to delivering impactful solutions.

The Analogy of Building a House

Software development is much like constructing a house. You wouldn’t start laying bricks without a blueprint, as it risks wasting time, money, and energy on a structure that may not meet your needs. A blueprint provides a clear vision of the final product, allowing adjustments before construction begins. Similarly, in software engineering, a well-defined plan ensures that the solution aligns with the problem, saving resources and maximizing efficiency.

The Role of a Software Engineer

Our role as software engineers extends beyond writing code. We are problem-solvers, leveraging technology to address challenges effectively. Coding is merely the final step in a process that begins with understanding the problem and designing a solution. Learning about system analysis transformed my approach, helping me become a more effective developer. By prioritizing planning, I could deliver solutions that were both efficient and impactful.

A Structured Approach to Software Development

To optimize my workflow, I follow these steps before writing a single line of code:

1. Map the Workflow: Create a detailed flowchart for each feature to visualize the process and ensure clarity.

2. Validate with Stakeholders: Confirm the approach with clients or product managers to align on the problem and proposed solution.

3. Assess and Mitigate Risks: Identify potential risks in the approach, choosing the path with minimal risk or ensuring risks are manageable.

4. Document Everything: Maintain comprehensive, up-to-date documentation of the process to track decisions and progress.

This methodical approach has streamlined my coding process, reduced wasted effort, and consistently delivered solutions that meet client needs.

Conclusion

Effective software development begins with understanding, not coding. By treating planning as a blueprint for success, we can save time, reduce costs, and build solutions that truly address the problem at hand. Adopting a structured approach—mapping workflows, validating with stakeholders, mitigating risks, and documenting thoroughly—empowers developers to code with purpose and efficiency. Before you build, take the time to plan. Your future self, your team, and your clients will thank you.

The Problem: Rigid Discount Logic

Imagine you’re building an e-commerce system where customers get discounts based on their membership tier (Silver, Gold, Platinum). Initially, you might be tempted to write a big if-else block to handle different discount calculations:

public decimal CalculateDiscount(string membershipType, decimal amount)
{
    if (membershipType == "Silver")
        return amount * 0.05m;
    else if (membershipType == "Gold")
        return amount * 0.10m;
    else if (membershipType == "Platinum")
        return amount * 0.15m;
    else
        return 0;
}

This works for a small system, but it’s a maintenance nightmare. Adding a new membership tier means cracking open the code and adding another else if. That’s exactly what OCP tells us to avoid—modifying existing code for new functionality. Plus, it’s hard to test and scale. Enter the Strategy and Factory patterns.

Step 1: Define the Strategy with an Interface

The Strategy Pattern lets us define a family of algorithms (in this case, discount calculations), encapsulate each one, and make them interchangeable. We start by creating an interface that all discount policies will follow:

internal interface IDiscountPolicy
{
    decimal CalculateDiscount(decimal amount);
}

This interface is the contract. Any discount policy we create must implement CalculateDiscount and return a decimal. This keeps things clean and ensures all policies are interchangeable.

Step 2: Implement Concrete Strategies

Now, let’s create the actual discount policies for each membership tier. Each policy implements the IDiscountPolicy interface and defines its own discount logic:

internal class DiscountSilverPolicy : IDiscountPolicy
{
    public decimal CalculateDiscount(decimal amount)
    {
        return amount * 0.05m;
    }
}

internal class DiscountGoldPolicy : IDiscountPolicy
{
    public decimal CalculateDiscount(decimal amount)
    {
        return amount * 0.10m;
    }
}

internal class DiscountPlatinumPolicy : IDiscountPolicy
{
    public decimal CalculateDiscount(decimal amount)
    {
        return amount * 0.15m;
    }
}

Each class is simple and focused, handling one specific discount calculation. If we need a new tier, like “Diamond,” we just create a new class implementing IDiscountPolicy—no need to touch the existing ones. This is the “open for extension” part of OCP in action.

Step 3: Use a Factory to Create Strategies

So, how do we decide which policy to use at runtime? This is where the Factory Pattern comes in. Instead of scattering logic to pick the right policy across your codebase, a factory centralizes that decision. Here’s how we can implement it:

internal static class DiscountPolicyFactory
{
    private static readonly Dictionary<DiscountType, IDiscountPolicy> _discountPolicies = new()
    {
        { DiscountType.Silver, new DiscountSilverPolicy() },
        { DiscountType.Gold, new DiscountGoldPolicy() },
        { DiscountType.Platinum, new DiscountPlatinumPolicy() }
    };

    public static IDiscountPolicy GetDiscountPolicy(DiscountType discountType) =>
        _discountPolicies.TryGetValue(discountType, out var policy)
            ? policy
            : throw new ArgumentException("Invalid discount type");
}

We’re using an enum DiscountType to represent the membership tiers (Silver, Gold, Platinum). The factory maintains a dictionary mapping each DiscountType to its corresponding policy. When you call GetDiscountPolicy, it returns the right IDiscountPolicy implementation or throws an exception if the type is invalid.

Step 4: Putting It All Together

Here’s how you’d use this setup in your application:

var discountType = DiscountType.Gold;
decimal validAmount = 1000m;

// Get the right discount strategy from the factory
var discountPolicy = DiscountPolicyFactory.GetDiscountPolicy(discountType);

// Apply discount directly
decimal discount = discountPolicy.CalculateDiscount(validAmount);
decimal finalAmount = validAmount - discount;

Console.WriteLine($"Final amount after {discountType} discount: {finalAmount}");

Or, you can also create the DiscountCalculator class to encapsulate this logic:

internal class DiscountCalculator
{
    private readonly IDiscountPolicy _discountPolicy;

    public DiscountCalculator(IDiscountPolicy discountPolicy)
    {
        _discountPolicy = discountPolicy;
    }

    public decimal CalculateFinalAmount(decimal amount)
    {
        return amount - _discountPolicy.CalculateDiscount(amount);
    }
}

And the implementation will be like this:

var discountType = DiscountType.Gold;
decimal validAmount = 1000m;

// Get the right discount strategy from the factory
IDiscountPolicy discountPolicy = DiscountPolicyFactory.GetDiscountPolicy(discountType);

// Pass it into the calculator
var discountCalculator = new DiscountCalculator(discountPolicy);

// Now, the calculator takes care of the final amount logic
Console.WriteLine($"Final amount after {discountType} discount:
{discountCalculator.CalculateFinalAmount(validAmount)}");

The beauty here is that the client code doesn’t need to know how discounts are calculated, or which policy is being used. It just asks the factory for a policy and calls CalculateDiscount. If you add a new discount tier, you only need to:

1. Create a new policy class implementing IDiscountPolicy.

2. Update the factory’s dictionary with the new policy.

No existing code needs to change, satisfying OCP’s “closed for modification” rule.

Why This Works

• Strategy Pattern: Encapsulates discount logic into separate classes, making them easy to swap or extend.

• Factory Pattern: Centralizes the creation of strategies, keeping the client code clean and decoupled.

• OCP Compliance: Adding a new discount tier doesn’t require modifying existing classes—just extend with a new policy and update the factory.

By combining Strategy and Factory patterns, you’ve got a clean, extensible system that’s easy to maintain and scales like a charm. Give it a try in your next project, and you’ll see how much easier it is to add new features without breaking a sweat.

What Is Deferred Execution?

Deferred execution means a LINQ query doesn’t execute when you define it—it’s only executed when you request the results. With EF Core, queries are built using IQueryable<T>, which creates an expression tree that EF Core translates into SQL when the query is materialized. This allows you to build complex queries incrementally without hitting the database until necessary.

Key benefits:

• Fewer database hits: Chain multiple LINQ operations (e.g., Where, OrderBy, Take) into a single SQL query.

• Flexibility: Modify the query before execution without redundant database calls.

• Performance: Push filtering, sorting, and projections to the database, avoiding unnecessary data transfer.

However, you need to know when a query materializes to avoid pitfalls like pulling too much data into memory.

Deferred Execution in Action

Let’s explore deferred execution with a practical example, querying a Users table in EF Core. We’ll filter users over 18, find the first matching user, and count the total matches.

Deferred Execution Example

Here’s how deferred execution works with IQueryable<T>:

// Define the query (not executed yet)
var query = dbContext.Users.Where(u => u.Age > 18);

// Deferred execution: each operation triggers a separate SQL query
var firstUser = query.First(); // SQL: SELECT TOP(1) * FROM Users WHERE Age > 18
var count = query.Count();     // SQL: SELECT COUNT(*) FROM Users WHERE Age > 18

What’s happening?

• The query variable is an IQueryable<T> representing the LINQ expression Where(u => u.Age > 18). It doesn’t hit the database when defined.

• When First() is called, EF Core translates the query into SELECT TOP(1) * FROM Users WHERE Age > 18 and executes it.

• When Count() is called, EF Core generates a separate query: SELECT COUNT(*) FROM Users WHERE Age > 18.

• Key point: Each materialization (First(), Count()) triggers a distinct database call, fetching only the specific data needed.

What Triggers Materialization?

A query remains deferred until you materialize it, meaning you request the actual data from the database. Here are common scenarios that trigger materialization with IQueryable<T> in EF Core:

• Iteration: Looping over the query (e.g., foreach (var user in query)).

• Aggregation methods: Calling Count(), Sum(), Average(), Min(), Max(), etc.

• Single result methods: Calling First(), FirstOrDefault(), Single(), SingleOrDefault(), Last(), or LastOrDefault().

• Materialization methods: Calling ToList(), ToArray(), ToDictionary(), or ToHashSet().

• Conversion to IEnumerable: Calling AsEnumerable(), which forces subsequent operations to execute in memory.

Example:

var query = dbContext.Users.Where(u => u.Age > 18);
// Still deferred: no database hit
query = query.OrderBy(u => u.LastName);
// Still deferred: no database hit
var results = query.ToList(); // Materializes: executes SQL and loads data into memory
foreach (var user in query) { ... } // Materializes: executes SQL and iterates results
var count = query.Count(); // Materializes: executes SQL to compute count

Note: Each materialization triggers a new database query, so avoid multiple materializations of the same query to prevent redundant database hits.

Immediate Execution Contrast

Forcing immediate execution materializes the query early, loading data into memory:

// Load all matching users into memory immediately
var users = dbContext.Users
    .Where(u => u.Age > 18)
    .ToList();

// Operations happen in memory
var firstUser = users.FirstOrDefault(); // CLR processes the list
var count = users.Count;                // CLR counts the list

What’s happening?

• ToList() triggers immediate execution, running SELECT * FROM Users WHERE Age > 18 and loading all matching rows into memory.

• FirstOrDefault() and Count operate on the in-memory List<User>, not the database.

• Downside: If the Users table has 1 million rows over 18, all are pulled into memory, even though you only need one user and a count. This is inefficient for large datasets.

Optimizing Multiple Operations

In the deferred execution example, calling First() and Count() separately results in two database queries. To optimize, you can combine these into a single query using grouping:

var result = await dbContext.Users
    .Where(u => u.Age > 18)
    .GroupBy(u => 1) // Dummy key to group all rows
    .Select(g => new
    {
        FirstUser = g.OrderBy(u => u.Id).FirstOrDefault(),
        Count = g.Count()
    })
    .FirstOrDefaultAsync();

What’s happening?

• The GroupBy(u => 1) groups all rows into a single group, allowing FirstOrDefault and Count to be computed together.

• EF Core translates this into a single SQL query (simplified):

SELECT TOP(1) (
    SELECT TOP(1) * FROM Users WHERE Age > 18 ORDER BY Id
) AS FirstUser,
COUNT(*) AS Count
FROM Users WHERE Age > 18;

• Benefit: One database round-trip instead of two, reducing latency and server load.

• Note: Using FirstOrDefaultAsync() ensures async execution, a best practice for database operations in EF Core.

Real-World Analogy

Think of deferred execution like planning a grocery shopping trip:

• Deferred execution: You write a shopping list (IQueryable<T> query), adding items as you think of them (e.g., “milk,” “eggs,” “only organic”). You don’t go to the store until you’re ready, and you get exactly what’s on the final list in one trip.

• Immediate execution: You go to the store, buy everything in the dairy aisle (ToList()), bring it home, and then decide you only needed one carton of milk. Wasteful!

Deferred execution lets you refine your “shopping list” before hitting the database, ensuring you only fetch what you need.

Common Pitfalls to Avoid

1. Premature Materialization:

   • Calling ToList() or AsEnumerable() too early forces all data into memory, losing the benefits of deferred execution.

   • Example: dbContext.Users.ToList().Where(u => u.Age > 18) pulls all users into memory before filtering, which is inefficient.

2. Multiple Queries by Accident:

   • Materializing an IQueryable<T> multiple times (e.g., in a loop) triggers multiple database hits.

   • Example:

var query = dbContext.Users.Where(u => u.Age > 18);
foreach (var user in query) { ... } // SQL executed
var count = query.Count();         // SQL executed again

• Fix: Materialize once (var users = query.ToList();) or use the optimized grouping approach above.

3. Forgetting Async:

   • Use async methods like ToListAsync(), FirstOrDefaultAsync(), or CountAsync() to avoid blocking threads in web apps or APIs.

When to Leverage Deferred Execution

• Building complex queries: Chain multiple Where, OrderBy, or Select operations to create a single, optimized SQL query.

• Dynamic queries: Adjust filters based on conditions (e.g., user input) before executing.

• Aggregates and single records: Combine operations like First() and Count() into one query for efficiency.

Example (dynamic query):

var query = dbContext.Users.AsQueryable();
if (onlyActive)
    query = query.Where(u => u.IsActive);
if (minAge.HasValue)
    query = query.Where(u => u.Age >= minAge.Value);
var results = await query.ToListAsync();

Here, deferred execution lets you build the query dynamically without hitting the database until ToListAsync().

Conclusions

• Deferred execution delays query execution until materialization (e.g., ToList(), First(), Count(), or iteration), allowing flexible query composition.

• Materialization triggers: Iteration, aggregation (Count, Sum), single result methods (First, Single), or conversion to in-memory collections (ToList, AsEnumerable).

• IQueryable with EF Core translates LINQ queries into optimized SQL, executed by the database.

• Avoid immediate execution (e.g., early ToList()) for large datasets to prevent loading unnecessary data into memory.

• Optimize multiple operations by combining them into a single query, like using GroupBy for FirstOrDefault and Count.

• Pro Tip: Use async methods (ToListAsync(), FirstOrDefaultAsync()) for database queries to keep your app responsive.

Deferred execution is a superpower in LINQ with EF Core. By understanding when queries materialize and how to optimize them, you can write cleaner, faster, and more scalable code. Next time you’re querying a database, use deferred execution to minimize database hits and maximize performance.

What Are They?

IEnumerable

• Definition: Represents an in-memory sequence of objects you can iterate over.

• Execution: Uses delegates (Func<T, bool>) to filter or transform data, executed by the CLR (Common Language Runtime).

• Typical Use: LINQ-to-Objects for in-memory collections like List<T> or arrays.

IQueryable

• Definition: Represents a query that can be executed against a query provider (e.g., Entity Framework Core for databases).

• Execution: Uses expression trees (Expression<Func<T, bool>>) that a provider translates into something like SQL.

• Typical Use: LINQ-to-Entities for database queries or remote data sources.

The core difference is where the query runs: IEnumerable<T> processes data in memory, while IQueryable<T> pushes processing to the data source (e.g., a database).

Working with In-Memory Collections

When querying in-memory data (like a List<T>), both IEnumerable<T> and IQueryable<T> execute in the CLR, so their differences are subtle.

IEnumerable Example

Filtering a list of users in memory:

var users = new List<User>
{
    new User { Name = "Alice", Age = 25 },
    new User { Name = "Bob", Age = 40 },
    new User { Name = "Charlie", Age = 35 }
};

// Filter users over 30 using IEnumerable<T>
IEnumerable<User> result = users.Where(u => u.Age > 30);

What’s happening?

• The Where clause uses a delegate (Func<User, bool>).

• The CLR iterates each element, applying the filter:

Func<User, bool> predicate = user => user.Age > 30;
foreach (var user in users)
{
    if (predicate(user))
    {
        yield return user; // Include if true
    }
}

Result: Returns Bob and Charlie, processed in memory.

IQueryable Example

Same filter, but with IQueryable<T>:

var users = new List<User>
{
    new User { Name = "Alice", Age = 25 },
    new User { Name = "Bob", Age = 40 },
    new User { Name = "Charlie", Age = 35 }
};

// Convert to IQueryable<T> and filter
IQueryable<User> result = users.AsQueryable().Where(u => u.Age > 30);

What’s happening?

• The Where clause builds an expression tree (Expression<Func<User, bool>>).

• Since no database provider is involved, LINQ-to-Objects evaluates the expression tree in memory, looping through the collection like IEnumerable<T>.

Outcome: For in-memory data, both interfaces perform similarly. Use IEnumerable<T> for simplicity unless you’re testing query provider behavior.

Working with Databases (Entity Framework Core)

When querying a database with Entity Framework Core, the choice between IEnumerable<T> and IQueryable<T> drastically affects performance. IEnumerable<T> processes data in memory, while IQueryable<T> lets the database handle the heavy lifting.

IEnumerable Example (Pulls All Data to Memory)

Suppose you’re querying a Users table:

// Load all users into memory
IEnumerable<User> users = dbContext.Users.AsEnumerable();

// Filter and sort in memory
var result = users
    .Where(u => u.IsActive && u.Age > 30)
    .OrderBy(u => u.LastName)
    .Take(2);

What’s happening?

• AsEnumerable() (or ToList()) forces the query to execute immediately, retrieving all rows from the Users table (e.g., SELECT * FROM Users).

• The CLR then applies Where, OrderBy, and Take to the in-memory collection.

• Problem: If the table has 1 million rows, all 1 million are loaded into memory before filtering or sorting. This is slow and resource-intensive.

Example SQL executed:

This line of code:

IEnumerable<User> users = dbContext.Users.AsEnumerable();

Will generate this SQL query:

SELECT * FROM Users;

• Downside: Network traffic spikes, memory usage balloons, and performance suffers.

⚠️ Important Note: Deferred Execution

If you don’t call .AsEnumerable() or .ToList(), the query is not executed immediately:

// IQueryable<User> (DbSet) upcasted to IEnumerable<User>
IEnumerable<User> users = dbContext.Users;

// Still part of the query pipeline
var result = users
    .Where(u => u.IsActive && u.Age > 30)
    .OrderBy(u => u.LastName)
    .Take(2);

What’s really happening:

• dbContext.Users is a DbSet<User>, which implements both IQueryable<User> and IEnumerable<User>.

• Simply assigning it to an IEnumerable<User> does not materialize the data.

• EF Core still sees the underlying IQueryable.

• When you chain .Where(), .OrderBy(), .Take(), the expression tree is preserved.

• EF Core translates the final query into SQL when you enumerate (e.g. foreach, .ToList()).

SQL Generated:

SELECT TOP(2) *
FROM Users
WHERE IsActive = 1 AND Age > 30
ORDER BY LastName;

Filtering, sorting, and limiting still happen in the database, not in memory.

Please read more about deferred execution here: Understanding Deferred Execution in LINQ with Entity Framework Core

IQueryable Example (Database-Optimized)

Same query, but using IQueryable<T>:

// Build query to execute in the database
IQueryable<User> usersQuery = dbContext.Users
    .Where(u => u.IsActive && u.Age > 30)
    .OrderBy(u => u.LastName)
    .Take(2);

// Execute when needed
var result = usersQuery.ToList();

What’s happening?

• The query builds an expression tree that EF Core translates into a single, optimized SQL query:

SELECT TOP(2) *
FROM Users
WHERE IsActive = 1 AND Age > 30
ORDER BY LastName;

• The database performs the filtering, sorting, and limiting, returning only the two matching rows.

• Benefit: Minimal data is transferred, and the database’s query engine optimizes the operation.

Outcome: IQueryable<T> is far more efficient for databases, as it minimizes data transfer and leverages the database’s capabilities.

Key Differences in Database Queries

• IEnumerable:

  • Pulls all data into memory before processing.

  • Filtering/sorting happens in the CLR, which is slow for large datasets.

  • Risk: Overloading memory and network with unnecessary data.

• IQueryable:

  • Translates LINQ operations into SQL, executed by the database.

  • Only retrieves the data you need.

  • Benefit: Faster, less memory usage, and scalable for large datasets.

A Real-World Analogy

• IEnumerable: You order every item from an online store, have it shipped to your house, then pick the ones you want. Wasteful!

• IQueryable: You filter your order online (e.g., “only blue shirts under $20”), and only those items are shipped. Efficient!

When to Use Each

Use IEnumerable

• In-memory collections: For List<T>, arrays, or cached data.

• Small datasets: When the data is already in memory and performance isn’t a concern.

• Example: Filtering a small list of cached items.

var cachedProducts = GetProductsFromCache(); // Returns List<Product>
var discounted = cachedProducts.Where(p => p.Price < 10);

Use IQueryable

• Database queries: For EF Core or other query providers (e.g., APIs).

• Large datasets: When you want the database to handle filtering, sorting, or paging.

• Example: Fetching paginated data from a database.

var activeUsers = dbContext.Users
    .Where(u => u.IsActive)
    .OrderBy(u => u.LastName)
    .Skip(10)
    .Take(5)
    .ToList();

Quick Comparison Table

Conclusions

• IEnumerable: Great for in-memory data like lists or arrays. Avoid for database queries unless the dataset is small.

• IQueryable: Ideal for databases or remote sources, pushing filtering and sorting to the data source for efficiency.

• Pro Tip: Be cautious with AsEnumerable() or ToList() in database queries—they force data into memory, negating IQueryable<T>’s benefits.

Choosing between IEnumerable<T> and IQueryable<T> depends on where your data lives. For in-memory work, IEnumerable<T> is simpler. For databases, IQueryable<T> is your go-to for performance and scalability. Next time you write a LINQ query, think about where the work should happen—client or server—and pick the right tool for the job.

While this approach works, it comes with several drawbacks—especially in production:

• Deployment Complexity.

  Even small configuration changes may require a full CI/CD pipeline run or manual updates in each environment on your cloud server. This slows down delivery and increases operational overhead.

• Difficult to Maintain.

  If you have multiple environments (e.g., Development, Staging, and Production), keeping all configuration files synchronized can be error-prone. Missing or outdated values in one environment can lead to bugs or inconsistencies.

• Limited Access Control.

  appsettings.json is accessible to anyone with file system access. Fine-grained access control—such as granting read-only permissions to specific keys—is not straightforward.

This is why you need central configuration.

A centralized configuration system solves these problems by providing:

• One source of truth for configuration values.

• Instant updates without requiring application redeployments.

• Better security and access control for sensitive values.

Azure App Configuration

Azure App Configuration is a fully managed service that lets you store, manage, and distribute application settings from a single location.
Rather than storing configuration values in local files and including them in your codebase, you should keep them in a centralized store and retrieve them at runtime.

Key benefits:

• Instant configuration updates without redeploying your app

• Consistency across multiple environments and applications

• Dynamic settings support, including feature flags

Let’s get started.

Setting Up Azure App Configuration.

1. Create the service.
   In the Azure Portal, search for App Configuration in the top search bar.
   Click Create and provide the required details (subscription, resource group, region, and name). Once done, click Review + Create, then Create.

2. Add configuration values.
   After the resource is created, open it and navigate to Configuration Explorer from the left-hand menu.
   Click + Create to add a new key-value pair.

3. Define your settings.
   You can add keys in the same way you would structure them in appsettings.json. For example:

   • AppSettings:AppName → "My Web App"

The example below shows what it looks like in the Azure configuration.

Note: You can categorize your key using a label.

It’s similar to this structure in your appsettings.json:

{
  "AppSettings": {
    "AppName": "MyApp",
    "Developer": "Kristiadhy"
  }
}

Now, let's look at how you can read it from your app.

Connecting your ASP NET Core app to Azure App Configuration.

Here’s how you can connect your app to Azure App Configuration.

Install the required NuGet packages

From your project directory, run:

dotnet add package Microsoft.Azure.AppConfiguration.AspNetCore

Retrieve the connection string from Azure

In the Azure Portal, navigate to your App Configuration resource and:

• Go to Access Settings in the left-hand menu.

• Copy the Primary Connection String.

Note: You'll have Read-Write keys or Read-Only keys. Please select accordingly.

Note: To use a user secret in Visual Studio, right-click your project and select Manage User Secret. Then, enter the value as shown in the example below.

Update Program.cs to use Azure App Configuration

Modify your Program.cs to load configuration from Azure:

using Azure.Identity;

var builder = WebApplication.CreateBuilder(args);

// Connect to Azure App Configuration
builder.Configuration.AddAzureAppConfiguration(options =>
{
    options.Connect(builder.Configuration["AzureAppConfiguration:ConnectionString"]);
});

builder.Services.AddAzureAppConfiguration();

var app = builder.Build();

app.UseAzureAppConfiguration();

app.MapControllers();
app.Run();

Using the configuration in your code.

public class AppConfigController : ControllerBase
{
  private readonly IConfiguration _configuration;

  public AppConfigController(IConfiguration configuration)
  {
    _configuration = configuration;
  }

  [HttpGet("Configuration")]
  public IActionResult GetAppConfigValueFromConfiguration()
  {
    var appSettings = new AppSettings
    {
      AppName = _configuration["AppSettings:AppName"]!,
      Developer = _configuration["AppSettings:Developer"]!
    };
    return Ok(appSettings);
  }
}

The example above is also not recommended 🚫; it’s better to use the Option Pattern instead of injecting the configuration directly into your controller. In the free repository below, I have provided a more robust approach ✅:

• Using an extension method that makes your program.cs cleaner.

• Different refresh settings with explanations to help you understand the refresh with multiple approaches.

• Using the Option Pattern for a more effective approach.

Grab this for repository free: https://github.com/kristiadhy/AzureAppConfigAndKeyVaultIntegration

Note: If you find this helpful, please like the repo.

Conclusion

By using Azure App Configuration, you centralize configuration management, enabling instant updates across environments without redeployments.

This combination delivers:

• Centralized management for all application settings.

• Consistent configuration across multiple apps and environments.

• Faster, safer updates without downtime.

In the next article, I'll explain how to integrate the Azure App Configuration and Key Vault.

This article covers everything from preparing your server environment and installing Docker to setting up Nginx as a reverse proxy and securing your application with SSL using Let's Encrypt. By the end of this article, you'll have a clear understanding of each step and why it's crucial for a secure, scalable, and maintainable deployment.

This guide assumes you have:

• A Dockerized web application ready for deployment (e.g., an ASP.NET Core application with a Dockerfile and docker-compose.yml).

• A Linux VPS (Ubuntu is used in examples).

• Basic familiarity with Linux command-line interface.

• A registered domain name pointing to your VPS's IP address.

Let's get started!

1. Prepare the User and Directory for Your Application

Security and organization are paramount in a production environment. We will create a dedicated system user and a specific directory structure for your application. This isolation helps prevent unauthorized access to other parts of your system and keeps your deployments organized.

1.1 Create a Dedicated User for Your Website

It's a security best practice to run your web applications under a dedicated, unprivileged user account rather than the root user. This limits the potential damage if your application is compromised.

Let's create a user called mywebsiteuser:

sudo adduser mywebsiteuser

Explanation:

• sudo: Executes the command with superuser privileges.

• adduser: A high-level utility in Debian-based systems (like Ubuntu) to add a new user. It handles creating the user's home directory, setting up initial permissions, and prompting for a password and other user details.

You'll be prompted to set a password for mywebsiteuser and provide some optional information. Choose a strong password.

1.2 Create a Web Root Directory for Each App

For consistent management and separation of concerns, it's recommended to place application code under a standardized web root directory, commonly /var/www. This makes it easier to locate and manage your deployments.

sudo mkdir -p /var/www/mywebsite

Explanation:

• mkdir: Creates a new directory.

• -p: The parents option ensures that if any parent directories in the path (/var/www in this case) do not exist, they will be created automatically.

• /var/www/mywebsite: This is the full path where your mywebsite application's files will reside.

1.3 Set Ownership of These Directories

After creating the directory, it's crucial to assign its ownership to the dedicated user you just created. This ensures that only mywebsiteuser (and root) can modify the contents of this directory.

sudo chown -R mywebsiteuser:mywebsiteuser /var/www/mywebsite

Explanation:

• chown: Changes the owner and group of files or directories.

• -R: The recursive option applies the ownership change to all files and subdirectories within /var/www/mywebsite.

• mywebsiteuser:mywebsiteuser: Sets both the owner and the primary group of the directory to mywebsiteuser.

1.4 Set Permissions for the Directory

While chown sets ownership, chmod sets file and directory permissions. These permissions dictate who can read, write, or execute files.

sudo chmod -R 755 /var/www/mywebsite

Explanation:

• chmod: Changes file mode bits (permissions).

• 755: This is an octal representation of permissions:

  • 7 (Owner): Read (4) + Write (2) + Execute (1) = 7. The owner (mywebsiteuser) has full control over files and directories.

  • 5 (Group): Read (4) + Execute (1) = 5. Members of the mywebsiteuser group can read and traverse (execute) directories.

  • 5 (Others): Read (4) + Execute (1) = 5. Everyone else can read and traverse directories.

• Why these permissions? This configuration is standard for web content. The owner needs full control to deploy and manage the application. Others (like the web server process) only need read and execute (traverse) permissions to serve static content or execute scripts. Write access for others is generally not needed and poses a security risk.

1.5 Switch to the Application User When Deploying

When performing operations related to your specific application, such as cloning your Git repository or deploying new code, you should always do so as the mywebsiteuser. This maintains the security boundaries established.

To switch to the mywebsiteuser shell:

sudo -i -u mywebsiteuser

Explanation:

• sudo -i: Simulates an initial login, giving you a shell as the target user with their environment variables.

• -u mywebsiteuser: Specifies mywebsiteuser as the user to switch to.

Once you've switched users, navigate to your application's root directory:

cd /var/www/mywebsite

All subsequent operations (like git clone, docker-compose up) that directly interact with your application's files should be performed from this user and directory.

2. Install Docker and Docker Compose

Docker is the cornerstone of this deployment strategy, allowing you to package your application and its dependencies into isolated containers. Docker Compose simplifies the management of multi-container Docker applications.

2.1 Option 1: Install Docker from the Ubuntu Repository (Simple, but potentially older version)

This method uses the Docker package available in Ubuntu's default repositories. It's generally simpler but might provide an older version of Docker.

sudo apt update
sudo apt install -y docker.io
sudo systemctl enable --now docker
sudo usermod -aG docker $USER

Explanation:

• sudo apt update: Refreshes the list of available packages from the repositories.

• sudo apt install -y docker.io: Installs the docker.io package. The -y flag automatically answers yes to prompts.

• sudo systemctl enable --now docker:

  • systemctl enable docker: Configures Docker to start automatically on system boot.

  • --now: Starts the Docker service immediately without requiring a reboot.

• sudo usermod -aG docker $USER: Adds your current logged-in user (the user you are using to SSH into the VPS) to the docker group. This is crucial because it allows your current user to run Docker commands without needing sudo every time.

2.2 Option 2: Install Docker CE (Community Edition) from Official Docker Repository (Recommended)

This is the recommended approach for production environments as it provides the latest stable version of Docker CE, along with containerd (a core container runtime) and Docker Compose CLI plugin.

First, update your package index and install necessary utilities:

sudo apt update
sudo apt install ca-certificates curl gnupg -y

Explanation:

• ca-certificates: Allows web browsers and other programs to check the authenticity of SSL/TLS certificates.

• curl: A command-line tool for transferring data with URLs. Used here to download Docker's GPG key.

• gnupg: GNU Privacy Guard, used for managing cryptographic keys. Needed to verify the authenticity of Docker packages.

Next, add Docker's official GPG key. This key is used to verify the authenticity of packages downloaded from Docker's repository, ensuring they haven't been tampered with.

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

Explanation:

• sudo install -m 0755 -d /etc/apt/keyrings: Creates the /etc/apt/keyrings directory with appropriate permissions if it doesn't exist. This is where APT stores cryptographic keys.

• curl -fsSL https://download.docker.com/linux/ubuntu/gpg: Downloads the Docker GPG key.

  • -f: Fail silently on HTTP errors.

  • -s: Silent mode (don't show progress meter or error messages).

  • -S: Show error messages even with -s.

  • -L: Follow redirects.

• | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg: Pipes the downloaded key to gpg --dearmor, which converts it to a format readable by APT, and saves it to the specified file.

• sudo chmod a+r /etc/apt/keyrings/docker.gpg: Sets read permissions for all users on the GPG key file.

Now, add the Docker repository to your APT sources:

echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

Explanation:

• echo "deb ... stable": This command constructs the repository entry string.

  • $(dpkg --print-architecture): Dynamically gets your system's architecture (e.g., amd64).

  • signed-by=/etc/apt/keyrings/docker.gpg: Specifies the GPG key used to sign packages from this repository.

  • $(. /etc/os-release && echo "$VERSION_CODENAME"): Dynamically gets your Ubuntu version's codename (e.g., jammy for Ubuntu 22.04).

  • stable: Specifies that you want the stable release channel.

• | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null: Pipes the output of echo to tee. tee writes to both standard output and the specified file (/etc/apt/sources.list.d/docker.list). Using sudo tee allows writing to a system file, and > /dev/null suppresses output to the console.

• sudo apt update: Updates your package index again to include packages from the newly added Docker repository.

Finally, install Docker Engine, containerd, and Docker Compose (CLI plugin):

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

Explanation:

• docker-ce: The Docker Engine Community Edition.

• docker-ce-cli: The Docker command-line interface.

• containerd.io: A high-level container runtime that Docker Engine uses internally.

• docker-buildx-plugin: A Docker CLI plugin for extended build capabilities (e.g., building multi-platform images).

• docker-compose-plugin: The new, integrated Docker Compose CLI plugin (accessible via docker compose without a hyphen).

Add your user to the docker group (again, in case you purged it or if this is a fresh setup):

sudo usermod -aG docker ${USER}

Important Note: The $USER (or ${USER}) variable expands to the username of the user currently logged in. This command adds your current SSH user to the docker group.

To apply group membership changes, you MUST log out and log back in to your VPS. This reloads your user's group memberships. Simply running new commands will not reflect the change until a new session is started.

2.3 Test Docker Installation

After logging back in, verify that Docker is correctly installed and that your user can run Docker commands without sudo:

docker run hello-world

3. Install Docker Compose (Legacy Standalone Binary - If not using Docker CE plugin)

(Note: If you followed Option 2 and installed docker-compose-plugin, you can skip this section as docker compose is already available as a Docker CLI subcommand. This section is for situations where you might have installed Docker via Option 1 or prefer the standalone docker-compose binary.)

While the docker-compose-plugin is the modern approach, some users might still prefer or require the standalone docker-compose binary.

First, define where the Docker Compose binary will be stored:

DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker}
mkdir -p $DOCKER_CONFIG/cli-plugins

Explanation:

• DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker}: This sets the DOCKER_CONFIG environment variable. If DOCKER_CONFIG is already set, it uses its value; otherwise, it defaults to $HOME/.docker. This is a common location for Docker CLI plugins.

• mkdir -p $DOCKER_CONFIG/cli-plugins: Creates the cli-plugins directory within your DOCKER_CONFIG path.

Download the Docker Compose binary:

curl -SL https://github.com/docker/compose/releases/latest/download/docker-compose-linux-x86_64 -o $DOCKER_CONFIG/cli-plugins/docker-compose

Explanation:

• curl -SL ...: Downloads the latest stable Docker Compose binary for Linux (x86_64 architecture).

  • -S: Show error messages.

  • -L: Follow redirects.

• -o $DOCKER_CONFIG/cli-plugins/docker-compose: Specifies the output file path and name for the downloaded binary.

3.1 Apply Executable Permissions

The downloaded binary needs to be marked as executable to be run as a command.

chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose

Explanation:

• chmod +x: Adds execute permission to the specified file.

3.2 Verify the Installation

Confirm that Docker Compose is correctly installed and accessible:

docker compose version # If using the plugin (Option 2)
# OR
docker-compose version # If using the standalone binary (Option 3)

You should see the version number of Docker Compose printed to your console.

4. Create an SSH Key for Your GitHub Repository

When deploying your application, you'll typically pull your code from a Git repository (like GitHub, GitLab, or Bitbucket). Using SSH keys for authentication is more secure and convenient than using HTTPS with a personal access token, especially for automated deployments.

4.1 Change to Your Specific Website User

Crucially, generate the SSH key as the mywebsiteuser (or whatever dedicated user you created), NOT as the root user or your primary SSH user. This ensures that the key is associated with the correct user and adheres to the principle of least privilege.

sudo -i -u mywebsiteuser

You are now operating as mywebsiteuser. Any files created will be owned by this user.

4.2 Create an SSH Key

ssh-keygen -t ed25519 -C "mywebsiteuser_github_key"

Explanation:

• ssh-keygen: The command to generate SSH key pairs.

• -t ed25519: Specifies the type of key to create. ed25519 is a modern, highly secure, and efficient elliptic curve algorithm, generally preferred over RSA for new keys.

• -C "mywebsiteuser_github_key": Adds a comment to the public key. This is helpful for identifying the key's purpose when you add it to GitHub or other services.

You will be prompted for:

• File in which to save the key: Press Enter to accept the default location (/home/mywebsiteuser/.ssh/id_ed25519).

• Passphrase: Use a passphrase if possible for better security. A passphrase adds an extra layer of protection, requiring you to enter it before the private key can be used. This protects your key if someone gains unauthorized access to your VPS. If you choose not to use one (e.g., for automated deployments where passphrase prompts are problematic), understand the increased risk.

4.3 Verify Key Generation and Permissions

After generation, verify the keys exist and have correct permissions:

ls -al ~/.ssh/

You should see two files: id_ed25519 (your private key) and id_ed25519.pub (your public key).

Permission Check:

• The private key (id_ed25519) must have permissions 600 (read/write for owner only). This is critical; if others can read your private key, your security is compromised.

• The public key (id_ed25519.pub) should have 644 (read for owner, read for group/others).

• The .ssh directory itself should have 700 (read/write/execute for owner only).

If permissions are not correct, fix them immediately:

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 700 ~/.ssh/ # Ensure the .ssh directory itself is secure

4.4 Copy the Public Key

You need to add your public key to GitHub (or your Git hosting service). Display the public key's content:

cat ~/.ssh/id_ed25519.pub

Copy the entire output, which starts with ssh-ed25519 and ends with the comment you provided.

4.5 Add the Public Key to GitHub

1. Log in to your GitHub account (your personal one that owns the repository or the organization that manages it).

2. Navigate to Settings -> SSH and GPG keys -> New SSH key.

3. Title: Give it a meaningful name, like "VPS mywebsiteuser key" or "Production server mywebsite user".

4. Key: Paste the public key you copied earlier into this field.

5. Click "Add SSH key".

4.6 Clone the Repository Using the SSH URL

Now, with the SSH key set up and added to GitHub, you can securely clone your repository. Remember to be operating as the mywebsiteuser.

cd /var/www/mywebsite # Navigate to your app's web root directory
git clone git@github.com:yourgithubuser/yourrepository.git .

Explanation:

• git@github.com:yourgithubuser/yourrepository.git: This is the SSH URL for your GitHub repository. You can find this URL on your repository's page on GitHub (click the "Code" button and select "SSH").

• .: The dot at the end instructs Git to clone the repository into the current directory (/var/www/mywebsite), rather than creating a new subdirectory.

5. Inject Environment Variables

Docker Compose allows you to inject environment variables into your containers, which is a standard way to manage configuration that varies between environments (e.g., database connection strings, API keys). The .env file is a convenient way to manage these variables locally or on your server.

5.1 Create a .env File

Navigate to your project's root directory on the VPS (/var/www/mywebsite):

cd /var/www/mywebsite
touch .env

Explanation:

• touch .env: Creates an empty file named .env. This file should be placed at the same level as your docker-compose.yml file.

5.2 Add Your Variables to .env

Open the .env file using a text editor (e.g., nano or vim):

nano .env

Inside the .env file, add your environment variables in a KEY=VALUE format, one per line. For example:

ASPNETCORE_ENVIRONMENT=Production
CONNECTION_STRINGS__DEFAULTCONNECTION=Server=my_db_server;Database=mydb;User Id=myuser;Password=mypassword;
API_KEY=your_secret_api_key_here

Security Note: The .env file on your VPS will contain sensitive information. Ensure its permissions are strict (e.g., chmod 600 .env if it's not already, though touch usually creates it with appropriate user-only write access by default). Never commit your .env file to your Git repository! Add it to your .gitignore file.

6. Deploy Your Docker Compose Application

With Docker installed, the repository cloned, and environment variables configured, you're ready to bring up your application.

6.1 Navigate to Your Project Directory

cd /var/www/mywebsite

6.2 Build and Run with Docker Compose

This command will read your docker-compose.yml file, build any necessary Docker images, and start your services.

docker-compose up -d --build

Explanation of the command:

• docker-compose up: This command starts the services defined in your docker-compose.yml file. Docker Compose will automatically create networks, volumes, and containers as specified.

• -d (detached mode): This is crucial for production deployments. It runs your containers in the background, freeing up your terminal immediately. Without -d, your terminal would be attached to the container logs, and closing the terminal would stop the containers.

• --build: This forces Docker Compose to rebuild your images before starting the containers. This is important if you've made changes to your Dockerfile or your application's code and want to ensure the latest version is deployed. If you're using pre-built images from a container registry (e.g., Docker Hub, Azure Container Registry), you might omit this flag and use docker-compose pull first to download the latest images. For local builds from source code, --build is essential.

6.3 Verify Your Containers

After running docker-compose up -d --build, you should verify that your containers are running as expected.

docker ps

Explanation:

• docker ps: Lists all currently running Docker containers.

You should see your web application container (e.g., mywebsite-webapp) and any other services (like a database container) listed with their STATUS as Up and their PORTS mapping. For example:

CONTAINER ID   IMAGE                COMMAND               CREATED         STATUS         PORTS                     NAMES
<id>           mywebsite-webapp     "dotnet Mywebsite.dll"  2 minutes ago   Up 2 minutes   0.0.0.0:8080->80/tcp      mywebsite_webapp_1

Pay close attention to the PORTS column. This shows which port on your VPS (e.g., 8080) is mapped to which port inside your container (e.g., 80). Your Nginx reverse proxy will forward requests to the VPS host port.

6.4 Check Logs (Optional but Recommended for Debugging)

To ensure your application started successfully and to debug any issues, check the container logs:

docker-compose logs -f webapp

Explanation:

• docker-compose logs: Displays the logs from your services.

• -f (follow): Streams new logs in real-time, similar to tail -f. This is extremely useful for monitoring startup or diagnosing runtime errors.

• webapp: Replace webapp with the service name of your web application as defined in your docker-compose.yml file.

Press Ctrl+C to exit the log stream. Look for messages indicating your application has started listening on its internal port (e.g., "Now listening on: http://[::]:80").

7. Configure Your Website for Internet Access (Nginx Reverse Proxy)

Even though your Docker container is running, it's typically only accessible on the VPS itself (e.g., via localhost:8080). To make your application available to the internet via your domain name, you need a reverse proxy. Nginx is a popular, high-performance choice for this role. It will sit in front of your Dockerized application, handle incoming web requests, and forward them to your running Docker container.

7.1 Install Nginx

If Nginx is not already installed:

sudo apt update
sudo apt install nginx -y
sudo systemctl enable --now nginx

Explanation:

• sudo systemctl enable --now nginx: Enables Nginx to start on boot and starts it immediately.

7.2 Create Nginx Configuration File

Nginx configurations for individual websites are usually placed in /etc/nginx/sites-available/. You'll create a new file for your website.

sudo nano /etc/nginx/sites-available/mywebsite

Paste the following configuration. Remember to replace your_domain.com with your actual domain name and adjust the proxy_pass port if your Dockerized application isn't listening on port 8080 internally.

# /etc/nginx/sites-available/mywebsite

server {
    listen 80;
    listen [::]:80; # Listen on IPv6 as well
    server_name your_domain.com www.your_domain.com; # Replace with your actual domain(s)

    location / {
        # Forward requests to your Dockerized application
        proxy_pass http://localhost:8080; # Or the IP of your Docker host if not localhost
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme; # Crucial for ASP.NET Core apps behind a proxy
        proxy_cache_bypass $http_upgrade;
        # Disable buffering for WebSockets/Server-Sent Events if your app uses them
        # proxy_buffering off;
    }

    # Optional: Add error pages or other configurations as needed
    # error_page 500 502 503 504 /50x.html;
    # location = /50x.html {
    #     root /usr/share/nginx/html;
    # }
}

Explanation of Nginx Directives:

• listen 80;: Nginx will listen for incoming HTTP requests on port 80.

• listen [::]:80;: Similar to above, but for IPv6 traffic.

• server_name your_domain.com www.your_domain.com;: This tells Nginx which domain names this server block should respond to. It's crucial for Nginx to route requests correctly, especially when hosting multiple sites on one server.

• location / { ... }: This block defines how Nginx handles requests for the root URL (/) and its subpaths.

• proxy_pass http://localhost:8080;: This is the core of the reverse proxy. It tells Nginx to forward all requests received by this server block to your Dockerized application, which is running on localhost (the VPS itself) at port 8080 (the host port you mapped in docker-compose.yml).

• proxy_http_version 1.1;: Specifies the HTTP protocol version for the proxy connection.

• proxy_set_header ...: These directives pass important client information (like original host, real IP address, and protocol scheme) from Nginx to your backend application. This is vital for applications like ASP.NET Core that might need to know the original request's scheme (HTTP vs. HTTPS) or the client's actual IP address, as they see Nginx as the direct client otherwise.

7.3 Create a Symbolic Link

To enable your new Nginx configuration, you need to create a symbolic link from sites-available (where configurations are stored) to sites-enabled (where Nginx looks for active configurations).

sudo ln -s /etc/nginx/sites-available/mywebsite /etc/nginx/sites-enabled/

Explanation:

• ln -s: Creates a symbolic link (a shortcut).

• /etc/nginx/sites-available/mywebsite: The source file (your configuration).

• /etc/nginx/sites-enabled/: The destination directory where the link will be created.

7.4 Test Nginx Configuration

Before restarting Nginx, always test your configuration for syntax errors. This prevents Nginx from failing to start due to a simple typo.

sudo nginx -t

You should see output similar to: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok and nginx: configuration file /etc/nginx/nginx.conf test is successful. If there are any errors, fix them in your configuration file before proceeding.

7.5 Restart Nginx

Apply the new configuration by restarting Nginx. A restart is needed for Nginx to load the new server block.

sudo systemctl restart nginx

If Nginx fails to restart or you encounter issues, use sudo systemctl status nginx to view the service's status and error logs for debugging.

7.6 Set Your Domain DNS to Point to Your VPS

This is done outside of your VPS, through your domain name registrar or DNS provider.

• Open your domain setting from your domain provider. Log in to your domain registrar's website (e.g., GoDaddy, Namecheap, Cloudflare).

• Set the DNS manager. Locate the DNS management section for your domain.

• Adjust the domain name of the A record to point to your VPS.

  • You'll typically create an A record for your main domain (e.g., your_domain.com) pointing to your VPS's public IPv4 address.

  • You might also create a CNAME record for www.your_domain.com pointing to your_domain.com, or another A record directly to the IP.

• Save the changes. DNS changes can take some time to propagate across the internet (anywhere from a few minutes to 48 hours), although typically it's much faster.

Once DNS has propagated, accessing http://your_domain.com in a browser should now hit your Nginx server, which then forwards the request to your Dockerized application. You might still see "Welcome to nginx!" or experience issues if the default Nginx site is interfering (see troubleshooting below).

8. Implement SSL with Certbot (Let's Encrypt)

Securing your website with HTTPS (SSL/TLS) is non-negotiable for modern web applications. It encrypts communication between your users and your server, protects data integrity, and is a strong ranking signal for search engines. Let's Encrypt provides free, automated SSL certificates, and Certbot is the tool to manage them.

8.1 Install Certbot

Certbot is often installed via Snap, a universal packaging system for Linux.

sudo snap install core
sudo snap refresh core # Ensures Snap core is up to date
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot # Create a symbolic link for easy access

Explanation:

• snap install core: Installs the Snap "core" components, which are foundational for running other snaps.

• snap refresh core: Updates the core snap.

• snap install --classic certbot: Installs Certbot. The --classic flag is needed because Certbot requires broad system access.

• sudo ln -s /snap/bin/certbot /usr/bin/certbot: Creates a symbolic link so you can run certbot directly from your PATH without needing to specify /snap/bin/certbot.

8.2 Obtain and Install SSL Certificate

Certbot has an Nginx plugin that can automatically configure Nginx for SSL.

sudo certbot --nginx

Explanation:

• certbot --nginx: This command tells Certbot to use its Nginx plugin to configure SSL.

Follow the prompts:

1. Certbot will ask for your email address for urgent renewal notices and security warnings.

2. Agree to the Let's Encrypt Terms of Service.

3. Choose whether to share your email with the Electronic Frontier Foundation (EFF).

4. Certbot will detect your Nginx configurations and list the domains it found. Select the numbers corresponding to your_domain.com and www.your_domain.com.

5. It will ask if you want to redirect HTTP traffic to HTTPS. Choose 2 (Redirect). This is best practice as it ensures all traffic uses the secure HTTPS connection.

Certbot will then automatically:

• Obtain the SSL certificates from Let's Encrypt.

• Modify your /etc/nginx/sites-available/mywebsite file to include HTTPS listeners (port 443), redirect HTTP traffic (port 80) to HTTPS, and set up the correct ssl_certificate and ssl_certificate_key paths.

• Configure automatic certificate renewal. Let's Encrypt certificates are valid for 90 days, and Certbot sets up a cron job or systemd timer to renew them automatically before they expire.

After this, your website should be accessible via HTTPS! Try accessing https://your_domain.com in your browser.

9. Fix the "Welcome to nginx!" Message or Incorrect Site Loading

This typically happens if the default Nginx configuration file is taking precedence over your custom site configuration. Nginx serves the "Welcome to Nginx!" page from its default site.

9.1 Inspect sites-enabled

First, let's see which Nginx site configurations are actually active:

ls -l /etc/nginx/sites-enabled/

You will likely see something like this:

default -> /etc/nginx/sites-available/default
mywebsite -> /etc/nginx/sites-available/mywebsite

If both default and mywebsite are symlinked here, Nginx has rules for determining which server block to use. If your custom server_name isn't an exact match, or if the default_server directive is used in the default config, it can pick the wrong one.

9.2 Disable the Default Nginx Site (Recommended Approach)

This is the cleanest way to ensure your custom site configuration takes precedence.

sudo unlink /etc/nginx/sites-enabled/default

Explanation:

• unlink: Removes a symbolic link. This command effectively disables the default Nginx site without deleting the original configuration file (/etc/nginx/sites-available/default).

9.3 Re-verify and Correct Your mywebsite Nginx Configuration

It's crucial that your mywebsite configuration (especially the server_name directive) is perfectly accurate for your domain(s).

sudo nano /etc/nginx/sites-available/mywebsite

Ensure the server_name directives are exact matches for your domain(s). After Certbot runs, your file should look something like this, with both HTTP and HTTPS blocks:

# /etc/nginx/sites-available/mywebsite

# HTTP block - will be redirected by Certbot to HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name mywebsite.id www.mywebsite.id; # <-- MUST MATCH YOUR DOMAIN EXACTLY

    # Certbot will inject the redirect here after you run it for this domain
    # And also the location block for .well-known/acme-challenge
    # For example, it adds:
    # return 301 https://$host$request_uri;
    # (Other Certbot-specific configurations will also be here)
}

# HTTPS block - Certbot creates/modifies this
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name mywebsite.id www.mywebsite.id; # <-- MUST MATCH YOUR DOMAIN EXACTLY

    ssl_certificate /etc/letsencrypt/live/mywebsite.id/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mywebsite.id/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    include /etc/letsencrypt/ssl-dhparams.conf;

    location / {
        proxy_pass http://localhost:8080; # Points to your mywebsite.web Docker container
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme; # Crucial for ASP.NET Core apps behind a proxy
        proxy_cache_bypass $http_upgrade;
    }
}

Make sure you have both the http:// and https:// server blocks for your domain. Certbot creates the HTTPS one and modifies the HTTP one to redirect.

9.4 Test Nginx Configuration Again

sudo nginx -t

This command checks for syntax errors in all your Nginx configuration files. If there are any, it will tell you where they are. Fix them before proceeding.

9.5 Reload Nginx

After making changes to Nginx configuration files, use reload to apply them without interrupting service for other domains (if you have any). If reload doesn't work, restart is a more forceful option.

sudo systemctl reload nginx

After These Steps:

• Clear your browser cache: Sometimes browsers cache redirects or old content. A hard refresh (Ctrl+F5 or Cmd+Shift+R) or clearing your browser's cache can help ensure you're seeing the latest content from your server.

• Try accessing your website again. It should now load correctly via HTTPS.

Conclusion:

You have successfully deployed your Dockerized web application to a Linux VPS! By following these steps, you've established a secure, organized, and scalable environment for your application. This setup leverages Docker for containerization, Nginx for efficient reverse proxying and load balancing, and Let's Encrypt for essential SSL security, all adhering to industry best practices for robust deployment.

You can skip some steps if you want to and choose what's best for you.

Rent Your Virtual Private Server (VPS).

The first step is to choose a reputable hosting provider. Popular options include DigitalOcean, Vultr, and Hetzner. When selecting a plan, consider your application's resource requirements:

• CPU: More cores generally translate to better performance, crucial if you anticipate significant traffic or compute-intensive tasks.

• RAM: Ample memory ensures your applications run smoothly, preventing slowdowns and crashes under load.

• Storage: Opt for SSD (Solid State Drive) storage for significantly faster read/write speeds, which benefits database operations and application loading times. Ensure you have enough capacity for your application files, databases, and any future growth.

• Bandwidth: Important if your application handles a large volume of data transfers, such as file downloads, streaming media, or high traffic.

For a small application or testing environment, a basic plan might suffice. However, for larger or production-ready applications, investing in a more powerful plan from the start can save you headaches down the line and ensure a scalable foundation.

Secure Your Root Account.

Upon initial login to your new VPS (usually as the root user), the very first thing you should do is change the default password. This is a critical security measure as default passwords are often weak or publicly known.

To change it, simply type:

passwd

You'll be prompted to enter your new password twice. Choose a strong, unique password that combines uppercase and lowercase letters, numbers, and symbols.

Create a Non-Root User

Working directly as the root user is a significant security risk. The root user has absolute control over the system, and a single misplaced command can lead to irreversible damage. To mitigate this, it's a best practice to create a new, unprivileged user for your day-to-day operations and grant it sudo privileges for administrative tasks. This aligns with the principle of "least privilege" and contributes to a more secure and maintainable system.

To create a new user (replace myusername with your desired username):

adduser myusername

Follow the prompts to set a strong password for this new user and fill in any additional information (you can usually press Enter to skip these if not needed).

Next, grant this new user sudo permissions, allowing them to execute commands with root privileges when necessary, by prefixing the command with sudo.

usermod -aG sudo myusername

Now, you can log out of the root user and log in as myusername. From this point forward, you'll use sudo for any administrative operations.

Enhance Security with SSH Keys.

After changing your password, the next level of security involves disabling password-based SSH logins entirely and exclusively using SSH keys. SSH keys provide a much stronger authentication mechanism, making brute-force password attacks virtually impossible. This is a fundamental step in securing your server.

Step-by-Step SSH Key Setup:

1. Generate an SSH key on your local machine: Open your local terminal and generate a new SSH key pair. ed25519 is the modern and recommended algorithm due to its strong security and smaller key sizes, but rsa is also an option.

    ssh-keygen -t ed25519
   

   Press Enter when prompted for a file to save the key (it will default to ~/.ssh/id_ed25519) and when asked for a passphrase. While a passphrase adds an extra layer of security, it means you'll need to enter it every time you use the key. For convenience, many users opt not to set one for their primary key, but consider it for higher-security scenarios.

2. Copy the public key to your server: This command securely copies your public key (id_ed25519.pub) to the authorized_keys file on your VPS, allowing you to log in with your key. Replace myusername and your-server-ip with your actual details.

    ssh-copy-id myusername@your-server-ip
   

   You will be asked for your myusername's password one last time.

3. Test your SSH key login: Before proceeding, try logging in to your VPS using your new user and SSH key to ensure it works correctly.

    ssh myusername@your-server-ip
   

   If successful, you should be logged in without being prompted for a password.

4. Disable password login on the server: Once you've confirmed SSH key login works, edit the SSH daemon configuration file to disallow password authentication. This significantly hardens your server against unauthorized access.

    sudo nano /etc/ssh/sshd_config
   

   Find the line PasswordAuthentication yes and change it to:

    PasswordAuthentication no
   

   You might also want to ensure PermitRootLogin no is set to prevent direct root logins via SSH, forcing you to use your non-root user and then sudo if needed.

   Save and exit nano (Ctrl+O, Enter, Ctrl+X).

5. Restart the SSH service: Apply the changes by restarting the SSH service.

    sudo systemctl restart ssh
   

   Now, your server is much more secure, relying solely on cryptographic SSH keys for authentication.

Install and Configure UFW (Uncomplicated Firewall).

A firewall is your server's first line of defense, controlling what network traffic is allowed in and out. UFW (Uncomplicated Firewall) is a user-friendly front-end for iptables, making it easier to manage firewall rules. It's critical to configure your firewall before deploying any applications.

Here's a safe baseline configuration, ideal for web applications:

sudo ufw default deny incoming       # Deny all incoming connections by default
sudo ufw default allow outgoing      # Allow all outgoing connections by default
sudo ufw allow OpenSSH               # Allow SSH connections (port 22)
sudo ufw allow 80/tcp                # Allow HTTP traffic (port 80)
sudo ufw allow 443/tcp               # Allow HTTPS traffic (port 443)
sudo ufw enable                      # Enable the firewall

You'll be asked to confirm enabling the firewall; type y and press Enter.

To verify your firewall's status and rules:

sudo ufw status verbose

This setup allows essential services while blocking all other unsolicited incoming connections, significantly reducing your server's attack surface.

Set the Correct Timezone and Locale.

Proper timezone and locale settings are essential for accurate logging, scheduling tasks, and ensuring your applications behave as expected across different geographical locations.

Timezone Configuration:

Set your server's timezone. For example, if you are in Jakarta, Indonesia, you'd set it to Asia/Jakarta.

sudo timedatectl set-timezone Asia/Jakarta

Verify the change:

timedatectl

This command will display current system time, RTC time, and your configured timezone.

Locale Configuration:

The locale determines the language, character encoding, and cultural conventions for your system. For most English-speaking systems, en_US.UTF-8 is a common and robust choice.

Check your current locale:

locale

If you need to set a new one:

sudo update-locale LANG=en_US.UTF-8

You can list all available locales with:

locale -a

After changing the locale, it's best to log out and log back in to ensure the changes are fully applied to your session.

Enable SSH Rate Limiting with Fail2ban.

Fail2ban is a powerful intrusion prevention framework that scans log files (like those for SSH, web servers, etc.) for repeated failed login attempts and automatically bans the offending IP addresses for a specified period. This is an excellent defense against brute-force attacks.

Installation:

sudo apt update
sudo apt install fail2ban -y

Basic Configuration:

1. Copy the default configuration file to a local override. This is a best practice, as it ensures your custom settings won't be overwritten during future fail2ban package updates.

    sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
   

2. Edit the local configuration file:

    sudo nano /etc/fail2ban/jail.local
   

   Look for the [sshd] section. Ensure it is enabled and review the maxretry and bantime settings:

   Ini, TOML

    [sshd]
    enabled = true
    port = ssh
    filter = sshd
    logpath = %(sshd_log)s
    maxretry = 5   ; How many failed attempts allowed before banning
    bantime = 1h   ; How long to block the IP (e.g., 1h for 1 hour, 1d for 1 day)
   

   The port setting typically defaults to ssh (which resolves to port 22). If you've changed your SSH port, update this accordingly. maxretry defines the number of failed attempts before a ban, and bantime specifies the duration of the ban.

   Save and exit nano.

3. Restart and Enable Fail2ban:

    sudo systemctl restart fail2ban
    sudo systemctl enable fail2ban # Ensure it starts on boot
   

4. Check Status:

    sudo fail2ban-client status
    sudo fail2ban-client status sshd
   

   These commands will show you the active jails and any currently banned IPs for the SSH service. Fail2ban will now diligently monitor /var/log/auth.log (or your configured log path) and automatically ban repeat SSH failures, significantly enhancing your server's security posture.

Install Malware/Rootkit Scanners.

While your primary defense should be proactive security measures, having tools to detect compromises is also vital. rkhunter (Rootkit Hunter) is a popular utility for scanning for rootkits, backdoors, and other potential vulnerabilities.

sudo apt install rkhunter -y && \
sudo rkhunter --update && \
sudo rkhunter --propupd && \
sudo rkhunter --check

• --update: Updates the data files used by rkhunter.

• --propupd: Updates the file properties database. You should run this after a fresh install or major system updates to prevent false positives.

• --check: Performs the actual scan.

You should re-run sudo rkhunter --check regularly as part of your server maintenance routine to check for new issues.

Uninstall Default Applications (If Unnecessary).

Many VPS providers pre-install common application stacks like LAMP (Linux, Apache, MySQL, PHP) to get users up and running quickly. However, if you plan to deploy your applications using Docker, these pre-installed components are often redundant and can introduce conflicts or unnecessary attack surfaces. Removing them provides a cleaner environment and ensures Docker has full control over application orchestration.

Here's how to remove common default software on an Ubuntu-based VPS:

# Stop and Remove Apache
sudo systemctl stop apache2
sudo apt remove --purge apache2 apache2-utils apache2-bin apache2.2-common

# Stop and Remove MySQL (if installed directly, not in Docker)
sudo systemctl stop mysql
sudo apt remove --purge mysql-server mysql-client mysql-common

# Stop and Remove MariaDB (if installed directly, not in Docker)
sudo systemctl stop mariadb
sudo apt remove --purge mariadb-server mariadb-client

# Remove PHP and its modules (if installed directly)
sudo apt remove --purge php*

# Clean up any residual packages and orphaned dependencies
sudo apt autoremove
sudo apt autoclean

How to check what's installed:

If you're unsure what services are running or installed, you can use dpkg -l to list packages and grep to filter for specific ones:

dpkg -l | grep apache
dpkg -l | grep mysql
dpkg -l | grep php
dpkg -l | grep mariadb

Remove anything that's not explicitly needed for your Dockerized environment. This contributes to a "clean architecture" for your server itself, reducing clutter and potential vulnerabilities.

Set Up Your Hostname.

When you first provision your VPS, it's often assigned a generic hostname. It's good practice to map this properly within your system for easier identification and to ensure services that rely on hostname resolution function correctly.

1. Check your current hostname:

    hostname
   

2. Edit your /etc/hosts file: This file maps hostnames to IP addresses locally on your server.

    sudo nano /etc/hosts
   

   Look for a line that might resemble 127.0.1.1 oldhostname and update it to reflect your VPS provider's assigned hostname, or a custom one if you prefer. For example:

    127.0.1.1   your-vps-hostname
   

   Also, ensure you have the standard localhost entry:

    127.0.0.1   localhost
   

   So, a typical /etc/hosts file will look something like this:

    127.0.0.1   localhost
    127.0.1.1   your-vps-hostname
    # The following lines are desirable for IPv6 capable hosts
    ::1     localhost ip6-localhost ip6-loopback
    ff02::1 ip6-allnodes
    ff02::2 ip6-allrouters
   

   💡

   Important Note: This /etc/hosts mapping only affects local name resolution within your VPS. External clients will still need to use your domain name (with proper DNS records configured at your domain registrar) to reach your server.

   Save and exit nano (Ctrl+O, Enter, Ctrl+X).

Install NGINX (Reverse Proxy for Dockerized Apps).

NGINX is an incredibly versatile and high-performance web server that excels as a reverse proxy. For modern, Docker-based application deployments, NGINX is almost indispensable.

Why use NGINX?

• Reverse Proxy: It acts as a single entry point for all incoming web traffic, routing requests to the appropriate Docker containers based on rules you define. This decouples your application containers from direct public exposure, enhancing security.

• Load Balancing: NGINX can distribute incoming traffic across multiple instances of your application (e.g., multiple Docker containers), improving scalability and fault tolerance.

• Static File Serving: It's highly efficient at serving static assets (HTML, CSS, JavaScript, images), offloading this task from your application containers.

• SSL Termination: NGINX can handle SSL/TLS encryption and decryption, allowing your application containers to run on plain HTTP internally, simplifying their configuration.

• Security: By sitting in front of your application, NGINX can filter malicious requests and provide an additional layer of defense.

In a Dockerized setup, NGINX often serves as the public-facing component, directing requests to your backend services running in containers. This aligns perfectly with a "clean architecture" by clearly separating concerns.

Installation:

sudo apt update
sudo apt install nginx

After installation, verify that NGINX is running:

sudo systemctl status nginx

You should see output indicating that the service is active (running).

Enable NGINX to start automatically on boot:

sudo systemctl enable nginx

To test if NGINX is working, open your VPS's IP address in a web browser. You should see the default NGINX welcome page, confirming that your web server is operational.

In a .NET application, application configuration refers to the process of loading settings—typically key-value pairs—into your application or hosting environment. These settings can come from multiple sources, known as configuration providers.

⚙️ Host and Application Configuration in ASP.NET Core

ASP.NET Core separates configuration into two main categories:

1. Host Configuration

• Controls how the application is hosted and started (e.g., server URLs, environment).

• Loaded early—before the app is built.

• Examples:

  • ASPNETCORE_ENVIRONMENT – sets the environment (e.g., Development, Production)

  • DOTNET_URLS – sets the URLs the app will listen on

2. Application Configuration

• Governs application behavior and feature settings used at runtime.

• Loaded after the host is built.

• Examples:

  • ConnectionStrings:Default – database connection string

  • JwtSettings:Secret – authentication secret

  • MyCustomFeature:Enabled – feature flags

Both types of configuration are layered from multiple sources (JSON files, env vars, CLI args, etc.), but their timing and purpose differ.

Configuration priority.

Even though host configuration is loaded first and used to build the application host, application configuration has higher effective priority at runtime.

🔑 Here's how ASP.NET Core resolves conflicts when the same key exists in multiple sources:

✅ In short: application configuration overrides host configuration during runtime. This means your feature flags, secrets, and connection strings won’t be unintentionally overridden by host-level settings.

🏗️ WebApplicationBuilder in ASP.NET Core Application.

When you initialize an ASP.NET Core application, you'll commonly see the following line of code:

var builder = WebApplication.CreateBuilder(args);

This single line does a lot under the hood. One of its key responsibilities is setting up a default configuration system with a built-in order of precedence. Here's how configuration sources are loaded—from lowest to highest priority:

1. appsettings.json

2. appsettings.{Environment}.json (e.g., appsettings.Development.json)

3. User secrets (only in the Development environment)

4. Environment variables

5. Command-line arguments

Internally, this is roughly equivalent to the following:

Host.CreateDefaultBuilder(args)
    .ConfigureAppConfiguration((hostingContext, config) =>
    {
        var env = hostingContext.HostingEnvironment;

        config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
              .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);

        if (env.IsDevelopment())
        {
            config.AddUserSecrets<Program>();
        }

        config.AddEnvironmentVariables();

        if (args != null)
        {
            config.AddCommandLine(args);
        }
    });

This layered configuration model gives you flexibility to manage settings in a way that’s appropriate for different environments and deployment scenarios.

🦀 Common Mistake: Re-adding Configuration Sources

A common pitfall in ASP.NET Core is manually re-adding configuration providers after this line:

var builder = WebApplication.CreateBuilder(args);

For example:

builder.Configuration.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
                     .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);

At first glance, this might seem harmless—but it's usually unnecessary and potentially harmful.

By manually adding configuration files again, you risk:

• Overriding existing values unintentionally

• Redundant file reads

• Unexpected configuration merge behavior.

🤝 Understanding Merged Configuration

The configuration system in ASP.NET Core merges settings from all providers. If multiple sources define values for the same key, the last one added wins.

🔹 Adding New Keys

Suppose you have the following in your appsettings.json:

"JwtSetting": {
  "Issuer": "yourIssuer",
  "Audience": "yourAudience",
  "AccessTokenExpMinute": 10,
  "RefreshTokenExpiration": 30
}

And you define this in your user secrets (Development only):

"JwtSetting": {
  "Secret": "your-secret-key"
}

The final merged configuration at runtime will be:

"JwtSetting": {
  "Issuer": "yourIssuer",
  "Audience": "yourAudience",
  "AccessTokenExpMinute": 10,
  "RefreshTokenExpiration": 30,
  "Secret": "your-secret-key"
}

Each source contributes to the overall object unless a full override is performed.

🔹 Overriding Existing Keys

If the same key is defined in multiple places, the source added last takes precedence. For example:

// appsettings.json
"ApiKey": "ValueFromAppSettings"

// appsettings.Development.json
"ApiKey": "ValueFromDevSettings"

Then you set an environment variable:

set ApiKey=ValueFromEnv

And run the application with a command-line override:

dotnet run --ApiKey=ValueFromCommandLine

The final value of ApiKey will be:

"ApiKey": "ValueFromCommandLine"

Custom Configuration Sources

In addition to the built-in configuration providers, ASP.NET Core makes it easy to add custom configuration sources. This is especially useful for keeping sensitive data like secrets or credentials out of your codebase.

For example, instead of storing everything in appsettings.json you could store some settings in the Azure App Configuration or securely store secrets in the Azure Key Vault.

🔗 I’ve written a detailed guide on integrating Azure Key Vault with ASP.NET Core. You can read it here: Azure Key Vault: Secure .NET App Secrets

Conclusion

Using configuration properly in ASP.NET Core enables your application to be environment-aware, secure, and maintainable. By understanding how the configuration system merges values across sources—and by using the right source for the right purpose—you can avoid common pitfalls and keep your app flexible for development, testing, and production.

For best results:

• Let WebApplication.CreateBuilder handle the default setup.

• Use additional providers (like Azure Key Vault or custom JSON files) only when necessary.

• Understand and leverage the configuration precedence order to avoid surprises at runtime.

Why use Azure Key Vault?

Your secret is stored safely in the cloud.

By avoiding the storage of security information within applications, you eliminate the need to embed sensitive data in the code. For instance, if an application needs to connect to a database, you can securely store the connection string in Key Vault instead of hardcoding it in the application.

Access to your Key Vault is also secured through both authentication and authorization. Before a caller (whether a user or an application) can access the Key Vault, they must first be properly authenticated and authorized. Authentication is handled through Microsoft Entra ID, while authorization can be managed either using Azure Role-Based Access Control (Azure RBAC) or Key Vault access policies.

Easy to monitor.

Azure Key Vault makes it easy to monitor how and when your secrets are accessed. By enabling logging for your vaults, you can track all activity in detail. You have full control over your logs — you can secure them by restricting access and deleting any logs you no longer need.

Automatic Secret Refresh Without Application Restart.

Another powerful advantage of using Azure Key Vault is its ability to automatically refresh secrets when they change, without requiring you to restart your application.

For example, if you store a JWT secret key in Key Vault and later decide to update it (e.g., for security rotation), your application can pick up the updated secret automatically. This eliminates downtime and reduces the risk associated with manually restarting services to load new secrets.

By combining Azure Key Vault with services like Azure App Configuration and enabling dynamic refresh policies, you can ensure that your application always uses the latest secure values, improving both security and operational efficiency.

Tip: To automatically see secret updates without restarting services, use IOptionsSnapshot<T> instead of IOptions<T> for your settings injection

Create and configure Azure Key Vault

Now, let’s jump into the implementation.

• Go to https://portal.azure.com/ , select a service named Key Vaults, and create it.

  

• In the side menu, select Objects > Secrets.

• At the top, select the generate/import menu

• Fill the name and secret value field, and then click the create button.

Note: In the screenshot below, I use "JwtSecret" as the secret name. However, in the example code, I use "JwtSettings--Secret"*.
Don’t let the difference confuse you — the concept remains the same.*

• You can manage access permissions using Access Control (IAM).

However, in this article, we won't dive deeper into configuring Access Control settings.

Now that your secrets are securely set up, it's time to integrate them into your .NET application.

Configure your .NET application.

There are two ways to connect your .NET application to Azure Key Vault: Automatic Configuration Approach and the Manual Service Approach.

Automatic Configuration Approach.

With this approach, you load secrets from Azure Key Vault directly into your application's configuration.

To do this, you need to install 3 packages (The example is using .NET CLI. You can also install using NuGet Package):

dotnet add package Azure.Identity
dotnet add package Azure.Security.KeyVault.Secrets
dotnet add package Azure.Extensions.AspNetCore.Configuration.Secrets

In the example below, I’ll show you how to configure your appsettings.json and Program.cs
Note: For better code organization, I recommend moving the setup into a separate method to keep your Program.cs clean. I’ve provided a full example in the repository linked at the end of this article.

appsettings.json

"AzureKeyVault": {
  "VaultURI": "Your vault URI",
  "ClientId": "Your client id",
  "TenantId": "Your tenant id",
  "ClientSecret": "Your client secret"
}

Program.cs

var keyVaultSettings = new
{
  VaultUri = builder.Configuration["AzureKeyVault:VaultUri"],
  TenantId = builder.Configuration["AzureKeyVault:TenantId"],
  ClientId = builder.Configuration["AzureKeyVault:ClientId"],
  ClientSecret = builder.Configuration["AzureKeyVault:ClientSecret"]
}; // Taken from appsettings.json

// Add services to the container.
builder.Configuration.AddAzureKeyVault(
          new Uri(keyVaultSettings.VaultUri),
          new ClientSecretCredential(
              tenantId: keyVaultSettings.TenantId,
              clientId: keyVaultSettings.ClientId,
              clientSecret: keyVaultSettings.ClientSecret),
          new AzureKeyVaultConfigurationOptions
          {
            ReloadInterval = TimeSpan.FromMinutes(30)
          }); // Custom extension method to add Azure

What’s interesting here is that you can seamlessly combine values from both your appsettings.json and Azure Key Vault.

For example, if your local appsettings.json contains a key like JwtSettings:Secret, and you have a corresponding secret in Azure Key Vault named JwtSettings--Secret (In key vault, use a double dash -- to map to the colon :), the value from Azure Key Vault will automatically override the value from your local configuration.

Now, when you access your app configuration using the name of your secret — for example, configuration["JwtSettings:Secret"] — you will retrieve the value from Azure Key Vault.

Manual Service Approach.

This approach uses a custom service to retrieve secrets. First, you need to install 2 packages:

dotnet add package Azure.Identity
dotnet add package Azure.Security.KeyVault.Secrets

Next, I create a method to validate the credentials needed to access Azure Key Vault.

public static SecretClient CreateSecretClient(IConfiguration configuration)
{
    // Bind the configuration section to the AzureKeyVaultConfig class
    var keyVaultSetting = configuration.GetSection("AzureKeyVault").Get<AzureKeyVaultConfig>()
                   ?? throw new InvalidOperationException("Missing AzureKeyVault configuration.");
     var credential = new ClientSecretCredential(keyVaultSetting.TenantId,
                            keyVaultSetting.ClientId, 
                            keyVaultSetting.ClientSecret);
    var vaultUri = new Uri(keyVaultSetting.VaultUri);
     return new SecretClient(vaultUri, credential);
}

Next, I create a service that retrieves the secrets by using the SecretClient.

public async Task<string> GetJwtSecretAsync()
{
     var response = await _secretClient.GetSecretAsync("JwtSettings--Secret");
     return response.Value.Value;
}

Now you can call your secret using the GetJwtSecretAsync() method.

When accessing Azure Key Vault from your .NET application, there are two common ways to authenticate.
In the above example, I used TenantId, ClientId, and ClientSecret to authenticate with Azure Key Vault. However, there's another option that I recommend, which is using DefaultAzureCredential().
In the next section, I'll show you both authentication methods you can use to connect to your Azure Key Vault.

Two Ways to Authenticate to Azure Key Vault

When accessing Azure Key Vault from your .NET application, there are two common ways to authenticate:

1. Using DefaultAzureCredential()

DefaultAzureCredential is the easiest and most flexible option for many scenarios. It automatically tries multiple authentication methods under the hood, such as:

• Environment variables

• Managed Identity (for Azure-hosted apps)

• Visual Studio / Azure CLI logged-in credentials (for local development)

This makes it a great choice if you want a seamless experience between local development and production environments, without changing any code.

Example:

var credential = new DefaultAzureCredential();
var client = new SecretClient(new Uri(keyVaultSettings.VaultUri), credential);

2. Using ClientSecretCredential

ClientSecretCredential is a more manual and explicit approach. You provide a Tenant ID, Client ID, and Client Secret directly, typically configured through your application settings.

This method is useful when you want full control over the credentials being used or when running in environments where Managed Identity is not available.

Example:

var credential = new ClientSecretCredential(
    tenantId: keyVaultSettings.TenantId,
    clientId: keyVaultSettings.ClientId,
    clientSecret: keyVaultSettings.ClientSecret);

var client = new SecretClient(new Uri(keyVaultSettings.VaultUri), credential);

🛠️ Let’s Get Hands-On!

I've uploaded the full implementation with a simple and clean approach — dive into the code here! Azure Key Vault Integration Repository

Happy coding!

Real-world Example

TV Remote

• A TV remote has several functions like turning the TV on or off, changing channels, increasing volume, etc.

• As users, we only know that these functions will be executed by pressing the corresponding buttons on the remote.

• What actually happens behind the scenes is hidden from us.

Benefits of Using Abstraction

• Reduces Complexity

  This principle only provides method signatures while hiding how those methods are implemented.

• Enhances Security

  Because we only provide the necessary details to call a method while hiding how the method is implemented.

• Facilitates Development

  Since we can make any internal system changes without affecting the users of the method.

Abstraction can be achieved in two ways:

• Using abstract classes and abstract methods.

• Using Interfaces.

Abstract Class and Abstract Method

Characteristics of an Abstract Class.

• Cannot be instantiated directly.

• Serves as a blueprint for other classes, meaning it can contain abstract methods (which must be implemented by its subclasses) and concrete methods (which have full implementations).

Characteristics of an Abstract Method

• Declared in an abstract class without implementation.

• Only has a method signature (method name, return type, and parameters) without implementation.

• The actual implementation is left to the subclasses.

Example of an abstract class with all abstract methods.

public abstract class IBank
{
    public abstract void ValidateCard();
    public abstract void WithdrawMoney();
    public abstract void CheckBalanace();
    public abstract void BankTransfer();
    public abstract void MiniStatement();
}

public class SBI : IBank
{
    public override void BankTransfer()
    {
        Console.WriteLine("SBI Bank Bank Transfer");
    }
    public override void CheckBalanace()
    {
        Console.WriteLine("SBI Bank Check Balanace");
    }
    public override void MiniStatement()
    {
        Console.WriteLine("SBI Bank Mini Statement");
    }
    public override void ValidateCard()
    {
        Console.WriteLine("SBI Bank Validate Card");
    }
    public override void WithdrawMoney()
    {
        Console.WriteLine("SBI Bank Withdraw Money");
    }
}

IBank sbi = new SBI();
sbi.ValidateCard();
sbi.WithdrawMoney();
sbi.CheckBalanace();
sbi.BankTransfer();
sbi.MiniStatement();

In the code above, we declare a class as an abstract class by adding the abstract modifier. We also declare all its methods as abstract methods, where no implementation is allowed (only the method body). However, when we create a subclass of IBank, in the example above, SBI, all methods from IBank must be implemented by adding the override keyword to each method in the child class.

We also need to pay attention during object initialization. On the left side or reference type, we set the object ‘sbi’ as IBank, the abstract class, while on the right side or object type, we set it as the SBI class. When we call a method, the compiler recognizes all these methods because they are in the abstract class, but during runtime, the implementation is determined based on the object type, in this case, SBI.

Example of an abstract class with abstract and concrete methods.

public abstract class Bird
{
    public abstract void Fly();
    public void LayEggs()
    {
        Console.WriteLine("Laying eggs");
    }
}
public class Sparrow : Bird
{
    public override void Fly()
    {
        Console.WriteLine("Sparrow is flying");
    }
}

In the code example above, we declare some methods as abstract methods and others as concrete methods. This way, when we create a subclass or child class, we must override the Fly() method because in the parent class, the method is set as an abstract method (without implementation), while the LayEggs() method is not overridden because it is a concrete method (with implementation).

Interface.

An interface is an abstract type used to define a contract (or blueprint) for classes that implement it.

Let's look at the code example directly.

interface ISpeakable
{
    void Speak();  // This method must be implemented by its child class.
}

interface IMoveable
{
    void Move();
}

public class Dog : ISpeakable, IMoveable
{
    public void Speak()
    {
        Console.WriteLine("Bark");
    }

    public void Move()
    {
        Console.WriteLine("Dog is running");
    }
}

Dog dog = new Dog();
dog.Speak();
dog.Move();

Note: A class is said to implement an interface, not inherit from it.

In the code above, we can see that the Dog class implements two interfaces simultaneously, ISpeakable and IMoveable, which is allowed, unlike abstract classes that do not allow a child class to be derived from two classes simultaneously (C# allows a class to be derived from only one class).

The concept of interfaces is very popular and often encountered in complex projects.

Differences between Abstract Class and Interface

See the differences between abstract classes and interfaces in the table below.

We have finished discussing the concept of Abstraction in Object-Oriented Programming (OOP), thus completing our discussion on the four pillars of Object-Oriented Programming (OOP). Thank you!

Polymorphism is a concept in Object-Oriented Programming (OOP) where an entity (variable, object, method) can change into other forms.

Real-world Example

Let's take the example of a person who can have many roles in their life.

• At the Office, Person A behaves like an employee.

• At the Mall, Person A behaves like a customer.

• At Home, Person A behaves like a father.

Polymorphism can be achieved in two ways:

• Compile-time Polymorphism (Method Overloading).

• Run-time Polymorphism (Method Overriding).

Compile-time Polymorphism (Method Overloading)

Occurs when several methods have the same name but different parameters (in number, type, or order).

Method overloading can be done under several conditions:

• Done on methods within the same class.

• Done on methods within a child class.

• Done on constructors.

Some rules for Method Overloading:

• Parameters must differ (in number, type, or order).

• Return type alone cannot distinguish overloaded methods.

• Occurs at compile time (also called Compile-time Polymorphism).

Example code: Method overloading in the same class.

public class Person
{
    public int SummingUp(int a, int b)
    {
        return a + b;
    }
    public int SummingUp(int a, int b, int c)
    {
        return a + b + c;
    }
    public double SummingUp(double a, double b)
    {
        return a + b;
    }
}

In the code above, we can see that there are three methods with the same name in one class. Although they have the same name, these three methods have different parameters, so the compiler recognizes them as different methods, and no error will occur.

Example code: Inheritance-based method overloading.

class Person1
{
    public void SummingUp(int a, int b)
    {
        Console.WriteLine(a + b);
    }
    public void SummingUp(float x, float y)
    {
        Console.WriteLine(x + y);
    }
}
class Person2 : Person1
{
    public void SummingUp(string s1, string s2)
    {
        Console.WriteLine(s1 +" "+ s2);
    }
}

In the code above, we perform method overloading in different classes, but they are still derived from the previous class. This way, the compiler can also recognize the method as different, so this can be done without causing errors.

Example code: Constructor Overloading.

class Person
{
    int x, y, z;
    public Person(int x)
    {
        Console.WriteLine("Constructor1 Called");
        this.x = 10;
    }
    public Person(int x, int y)
    {
        Console.WriteLine("Constructor2 Called");
        this.x = x;
        this.y = y;
    }
    public Person(int x, int y, int z)
    {
        Console.WriteLine("Constructor3 Called");
        this.x = x;
        this.y = y;
        this.z = z;
    }
    public void Display()
    {
        Console.WriteLine($"X={x}, Y={y}, Z={z}");
    }
}

Person obj1 = new Person(10);
obj1.Display();
Person obj2 = new Person(10, 20);
obj2.Display();
Person obj3 = new Person(10, 20, 30);
obj3.Display();

In the code above, we perform method overloading on the constructor along with an example of its implementation during initialization. This method is very advantageous because if at any time we want to add parameters to the constructor, we do not need to change the logic we have previously created when declaring objects. We just need to create a new constructor with different parameters and call it by adjusting the number and type of parameters.

Runtime Polymorphism (Method Overriding)

• Method overriding occurs when a child class specifically implements a method that has been defined in its parent class. The method that allows for overriding needs to be added with a virtual modifier.

• Done by adding the keyword 'override' to the method that performs the override.

• The goal is for the child class to replace the behavior of the method inherited from its parent class.

Some rules for Method Overriding:

• The modifier on the parent class method needs to be added with "virtual" and the modifier on the child class method needs to be added with "override".

• The method in the child class must have the same name, return type, and parameters as its parent class.

• Occurs at runtime (also called runtime polymorphism).

When do we need to override a method? If the logic in the parent class method cannot meet the business requirements of the child class.

Here is the example code.

public class Animal
{
    public virtual void Speak()
    {
        Console.WriteLine("The animal makes a sound.");
    }
}
public class Dog : Animal
{
    public override void Speak()
    {
        Console.WriteLine("The dog barks.");
    }
}
public class Cat : Animal
{
    public override void Speak()
    {
        Console.WriteLine("The cat meows.");
    }
}

Animal myAnimal = new Animal();
myAnimal.Speak(); // "The animal makes a sound."
myAnimal = new Dog();
myAnimal.Speak(); // "The dog barks."
myAnimal = new Cat();
myAnimal.Speak(); // "The cat meows."

In the example code above, we perform method overriding on the Speak() method. In the parent class, we initially determined the implementation of the Speak() method, but in the child class, we override it by providing a new implementation for the Speak() method. So when the class is initialized into an object, we can call the method and produce different outputs according to the Object Type we use.

Note:

• If there is no method override in the child class, the method from its parent class will be executed.

• Example: If we delete the Speak() method in the Cat class, when executing the Speak() method for the Cat object type, the output will be: "The animal makes a sound," not "The cat meows" anymore.

What actually happens at compile time and run time?

• At compile time, the compiler checks the reference type.

• At run time, the CLR checks the object type.

• This is why it is called compile-time polymorphism and runtime polymorphism.

The consequence is that when there is an implementation error related to the object type, the error will not be detected at compile time because the writing is considered correct. However, when run at runtime, the error will appear and be discovered.

We have learned about the concept of Polymorphism in OOP, next we will look at the last concept of OOP, which is Abstraction.

Real-world Example

For example, a Bag and its contents. In this illustration, all the contents of the bag, such as books, pens, rulers, etc., are combined and stored in a bag. We cannot take out the pen, book, and various other items inside the bag without first opening the bag.

Code Example

class Bank
{
    public long AccountNumber;
    public string Name;
    public int Balance;

    public void GetBalance()
    {
    }
    public void WithdrawAmount()
    {
    }
    public void Deposit()
    {
    }
}

In the example above, the Bank class is an example of encapsulation. The data members and methods of the class are bound in a single unit, which is the Bank class.

Here, encapsulation binds the implementation details of the Bank class. If there is code that wants to access the fields & methods in the Bank class, it must first initialize an object of the Bank class, as shown in the code below.

Bank bank = new Bank();
// The property and method below cannot be accessed without first
// declaring an object of the bank class.
bank.AccountNumber = 12345678;
bank.Name = "Kristiadhy";
bank.GetBalance();
bank.WithdrawAmount();

Data Hiding in Encapsulation

The biggest advantage of encapsulation is data hiding, the process where we hide internal data from the outside world. Data hiding is also known as Data Encapsulation.

To hide and expose data, we need access modifiers. Access Modifiers are keywords that determine the accessibility level of a class, method, variable, and other members.

In C#, generally, access modifiers can be divided into 4 (although it can be more if combining several access modifiers), for example:

• Private.

  Members can only be accessed within the class itself.

• Protected.

  Members can be accessed within the class and all its derived classes.

• Internal.

  Members can be accessed within the same assembly.

• Public.

  Members can be accessed by the same assembly or different assemblies that reference it.

Here is the code example:

public class BankDataEncapsulation
{
    // The balance field is hidden from access outside the class
    // by using the private access modifier
    private double balance;

    // Create public Setter and Getter methods
    // Public Getter method
    // This method is used to return the value of the balance variable
    public double GetBalance()
    {
        // We can add validation if necessary    
        return balance;
    }

    // Public Setter Method
    // This method is used to assign a value to the balance variable
    public void SetBalance(double balance)
    {         
        // We can add validation to check
        // whether the input data is correct or not.
        this.balance = balance;
    }
}

In the code example above, in the class, we have a field balance set as private. The field cannot be accessed by anyone outside its class (even if the class has been initialized as an object). An example can be seen in the code below.

BankDataEncapsulation bankEncapsulation = new BankDataEncapsulation();
bankEncapsulation.balance; // This line will result in a compile-time error.

So how do we manipulate the balance value in the BankDataEncapsulation class? We can do it by accessing the getter and setter methods that have been set as public. Please see the code example below.

BankDataEncapsulation bankEncapsulation = new BankDataEncapsulation();
bankEncapsulation.SetBalance(500);
Console.WriteLine(bankEncapsulation.GetBalance());

This way, the balance field is safe and locked so that its value cannot be changed except by the methods allowed by the class through certain access modifiers. This ensures data security.

Additionally, when we want to add validation to the balance value, we can add it by modifying the getter and setter methods, so we don't need to change the code when calling the method. Here is the code example.

    public double GetBalance()
    {
        // In the getter method, we add validation.
        if(balance > 1000000)
            throw new Exception("Anda tidak bisa cek saldo diatas 1000000");  

        return balance;
    }

    public void SetBalance(double balance)
    {         
        // We also add validation in the setter method.
        if(balance < 0)
            throw new Exception("Saldo tidak boleh negatif");

        this.balance = balance;
    }

We can see that even though there is additional logic in both methods, the code when calling the method remains the same/unchanged, still like this.

BankDataEncapsulation bankEncapsulation = new BankDataEncapsulation();
bankEncapsulation.SetBalance(500);
Console.WriteLine(bankEncapsulation.GetBalance());

This is very advantageous because we don't need to make many adjustments when there is a change in logic. This is a simple example of the benefits of the Encapsulation concept.

Some Benefits of Encapsulation

• Data Protection.

  We can validate data before storing it in a variable.

• Data Hiding.

  The caller will not know about the implementation of the parts inside the class.

• Security.

  The principle of encapsulation helps secure our code by ensuring that other units (class, interface, etc.) cannot access data directly.

• Flexibility.

  The principle of encapsulation makes our code more flexible, allowing programmers to easily change or update the code.

• Control.

  The principle of encapsulation provides greater control over the data stored in variables. For example, we can control data by validating whether it is good enough to be stored in a variable.

We have learned about one of the concepts of the 4 pillars of OOP, which is Encapsulation. Next, we will learn about another concept in OOP, which is Polymorphism.

Real-world example.

The relationship between animals and dogs.

• Animals are a general category that includes various living creatures with basic traits like breathing and moving.

• Dogs, as a type of animal, inherit these traits but also have specific characteristics, such as barking and loyalty to their owners.

• In this illustration, animals are referred to as the base class/parent class/superclass, while dogs are referred to as the derived class/child class/subclass, inheriting basic traits from animals and adding their own unique traits.

Code example.

Here is an example of creating a class for animals (class Animal) and dogs (class Dog).

public class Animal
{
    public void Eat()
    {
        Console.WriteLine("Animal is eating.");
    }
}

public class Dog : Animal
{
    public void Bark()
    {
        Console.WriteLine("Dog is barking.");
    }
}

Here is an example when the dog class (which is a subclass of the Animal class) is initialized into an object.

Dog myDog = new Dog();
myDog.Eat();
myDog.Bark();

In the code above, we can see that the variable myDog is declared with the object type 'Dog'. When calling a method, the myDog object can call the Eat() method, which is a method from its parent class, 'Animal', but can also call the Bark() method, which is a unique method of the 'Dog' class itself.

Rules of Inheritance to consider.

In using inheritance, there are several rules to consider, including:

Rule 1:

A child class can access members of the parent class, but the parent class can never access members purely defined in the child class.

// Code example 1
Dog myDog = new Dog();
myDog.Eat();
myDog.Bark(); // This part does NOT result in an error.

// Code example 2
Animal myAnimal = new Animal();
myAnimal.Eat();
myAnimal.Bark(); // This part results in an error.

The last line in code example 2 above will result in an error because Bark() is a method or function specific to Dog, which is a child class, not a method belonging to Animal as the parent class of Dog.

Rule 2:

We can initialize a parent class variable using a child class instance. With this technique, the parent class will act as a reference variable.

Animal myAnimal= new Dog();
myAnimal.Eat();
myAnimal.Bark();

In the variable declaration above, we initialize the variable myAnimal with its object type as Dog. In the last line of that code, the compiler will recognize it as an error. Why? Because at compile time, the compiler checks the reference variable (left side), while the object type (right side) is checked at runtime (we will explore more about what happens at compile time and runtime in the topic of Polymorphism). Since at compile time the reference variable (left side) is used, which is the Animal class, and that class does not have a Bark() method/function, an error occurs.

Rule 3:

If the parent class has a constructor, that constructor must be accessible by the child class.

public class Animal
{
    Animal() // Constructor from the parent class
    {
        Console.WriteLine("Animal Constructor is Called");
    }
    public void Eat()
    {
        Console.WriteLine("Animal is eating.");
    }
}

public class Dog : Animal
{
    public Dog() // Constructor from the child class
    {
        Console.WriteLine("Dog Constructor is Called");
    }
    public void Bark()
    {
        Console.WriteLine("Dog is barking.");
    }
}

In the section above, an error will occur because the animal constructor does not allow access by other classes outside itself (the default modifier on a class is private). The solution is to provide a modifier that allows the child class to access the constructor of its parent class, for example: By adding the "Public" access modifier to the Animal constructor, no error will occur.

Rule 4:

If the parent class constructor is given parameters, the child class constructor cannot implicitly call its parent constructor without passing parameters.

public class Animal
{
    public Animal(int number)
    {
        Console.WriteLine($"Animal Constructor is Called : {number}");
    }
    public void Eat()
    {
        Console.WriteLine("Animal is eating.");
    }
}

public class Dog : Animal
{
    // When creating a constructor for the child class, you must also 
    // pass parameters to its base class.
    // If not (if the code ": base(10)" is not written), an error will occur.
    public Dog() : base(10)
    {
        Console.WriteLine("Dog Constructor is Called");
    }
    public void Bark()
    {
        Console.WriteLine("Dog is barking.");
    }
}

Notice the code above, when declaring the constructor in the child class, we pass parameters to the base class constructor or its parent class, so the code is correct and not in error. However, if “: base(10)” is not written, meaning no parameters are passed to the parent class, an error will occur.

Types of inheritance.

Single Inheritance.

Where a class, known as a derived class, is based on another class, known as the base class (or parent class).

public class Animal
{
    public void Eat()
    {
        Console.WriteLine("Animal is eating.");
    }
}

public class Dog : Animal
{
    public void Bark()
    {
        Console.WriteLine("Dog is barking.");
    }
}

Multilevel Inheritance.

Where a class is derived from another derived class, creating an inheritance chain.

public class Grandfather
{
    public void Display()
    {
        Console.WriteLine("This is the grandfather class");
    }
}

public class Father : Grandfather
{
    public void Show()
    {
        Console.WriteLine("This is the father class");
    }
}

public class Child : Father
{
    public void DisplayChild()
    {
        Console.WriteLine("This is the child class");
    }
}

Hierarchical Inheritance.

Where multiple classes are derived from a single base class, forming a tree-like structure.

public class Parent
{
    public void Display()
    {
        Console.WriteLine("This is the parent class");
    }
}

public class Child1 : Parent
{
    public void Show1()
    {
        Console.WriteLine("This is the first child class");
    }
}

public class Child2 : Parent
{
    public void Show2()
    {
        Console.WriteLine("This is the second child class");
    }
}

We can see this more clearly in the following image.

We have learned about the concept of Inheritance in OOP, next we will look at the next concept of OOP, which is Encapsulation.

The main goal of Object-Oriented Programming (OOP) is to organize code in a way that reflects real-world entities and interactions, making applications more robust and easier to develop.

Class vs Object

Class

A class is a blueprint or template that contains data and behavior (method/function) that can be accessed by creating an instance (object) of that class. For more clarity, let's look at the following image:

The image above is an illustration of a blueprint or template of a car. The image is not the actual physical car, but just a sketch, which we call the car class.

The "Car" class has attributes such as color, brand, and model, as well as methods or functions like move and stop.

Object

An object is an instance or realization of a class, an object is like the physical form of a class. Objects can have their own data values that differ from one object to another. For more clarity, let's look at the following image.

The image above is no longer a blueprint or template, but has become a car object, which is called an object.

Now we can assign values to the car object's attributes according to the list of attributes specified in its blueprint or class (color, brand, and model), for example:

• Color = Blue.

• Brand = BMW.

• Model = i5 (just an example, I don't know what type of BMW the image is XD).

We can also execute the behavior or methods of the car (called method/function) such as the "move" and "stop" methods. When we execute its method/function, the car will perform the "move" or "stop" command.

Code Example

Here is a code example for class and object in the C# programming language.

Example code for class:

public class Car
{
    // This is an AutoProperty (C# 3.0 and higher)
    // used to generate a private field for you
    public string Color { get; set; }
    public string Brand { get; set; }
    public string Model { get; set; }

    public void Drive()
    {
        Console.WriteLine("The car is driving.");
    }
}

Example code for object:

// This is an object of the Car class.
Car myCar = new Car();
myCar.Color = "Blue";
myCar.Brand = "BMW";
myCar.Model = "i5";
myCar.Drive();

Here is the difference between class and object in a table:

We have learned more about classes and objects, next we will look at the 4 basic principles of Object Oriented Programming (OOP), starting with the first principle, Inheritance.

Publish your web app project.

You must publish your website to a folder before deploying it to a Linux VPS. In your visual studio, you can right click on your project and select publish. Set your public profile to folder.

Set your folder location.

And in your publish configuration, you can set it up as follows.

After you succeed, check it out and make sure everything is working correctly. If you need to make any adjustments, republish it.

Copy the project to your VPS.

Now please login to your Linux VPS server using FTP client, in my case I use WinSCP.

After you log in successfully, drag all the files from your 'publish' folder into your website folder location on the VPS server, for example, /var/www/yourdomainname.com/.

Edit your virtual host configuration file.

Next, you'll want to configure the virtual host file. Head over to /etc/apache2/sites-available and edit your virtual host file, yourdomainname.com.conf, by adding a few lines (I've put the comments in there for you).

<VirtualHost yourdomainname.com:443>
    ServerAdmin admin@yourdomainname.com
    ServerName yourdomainname.com
    ServerAlias www.yourdomainname.com
    DocumentRoot /var/www/yourdomainname.com/wwwroot
    # ---Start here---
    ProxyPreserveHost   On
    ProxyPassMatch      ^/_blazor/(.*) http://localhost:5000/_blazor/$1
    ProxyPass           /_blazor ws://localhost:5000/_blazor
    ProxyPass           / http://localhost:5000/
    ProxyPassReverse    / http://localhost:5000/
    # ---End here---
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
    SSLEngine on
    SSLCertificateFile /etc/ssl/private/certificate.crt
    SSLCertificateKeyFile /etc/ssl/private/private.key
    SSLCertificateChainFile /etc/ssl/private/ca-bundle.crt
</VirtualHost>

You can read it here for more details Host and deploy ASP.NET Core server-side Blazor apps | Microsoft Learn

Enable some proxy services.

After that you need to enable some proxy services. Please run these commands using your SSH:

a2enmod proxy
a2enmod proxy_wstunnel
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

I got this from here Deploying DotNet Core to Linux | Coding Droplets, thanks to Coding Droplets.

Now you can run your Blazor app. You can use this command:

cd /var/www/yourdomainname.com
dotnet run YourWebAppName.dll

To register your web app as a service and running in the background, go to the next step.

Create a service unit file.

Use your FTP client again, navigate to /etc/systemd/system/ and make a service file. You can name whatever you want for example YourWebService.service. Inside the file you can write like this:

[Unit]
Description = My Blazor web app service.

[Service]
WorkingDirectory = /var/www/yourdomainname.com
ExecStart = /usr/bin/dotnet /var/www/yourdomainname.com/YourWebAppName.dll
Restart = always
RestartSec = 10
KillSignal = SIGINT
SysLogIdentifier = YourWebAppName
User = YourUserName
Environment = ASPNETCORE_ENVIRONMENT = Production

[install]
WantedBy = multi.user.target

Now, enable and Run the service.

systemctl start YourWebAppName
systemctl enable YourWebAppName

Now that your web app service is up and running in the background, go ahead and open your website to test it out!

I previously used Azure to host Asp .Net Core or Blazor Web Assembly 8.0 application and it was easy. You simply select and set up the service in the Azure portal, link your GitHub account, publish your application, and point to your Azure account, and your website app will go online. Now let's explore another method using a VPS, which is also pretty simple if we're willing to understand the details.

Before you can host your Asp .Net Core or Blazor Web Assembly 8.0 application on a Linux VPS, you need to acquire and set it up.

Get a VPS service.

First, pick any provider that suits you. VPS prices are usually pretty affordable. Just remember, before you start installing Linux OS on your VPS server, make sure the OS version is compatible with the .Net version you want to install, in this case, .Net 8. You can check the supported .NET releases and the versions of Ubuntu they're supported here: .NET and Ubuntu overview - .NET | Microsoft Learn. In my case, I use Ubuntu 20.04, just make sure to select the right OS during the initial VPS registration. A web server is typically pre-installed when you register for a VPS. If it’s not, you can choose from popular options like Nginx or Apache. This time, I’m going with Apache.

Install the .NET 8.0 package.

After the Apache is installed on your server, now it's time to install the .Net 8.0 package. You can choose between the SDK and runtime options, depending on what you need. Check out this link for details: https://learn.microsoft.com/en-us/dotnet/core/install/linux-ubuntu-install?tabs=dotnet8&pivots=os-linux-ubuntu-2004.

Next, make sure you add the Microsoft package signing key to your trusted keys and include the package repository.

wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb sudo dpkg -i packages-microsoft-prod.deb rm packages-microsoft-prod.deb

To install the .NET runtime, just run the following commands:

sudo apt-get update && sudo apt-get install -y aspnetcore-runtime-8.0

Create a directory for your website.

You can do the following:

mkdir -p /var/www/yourdomainname.com

Set the ownership of the directory. If you have set up a separate user, you can configure it for that user. But I haven't set up a specific user in this guide, so I'm still using root.

sudo chown -R $USER:$USER /var/www/yourdomainname.com

Next, make sure the permissions on the directory allow you to read, write and execute files. And only give read and execute permissions to groups and others.

You can run the command below.

sudo chmod -R 755 /var/www/yourdomainname.com

Change the default virtual host configuration.

Go to /etc/apache2/sites-available/, and you will find a file like this 000-default.conf. This is the default virtual host configuration, you can copy its contents and create a new virtual host file for your site, you can name it yourdomainname.com.conf. Edit the contents as shown in the example below:

<VirtualHost *:80>
ServerAdmin admin@yourdomainname.com
ServerName yourdomainname.com
ServerAlias www.yourdomainname.com
DocumentRoot /var/www/yourdomainname.com
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Replace yourdomainname.com with your domain name and adjust the document root to the folder path that will be used to store website data. The next step is to enable the virtual host configuration you have created.

Run the following command:

a2ensite yourdomainname.com

Disable the default configuration and check that the virtual host configuration is correct by using the command below:

sudo a2dissite 000-default.conf
sudo apache2ctl configtest

If it is correct, the 'syntax OK' message will appear. Now restart the Apache service.

service apache2 restart

Now you can test by accessing the domain name via your web browser.

Install and upload the SSL to your server.

First, you need to buy the SSL and choose a provider that suits you. In my case, I use Jagoan hosting service https://www.jagoanhosting.com/. You can find out how to configure it from the provider you bought the SSL from. For me, I use the following (You can change the website's language to English):

1. SSL Activation Tutorial via Member Area from Jagoan Hosting

2. How to Install SSL on Apache Ubuntu - Knowledge Base Jagoan Hosting Indonesia

To simplify it I will summarize it briefly as follows:

1. Generate the CSR.

2. Copy the private key to your storage and keep it.

3. Validate your SSL. There are some options to do this: By DNS name, by email, or by using HTTP/HTTPS.

4. Download your SSL certificate, it contains 3 CA files and 1 CRT file.

5. Make a CA bundle file by combining the 3 CA files you have downloaded.

6. Now you have 3 files: private key, CA bundle, and the domain certificate.

7. Enable SSL module in Apache: a2enmod ssl and then restart the Apache service apache2 service restart .

8. Create a folder to store your SSL mkdir -p /etc/ssl/private and set the role to it chmod 700 /etc/ssl/private.

9. Upload your SSL to the server by using FTP client, in my case I use WinSCP.

10. Edit your virtual host configuration by adding these lines:

    …
    SSLEngine on
    SSLCertificateFile /etc/ssl/private/certificate.crt
    SSLCertificateKeyFile /etc/ssl/private/private.key
    SSLCertificateChainFile /etc/ssl/private/ca-bundle.crt
    …
    

    Then restart apache with the command:

    apache2 service restart
    

    Now your Linux VPS should be ready. It's time to deploy your ASP .NET Core or Blazor Web Assembly 8.0 application!