DEV Community: Maria-Lurdes Dehtiarenko

What Falling Off a Horse Taught Me About Frontend Architecture

Maria-Lurdes Dehtiarenko — Mon, 16 Mar 2026 14:56:17 +0000

I once fell off a horse during a fast run. My horse got scared and started running at full speed. For a moment I managed to calm him down. Then the rush started again. In one sharp turn I lost balance and fell. That moment taught me something uncomfortable: You can’t force stability in an unstable system.

I’ve seen the same pattern in frontend development.

Working as a frontend engineer at Sombra, I’ve worked on projects where we tried to control complexity by adding more structure - more layers, more state management, more abstraction.

Sometimes it helped. Sometimes it made the system harder to handle.

Lesson 1: Balance Over Force

In horse riding, too much pressure creates resistance. Too little control creates chaos.

Frontend architecture behaves the same.

Overengineering - adding unnecessary layers, heavy global state, or complex abstractions - creates resistance in development.

Angular example:

Introducing a full global state management solution like NgRx for a simple feature module can easily become overengineering. Instead of simplifying the architecture, it adds actions, reducers, selectors, and effects - even when the data is used by only a few components. Suddenly, a small form with 3 fields required 20+ boilerplate files and extra mental overhead.

At the same time, having no structure - like letting multiple components directly call HTTP services or manage shared data without coordination - leads to messy data flow and unpredictable behavior.

Takeaway:

Introduce tools like state management or architectural layers only when complexity truly requires them, not because they feel "enterprise-ready"

Practical tip: If your module has <5 components and minimal shared state, consider local component state or a feature-scoped service instead of NgRx.

Lesson 2: Subtle Control Beats Micromanagement

A rider doesn’t need constant force. Small adjustments are enough.

The same applies to frontend systems.

Instead of micromanaging everything through a heavy global store, prefer:

Clean and simple APIs
Clear data flow
Minimal abstraction
Feature-scoped state when possible

Too many layers create friction and increase cognitive load — the mental effort developers need to understand how the system works.

Angular example:

Instead of putting every API call through a global store, you can keep state in a feature service.

For instance, a UserProfileService that holds only the profile state for that module, exposing getProfile() and updateProfile() methods, keeps things predictable without unnecessary boilerplate.

Takeaway: Balance between centralization and local control reduces overhead and makes debugging easier.

Lesson 3: Reacting to Unpredictability

Horses react to sudden changes - noise, movement, fear.

Frontend applications react to:

Async behavior
Race conditions
API failures
User-triggered events

When something breaks, the goal is not panic fixes but observation.

Good engineers look for patterns:

What changed? What triggered the issue? Is it reproducible?

Stability comes from understanding behavior - not patching symptoms blindly.

Lesson 4: Reading Signals

Experienced riders read subtle signals - body tension, weight shifts, breathing changes.

In frontend development, signals are everywhere:

Logs and warnings
Performance metrics
Small UI inconsistencies
Memory or state leaks

Angular example:

Using Angular’s DevTools, logging services, and ChangeDetectionStrategy can reveal subtle signals before they become major bugs. For instance, a slight lag in change detection may indicate a heavy computation in a component or inefficient subscription handling.

Debugging is interpretation, not brute force. The earlier you detect signals, the smaller the problem becomes.

Conclusion: Engineering Is Communication

You cannot dominate complex systems — you collaborate with them.

With a horse, control comes through balance and timing.

With frontend architecture, control comes through clarity, simplicity, and thoughtful design.

Stability is not something you can force into a system.
It is something you build - through understanding how the system behaves and making careful adjustments over time.

In many cases, stability doesn’t come from adding more layers, tools, or abstractions.
It comes from stepping back, simplifying where possible, and choosing the right level of structure for the problem you are solving.

So I’m curious: Where do you personally draw the line between
good architecture and overengineering?

🚫 NOT Another Boring Energizer - P.1: Wall of Travel Souls

Maria-Lurdes Dehtiarenko — Mon, 28 Jul 2025 14:35:13 +0000

Most energizers are forgotten the second they end.
I wanted to build something different - something small but deep, where people leave the call having actually learned something about each other.

This is a concept I created for my remote team - and it's one of the few energizers that left people smiling after the call, not just during it.

🎒 “Wall of Travel Souls”

A team-building experience based on personal travel memories.

⏳ Duration: 20–30 min

🎯 Purpose: Emotional connection, storytelling, light creativity

💻 Format: Remote or hybrid-friendly

📸 Prep: Ask team to send 1 meaningful photo from any trip — past or recent

🔧 What You Need

A shared wall (Miro, Figma, Canva, Jamboard, etc.)
A simple avatar template (or let them freestyle)
1 short, open-ended prompt

💬 The Prompt

Think of one special moment from any vacation or trip. A quiet moment, a funny accident, something magical. Use the template to build a character or space that shows the essence of that memory. Write 1–3 sentences next to it to bring it to life.

📨 Script to Send Your Team (before the call)

