Forem: Long Huynh

Everyone Is Wrong, But Me

Long Huynh — Thu, 26 Jun 2025 21:43:27 +0000

Let’s face it, we’ve all been there.

The team is hyped about a new direction. Diagrams are flying, Figma is open, Jira tickets are multiplying. People are nodding, approving, moving forward at full speed...

But in your head?

“Everyone is wrong. But me.”

The Lonely Genius Problem

There’s something deeply satisfying (and slightly dangerous) about thinking you’re the only one who sees the truth. Maybe the proposed solution will break in production. Maybe migrating to another framework doesn’t fix the root issue. Maybe your teammates are caught in groupthink, and only you have taken the red pill.

It’s okay. You’re not alone in feeling alone.

But how you handle that moment makes the difference between being a respected voice of reason, and being that developer everyone avoids.

How Not to Say It

Let’s start with some approaches that never go well:

“This is a terrible idea.”

You’ve just shut down the conversation.
“I don’t know why no one else sees this.”

Congratulations, you’ve insulted the room.
“I’m the only one thinking clearly here.”

Translation: "I don’t work well with others."

Being right isn’t a license to be rude. It’s an opportunity to lead with clarity and humility.

How to Say It Better

Here are some ways to express dissent that actually invite collaboration instead of conflict.

1. Frame It As Curiosity

“Can I walk through a concern I have? I’m trying to understand how this approach handles edge cases.”

This shows that you're looking for understanding, not just a platform to preach from.

2. Isolate the Assumption

“I think this hinges on the assumption that X is always true. I’m not sure that holds in every case.”

Calling out assumptions is constructive and objective. You’re challenging the logic, not the people.

3. Use "Yes, And…" Language

“I agree this solves the immediate need. I’m wondering how it scales in the long term.”

Acknowledging the value in someone else’s idea before building on it shows maturity and collaboration.

4. Invite Collaboration

“Would it be okay if I prototyped an alternative? It might give us something to compare against.”

Now you’re not just raising concerns, you’re doing the work to help validate them.

Real Dev-Life Examples

Here are some “Everyone Is Wrong, But Me” moments, with more constructive alternatives.

Instead of:

“We should just use MongoDB for everything.”

Try:

“Mongo is great for flexibility, but I’d love to discuss how we’d handle transactional consistency in this setup.”

Instead of:

“Everyone says yes, but this is obviously a mistake.”

Try:

“Before we lock this in, can we sanity-check the performance impact? I have a few metrics from past projects that might be relevant.”

Instead of:

“That’s a lazy architecture decision.”

Try:

“I think I understand why we chose this path, but what were the tradeoffs we considered?”

When You’re Actually Wrong

Sometimes, the surprise twist is this: you’re not the lone genius. You’re just… wrong.

And that’s okay.

Knowing how to listen, reconsider, and thank others for their insights is a high-level skill. It earns trust and makes your future feedback more valuable, because people know you’re honest, not just opinionated.

Final Thoughts

The next time you catch yourself thinking:

“Everyone is wrong, but me…”

Pause. Take a breath.

Then try this instead:

“I’d like to offer a different take. Can we dig into this together?”

That shift in tone turns you from the naysayer into the person who sharpens the conversation, the one who helps the team get it right, not just get along.

Because the goal isn’t to always be right.

It’s to help the team make better decisions.

"Strong opinions, humbly expressed" isn’t just a motto, it’s a survival strategy in software development.

Mastering API Design: The Power of Namespaces and Contracts

Long Huynh — Tue, 18 Mar 2025 22:32:14 +0000

In modern software development, maintaining clear structure and predictability is crucial for long-term maintainability and scalability. Two key principles that help achieve this are namespaces and solid contracts in APIs. These concepts help developers manage versioning, maintain compatibility, and ensure predictable communication between different components of a system.

Benefits of Using Namespaces

Namespaces provide a way to group logically related code and prevent naming conflicts. They offer several benefits, including:

