Abstract

First it was cigarettes. Then seatbelts. Now, it’s push notifications, infinite scroll, and algorithmic feeds—tools designed to hijack attention faster than the law can catch up.

We've been here before. Big Tobacco sold addiction as freedom. Car makers dismissed seatbelts as overreach. Today, tech platforms follow a similar script: profit first, responsibility later. Meanwhile, our mental space is under siege.

This isn't about self-control. It's about cognitive sovereignty—the right to mental space free from engineered interference. Just as clean air and road safety became public responsibilities, so must our ability to focus, rest, and think clearly.

Notifications Are the New Cigarettes

Push alerts aren’t there to inform. They’re there to interrupt—to trigger, to bait, to pull you back in. Even the now-dated “150 phone checks per day” figure points to a deeper truth: compulsive attention loops are the norm, not the exception.

We regulate nicotine because it's addictive and harmful. Why do we allow the same logic to shape every app in a child’s pocket?

From Optimization to Oversight

There’s no “natural stopping point” in most digital platforms. Infinite scroll, autoplay, algorithmic curation—they all mimic slot machines. This isn’t just distraction. It’s entrapment.

We don’t just need better habits. We need better rules:

Scroll limits: Cap algorithmic feeds at 30 minutes per app, enforced at the OS level.

Notification quotas: Make attention-safe defaults the norm.

Mandatory quiet hours: Require overnight digital downtime, as France does in schools.

When GDPR launched, it was derided as bureaucratic. But it worked. It reduced data misuse and reshaped norms. We can—and must—do the same for attention.

Protecting the Next Generation

A 12-year-old’s brain shouldn’t be a testing ground for TikTok’s algorithm. Yet 89% of teens have unrestricted access to platforms optimised for compulsive use.

California has proposed limits on algorithmic feeds for under-13s. Finland has introduced screen-free school days. The UK already restricts phones in classrooms. Northern Ireland could easily follow—and lead.

We could go further: fund phone-free libraries, parks, youth centres. Make space for boredom, focus, conversation.

Critics say it’s overreach. But they said the same about seatbelts. Today, seatbelts save over 15,000 lives a year in the U.S., and around 2,000 in the UK. Regulation works.

The Firehose Must Be Throttled

We’ve normalised cognitive overwhelm. Whether or not multitasking “drops IQ” is debated—but the erosion of memory, focus, and clarity isn’t.

To reverse the tide, we need:

International standards for humane design, led by global forums like the UN Internet Governance Forum.

Transparency on tech lobbying, especially from firms working to block youth safety measures.

This isn’t a tech issue. It’s a civic one.

A Manifesto for Cognitive Sovereignty

This isn’t anti-tech. It’s pro-human. Just as Silent Spring catalysed environmental reform, we need a new framework—one that protects attention, empathy, and presence from being monetised out of existence.

The revolt won’t go viral. It will be quiet, slow, and gloriously unoptimised. It will look like boredom, stillness, and the freedom to think.

And like seatbelts, it may be inconvenient—but it could save lives, one quiet decision at a time.

Civilization thrives when law restrains exploitation. Our minds deserve no less.

Repo

https://github.com/shaydoc/minimal-api-dotnet

Directory Structure

.
├── /                      # Root directory
├── Program.cs             # Main entry point for the application
├── /ef                    # Dir for Entity Framework related files
│   └── UserContext.cs       # EF Core DB Context for User
├── /endpoint              # Dir for API endpoints
│   └── UserEndpoint.cs      # API endpoint for User
├── /Migrations            # Dir for database migration scripts
├── /poco                  # Dir for Plain Old CLR Objects (POCOs) or simple entities
│   ├── User.cs              # POCO class for User
│   └── UserValidator.cs     # Class for User validation
├── /repository            # Dir for repository classes
│   ├── IUserRepository.cs  # Interface for User repository
│   └── UserRepository.cs   # Class implementing User repository
├── /services              # Dir for service classes
│   ├── IUserService.cs     # Interface for User service
│   └── UserService.cs      # Class implementing User service
└── /wwwroot               # Root Dir for static files
    └── /content           # Dir for content files
        └── /data          # Dir for database files
            └── user.db    # SQLite database file for User

API Explorer

Setting Up Your Environment

Before we get started, you need to ensure that you have .NET Core installed on your machine. If you haven't done so, you can download and install it from the official site.

Once installed, you can download the repo here, and you can run the API from this directory by using the command:

dotnet watch run

Adding Dependencies

