DEV Community: Anoush

User Connectivity: Making the System Scale with Event Hub Partitions, ACA, and KEDA

Anoush — Thu, 06 Aug 2026 15:57:15 +0000

Part 3 of the User Connectivity Architecture series.

Introduction

The first post in this series described the pattern: a heartbeat on a timer, an Event Hub, a worker writing sessions into Redis, and Redis key expiration driving facility online/offline status.

One detail matters later. The heartbeat interval is not hard-coded in the client. The API tells the client when to call next, and the default is 30 seconds.

The second post covered two years of running that in production.

This post is about the month it stopped working.

In January 2026 our heartbeat traffic went from boring to terrifying and stayed there for about four weeks. This is the story of what broke, why the original design had a ceiling we never noticed, and the changes that fixed it: more Event Hub partitions, Azure Container Apps, and KEDA.

The Storm

A normal day looked like this:

51,000-58,000 heartbeats per hour, hour after hour
Roughly 15-16 events per second at idle
Flat, predictable, forgettable

On January 5, around 7:00 AM PST, it stopped being flat.

Time (PST)	Heartbeats/hour
Baseline	~57,000
12:00 PM	80,005
1:00 PM	216,351
5:00 PM	343,480
9:00 PM	466,760

That is eight times normal event volume in a single hour, and it was still climbing.

Events were only half the story. SignalR connection counts told the other half. At the worst of it we were holding roughly eleven times the connections we normally maintain, and every one of those was a browser session we had to track, keep alive, and report status for.

It did not spike and recover. It stayed elevated for weeks while we hunted for the cause.

When we finally found it, the answer was almost funny: 507 zombie sessions that never ended, running months-old cached client code, and a single user account responsible for 33% of all our token API traffic.

One account. Eight times the load. Four weeks.

What Eight Times Load Actually Did

Here is the part that matters, and it has nothing to do with the number itself.

Our Event Hub had one partition.

In Event Hubs, the partition count sets how much you can read in parallel. Within a consumer group, each partition is owned by one processor at a time.

One partition means one owner. Everything else waits its turn. More instances, more CPU, better code, none of it helps. There is only one lane.

So while events poured in at well over a hundred per second, HeartbeatMonitor processed them single-file. A handful per second. Sometimes it felt like one.

Incoming and outgoing stopped matching, and the backlog only grew. Facility connectivity status, the thing hospitals and EMS actually look at, started lagging reality.

Then the Consumption plan added its own failure mode: SNAT port exhaustion.

Under sustained storm traffic, outbound connections tied up SNAT ports faster than they were released. We ran out. New connections slowed, then failed outright. Failed calls made clients retry. Retries made more load. More load exhausted more ports.

We had built a feedback loop, and it was feeding itself.

Consumption gave us nothing to work with either. No instance visibility, no per-instance control, no way to reason about what any single worker was doing. And since scale-out was capped by the partition count anyway, more instances would not have helped even if we could see them.

The pattern was fine. The plumbing under it had a ceiling of one.

Buying Time

Before rewriting anything, we needed to survive.

That heartbeat interval from the intro is a variable, and the API hands it to every client on every call. It normally sits at 30 seconds. We set it to 90 seconds, which cut incoming events by roughly two thirds. No deploy, no client update.

It worked. It was also a tourniquet. Connectivity status got noticeably coarser, but it kept the lights on while we built the real fix.

Worth stealing regardless of your architecture: let the server tell the client how often to call. That one design decision was the difference between a bad month and an outage.

Fix 1 - Give the Queue More Lanes

On our Event Hub tier we could not change the partition count on the existing hub, so we created a new one: heartbeat-p8, with 8 partitions and a dedicated heartbeat-monitor consumer group.

That is the whole fix, and it is the foundation for everything after it. Eight partitions means eight streams can be processed in parallel instead of forcing all the work through one. A noisy workload has far less ability to stall the entire pipeline.

Eight lanes only help if you have eight drivers, though. That is the next part.

Fix 2 - Why KEDA

KEDA watches how many unprocessed events are sitting in the Event Hub and scales the worker for you. No timers, no guessing, no manual scale-out.

Here is the behavior that sold us. As lag grows, KEDA adds replicas. The Event Hub processor then spreads partition ownership across whatever replicas are running, each one checkpointing independently. Events fan out across partitions, replicas fan out to match.