1. Avoiding Naming Collisions

In large codebases, multiple developers might use similar function or class names. Namespaces help organize them properly, ensuring that each component remains unique.

Example in TypeScript:

Defines a namespace for retrieving a list of cats with request parameters.

namespace Cats.Api.V1.GetCats {
    export namespace Request {
        export interface Params {
            limit: number;
            sort: "asc" | "desc";
        }
    }

    export namespace Response {
        export interface Data {
            id: number;
            name: string;
        }
        export type Result = Data[];
    }
}

Defines a namespace for modifying a cat's attributes such as name and age.

namespace Cats.Api.V1.ModifyCat {
    export namespace Request {
        export interface Params {
            id: number;
            name?: string;
            age?: number;
        }
    }
}

Defines a namespace for adopting a new cat, we only need to pass the name.

namespace Cats.Api.V1.AdoptCat {
    export namespace Request {
        export interface Params {
            adopterName: string;
        }
    }
}

Defines a namespace for releasing a cat with an optional reason.

namespace Cats.Api.V1.ReleaseCat {
    export namespace Request {
        export interface Params {
            id: number;
            reason?: string;
        }
    }
}

2. Enhancing Code Readability and Organization

By structuring code using namespaces, developers can quickly identify related components. This improves maintainability, especially when teams grow and more modules are added.

3. Facilitating Versioning and Backward Compatibility

Namespaces can help version APIs and modules, allowing multiple versions to coexist without breaking existing functionality.

Example in TypeScript

Version 2 of GetCats adds an optional filter parameter.

namespace Cats.Api.v2.GetCats {
    export namespace Request {
        export interface Params {
            limit: number;
            sort: "asc" | "desc";
            filter?: string;
        }
    }

    export namespace Response {
        export interface Data {
            id: number;
            name: string;
            breed?: string;
        }
        export type Result = Data[];
    }
}

The Role of a Solid API Contract

An API contract defines the expected request and response format between services, ensuring consistency and reliability.

1. Predictability and Stability

Clearly defined API contracts help frontend and backend teams work independently. Clients can rely on consistent response structures without worrying about unexpected changes.

2. Seamless Versioning and Upgrades

With versioning strategies in place, breaking changes can be avoided by supporting multiple API versions simultaneously.

Example

{
    "Cats.Api.V1.GetCats.Request": { "limit": 10, "sort": "asc" },
    "Cats.Api.V1.GetCats.Response": { "cats": [{ "id": 1, "name": "Whiskers" }, { "id": 2, "name": "Felix" }] },
    "Cats.Api.V1.ModifyCat.Request": { "id": 1, "name": "Mittens" },
    "Cats.Api.V1.AdoptCat.Request": { "adopterName": "John Doe" },
    "Cats.Api.V1.ReleaseCat.Request": { "id": 3, "reason": "Releasing back to nature" },
    "Cats.Api.v2.GetCats.Request": { "limit": 20, "sort": "desc", "filter": "breed" },
    "Cats.Api.v2.GetCats.Response": { "cats": [{ "id": 1, "name": "Whiskers", "breed": "Siamese" }, { "id": 2, "name": "Felix", "breed": "Persian" }] }
}

Conclusion

Namespaces and API contracts are fundamental for managing complexity in software development. Namespaces help organize code and prevent conflicts, while well-defined API contracts ensure predictable and stable interactions between services. By implementing these best practices, teams can build scalable, maintainable, and robust applications.

Mastering API Design: The Power of Namespaces and Contracts

Long Huynh — Tue, 18 Mar 2025 22:32:14 +0000

Benefits of Using Namespaces

Namespaces provide a way to group logically related code and prevent naming conflicts. They offer several benefits, including:

1. Avoiding Naming Collisions

In large codebases, multiple developers might use similar function or class names. Namespaces help organize them properly, ensuring that each component remains unique.

Example in TypeScript:

Defines a namespace for retrieving a list of cats with request parameters.

