DEV Community: Florent M

RxJS Deserves Better Than Its Constant Criticism – Lessons From a Real-World Production System

Florent M — Thu, 26 Jun 2025 06:25:00 +0000

As the Co-founder & CTO of Disign — a robust cloud-based digital signage platform deployed across platforms like Android digital signage players, Raspberry Pi, and many other devices — I want to share why we continue to rely heavily on RxJS, despite the growing trend to move away from it in modern Angular development.

I frequently see developers bashing RxJS as overly complex, outdated, or irrelevant since the arrival of Angular Signals and other reactive paradigms from frameworks like SolidJS or Svelte. But RxJS isn’t just about data binding or UI state, it solves fundamental problems that are critical in real-world, asynchronous, event-driven applications.

At Disign, I’m talking about one of our largest frontend projects, with more than 2,000+ components (although that number can be misleading in terms of scale). What really matters is that we have around 175 distinct business entities modeled on the frontend alone: each with their own logic, state, and reactive requirements. It’s a large and growing codebase, and the architectural decisions we make today affect long-term maintainability and performance. RxJS plays a central role in how we manage that complexity.

RxJS is more than a UI tool

RxJS gets a bad rep because people often evaluate it through the narrow lens of UI change detection or component reactivity. But its true power lies elsewhere: it’s a general-purpose abstraction over streams of values and events, not just DOM updates.

We use RxJS extensively at Disign to orchestrate logic in a player that:

Runs 24/7, with strict performance and memory constraints
Processes events from many asynchronous sources (touch input, WebSockets, scheduled timers, APIs, sensors)
Reacts in real time to clock-based programming and automation
Manages user interaction, scheduled content, and live data feeds, all at once
Supports third-party applications built using the Disign SDK for interactive signage, which brings additional reactive requirements through embedded apps and custom logic

Why RxJS works for us

RxJS allows us to write deeply flexible and composable business logic. We don’t want our core logic tied to Angular-specific constructs like Signals. Here's an example pattern we use regularly:

yourMethod(): Observable<any> {
  // Do whatever you want. No limits. Sync or async.
  /*
  return combineLatest([
    this.http.get(...),
    this.store.select(...),
    this.socketStream$,
    interval(1000),
  ]).pipe(
    filter(([httpData, storeData, socketData, time]) => ...),
    map(([...]) => this.transform(...)),
    retry({ count: 3 }),
    shareReplay(1)
  );
  */
}

This kind of stream represents business logic pipelines: they’re reactive, easy to test, and adaptable. If requirements change tomorrow (e.g., we need to debounce, delay, switch to polling, etc.), we can update the operator chain without restructuring our whole service.

Compare that with traditional async/await or Promises, they’re great for one-off flows, but don’t scale well when handling concurrent, dynamic, multi-source data.

Signals are cool, but not enough

Angular’s Signals are a welcome addition for template reactivity and fine-grained UI updates, especially in zoneless mode. They make markForCheck() obsolete and remove the need for takeUntilDestroyed() in components.

But Signals fall short when it comes to:

Managing external, asynchronous data flows
Coordinating logic across services and modules
Composing complex behaviors over time
Sharing logic outside the component layer

More importantly, they tie your code tightly to Angular. For us, that’s a risk we’re not willing to take. We want our core logic, scheduling, state handling, content orchestration, to be decoupled from any one UI framework.

Async logic is everywhere in Disign

Disign is a very different beast from a typical SPA. While most applications revolve around user interaction, we deal with:

Autonomous scheduling of content
External triggers from APIs and sensors
Live, always-on displays that can't afford memory leaks
Tactile interfaces with heavy user input and performance expectations

Here’s what a “simple” scenario might look like:

“At 9:00 AM, if the room is occupied and the temperature exceeds 24°C, switch to the cooling mode scenario, but only if the display has been idle for more than 5 minutes.”

This reads like a single sentence. But under the hood, it requires:

Scheduling logic
Sensor input streams
Display state tracking
Debouncing and timing conditions
A fallback mechanism if sensors fail
An override if a user manually takes control

RxJS handles this elegantly via composition. No imperative timers. No nested callbacks. No unreadable async trees. Just streams.

RxJS and "memory safety"

In a system that runs 24/7, memory leaks are unacceptable. RxJS gives us control over subscriptions, especially when combined with patterns like takeUntil, shareReplay, switchMap, or finalize.

Yes, this comes at the cost of complexity. You need to understand how the stream behaves, how it cleans up, and how operators interact. But that complexity buys us predictability and safety — two traits that matter more in production than "easy to learn."

The native observable spec is coming