Set maxReplicas to the partition count. This is the one number worth getting right.

There are only eight partitions to own, so a ninth replica has nothing to take. At best it sits idle. At worst it adds avoidable rebalancing, which means brief churn and duplicate processing from the last checkpoint. Extra replicas do not buy throughput.

All of it lives in Bicep, so every environment gets the same behavior with different numbers:

scale: {
  minReplicas: minReplicas
  maxReplicas: maxReplicas
  rules: [
    {
      name: 'eventhub-keda-rule'
      custom: {
        type: 'azure-eventhub'
        metadata: {
          consumerGroup: toLower(eventHubConsumerGroup)
          unprocessedEventThreshold: kedaUnprocessedEventThreshold
          activationUnprocessedEventThreshold: '0'
          checkpointStrategy: 'blobMetadata'
          blobContainer: 'heartbeat-checkpoints'
        }
        auth: [
          {
            secretRef: 'eventhub-connection'
            triggerParameter: 'connection'
          }
          {
            secretRef: 'storage-connection'
            triggerParameter: 'storageConnection'
          }
        ]
      }
    }
  ]
}

Two things in there cost us real time, so take them for free:

checkpointStrategy: 'blobMetadata' - get this wrong and KEDA reads your lag as zero and never scales
If an old Function App is still running against the same hub and consumer group, it keeps competing for partition ownership and the Container App never settles. Stop it first.

Non-production environments run 2 partitions with minReplicas: 0, so they scale to zero and cost nothing when nobody is testing.

Fix 3 - Make the Image Small Enough to Matter

Fast scale-out is a lie if your container takes 45 seconds to start.

So the HeartbeatMonitor image got stripped down:

No ingress. It is a worker. Nothing calls it. It has no reason to have a networking surface.
No health check libraries. ACA probes handle liveness.
No extra packages. If it is not on the hot path between Event Hub and Redis, it is not in the image.

The result is a small image sitting in ACR, ready to go. During a storm, the time between "KEDA notices lag" and "a new instance is processing events" is measured in seconds, not minutes. That difference is the entire point.

There is a quieter benefit too. Moving off Consumption to a container we control means we can actually see and tune each instance: logs, probes, resource limits, startup behavior. After a month of flying blind, that visibility was worth as much as the scaling.

SessionMonitor - A Different Job, Different Rules

Not everything should scale out.

SessionMonitor reconciles Redis session state against SQL and pushes facility status changes. Running two of them means doing the same work twice. So it moved to ACA as well, but fixed at exactly one instance.

What it got instead:

A speed knob in Redis. The poll interval is read from Redis at runtime, not from config. Speed it up, slow it down, or effectively pause it, mid-incident, with no redeploy.

redis-cli SET SessionMonitor:PollIntervalSeconds 15

Catch-up on startup. Every session lives in Redis as two keys: a short-lived one that expires when the user goes quiet, and a long-lived one that sticks around as the record.

The short key expiring is the signal that someone went offline. But Redis expiration events are fire-and-forget. If the container is down at that moment, the signal is gone and that session stays marked online forever. In the old Function App, that is exactly what happened.

So SessionMonitor now starts by comparing the two sets of keys. Anything holding a long-lived key with no short-lived partner expired while we were away. It clears those first, then starts listening for live events.

Simple idea, and it means a restart or a deploy no longer costs us accuracy.

Proving It

Honest answer first: we could never reproduce the real storm in a load test. Not even close. Four weeks of a broken client hammering production is not something you manufacture with JMeter on a Tuesday.

So we stopped trying to recreate the storm and tested the thing that actually mattered, which is the response.

The method was simple:

Stop the Container App entirely
Run the JMeter load test for several minutes against the heartbeat API
Let the queue pile up to tens of thousands of unprocessed events
Start the Container App and watch

Production normally keeps one replica running at all times. We stopped it on purpose so the test would show the worst case: a cold start into a full queue.

KEDA drove it up to all eight replicas almost immediately. All eight partitions were consumed in parallel, the backlog drained, and once the queue was clear it scaled back down on its own.

That is the behavior we needed to see. Not "can we survive a storm we already survived," but "when the backlog appears, does the system react instantly and without anyone being awake."