namespace Cats.Api.V1.GetCats {
    export namespace Request {
        export interface Params {
            limit: number;
            sort: "asc" | "desc";
        }
    }

    export namespace Response {
        export interface Data {
            id: number;
            name: string;
        }
        export type Result = Data[];
    }
}

Defines a namespace for modifying a cat's attributes such as name and age.

namespace Cats.Api.V1.ModifyCat {
    export namespace Request {
        export interface Params {
            id: number;
            name?: string;
            age?: number;
        }
    }
}

Defines a namespace for adopting a new cat, we only need to pass the name.

namespace Cats.Api.V1.AdoptCat {
    export namespace Request {
        export interface Params {
            adopterName: string;
        }
    }
}

Defines a namespace for releasing a cat with an optional reason.

namespace Cats.Api.V1.ReleaseCat {
    export namespace Request {
        export interface Params {
            id: number;
            reason?: string;
        }
    }
}

2. Enhancing Code Readability and Organization

By structuring code using namespaces, developers can quickly identify related components. This improves maintainability, especially when teams grow and more modules are added.

3. Facilitating Versioning and Backward Compatibility

Namespaces can help version APIs and modules, allowing multiple versions to coexist without breaking existing functionality.

Example in TypeScript

Version 2 of GetCats adds an optional filter parameter.

namespace Cats.Api.v2.GetCats {
    export namespace Request {
        export interface Params {
            limit: number;
            sort: "asc" | "desc";
            filter?: string;
        }
    }

    export namespace Response {
        export interface Data {
            id: number;
            name: string;
            breed?: string;
        }
        export type Result = Data[];
    }
}

The Role of a Solid API Contract

An API contract defines the expected request and response format between services, ensuring consistency and reliability.

1. Predictability and Stability

Clearly defined API contracts help frontend and backend teams work independently. Clients can rely on consistent response structures without worrying about unexpected changes.

2. Seamless Versioning and Upgrades

With versioning strategies in place, breaking changes can be avoided by supporting multiple API versions simultaneously.

Example

{
    "Cats.Api.V1.GetCats.Request": { "limit": 10, "sort": "asc" },
    "Cats.Api.V1.GetCats.Response": { "cats": [{ "id": 1, "name": "Whiskers" }, { "id": 2, "name": "Felix" }] },
    "Cats.Api.V1.ModifyCat.Request": { "id": 1, "name": "Mittens" },
    "Cats.Api.V1.AdoptCat.Request": { "adopterName": "John Doe" },
    "Cats.Api.V1.ReleaseCat.Request": { "id": 3, "reason": "Releasing back to nature" },
    "Cats.Api.v2.GetCats.Request": { "limit": 20, "sort": "desc", "filter": "breed" },
    "Cats.Api.v2.GetCats.Response": { "cats": [{ "id": 1, "name": "Whiskers", "breed": "Siamese" }, { "id": 2, "name": "Felix", "breed": "Persian" }] }
}

Conclusion

How to Start a Technical Design for Beginners?

Long Huynh — Wed, 19 Feb 2025 13:58:21 +0000

Technical design is an essential part of software development, yet many beginners find it intimidating. I have often seen developers, including myself at times, jump straight into coding a big feature only to realize later that they didn't anticipate potential blockers. Whether you're working on a personal project, a startup MVP, or contributing to a larger system, understanding how to approach technical design can save you from costly mistakes and rework. This guide will help you get started with structuring a technical design from scratch.

1. What is Technical Design?

Technical design is the process of defining how a system or feature should be built before writing code. It includes architectural choices, data structures, APIs, scalability considerations, and more.

High-Level Design (HLD) vs. Low-Level Design (LLD)

High-Level Design (HLD): Focuses on the overall architecture, system components, and how they interact. Example: Choosing between a monolithic or microservices architecture.
Low-Level Design (LLD): Deals with implementation details like database schema, API endpoints, and business logic.

When Do You Need a Technical Design?