Let’s not forget that observables are being standardized for the web platform (WICG Observable Proposal). Just like Promises and async/await became part of JavaScript, Observables may soon follow. When that happens, RxJS will evolve to wrap the native version, just as it did with Promises.

So we’re not betting on an obsolete technology — we’re building on a pattern that has stood the test of time across languages and platforms.

RxJS vs. async/await: A false dichotomy

Here’s the thing: we use both.

async/await for imperative, one-shot flows
RxJS for declarative, ongoing, multi-source logic

They aren’t mutually exclusive, but for complex systems, RxJS wins every time.

Final thoughts

RxJS isn’t perfect. Nothing is. But it’s one of the most powerful, flexible, and scalable tools in our stack at Disign.

If you’re building:

Applications with complex async requirements
Systems that run continuously
Logic that involves events, scheduling, and user input

Then you owe it to yourself, and your architecture, to take RxJS seriously.

Let’s stop dismissing RxJS because it’s hard. Let’s use it when it makes sense, and in many serious projects, it absolutely does.

And you, do you use RxJS?

I’m always curious to hear how others are using RxJS, or why they’ve decided not to. Do you rely on it in your projects? Have you switched to Signals, or moved away from reactive streams entirely?

What has worked for you?
What challenges did you face?
Are you using RxJS outside Angular: maybe in React, Node.js, or standalone services?

Let’s discuss in the comments 👇

I'm happy to answer questions or dive deeper into our implementation at Disign if it helps!

🧼 Data Hygiene: The Real Foundation of Angular Front-End Architecture

Florent M — Mon, 23 Jun 2025 06:25:17 +0000

Structure your data like a DBMS (e.g., PostgreSQL, MySQL...) to ensure the scalability of your Angular apps.

I'm the co-founder and CTO of Disign, a SaaS software for digital signage that transforms any screen into a powerful visual communication tool. Whether you're using cloud-based digital signage, deploying content on Android digital signage players (including Android TV), or leveraging Raspberry Pi digital signage through our custom embedded operating system DisignOS with OTA updates and system-level management, we support a wide range of devices and configurations.

We manage several complex applications built with Angular—including Disign Studio, our content creation and management interface, as well as embedded technologies powering our player apps across platforms.

Today, I want to talk about a more fundamental—and often overlooked—topic: data hygiene. In my opinion, it's the bedrock of a solid, maintainable, and scalable front-end project.
We manage several complex applications built with Angular, including Disign Studio, our content creation and management interface.

Let's start with the most important: Your Data

If there's one concept you should take away from this article, it's this one. An application can be performant, tested, well-coded... but if the data structure is flawed, everything else eventually crumbles.

Let's take Disign Studio as an example. Our content management and creation platform allows you to:

manage screens worldwide, across multiple sites and locations,
create beautiful content with full customization, whether no-code or low-code,
build interactive touch applications to go beyond passive signage,
integrate live data, enable real-time sync, and trigger automated content flows,
schedule complex rotations, set rules, or respond to specific events,
control players remotely: turn screens on/off, preview content in real time, track performance,
and support any type of hardware, our lightweight Disign OS runs on Raspberry Pi, Android and Android TV, and other digital signage players like Tizen or BrightSign.
and offer all the essential features for professional digital signage.

A few figures to set the scene:

2000+ Angular components (a large-scale app)
175 business entities on the front end (even more on the back end)

Here, entities refer to the "models" representing business objects — the equivalent of a SQL table — not Angular features, states, or components.

And the reason it all works? The data is well-structured from the start.

Design your data like a DBMS

Too often, I see developers ignoring the basics of relational modeling in the frontend. But thinking of your entities like SQL tables is an excellent way to guarantee clarity and scalability: Smart people have spent decades figuring out the best ways to structure data. They didn't wait for you, or for Angular, to propose solutions to these problems.

Basic principles to follow:

✅ Data uniqueness: no unnecessary duplication.
✅ Explicit relationships: 1-n, n-n, via IDs.
✅ No computed data: keep that for runtime or views.
✅ Flat design: avoid deeply nested JSON structures.
✅ Scalars only: store simple values (no JSON, no Date objects).
✅ If you must store a JSON: treat it as a "string" (JSON.stringify), like a basic DB would (deliberately ignoring JSONB or other optimizations).

Example typescript entities:

export interface Screen {
  id: string;
  name: string;
  campaignId: string; // 1-n relation
}

export interface Campaign {
  id: string;
  name: string;
}

Instead of nesting screens inside a Campaign, you create two normalized entities, indexed by ID-just like in a relational database.

What to avoid at all costs