Where We Landed

Production reads and writes to the queue stay in sync, including under heavy load
The heartbeat interval is back to normal, no tourniquet needed
No SNAT port exhaustion since the migration
Processing capacity scales with demand instead of collapsing under it
Every environment is defined in Bicep, so dev, QA, staging, training, and prod behave identically at different sizes

The architecture from the first post, heartbeat to Event Hub to Redis expiration to SignalR, was never the problem. It held up for two years and it holds up today.

It just needed more than one lane, and something smart enough to fill them.

Previous posts in this series:

Scaling API Access with Azure API Management: From Manual to Self-Service

Anoush — Sun, 04 Jan 2026 22:03:40 +0000

Introduction

Working on a healthcare application using .NET and Azure. The backend is .NET Core with SQL Server and Azure Functions on Azure Cloud. This application is a B2B product, where we need to expose our APIs to external clients and users who integrate with our services.

We came out first with a traditional approach where each client would get custom API endpoints and we generate a GUID id (API key) for each client/user. We store the ids in our database and based on API key we authorize and authenticate the clients. But as we scaled up hundreds/thousands of facilities and users, this became unmanageable. Also, it is not secure to have the main API endpoint accessible to public. We needed a better way.

This article describes how I architected our API access to be scalable, self-service and more secure. Basically, going from a manually configured API setup to an automated multi-tenant API gateway that serves thousands of users with zero manual configuration.

The Problem

Our application needed to serve hundreds or thousands of external users across multiple facilities. Each facility needed access to our APIs to exchange data. But here's the challenge: each client has access to different APIs and needed different parameters to push and pull their data.

For example:

Facility A needs facilityId=5001&locationId=1001
Facility B needs facilityId=5002&locationId=1002
Facility C needs facilityId=5003&locationId=1003$specificParams=Ture

The traditional approach would be to create separate API id called API Key in the database and endpoints would access their data based on their API Key. Or worse, require each facility to pass their own parameters and trust they're sending the right ones. Neither scales. The first creates endpoint sprawl. The second creates security issues.

We needed our users to sign up, set up their settings (set their facility, location and other parameters in UI) and choose their API endpoint that could serve everyone securely, with each user automatically getting their correct parameters without manual configuration.

Architecture and Setup

We built our solution using three Azure services: Azure API Management (APIM), Azure Functions, and Azure Table Storage.
APIM acts as our API gateway. It's the single entry point for all external users. Functions handle our business logic and subscription management. I used APIM to set up API policies. Table Storage holds each subscription's custom parameters.

Here's how I set it up. In APIM, I created one API endpoint. This single endpoint serves all facilities. When a user calls this endpoint with their subscription key, APIM does all the heavy lifting automatically through a policy.

I have a separate function that is fully dedicated to managing APIM subscriptions. I created two main APIs: one to manage subscription creation (POST /api/subscription/create) and one to retrieve subscription parameters (GET /api/subscription/{id}). The first one is called when users sign up. The second one is called by APIM's policy to get that user's parameters.

In Table Storage, we store a simple table called ApiSubscriptions with three columns: SubscriptionId (the primary key), SubscriptionKey, and Parameters. When a user signs up, I store their parameters here as a query string like facilityId=5001&locationId=1001.

The Flow

When a user calls our API, here's what happens automatically:
The facility sends a GET request to https://api.example.com/data/ids with their subscription key in the header: Ocp-Apim-Subscription-Key: abc123...
APIM receives the request and validates the subscription key. If it's invalid, the request is rejected immediately.

Once validated, APIM executes our policy. The policy does three things in sequence:

First, it calls Azure AD to get an OAuth token. This token is needed to call our backend Function App securely. APIM makes a POST request to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token with client credentials. Azure AD returns a bearer token.

Second, APIM calls our Function App to get this subscription's parameters. It makes a GET request to /api/subscription/{subscriptionId} with the bearer token in the Authorization header. The Function App looks up the subscription in Table Storage and returns the parameters: facilityId=5001&locationId=1001.

Third, APIM appends these parameters to the main backend API call. It rewrites the URL from /data/ids to /data/ids?code={functionCode}&facilityId=5001&locationId=1001 and forwards the request to the Function App with the OAuth token.