For this API service, we require several packages, which we'll use with .NET 7 to set up SQLite. We'll install these packages using the `dotnet add package` command:

 # SQLite
 $: dotnet add package Microsoft.Data.Sqlite

 # Entity Framework Adapter for SQLite
 $: dotnet add package Microsoft.EntityFrameworkCore.Sqlite

 # Entity Framework Core Design for Migrations
 $: dotnet add package Microsoft.EntityFrameworkCore.Design

 # FluentValidation for Elegant Model Validation
 $: dotnet add package FluentValidation.AspNetCore

 # OpenApi for API Decoration
 $: dotnet add package Microsoft.AspNetCore.OpenApi

 # Swashbuckle for API Documentation
 $: dotnet add package Swashbuckle.AspNetCore

Connecting to SQLite

Next, we need to define the SQLite connection string in our appsettings.Development.json and appsettings.json files. Add the following lines:

"ConnectionStrings": {
  "DefaultConnection": "Data Source=./wwwroot/content/data/user.db"
},

And then, create a wwwroot/content/data directory where the SQLite file will be housed.

For the minimal-api-dotnet.csproj, add an ItemGroup to ensure that the local SQLite copy does not overwrite the production version.

<ItemGroup>
   <Content Update="wwwroot\content\**\*" CopyToPublishDirectory="Never" />
</ItemGroup>

Note: If you're deploying via GitHub Actions using the `uses: actions/upload-artifact@v2` step, be aware that your SQLite DB will be reset.

Incorporating Entity Framework Core

In our /ef directory, we'll create a UserContext. This class drives the Entity Framework and contains a DbSet<User> for a User table with an `Id` and a `Name`. Later on, we'll run a migration script to add an `Email` column.

To connect the Entity Framework with our SQLite database, add the following to the Program.cs:

using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContext<UserContext>(options =>
options.UseSqlite(
     builder.Configuration.GetConnectionString("DefaultConnection")
     )
);

var app = builder.Build();

We also add the user service, user validator, and the DB context to the dependency injection container:

// DI the user service, user validator, and the DB context
builder.Services.AddScoped<IUserService, UserService>();
builder.Services.AddScoped<IValidator<User>, UserValidator>();
builder.Services.AddScoped<IUserRepository, UserRepository>();

User API Endpoints

Creating the user API endpoints is simple. In the /endpoint directory, we create a UserEndpoint static class to map all the HTTP methods of the User api. Then we delegate the incoming requests on to our Service Layer, which can be repurposed for other connectors. The Service Layer will apply validation checks using our Fluent Validation prior to delegating on to the repository, which will take responsibility for committing the data to the Database table.

Endpoint groups help manage API versioning, while the Fluent API allows easy chaining of features like CORS, authorization, and rate limiting:

Program.cs

app.MapGroup("/api/v1/users")
    .MapGroupOneUserApi()
    .WithTags("Public");


UserEndpoint.cs