For new features that impact multiple parts of the system.
When integrating with third-party services.
Before migrating from monolithic to microservices.
For designing scalable and maintainable applications.
When you want to avoid unforeseen blockers during implementation.

2. Understanding the Problem Statement

One of the most common mistakes I've observed is jumping into development without fully understanding the problem. Before writing a single line of code, clearly define the problem you’re solving. Ask yourself:

What is the goal of this feature/system?
Who are the users? (Internal services, external customers, third-party integrations)
What are the constraints? (Scalability, performance, compliance, budget)
What are the functional and non-functional requirements?
- Functional: Business logic, user interactions, API specifications.
- Non-functional: Performance, security, availability, scalability.

3. Breaking Down the System

Choosing the Right Architecture

Some common architectural patterns include:

Monolithic: Suitable for small applications with simple business logic.
Microservices: Good for scalable, distributed applications.
Event-driven architecture: Useful for asynchronous processing (e.g., Kafka, RabbitMQ).
Serverless: Ideal for lightweight, scalable applications without managing infrastructure.

Identifying Key Modules

Break the system into core components (e.g., frontend, backend, database, external integrations).
Define how components interact (APIs, events, direct function calls).
Decide on communication protocols (REST, GraphQL, gRPC, WebSockets).

4. Choosing the Right Tech Stack

Your technology choices should align with:

Performance needs: Will your app handle thousands of requests per second?
Scalability: Should it support global users with minimal latency?
Maintainability: Will multiple teams contribute to the codebase?
Security: Does it involve sensitive data?

For example, a Vue 3 frontend with a Node.js/Express backend using PostgreSQL could work well for a typical web app. If scalability is a major concern, you might consider Kubernetes for orchestration.

5. Creating System Diagrams

One thing that has helped me avoid late-stage blockers is visualizing the design. It makes it easier to communicate ideas and identify potential issues.

Basic Diagrams to Start With

Flowcharts: Represent user interactions and system flows.
Component Diagrams: Show how different services interact.
Sequence Diagrams: Outline API request/response patterns.
Database Schema: Define how data is stored and related.

Tools for Diagramming: Draw.io, Lucidchart, Excalidraw, Mermaid.js.

6. Writing the Technical Design Document

A structured technical design document helps teams understand the proposed solution.

Here’s a simple template that I usually use as a starting point:

Technical Design Document Template

1. Overview

What problem does this design solve?
What is the scope of this design?

2. System Architecture

High-level diagram of components.
Justification for chosen architecture.

3. Data Flow

Sequence diagrams for major user interactions.
API endpoints and expected responses.

4. Scalability & Performance Considerations

How does the system scale with traffic?
Load balancing, caching strategies (e.g., Redis, CDN).

5. Security Considerations

Authentication (OAuth, JWT, API Keys).
Data encryption (in transit & at rest).

6. Trade-offs & Alternatives

Why were certain decisions made?
What are the alternative approaches and their pros/cons?

7. Reviewing & Iterating

One thing I’ve learned is that technical designs should always be reviewed and refined. Share your design with:

Peers/Senior Engineers for feedback on feasibility and scalability.
Product Managers to ensure business alignment.
Security Teams to address potential risks.

Be open to feedback and iterate on your design before implementation.

8. Common Mistakes to Avoid

Overcomplicating the design: Keep it as simple as possible while meeting requirements.
Ignoring scalability: Design for future growth, not just current needs.
Skipping documentation: Your future self and teammates will thank you.
Forgetting security: Secure APIs, encrypt sensitive data, and follow best practices.
Jumping into coding too early: Avoid rushing into implementation before validating the design.

Conclusion

Starting a technical design may feel overwhelming at first, but by following a structured approach, you can create well thought out designs that guide successful implementations. Focus on understanding the problem, breaking it down into components, documenting your design, and iterating based on feedback.

If you're new to technical design, start small and draft a design for it. Iterate on the design until your team, or you are happy about it. Remember, a little planning upfront can save a lot of time and frustration later!