The Function App processes the request with parameters and returns the facility's requested data. APIM forwards this response back to the user.
All of this happens in milliseconds. The facility doesn't know any of this is happening. They just send their subscription key (in the header of the call) and get their data back.

The diagram shows the complete flow from API Client through APIM to backend services with OAuth authentication and dynamic parameter injection.

The APIM Policy
The entire flow is controlled by an APIM policy. This is an XML-based configuration that runs for every API request. Here's what our policy looks like, broken down into the three main steps:
Step 1: Get OAuth Token

<send-request mode="new" response-variable-name="tokenResponse" timeout="10">
    <set-url>https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token</set-url>
    <set-method>POST</set-method>
    <set-header name="Content-Type">
        <value>application/x-www-form-urlencoded</value>
    </set-header>
    <set-body>grant_type=client_credentials&client_id={id}&client_secret={secret}&scope={id}/.default</set-body>
</send-request>

This calls Azure AD and gets back an access token. We store it in a variable called tokenResponse.

Step 2: Get Subscription Parameters

<send-request mode="new" response-variable-name="subscriptionResponse" timeout="10">
    <set-url>@($"https://{function-app}/api/subscription/{context.Subscription.Id}?code={code}")</set-url>
    <set-method>GET</set-method>
    <set-header name="Authorization">
        <value>@("Bearer " + accessToken)</value>
    </set-header>
</send-request>

This calls our Function App to get the parameters. Notice we're using context.Subscription.Id which is the unique subscription identifier in APIM. We send the OAuth token in the Authorization header.

Step 3: Call Backend with Parameters

<set-header name="Authorization">
    <value>@("Bearer " + accessToken)</value>
</set-header>

<rewrite-uri template="@{
    string parameters = context.Variables["parameters"];
    return $"/api/data?code={code}&{parameters}";
}" />

This appends the parameters to the backend call and sets the OAuth token in the Authorization header. The backend API receives the request with both authentication and the facility's specific parameters.

That's the entire policy. Three steps that run automatically for every request.

I also have other types of APIM Policies. For example, one that I use often is the rate-limit policy. That protects our APIs when there are a lot of calls during a short amount of time. This built-in policy will give "Too Many Requests" (HTTP 429) when that occurs.

Subscription Management

We built a Function App to handle subscription lifecycle. It has two main APIs:

Create Subscription (POST /api/subscription/create)

This function does four things:

Creates the user in APIM (if they don't exist)
Creates the subscription in APIM for the selected product
Stores the subscription parameters in Table Storage
Returns the subscription key and ID to the user

Here's the data flow: user submits their email, name, product selection, and facility selection through our signup portal. The Function App creates an APIM user using their email as the identifier. Then it creates a subscription for that user to our API product. Then it stores the subscription ID and parameters (facilityId=X&locationId=Y) in Table Storage. Finally, it returns the subscription key to the user.

*Get Subscription *(GET /api/subscription/{id})

This function is called by the APIM policy. It takes a subscription ID, looks it up in Table Storage, and returns the parameters. Simple lookup operation.

Both functions use OAuth authentication. Only APIM can call them because APIM uses Managed Identity to get a token from Azure AD.

One important configuration: the Function App's Managed Identity must authenticate to the correct Azure AD tenant. I explicitly set the tenant ID in the DefaultAzureCredential to ensure it gets tokens from the right Azure AD instance. Without this, authentication fails with a tenant mismatch error.

Developer Portal

I built two signup portals: one integrated into the APIM Developer Portal and one standalone static website hosted on Azure Storage.

In the APIM Developer Portal, I created a custom page called "Create Subscription". Users can access this page, fill out a form with their email, name, product selection, facility selection, other settings and click "Create Subscription". The form calls our Function App's create endpoint, and the user immediately gets their subscription key displayed on screen.

The standalone portal is a simple HTML page with JavaScript. It does the same thing but can be shared with external users who don't need to log into the APIM portal. We use this for quick onboarding by email invitations.

Both portals load the facility list dynamically from another Function App endpoint (GET /api/facilities) which queries our database for active facilities. It also lets users choose their APIM Product or API Group.
For the portals to call the Function App from the browser, I configured CORS in the APIM policy. I set allowed-origins to wildcard (*) for the POC. For production, this should be locked down to specific portal URLs only.

When the user submits the form, JavaScript calls POST /api/subscription/create with the payload example:

{
  "email": "user@example.com",
  "name": "John Doe",
  "product": "example-apis",
  "facilityId": "5001",
  "locationId": "1001"
}

The Function App does all the work and returns:

{
  "subscriptionKey": "abc123...",
  "subscriptionId": "user-example-com-xyz789"
}

The portal displays this to the user with instructions on how to use it.

Conclusion

This architecture solved our multi-tenant API access problem, without admin involvement and separates authentication and authorization using APIM. Each user gets their correct parameters automatically without manual configuration.

The key components:

APIM handles routing and policy execution
Azure Functions manage subscriptions and business logic
Table Storage holds subscription parameters
OAuth secures all communications
APIM Policy ties it all together with three simple steps

If you're building B2B APIs that need to serve multiple tenants with different parameters, this pattern works. It's scalable, secure, and self-service.

The full code and APIM policy are available in production. The system runs itself.

User Connectivity: Two Years in Production — Lessons Learned and New Patterns

Anoush — Wed, 24 Dec 2025 06:23:54 +0000

Introduction

This is a follow-up to my previous post on User Connectivity: A Real-time Web Solution for Online and Offline User Status. It has been almost two years since I first deployed my user connectivity solution to production. What started as an experiment has become a cornerstone of my architecture.
Could I make it simpler? Yes. However, the time and effort for an upgrade is not worth it given other priorities. The system has been rock solid, and I have expanded its use to solve other challenges in my application.

Expanding the Pattern: Solving Database Deadlocks

Recently, I encountered complex database deadlock issues caused by several API processes. After analyzing the problem, I recognized an opportunity to apply my event-driven architecture. By separating out specific tasks and processing them asynchronously, I eliminated the deadlocks entirely.
This led me to create a centralized service I call the Event Distributor. An Azure Function App responsible solely for listening to Redis expiration events and forwarding them to an Azure Event Grid queue. Multiple Azure Function App workers then process events from this queue.

Event Distributor Architecture

The goal of the Event Distributor is simple: one central service that listens to Redis expiration events and nothing else.

This separation provides several benefits:

Traceability: All events pass through a single point, making it easier to trace issues.
Logging: Every received event is logged to an Azure Cosmos DB with its status.
Scalability: Worker functions can scale independently based on queue depth.
Reliability: A single, well-monitored listener reduces the risk of missed events.

Key Observations: Azure Services

After two years of running this architecture, I have two critical observations for anyone implementing a similar solution with Azure services.

1. Use Premium Plan for Redis Listeners
If your Azure Function App uses the RedisPubSubTrigger to listen for Redis expiration events, you must use the Premium plan. The Consumption plan is not reliable for this use case.

Why? The Consumption plan has cold start delays and limited connection lifetimes. When the function app is idle, it can go to sleep and miss events from Redis. With the Premium plan, your function app is always on with long-lived connections — no cold starts, no missed events. I have not seen a single lost event since moving to Premium.

You may ask: how did the original user connectivity solution work on the Consumption plan?
The answer is traffic volume. Even in idle mode, my application generates 170–200 heartbeat events per second. During peak usage, this increases 6–10 times. The function app never goes to sleep because of this constant traffic. Additionally, my Heartbeat function app includes both the RedisPubSubTrigger and HTTP triggers, keeping it active.
For a dedicated Event Distributor that only listens to Redis expiration events, the Premium plan is essential.

2. Azure Managed Redis Limitation
Azure has introduced a new Redis service called Azure Managed Redis (formerly Redis Enterprise). This service runs on a clustered architecture with multiple Redis servers under the hood.

However, there is a significant limitation: these servers cannot be fully configured to send expiration events reliably. When the underlying servers restart or cycle, they lose their configuration and stop sending expiration events.

I have reported this issue to Microsoft. They confirmed it is on their backlog, but as of today, there is no solution. If your architecture depends on Redis key expiration events, be aware of this limitation before migrating to Azure Managed Redis.

Conclusion

My event-driven architecture has proven itself over two years of production use. It solved my original user connectivity requirements and has since helped me address complex database deadlock issues. The key takeaways:

Use the Premium plan for Redis listeners
Be cautious with Azure Managed Redis if you rely on expiration events

I hope this helps others take advantage of this architecture.

User Connectivity: A Real-time Web Solution for Online and Offline User Status

Anoush — Tue, 06 Feb 2024 06:46:08 +0000

Introduction:
This post explores user connectivity in a web application, focusing on displaying the real-time connectivity status of facilities. We'll discuss how users are associated with facilities, walk through our setup, communication methods with connected sessions, and our approach to ensuring a stable and reliable solution.

Connectivity Status:
In our context, connectivity status refers to whether a facility is online or offline. This status indicates whether one or multiple users associated with a facility are actively logged into our application.

Application Setup and Details:
Our application operates in real-time, using sessions associated with users. Users are linked to specific facilities, and each facility is associated with a distinct region or county.
The core of our real-time functionality involves notifying all relevant sessions/users about the facility's connectivity status in real-time, delivered to the user's browser using SignalR (Web Sockets protocol) event messages.
We host our application on Microsoft Azure Cloud, utilizing the following technology stack and

Azure Cloud Services:
Technology Stack:
Front-end: JavaScript/Angular
Back-end: .Net Core
Database: Azure SQL Server

Azure Services:
SignalR
Azure Event Hub
Redis Cache
Azure Functions

Solution:
Now, let's dive into the specifics of our solution.
To establish real-time user connectivity, our front-end application regularly sends heartbeat signals through simple Post API calls every 30 seconds. The heartbeat events are stored in an Azure Event Hub Queue, which can handle millions of events per second.

Heartbeat Event Process:
We utilize a worker service called the Heartbeat Monitor (implemented as Azure Functions) to read and store heartbeat events in Redis Cache. The events are stored in two lists: a Redis expiring list called Session list and another list called Session Value list, containing heartbeat event values.
Each time a heartbeat event is read, it is fetched from the Session list. If it does not exist, the session element is transactionally created in both lists to ensure synchronization. If the session already exists, the Session End Time is set to the expiration time in the Session Value list.

Expired Session Callback:
To manage session expiration, we listen to Redis expired keys and execute a function that processes the session and sets it to offline with a timestamp. This is done by configuring Redis to send events and listening to a specific event: __keyevent@0:expired.

However, Microsoft has introduced a new Azure Function Trigger, "RedisPubSubTrigger", which captures the expiration (__keyevent@0:expired) of a session more efficiently.

When a session expires, this listner function sets the session's offline timestamp in the session value list, which is set to null while session in online.

By listening to Redis expired keys, we execute function that process the session and set the session to be offline with timestamp. This was originally done by configuring the Redis to send events and listening to specific event "__keyevent@0:expired". However, Microsoft has new Azure Function Trigger "RedisPubSubTrigger" that capture the expire session. The session offline timestamp been set in the session value list, there after.

Session Monitor:
Another timer-based Azure Functions worker service runs every minute, processing each session in the Session Value list, associating sessions with facilities. After processing all sessions, the Session Monitor updates facility connectivity status, stores data in its private database, and removes offline sessions from the Session Value list.

Process Facility Session:
Moving from the Session Monitor's role, let's explore the 'Process Facility Session' step. Here, we update facility connectivity status and perform tasks for seamless user connectivity. The Session Monitor submits events to proper users or regions/counties, updates facility data in its database, and updates the facility status in the core database.

Conclusion:
The facility session process is highly efficient, processing only the updated facilities whose connectivity status has changed. It summarizes all sessions to the facility, avoiding the need to send events per session and reducing processing per browser connection.
Using Redis expiration keys is reliable and stable, streamlining functionality and code by eliminating the need to individually process each session in the list to determine its online or offline status.

Update (December 2024):
This architecture has been running successfully in production for over two years. I have published a follow-up article covering lessons learned, a new Event Distributor pattern, and important Azure service considerations: User Connectivity: Two Years in Production — Lessons Learned and New Patterns

Going Desktop to Mobile view by configuring the Angular router

Anoush — Tue, 09 Jul 2019 03:22:01 +0000

Working on an emergency application (with live data) using .net and angular. The backend is .net with SQL server and SignalR on Azure. This application is sales driven product, we came out first with desktop version and then mobile friendly version due to way the market and 90-80% of users are on desktop view.

This article describes how we architect our application do be responsive. Basically, going from an already existing desktop web application to responsive application. When referring to word “mobile” in article, it is not a mobile native application or Progressive Web App, it is referring to responsive application on different tables and mobile devices.

Architecture and Setup

We started by in our angular application under root folder “src”. We created a folder called “mobile”. We have the “app” folder for main desktop view, it can be renamed to “desktop”. This gave us a whole new place to have our mobile code and not been in the same folders with all other code, it is more organized, clean and separated from all other code.

In app router module “AppRoutingModule”, when application get loaded. We load an array of all paths of the application, from “app” and “mobile” folders. When application knows the size of window “window.innerWidth” it will modify the path array and rests the route configuration by calling "this.route.resetConfig()". Here we also listen to “window:resize” in the main component of the application for window resizing, and the router path gets modified and then router configuration gets reloaded. So, user can go from desktop to mobile view and vice and versa.

const desktopPreloadModules = [
  {
    path: 'dashboard', loadChildren: () =>
      import('app/modules/dashboard/dashboard.module')
        .then(mod => mod.DashboardModule)
  },
  {
    path: 'debug', loadChildren: () =>
      import('app/modules/debug/debug.module')
        .then(mod => mod.DebugModule)
  }
];

const mobilePreloadModules = [
  {
    path: 'dashboard', loadChildren: () =>
      import('mobile/modules/dashboard/dashboard.mobile.module')
        .then(mod => mod.DashboardMobileModule)
  },
  {
    path: 'debug', loadChildren: () =>
      import('mobile/modules/debug/debug.mobile.module')
        .then(mod => mod.DebugMobileModule)
  }
];

const appRoutes: Routes = [
  { path: 'login', component: LoginComponent },
  {
    path: 'main',
    component: MainComponent,
    canActivate: [AuthGuard],
    resolve: [AppDataResolver],
    children: [...desktopPreloadModules, ...mobilePreloadModules]
  },
  { path: '', redirectTo: '/main', pathMatch: 'full' },
  { path: '**', component: LoginComponent }
];

@NgModule({
  imports: [RouterModule.forRoot(appRoutes, { preloadingStrategy: SelectiveStrategy, enableTracing: false, scrollPositionRestoration: 'enabled' })],
  providers: [SelectiveStrategy],
  exports: [RouterModule]
})
export class AppRoutingModule {
  constructor(…) { … }
}

There is also CSS files that styling changes depending on the window size, we used media query for that, by calling:

@media only screen and (max-width: ####px)

In our application we also have some dynamic dialog boxes, we also override those components by reloading them either mobile view or desktop view.

After route is change the all components (that is in the current view) needs to be reloaded. Here, we solve this by simply navigating to and empty path this basically reloads all current component in the DOM (it is not refresh from server.)

Mobile Implementation

In the mobile for with similar path tree as desktop “app” folder, by using OOP inheritance, polymorphism and overriding methods. We could access all of the functionalities from desktop services and components and reused the code, by extending from same components. Following the open/closed principle. For example:

@Component({
  selector: 'my-mobile-component',
  templateUrl: './my.mobile.component.html'
})
export class MyMobileComponent extends MyDesktopComponent { }

In case mobile functionality is different than desktop, we override the desktop method in the mobile folder.

In our application which is medium to advanced application complexity. There is only one place that it is checking if application is mobile or desktop and that is in the “AppRoutingModule” there no “if (mobile) do this else do that” outside the router. We follow and stick with this pattern due to the fact that the application could be very messy. If we have a mobile specific component or function with extending the class from desktop and override or add mobile specific functions or view. Following the single responsibility principle.

Pros

Clean and organized code.
Easy to implement the mobile view application.
Reuse of the code, this saves us lots of time to impalement and test. The desktop code is already in production and been used by users, we know if works. So, we are confident that code works.
Follows the single responsibility principle
Follows the open/closed principle

Cons

If we want to override a desktop behavior or functionality we will need to extend it in mobile. This can give a little complexity to some deeper functionalities. However, doable by refactoring and using SOLID principles.
Can easily get a messy code if we breaking the pattern if someone writes “if (mobile) do this else do that” way or some other way.