static class UserEndpoint
{
  public static RouteGroupBuilder MapGroupOneUserApi(this RouteGroupBuilder group)
  {
    
    // Do call all data access APIs asynchronously.
    group.MapGet("/", async (IUserService service) => await service.GetUsersAsync())
    .WithName("List All Users v1")
    .WithOpenApi()
    .Produces<List<User>>(StatusCodes.Status200OK);

     ...
}

Database Migrations

Migrations are a crucial part of database versioning. For our example, we have already applied migrations to add an Email field and make it a required one on the Users table. Because we are using POCOs, we only need to add a property to our User.cs business object and the entity framework migration will pick it up

# To add email to the Users table:
$: dotnet ef migrations add AddUserEmail
$: dotnet ef migrations update

# To make email a required field:
$: dotnet ef migrations add UserEmailRequired
$: dotnet ef migrations update

Testing the API

To test the API, use the command dotnet watch run.

For viewing and interacting with the API specification, navigate to http://localhost:5080/swagger/index.html

And voilà, you've got your minimal Web API using Entity Framework and SQLite on ASP.NET Web API Core 7 up and running. Happy coding!

Resolving DNS is some business, there’s several things going on when you ask for that website in your browser address bar. The diagram below illustrates this behaviour. For an even better overview, check out the video here

1. Domain Name System (DNS):

The Domain Name System (DNS) is at the core of resolving domain requests. It is a distributed naming system that enables users to associate domain names with IP addresses. Whenever a user enters a domain name into a web browser, the DNS comes into action to locate the corresponding IP address.

2. Caching:

To optimize performance, DNS resolvers often employ caching mechanisms. When a user's device makes a domain request, the resolver first checks its cache to see if it has recently resolved the same domain name. If a match is found, the resolver can skip the time-consuming resolution process and provide the IP address directly.

3. Recursive DNS Resolution:

If the domain name is not found in the resolver's cache, it initiates the recursive DNS resolution process. The resolver communicates with authoritative DNS servers to resolve the domain request step by step.

4. Root DNS Servers:

The resolver begins by contacting the root DNS servers. These servers store information about the top-level domains (.com, .org, .net, etc.). The root servers respond by providing the IP address of the appropriate top-level domain (TLD) server.

5. TLD DNS Servers:

Once the resolver receives the IP address of the TLD server, it sends a query to the corresponding TLD DNS server. For example, if the domain is "example.com," the resolver contacts the .com TLD server. The TLD server then directs the resolver to the authoritative name server responsible for the requested domain.

6. Authoritative Name Servers:

At this stage, the resolver reaches the authoritative name server for the requested domain. These servers hold the most up-to-date information about the domain, including the IP address associated with it. The resolver sends a query to the authoritative name server, which responds with the requested IP address.

7. Returning the IP Address:

Once the resolver receives the IP address from the authoritative name server, it caches the information for future use and returns the IP address to the user's device. The user's device can now establish a connection with the web server hosting the requested domain, enabling the retrieval of the desired web content.

Resolving domain requests is a complex and vital process that underpins the functionality of the internet. The DNS system, with its distributed architecture, ensures that users can easily access websites by typing in human-readable domain names. We don’t typically delve this deep when making websites, but it sure is good to discover the process of how it all works….

Happy Web Developing!! 🚀

What is a Reverse Proxy?

A reverse proxy is a server that sits between client devices and a web server, forwarding client requests to the web server and returning the server’s responses back to the clients. It essentially acts as a gateway through which client requests are processed before reaching the web server.

While a forward proxy acts as an intermediary for client requests (think of it as the client's agent), a reverse proxy is essentially an agent for the server, protecting, controlling, and optimizing access to the server.

Common Reverse Proxies

There are several popular reverse proxies, such as:

• Nginx

• Apache HTTP Server with mod_proxy

• HAProxy

• Microsoft Azure Application Gateway

• AWS Elastic Load Balancing

• Traefik

Purpose and Advantages

1. Load Balancing

In large-scale enterprise applications, traffic can be immense. Reverse proxies distribute client requests across multiple servers, thus preventing any single server from getting overwhelmed. This leads to increased responsiveness and availability of applications.

2. Security and Anonymity

By masking the identity and internal structure of your backend servers, reverse proxies add an extra security layer. This is particularly important to prevent attacks such as DDoS which can be devastating to enterprise infrastructure.

3. SSL Termination

Handling SSL/TLS encryption and decryption (the process of encoding and decoding SSL/TLS certificates) can be resource-intensive for your backend servers. Reverse proxies can manage this process, known as SSL termination, freeing up resources on backend servers to efficiently handle application requests.

4. Caching and Content Compression

Reverse proxies can store static content and serve this to the client without forwarding the request to the backend server. This reduces the load on your servers and speeds up content delivery. Content compression can also be handled, which reduces the amount of data transferred over the network.

5. Application Firewall

Reverse proxies can act as an application firewall, protecting against SQL injection, Cross-site Scripting (XSS), and other web application vulnerabilities.

6. Global Server Load Balancing

For global enterprises, reverse proxies can route client requests to the closest or most responsive data center. This ensures lower latency and a better user experience.

Azure PaaS Example

Azure PaaS (Platform as a Service) offers a service called Azure Application Gateway which acts as a reverse proxy.

Suppose you have a large-scale web application with users from across the globe. You have deployed this application in several Azure regions to ensure low latency.

1. Create the Application Gateway: In the Azure portal, you can create an Application Gateway and specify the virtual networks your application is a part of.

2. Configure Backend Pools: Backend pools consist of the web servers that the Application Gateway will distribute traffic to. You can configure these pools with the IP addresses of your web servers across different regions.

3. Configure Routing Rules: Here, you can specify how the traffic should be distributed. For example, you can use a path-based rule that routes traffic to different pools based on the URL path.

4. SSL Termination: Import your SSL certificate into the Application Gateway. This offloads the SSL termination process from the web servers.

5. Enable Web Application Firewall: You can enable the WAF feature on the Application Gateway and choose from a set of predefined rules that protect against common web vulnerabilities or even create custom rules tailored for your application.

   6. Optimize Content Delivery: Configure caching within Application Gateway to cache static content. This will make the content readily available for serving, thus reducing the load on your backend servers.

   7. Monitor and Diagnose: Finally, integrate Application Gateway with Azure Monitor. This allows you to monitor the performance and health of your application and gateway, set up alerts, and troubleshoot issues.

   Wrapping Up

   Incorporating a reverse proxy is a fundamental step in scaling and securing enterprise applications, particularly when they are cloud-based. Through load balancing, enhanced security features, efficient SSL termination, content caching, and global server load balancing, reverse proxies such as Azure Application Gateway in Azure PaaS empower enterprises to build robust, fast, and secure applications. By shielding the internal servers from direct exposure to the internet, they add an essential layer of protection. The benefits they offer are especially critical for large-scale applications that require handling high volumes of traffic while providing an uninterrupted and optimized user experience.

In this post, we will delve into the capabilities of the Broadcast Channel API and put it to practical use by implementing a "log out from all tabs" functionality. So, without further ado, let's dive in!

What are Broadcast Channels?

Broadcast Channels support communication between browsing contexts (such as tabs, windows, or iframes) on the same origin (domain, protocol, and port). It's akin to a magical string attached between different parts of your application, enabling them to send messages to one another. see (Broadcast Channel API on MDN)

This API provides a simple and powerful way to communicate between different tabs without the need for complicated setups or server-side help.

Getting Started

To create a Broadcast Channel, you create a new BroadcastChannel object and give it a name. Any browsing context that creates a BroadcastChannel with the same name can communicate with each other!

const channel = new BroadcastChannel('my_channel');

Now let's send and receive messages:

// Sending a message
channel.postMessage('Hello across tabs!');

// Receiving a message
channel.onmessage = (event) => {
    console.log('Received: ', event.data);
};

Logging Out Across All Tabs - A Real-world Scenario

Imagine an application where a user is logged in across multiple tabs. When they log out from one tab, it's a best practice to log them out from all the tabs. Let's see how we can do this using the Broadcast Channel API.

Step 1: Setup the Broadcast Channel

When the user logs in, create a new Broadcast Channel. This can be done in your main JavaScript file or where your application initializes.

const logoutChannel = new BroadcastChannel('logout_channel');

Step 2: Listen for Logout Events

On each tab, listen for messages. If a message indicating that the user has logged out is received, perform the logout operation on this tab as well.

logoutChannel.onmessage = (event) => {
    if (event.data === 'logout') {
        // Perform the logout operation here
        console.log('Logging out from this tab as well...');
    }
};

Step 3: Broadcast the Logout Event

When the user initiates a logout in one tab, broadcast this event to all other tabs.

function userInitiatedLogout() {
    // Perform the logout operation for the current tab
    console.log('User logged out from this tab.');

    // Notify other tabs
    logoutChannel.postMessage('logout');
}

And that’s it! Whenever userInitiatedLogout() is called in any of the tabs, all other tabs will receive the message and log the user out.

Show me it working…..

Below is a small code example in VueJS, you can preview it here:

Logout of All Tabs Demo

<template>
  <div id="app">
    <div v-if="isLoggedIn">
      <h1>You are logged in</h1>
      <button @click="userInitiatedLogout">Log out</button>
    </div>
    <div v-else>
      <h1>You are logged out</h1>
    </div>
  </div>
</template>

<script setup>
import { shallowRef, onMounted, onBeforeUnmount } from 'vue'

// Create a reactive variable to store the login status
const isLoggedIn = shallowRef(true)

// Create a BroadcastChannel to communicate with other tabs
const logoutChannel = new BroadcastChannel('logout_channel')

// Create a function to log the user out
function userInitiatedLogout() {
  isLoggedIn.value = false
  logoutChannel.postMessage('logout')
}

onMounted(() => {
  // Listen for logout events from other tabs
  logoutChannel.onmessage = (event) => {
    if (event.data === 'logout') {
      isLoggedIn.value = false
    }
  }
})

onBeforeUnmount(() => {
  // Close the channel when the component is unmounted
  logoutChannel.close()
})
</script>

<style>
#app {
  text-align: center;
  margin-top: 60px;
}
</style>

Closing the Channel

Don't forget to close the channel when it's no longer needed, like when the user is logged out, to free up resources.

logoutChannel.close();

Conclusion

The Broadcast Channel API offers an elegant and simple way to communicate between browsing contexts on the same origin. As we have seen, it can be incredibly useful for synchronizing actions like logging out from all tabs. With just a few lines of code, you can make your web applications more responsive and user-friendly.

Happy coding! 🚀