Nested objects (campaigns in screens and vice versa)
Duplicate data
Partially represented entities (incomplete in some contexts)

This leads to technical debt, UI bugs, complex state, and maintenance headaches...

Don't store UI states (modals, scroll positions, etc.) in your business entities. You can of course create state entities for UI, but mentally separate them from business entities.

Why this rigor is essential?

Because everything else in your app stems from it:

State management becomes simpler
Data handling in components is intuitive
Maintenance and evolution are easier
Migrations can be done without breaking structure

And most importantly: if your data is clean, you almost never need ugly code or weird hacks in your components.

Data is the only source of truth. If it's wrong, your UI will be too.

REST API: Built for the app, not the public

Understand this crucial point: the REST API of your app is not public, nor generic. There's no point in creating a fully REST-compliant API with URLs like:

/screens/{screen_id}/campaigns/{campaign_id}

It's pointless. In most cases, a valid URL only needs one required parameter.
If your data is correct on the backend, that's enough to:

retrieve everything,
manage security (permissions, roles, etc.)...

Of course, there are many cases where more required parameters are needed, such as managing different contexts.

So, to sum up: design your API for your application.

If you need another API, say, a public one, build a separate API.

That doesn't mean duplicating code (hopefully all your business logic is easily reusable and independent of views).

It's built exclusively to serve our Angular application.

And so: it's optimized to be easily consumed by our state management, using the same data models as defined on the frontend.

Just a quick note on GraphQL: I really don’t think it’s well-suited for this kind of use case. It tends to overcomplicate things where a clean, app-specific REST API does the job far more effectively.

A well-designed REST API is... flat

Typical API response format at Disign (simplified):

{
  "pagination": {
    "total": 100,
    "page": 1,
    "limit": 25,
    "ids": []
  },
  "entities": {
    "campaigns": {
      "id1": { "id": "id1", "name": "Campaign 1" },
      "id2": { "id": "id2", "name": "Campaign 2" }
    },
    "screens": {
      "s1": { "id": "s1", "name": "Screen 1", "campaignId": "id1" },
      "s2": { "id": "s2", "name": "Screen 2", "campaignId": "id1" }
    }
  }
}

Why this format?

It mirrors exactly our ngrx/entity structure.
It populates the store without intermediate processing.
It adheres to all principles of data hygiene.

It's not about being “pretty.” This format avoids:

unnecessary selectors
cascading side effects
ambiguous updates

Of course, it can be adapted to fit your needs-but you get the idea.

The front-end == An in-memory database

What you need to understand is that state management data is nothing more than an in-RAM database. I'm talking here about business data and models, not UI state or others.

At Disign, we use NgRx with its entity module, which structures our entities like this:

export interface EntityState<T> {
  ids: string[];
  entities: { [id: string]: T };
}

And our API returns data in exactly this shape. The result:

No unnecessary mapping
Simple and effective selectors
Guaranteed scalability

The architecture becomes intuitive: changing an entity in the state = immediate, consistent UI updates.

State management: A necessary evil?

NgRx is often criticized: too verbose, hard to learn, not suited to every use case.
And that's true. If you have a simple app, you probably don't need it.

But at Disign, with 175 front-end entities, it's not even a question-we need it. Again, these designs weren't made to please people but to solve real problems. Nothing is perfect, but it gives us a logic to follow and makes teamwork easier.

At Disign, we use NgRx-we started with Angular 2 back in the day (2016?), there was no CLI, and NgRx was one of the first libraries available. We like it despite its flaws. We work around them with a custom layer we built for digital signage CMS Disign.

We developed:

meta-reducers: inter-entity communication
an automated migration system from reducer to createReducer
internal conventions to standardize all actions, effects, and selectors

It's a lot of effort. But it's also what allows us to:

maintain a healthy codebase
standardize our code
avoid long-term technical debt

And as always: the end user doesn't care. But it's vital for developers.

Are we just repeating the obvious?

Yes, maybe. But I assure you: in practice, many developers skip these fundamentals. The result: unnecessarily complex code, painful migrations, and slow feature delivery.

And that's not a matter of framework, Angular version, or RxJS magic. It's just data architecture.

Conclusion

We often underestimate the fundamental impact of data structure in a front-end application. Yet it's the starting point for everything else.

At Disign, if our applications are maintainable and scalable despite their complexity, it's largely thanks to this data discipline.

"Good data design means simple code. Bad data means complex code for no reason."

Never forget: your front end is just a RAM database. It's up to you to keep it clean.

And You?

Working on a large Angular app? Ever had to rebuild a data architecture after structural chaos? I'd love to hear your experiences.