Hey team!
For tomorrow’s energizer, please find one photo from any of your travels - just a moment that meant something to you.
You can send it to me directly.
We’ll use it during the call for a short, personal activity.
If possible, please have your camera on - we’re bringing a little piece of ourselves to the screen 🌍✨

🧩 Pro Tips (If You're Facilitating)

Prepare 2–3 sample cards ahead of time (include yours!)
Screenshot the final wall and send it out after the meeting as a memory

🗺️ A Sneak Peek Inside My Mural Setup

Here’s a little glimpse of how my board looked during the session.

👀 Liked the vibe?
This is just one of many energizers I’ve cooked up.
Follow me to catch the next drop – and maybe steal a few sparks for your own sessions 🌟

🦄 Chasing Traces Like Unicorns: Implementing OpenTelemetry in Angular

Maria-Lurdes Dehtiarenko — Fri, 11 Jul 2025 06:44:56 +0000

Once upon a time in a land of frontend chaos, brave developers struggled to find what the f*** was going wrong in production. Errors were like wild beasts — appearing, disappearing, teleporting across services — and no brave knight had the weapon to trace them properly.

Enter the majestic beast: OpenTelemetry 🪄✨

🧚‍♀️ What is OpenTelemetry?

OpenTelemetry is your enchanted toolkit for collecting traces, metrics, and logs from your applications. Think of it as the unicorn horn that pierces through the fog of frontend confusion, giving you a full map of your app’s behavior from browser to backend and back.

With OpenTelemetry, you're not just logging errors. You're tracing user journeys, seeing which spells (requests) failed, and where the dragons (delays) hide.

🌈 Why Should Frontend Devs Care?

Let’s be honest. Frontend apps are the glittering princess castles of software — they look good, but the plumbing underneath can get ugly fast. Crashes, slow fetch calls, ghost clicks — they all become a nightmare to debug without observability.

Using OpenTelemetry on the frontend:

Helps trace issues from UI to backend services
Gives performance insights for requests & user interactions
Enables correlation of logs with actual user actions
Makes you look like a goddamn wizard 🧙‍♀️ in your team

🦄✨ Installing the Magic Dust

Before summoning unicorn-level observability, install the following OpenTelemetry packages. These are the stable, battle-tested versions:

npm install @opentelemetry/api@^1.9.0 \
@opentelemetry/instrumentation-fetch@^0.37.0 \
@opentelemetry/instrumentation-user-interaction@^0.46.0 \
@opentelemetry/instrumentation-xml-http-request@^0.201.1 \
@opentelemetry/resources@^2.0.1 \
@opentelemetry/sdk-trace-web@^1.8.0 \
@opentelemetry/semantic-conventions@^1.34.0

Once installed, you’ve got everything you need to spy on your app like a sassy fairy with a magnifying glass.

🧙‍♂️ OpenTelemetry Service: Your Spellbook

Create a magical Angular service to initialize the spellbinding observability:

// src/app/core/telemetry/open-telemetry.service.ts

import { Injectable } from '@angular/core';
import { defaultResource, resourceFromAttributes } from '@opentelemetry/resources';
import { ATTR_SERVICE_NAME } from '@opentelemetry/semantic-conventions';
import { ConsoleSpanExporter } from '@opentelemetry/sdk-trace-base';
import { BatchSpanProcessor, SpanExporter, WebTracerProvider } from '@opentelemetry/sdk-trace-web';
import { FetchInstrumentation } from '@opentelemetry/instrumentation-fetch';
import { XMLHttpRequestInstrumentation } from '@opentelemetry/instrumentation-xml-http-request';
import { UserInteractionInstrumentation } from '@opentelemetry/instrumentation-user-interaction';
import { registerInstrumentations } from '@opentelemetry/instrumentation';
import { environment } from '../../../environments/environment';

@Injectable({ providedIn: 'root' })
export class OpenTelemetryService {
  constructor() {
    this.initializeOpenTelemetry();
  }

  private initializeOpenTelemetry(): void {
    const resource = defaultResource().merge(
      resourceFromAttributes({
        [ATTR_SERVICE_NAME]: 'unicorn-frontend',
      })
    );

    const spanProcessors = [];
    if (!environment.production) {
      spanProcessors.push(
        new BatchSpanProcessor(new ConsoleSpanExporter() as unknown as SpanExporter)
      );
    }

    const provider = new WebTracerProvider({ resource, spanProcessors });
    provider.register();

    registerInstrumentations({
      instrumentations: [
        new FetchInstrumentation({ propagateTraceHeaderCorsUrls: /.*/ }),
        new XMLHttpRequestInstrumentation(),
        new UserInteractionInstrumentation(),
      ],
    });
  }
}

🌟 Personal opinion from a tired fairy dev: ConsoleSpanExporter is noisy af. Like glitter in your eyes. You can still find traceId in headers — don’t clutter your logs unless you want full chaos mode.

⚙️ Initialize Tracing in App Module

Add the following initialization logic so that the magic spell is cast before the app even begins:

export const initializeTracing = (tracingService: OpenTelemetryService) => (): void => {
  // Tracing initializes in the constructor
};

export const appInitializerFactory = (tracingService: OpenTelemetryService) => async () => {
  initializeTracing(tracingService)();
};

{
  provide: APP_INITIALIZER,
  useFactory: appInitializerFactory,
  deps: [OpenTelemetryService],
  multi: true,
}

🔮 Add Trace Info to NGINX Logs (Because Even Servers Need Fairy Dust)

Why is this important?
Because logs aren’t just backend noise - they're gold when you want to trace issues or monitor behavior across systems. Services like Splunk Cloud thrive on structured, rich logs.

With this setup, you:

Extract trace and span IDs from the traceparent header
Customize what data appears in your logs
Format it all into clean JSON
And as a bonus? Add emojis to make them stand out 🌈😈

🔥 Sample NGINX Config Snippet

Add this at the top of your config file (default.conf.template, etc.):

map $http_traceparent $trace_id {
  ~^(dd)-([0-9a-f]{32})-([0-9a-f]{16})-(dd)$ $2;
  default -;
}

map $http_traceparent $span_id {
  ~^(dd)-([0-9a-f]{32})-([0-9a-f]{16})-(dd)$ $3;
  default -;
}

log_format with_trace escape=json '{'
  '"🕒timestamp":"$time_iso8601",'
  '"💋httpUserAgent":"$http_user_agent",'
  '"💌request":"$request",'
  '"💅status":"$status",'
  '"💖traceId":"$trace_id",'
  '"🎀spanId":"$span_id"'
'}';

🐉 Direct Logs to Standard Output

Want your logs to fly straight into the rainbow without clutter? Add this:

access_log /dev/stdout with_trace;
error_log /dev/stdout error;

No more dark caves of error.log. Trace IDs will light your path like fairy lanterns 🧚.

🏁 The Final Word from the Unicorn Queen

Using OpenTelemetry in frontend apps isn’t just for backend folks or infra wizards. You, the enchanted JS slinger, can now trace like a beast and debug like royalty. Don’t just chase bugs — track their exact path through the kingdom.

Stay magical. Stay traced. Stay fabulous.

Tips for Updating Your Angular Project: From Version 6 to 16 – BOOM! 🚀🔥🎯

Maria-Lurdes Dehtiarenko — Tue, 18 Feb 2025 09:10:07 +0000

Updating an Angular project from version 6 to 16 is no easy journey – but I did it! And now, I'm here to help you do it faster and with less hassle. So let's grab some magic ✨ and get to work! 💻⚡🎉

🛠️ Why It's Important to Keep Angular Updated

Postponing Angular updates can lead to compatibility issues, security vulnerabilities, and performance degradation. Keeping your project up to date ensures better performance, access to new features, and easier long-term maintenance. Don't delay – stay current and save yourself future headaches ⚙️

🔧 Most Useful Commands

npm outdated
Shows which packages need updates to maintain compatibility.
npm info [packageName]
Provides package details, including the latest available versions.
ng update
Angular's built-in command to assist with framework and dependency updates.
npm dedupe
Deduplicates dependencies in node_modules to resolve version conflicts.
npm cache verify
Ensures your cache isn't corrupted, helping avoid mysterious installation errors.

💡 Essential Rules for a Smooth Update

Check Node Version Compatibility 🚦🔍🔧
Angular updates often require specific Node versions. Make sure you're aligned before starting.
Use the Correct Node Version During Updates 🛠️🔑🔄
Run installs with the matching Node version. Upgrade Angular using a higher version afterward.
Don't Force Updates ⚠️🙅‍♂️🚫
Avoid using --force. It's better to fix the underlying issues before pushing forward.
Clean Up Unused Packages 🧹🗑️🎯
Encountering stubborn packages? Check if they're even being used. If not, remove them. Less baggage means fewer problems.
Run Tests Frequently – My Personal Mistake 🧪✅⚙️
I once tested everything very superficially and ended up with tons of bugs – big and small. Lesson learned: test thoroughly and often, especially after updates.

Additionally: While testing after each update might take more time and require fixing more bugs along the way, it's absolutely worth it. In the long run, this strategy will save you more time and nerves by preventing the accumulation of hard-to-debug issues later. 🕒🛠️😌

💥 Pro Tips & Hidden Gems ⚡🎓💡

Use Angular Update Guide: Always review Angular's official update guide to stay informed about breaking changes. 🧐📚🔍
Enable Strict Mode: If you haven't already, turn on Angular's strict mode for better type safety and potential performance improvements. 🧠📈🛠️
Analyze Build Performance: Run ng build --stats-json and use tools like webpack-bundle-analyzer to optimize your app's performance. 🚀🔍📊
Migrate Deprecated Features: Angular's release notes often highlight deprecated APIs. Migrate early to avoid compatibility issues later. 🔍🛠️⚙️

So there you have it – my personal battle-tested guide to modernizing your Angular app. Have you tackled a big version leap recently? Share your experience in the comments! 👇💬✨