Building a Micro Frontend Architecture with Vue 3, Vite and Module Federation

Long Huynh — Sat, 08 Feb 2025 01:47:25 +0000

Micro frontend architecture is a powerful way to build scalable and modular applications. Instead of having a monolithic frontend, we split it into multiple independent micro frontends (MFEs) that can be developed, deployed, and maintained separately. In this guide, we will walk through a Vue 3 based micro frontend setup using Vite, Module Federation, and Vue Router to create a flexible and scalable system.

This setup is useful when each micro frontend requires its own Vue instance, allowing different teams to work independently while maintaining separation. It also ensures good performance by loading only one additional instance of Vue.

We use Module Federation Runtime and a Route Manifest to dynamically fetch and load MFEs at runtime, reducing initial load times and improving flexibility.

What We Will Be Using

We will be going through this) sample project and see how we can create a host application that dynamically renders micro frontends, each with its own Vue instance.

The project consist of these dependencies:

Vue 3 – The frontend framework for both the host and MFEs
Vite – A fast build tool that supports Module Federation
Vue Router – To handle navigation between micro frontends
Module Federation Plugin – For dynamically loading MFEs

Setting Up the Host Application

The host application is responsible for orchestrating the micro frontends, handling routing, and dynamically loading them as needed.

Vite Configuration for the Host

In the host Vite configuration, we don't need much beyond specifying the name, filename, and shared dependencies.

packages/host/vite.config.js

import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';
import { federation } from '@module-federation/vite';
import { fileURLToPath, URL } from 'node:url';

// https://vite.dev/config/
export default defineConfig({
  plugins: [
    vue(),
    federation({
      name: 'host',
      filename: 'remoteEntry.js', // Entry point for the host's own remote modules
      shared: ['vue'], // Ensure shared dependencies are listed
    }),
  ],
  server: {
    port: 5010,
  },
});

Initializing Remotes at Runtime

Instead of defining remotes directly in the Vite config, we initialize them at runtime using the Module Federation Runtime.

In the plugin, we need to pass all the remotes that will be fetched at runtime. In a more advanced setup, we could fetch the remote manifest dynamically and initialize them as needed. However, for this example, the remotes are pre-defined in the route manifest.

packages/host/src/plugins/federationPlugin.js

import { init, loadRemote as _loadRemote } from '@module-federation/runtime';

export const federationPlugin = {
  install: (_, remotes) => {
    const mfRemotes = remotes.map((remote) => ({
      name: remote.module,
      entry: remote.entry,
      type: 'module',
    }));

    init({
      name: 'host',
      remotes: mfRemotes,
    });
  },
};

export default federationPlugin;

export const useModuleFederation = () => {
  const loadRemote = async (module) => {
    const loadedModule = await _loadRemote(`${module}/entry`);
    return {
      name: module,
      mount: loadedModule.mount,
      unmount: loadedModule.unmount,
    };
  };
  return { loadRemote };
};

Defining the Route Manifest

The Route Manifest serves as a centralized registry for defining remotes, providing a structured and scalable way to manage micro frontend routes. Instead of manually specifying routes, this manifest allows the system to dynamically determine where to fetch and load MFEs, ensuring clear separation of concerns and easier updates as new micro frontends are introduced. It is crucial to correctly define the module name (e.g., app1) and the entry path (e.g., entry: 'http://localhost:5011/remoteEntry.js') in the remote property to ensure proper remote fetching and integration.

We define two properties here: one that specifies the route details and another that indicates where to fetch and load the corresponding micro frontend.

packages/host/src/router/routeManifest.js

export const routeManifest = [
  {
    route: {
      path: '/app-1',
      name: 'App1',
      meta: { requiresAuth: false },
    },
    remote: { 
      module: 'app1', 
      entry: 'http://localhost:5011/remoteEntry.js' 
    }
  }
];

Setting Up Vue Router in the Host

Now that our route manifest is in place, we can configure the router to handle application routes dynamically. Instead of manually defining which micro frontend to load, the router reads from the manifest and directs all MFE routes to Loader.vue. This allows the system to fetch and mount the correct micro frontend at runtime.

Here, we map the route properties from the manifest to create our routes. If needed, we can extend the manifest to include additional properties like metadata for enhanced route handling.

packages/host/src/router/index.js

import { createRouter, createWebHistory } from 'vue-router';
import routeManifest from '../routeManifest';

const getRoutes = () => {
  return routeManifest.map((mfe) => ({
    path: mfe.route.path,
    name: mfe.route.name,
    meta: mfe.route.meta,
    component: () => import('@/components/Loader.vue'),
  }));
};

const routes = getRoutes();

const router = createRouter({
  history: createWebHistory(),
  routes,
});

export default router;

The Loader Component

The Loader.vue component is responsible for dynamically mounting and unmounting micro frontends (MFEs) as users navigate through the application. It ensures that only one instance of each micro frontend is active at any time, optimizing performance and preventing memory issues.

At its core, Loader.vue consists of a simple div element that serves as a container for dynamically mounted micro frontends.

packages/host/src/components/Loader.vue

<template>
  <div ref="containerRef"></div>
</template>

To ensure the correct micro frontend is loaded based on navigation, Loader.vue listens for route changes, identifies the appropriate micro frontend, and dynamically loads it while unmounting the previous one. This keeps the application responsive and efficient.

Setting Up the App 1 Application

Now that we have the host application configured, let's set up app1, our first micro frontend. This application will be loaded dynamically by the host at runtime using Module Federation.

Vite Configuration

To enable Module Federation, we need to configure vite.config.js for app1. This will allow it to expose its components and functionality to the host application.

In our route manifest, we have defined the remote configuration, which should correspond to app1. As shown here, the name is app1, and it is configured to be served on port 5011. This means that when app1 is running, the host application can dynamically access its remoteEntry.js file at http://localhost:5011/remoteEntry.js, enabling seamless integration between the host and the micro frontend.

packages/app-1/vite.config.js

import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';
import { federation } from '@module-federation/vite';

export default defineConfig({
  plugins: [
    vue(),
    federation({
      name: 'app1',
      filename: 'remoteEntry.js',
      exposes: {
        './entry': './src/entry.js',
      },
      shared: ['vue'],
    }),
  ],
  server: {
    port: 5011,
  },
});

Explanation of the Configuration

name: 'app1' – Identifies this micro frontend as app1.
filename: 'remoteEntry.js' – Defines the entry point for the remote module.
exposes: { './entry': './src/entry.js' } – Exposes the entry.js file so the host can import and mount it.
shared: ['vue'] – Ensures Vue is shared to prevent multiple instances.
server.port: 5011 – Runs app1 on port 5011.

Entry File for App 1

The entry file is responsible for mounting the micro frontend. It provides the necessary lifecycle methods (mount and unmount) so that the host application can dynamically load and unload app1.

packages/app-1/src/entry.js

import { createApp } from 'vue';
import App from './App.vue';

let appInstance = null;

export function mount(container) {
  appInstance = createApp(App);
  appInstance.mount(container);
}

export function unmount() {
  if (appInstance) {
    appInstance.unmount();
    appInstance = null;
  }
}

Running Both The Host and App 1

To run both application we can go to each directory and run npm run dev. This will start the host on port 5010, and app1 on port 5011, making it accessible for the host to load dynamically at runtime.

Conclusion

This guide walks through setting up a Vue 3-based micro frontend architecture using Vite and Module Federation. We covered:

Setting up the host app with Vite config and Route Manifest
Configuring Vue Router to dynamically load MFEs
Using Module Federation Runtime Plugin to initialize remotes dynamically

By initializing remotes at runtime instead of defining them in the Vite config, we gain more flexibility in managing MFEs and reduce unnecessary dependencies in the host application.

Check out the full GitHub Repository) for a working example.