DEV Community: SAVITA WADJE

Micro Frontends in Angular: A Simple Setup You Can Actually Follow

SAVITA WADJE — Fri, 04 Sep 2026 12:08:59 +0000

Micro frontends sound complicated the first time you read about them, separate teams, separate deployments, separate frameworks even. But the core idea is simpler than it sounds, and getting a basic setup running in Angular does not take as much effort as most articles make it seem.

What a micro frontend actually is

Instead of building one large Angular app that owns every feature, you split the app into smaller, independently built and deployed pieces. Each piece can be developed, tested, and released by a different team, on its own timeline, without waiting on everyone else.

A shell app (sometimes called the host) loads these smaller apps (called remotes) at runtime and stitches them together into one experience for the user.

Why bother with this

For a small app, honestly, you probably should not. Micro frontends add real complexity, and for a single team working on one codebase, a normal monolith Angular app is usually the better call.

Where it starts to make sense:

Multiple teams working on the same product, each owning a different section
Different parts of the app needing to release on different schedules
Large legacy apps where a full rewrite is not realistic, but individual sections can be modernized one at a time

The tool that makes this practical: Module Federation

Module Federation, originally a Webpack feature, lets one application load code from another application at runtime, without bundling it together at build time. Angular supports this through the @angular-architects/module-federation package, which handles most of the configuration for you.

Setting up a basic example

Let's build the simplest possible version: a shell app that loads one remote app containing a single feature.

Step 1: Create both apps

ng new shell-app --routing --style=css
ng new remote-app --routing --style=css

Step 2: Add Module Federation to both

cd shell-app
ng add @angular-architects/module-federation --project shell-app --port 4200 --type host

cd ../remote-app
ng add @angular-architects/module-federation --project remote-app --port 4201 --type remote

This generates a webpack.config.js in each project and wires up the basic federation setup automatically.

Step 3: Configure the remote app

In remote-app/webpack.config.js, expose the module you want the shell to be able to load:

module.exports = withModuleFederationPlugin({
  name: "remoteApp",
  exposes: {
    "./Module": "./src/app/remote/remote.module.ts",
  },
  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: "auto" }),
  },
});

Create a simple feature module in the remote app to actually expose:

// remote/remote.module.ts
import { NgModule } from "@angular/core";
import { CommonModule } from "@angular/common";
import { RouterModule } from "@angular/router";
import { RemoteComponent } from "./remote.component";

@NgModule({
  declarations: [RemoteComponent],
  imports: [
    CommonModule,
    RouterModule.forChild([{ path: "", component: RemoteComponent }]),
  ],
})
export class RemoteModule {}

// remote/remote.component.ts
import { Component } from "@angular/core";

@Component({
  selector: "app-remote",
  template: `<h2>Hello from the Remote App</h2>`,
})
export class RemoteComponent {}

Step 4: Configure the shell app

In shell-app/webpack.config.js, tell the shell where to find the remote:

module.exports = withModuleFederationPlugin({
  remotes: {
    remoteApp: "remoteApp@http://localhost:4201/remoteEntry.js",
  },
  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: "auto" }),
  },
});

Then add a lazy-loaded route in the shell that points to the remote module:

// shell-app routing
const routes: Routes = [
  {
    path: "remote-feature",
    loadChildren: () =>
      loadRemoteModule({
        remoteEntry: "http://localhost:4201/remoteEntry.js",
        remoteName: "remoteApp",
        exposedModule: "./Module",
      }).then((m) => m.RemoteModule),
  },
];

Step 5: Run both apps

# terminal 1
cd remote-app && ng serve

# terminal 2
cd shell-app && ng serve

Visit the shell app and navigate to /remote-feature. Angular loads the remote app's code at runtime and renders it right inside the shell, even though it is a completely separate build.

The part that actually trips people up

Shared dependencies. Both apps need to agree on shared library versions, especially Angular itself. If the shell and remote load different versions of Angular, you end up with duplicated frameworks running side by side, which is slow and buggy. The sharedconfig with singleton: true handles this, but mismatched versions between the two apps are the most common source of runtime errors when people first try this.

Routing across apps. The shell owns the top level routes. Remote apps expose modules, they do not control the browser URL directly. Keeping this boundary clear early on avoids a lot of confusion later.

Independent deployment. In a real setup, the remote app gets built and deployed separately, and its remoteEntry.js URL points to wherever it actually lives in production, not localhost. That URL becomes the contract between the shell and the remote.

When this is worth the complexity

If you are working solo or on a small team, stick with a normal Angular app, monoliths are simpler and Module Federation adds real overhead for no benefit at that scale. It starts paying off once you have multiple teams, independent release cycles, or a large legacy app you want to modernize piece by piece instead of all at once.

Wrapping up

Micro frontends are not magic, they are really just "load this other app's code at runtime instead of bundling it together." Once that clicks, the actual Angular setup is mostly configuration, not something conceptually hard.

Why FAIR Data Validators Don't Agree With Each Other

SAVITA WADJE — Fri, 04 Sep 2026 11:56:23 +0000

This one is from my masters coursework, a research internship I did on something most developers have probably never heard of: FAIR data validators. Stick with me, the actual finding is more interesting than the name suggests.

The problem I started with

Research data is supposed to follow something called the FAIR principles. Findable, Accessible, Interoperable, Reusable. The idea is simple: if a dataset follows these principles properly, other researchers can actually find it, use it, and trust it.

There are tools that automatically check how well a dataset follows FAIR, F-UJI, FAIR Evaluator, and FAIR Checker are the three big ones. You give them a dataset, they give you a compliance score.

Here is the question nobody had really answered before: if you run the same dataset through all three tools, do they agree?

Spoiler, they do not

I took datasets from Zenodo and DataCite and ran them through all three validators. Same dataset, same moment, three different tools claiming to measure the same thing.

On one climate science dataset, the overall scores came out like this:

F-UJI: 65%
FAIR Checker: 51%
FAIR Evaluator: 57%

A 14 point gap on the exact same dataset. That is not a rounding error, that is three tools genuinely disagreeing about whether the same data is FAIR.

Why? It comes down to vague words

This was the part that actually surprised me. I expected the disagreement to be random, like the tools just had bugs or different implementations. It was not random at all.

The FAIR specification uses words like formal, clear, and accessible, but never defines them precisely. So every tool that implements a validator has to make its own engineering decision about what those words mean. All of them are reasonable. All of them are different.

Look at how differently the tools interpreted a rule that just says a dataset needs a formal knowledge language:

F-UJI checks for JSON-LD or Schema.org in the metadata
FAIR Checker requires a registered OWL or RDF ontology URI
FAIR Evaluator just checks if any structured vocabulary is referenced at all

Three completely different technical checks, all built from the same vague sentence.

Compare that to a rule that is actually specific, like requiring a unique identifier. A DOI either resolves or it does not. All three tools agreed perfectly there, zero gap.

So the pattern became clear pretty fast: vague rules produce big disagreements, specific rules produce none.

Finding exactly where the gaps live

Once I saw the pattern, I wanted to pin down precisely which sub-principles were causing the disagreement, not just say "some things are inconsistent."

Three sub-principles kept showing up with the highest gaps, every single time:

I1, whether the dataset uses a formal knowledge language, gap of 0.3
R1.1, whether the dataset has a clear usage license, gap of 0.4
A2, whether metadata persists and stays accessible, gap of 0.3

Meanwhile things like unique identifiers and basic HTTP accessibility stayed at zero gap across all three tools, every time. The disagreement was not scattered randomly across all 15 sub-principles, it was concentrated in exactly the ones with the vaguest wording.

Can you actually fix this?

This was the part I found most satisfying. If the disagreement comes from vague metadata, then maybe better metadata closes the gap, regardless of which tool is checking it.

So I built what I called a Minimum Metadata Profile, a small, specific set of fields designed to satisfy the strictest interpretation of each rule:

A DOI that actually resolves over HTTP
Title and description in plain text
A machine readable license URI, not just a license name
An OWL or RDF ontology URI, using something standard like Dublin Core
An ORCID for the author, plus a related work DOI
Proper DataCite metadata registration

Then I ran the experiment. Took a dataset with no profile applied, ran all three validators, recorded the scores. Applied the profile, uploaded it to Zenodo again, ran all three validators on the improved version.

Every score went up. And more importantly, the gap between the tools shrank significantly. Writing metadata well enough to satisfy the strictest tool ended up satisfying the more lenient ones automatically.

What this actually means, practically

If you are a researcher or data manager wondering which FAIR score to trust, the honest answer is that the score itself is less important than understanding why it differs. The disagreement is not a bug in any one tool, it is a structural problem with how the FAIR principles are written.

The practical takeaway I landed on: do not just chase a score from one validator. Build metadata that satisfies the strictest possible interpretation of each rule, and the scores across every tool tend to converge.

What is next

The bigger fix has to happen at the specification level, not the tool level. My recommendation, and something worth pushing for through groups like the Research Data Alliance, is a unified technical definition for the vague sub-principles, so validators stop having to guess what "formal" or "clear" actually means. Until that happens, every validator will keep making its own reasonable, and different, engineering decision.

Why I am sharing this here

This was research work, but the core lesson felt very familiar to anything in software: specifications that use natural language instead of precise technical definitions will always get implemented inconsistently. I have seen smaller versions of this exact problem in API docs, in style guides, in "should be self explanatory" requirements at work. Vague words always eventually produce disagreement, whether it is three FAIR validators or three developers on the same team.

Simple Practices to Optimize Angular Applications

SAVITA WADJE — Fri, 04 Sep 2026 11:44:01 +0000

Angular apps can slow down quietly as they grow, more components, more data, more subscriptions nobody remembers to clean up. None of the fixes below are advanced tricks, just habits that make a real difference once you apply them consistently.

1. Use OnPush change detection

By default, Angular checks every component on every change detection cycle, even ones that have not actually changed. Switching to OnPush tells Angular to only re-check a component when its inputs change or an event fires inside it.

@Component({
  selector: "app-user-card",
  changeDetection: ChangeDetectionStrategy.OnPush,
  templateUrl: "./user-card.component.html",
})
export class UserCardComponent {
  @Input() user: User;
}

This alone can meaningfully cut down unnecessary checks in larger apps, especially ones with deep component trees.

2. Unsubscribe from observables properly

Forgetting to unsubscribe is one of the most common sources of memory leaks in Angular apps. Subscriptions that outlive their component keep doing work in the background long after the component is gone.

private destroy$ = new Subject<void>();

ngOnInit() {
  this.userService.getUser()
    .pipe(takeUntil(this.destroy$))
    .subscribe(user => this.user = user);
}

ngOnDestroy() {
  this.destroy$.next();
  this.destroy$.complete();
}

The async pipe in templates is even better when possible, it subscribes and unsubscribes automatically.

<div *ngIf="user$ | async as user">
  {{ user.name }}
</div>

3. Use trackBy with ngFor

Without trackBy, Angular re-renders the entire list whenever the underlying array reference changes, even if most items stayed the same. trackBy tells Angular how to identify individual items, so it only updates what actually changed.

trackByUserId(index: number, user: User): number {
  return user.id;
}

<div *ngFor="let user of users; trackBy: trackByUserId">
  {{ user.name }}
</div>

Small change, noticeable difference on any list that updates frequently.

4. Lazy load feature modules

Loading the entire app upfront means users wait for code they might not even use in that session. Lazy loading splits your app into chunks that load only when needed.

const routes: Routes = [
  {
    path: "admin",
    loadChildren: () =>
      import("./admin/admin.module").then((m) => m.AdminModule),
  },
];

This keeps your initial bundle smaller, which directly improves first load time.

5. Avoid function calls in templates

Calling a function directly in a template runs it on every single change detection cycle, not just when its inputs actually change.

<!-- Runs on every change detection cycle -->
<div>{{ calculateTotal() }}</div>

<!-- Calculated once, only recalculates when dependencies change -->
<div>{{ total }}</div>

If a value needs computing, calculate it once in the component class (or with a pure pipe) instead of calling a function straight from the template.

6. Use pure pipes for transformations

Pipes marked as pure only re-run when their input reference changes, unlike template function calls, which run constantly.

@Pipe({
  name: "formatCurrency",
  pure: true,
})
export class FormatCurrencyPipe implements PipeTransform {
  transform(value: number): string {
    return `$${value.toFixed(2)}`;
  }
}

<div>{{ price | formatCurrency }}</div>

Same result as a template function, far less repeated work.

7. Virtual scroll for long lists

Rendering hundreds or thousands of DOM elements at once, even off screen, is expensive. Angular CDK's virtual scroll only renders what is actually visible in the viewport.

html
<cdk-virtual-scroll-viewport itemSize="50" class="viewport">
  <div *cdkVirtualFor="let item of items">{{ item.name }}</div>
</cdk-virtual-scroll-viewport>

Makes a real difference on any list that can realistically grow large, like search results or activity feeds.

What actually matters most

If I had to pick just two to start with: OnPush change detection and properly unsubscribing from observables. Those two alone catch a large chunk of the performance issues I have run into in real Angular apps, the rest are worth adding as the app grows.

Curious what other practices people rely on, especially anything specific to newer Angular features like signals, that changes some of this.

Bootstrap vs Tailwind CSS: How I Decide Which One to Use

SAVITA WADJE — Fri, 04 Sep 2026 11:33:21 +0000

"Bootstrap or Tailwind, which one is better?" is a question I used to have a strong opinion about. Now I think it depends entirely on the project. Here is how I actually decide.

The core difference

Bootstrap gives you pre-built components: buttons, navbars, cards, modals, already styled and ready to drop in. Tailwind gives you utility classes: small, single-purpose classes you combine yourself to build your own design.

<!-- Bootstrap: pre-styled component -->
<button class="btn btn-primary">Submit</button>

<!-- Tailwind: build the style yourself -->
<button class="px-4 py-2 bg-blue-600 text-white rounded-md hover:bg-blue-700">
  Submit
</button>

Same button, completely different philosophy behind getting there.

When I reach for Bootstrap

Fast prototypes and internal tools. If I need something functional and reasonably clean quickly, not necessarily unique looking, Bootstrap gets me there fast. Admin panels, internal dashboards, quick MVPs.

Teams without a dedicated designer. Bootstrap's components already look decent out of the box, which matters when there is no design system or designer to define one.

Projects where consistency matters more than uniqueness. Bootstrap enforces a certain look and feel by default, which can be a feature, not a limitation, for internal tools where every screen should feel the same without much effort.

When I reach for Tailwind

Custom designs that need to look distinct. If the project has real design requirements, a specific brand feel, custom spacing, unique components, Tailwind gets out of the way instead of fighting against Bootstrap's defaults.

Projects that will grow and change a lot. Overriding Bootstrap's default styles gets messy over time, lots of !important, custom overrides stacked on top of the framework's own CSS. Tailwind avoids that problem because you are not overriding anything, you are just composing utilities.

When bundle size and unused CSS matter. Tailwind purges unused styles in production, so your final CSS only includes what you actually used. Bootstrap ships more CSS by default, even for components you never touch.

The trade-off nobody mentions enough

Bootstrap is fast to start with and slower to customize. Tailwind is slower to start with (more decisions up front) and faster to customize later. Neither is free, the cost just shows up at a different point in the project.

<!-- Overriding Bootstrap's default button padding -->
<button class="btn btn-primary" style="padding: 10px 20px;">
  Submit
</button>

<!-- Tailwind, same customization, no override needed -->
<button class="px-5 py-2.5 bg-blue-600 text-white rounded-md">
  Submit
</button>

With Bootstrap, customization often means fighting the framework. With Tailwind, customization is just part of how you already write every class.

My rule of thumb
Internal tool, quick prototype, no designer involved → Bootstrap
Custom product, brand-specific design, long-term project → Tailwind
Team already knows one well → stick with it, familiarity usually beats theoretical advantages

What I actually use most these days

I lean Tailwind for most client and product work now, mainly because customization pain shows up early with Bootstrap and I would rather deal with the utility class learning curve upfront than fight overrides six months in. But I still reach for Bootstrap without hesitation for quick internal tools where speed matters more than uniqueness.

Curious where others land on this, especially if you have used both on projects of a similar size. Would love to hear a different take in the comments.

Building JobFit AI, an AI Resume Matcher with the MERN Stack

SAVITA WADJE — Fri, 21 Aug 2026 15:19:39 +0000

Job hunting means rewriting the same resume bullet points for every posting and guessing whether you're even a good match. So I built JobFit AI: paste your resume and a job description, and it scores the match, tells you what's missing, and rewrites bullet points to fit the role, powered by the Gemini API, with your history tracked over time.

Here's how it's built, how it works, and how it might help you if you're job hunting too.

The problem I was solving

Every job application starts the same way. Copy the resume, tweak a few lines, guess if the keywords match what the recruiter is looking for, submit, repeat. I was doing this manually dozens of times and had no real way to know if my resume actually matched a posting or just felt like it did.

That is basically the whole reason JobFit AI exists.

Tech stack

Frontend: React 19 + Vite, React Router, Tailwind CSS v4
Backend: Node.js + Express, MongoDB with Mongoose
Auth: JWT + bcrypt, email/password, own database
AI: Google Gemini API (free tier)

Architecture

Three layers, kept deliberately separate:
1. Client (React)
Handles the resume/job description input, displays the match score and suggestions, and manages auth state. Kept as dumb as possible, all the real logic lives in the backend.

2. API layer (Express)
Handles auth, request validation, and talks to both MongoDB and the Gemini API. Each route is scoped tightly, one endpoint to submit a match request, one to fetch history, one to handle auth.

3. Data layer (MongoDB + Mongoose)
Stores user accounts and a history of every resume/job match a user has run, so they can go back and compare results over time instead of losing them after one session.

// simplified match route
router.post("/match", authMiddleware, async (req, res) => {
  const { resumeText, jobDescription } = req.body;

  const prompt = buildPrompt(resumeText, jobDescription);
  const aiResponse = await geminiClient.generateContent(prompt);

  const result = parseMatchResult(aiResponse);

  await MatchHistory.create({
    userId: req.user.id,
    resumeText,
    jobDescription,
    score: result.score,
    suggestions: result.suggestions,
  });

  res.json(result);
});

How the matching actually works

The core of the app is a single prompt sent to Gemini that asks it to compare the resume against the job description and return three things: a match score, a list of missing skills or keywords, and rewritten bullet points that better align with the role.

function buildPrompt(resumeText, jobDescription) {
  return `
    Compare this resume against the job description below.
    Return a match score out of 100, a list of missing keywords,
    and 3 rewritten resume bullet points tailored to this job.

    Resume:
    ${resumeText}

    Job Description:
    ${jobDescription}
  `;
}

The tricky part was not the prompt itself, it was getting Gemini to return something consistently structured that I could reliably parse into the UI, instead of a wall of freeform text.

Challenges I ran into

Structuring AI output reliably. Free-text responses looked fine but broke my UI whenever the format shifted slightly. I ended up being very explicit in the prompt about the exact structure I wanted back.
Rate limits on the free tier. Had to add basic request throttling on my end so users could not spam the match endpoint and burn through the quota.
Keeping history without bloating the database. Storing every resume and job description per request adds up fast, so I trimmed what gets stored long term versus what is just used for the immediate response.

What's next

Better diffing between resume versions over time
Exporting rewritten bullet points directly into a formatted resume
Support for multiple resume profiles per user

Try it / see the code
🔗

Angular vs React: How I Decide Which to Use for a New Project

SAVITA WADJE — Thu, 20 Aug 2026 15:15:22 +0000

The wrong question

"Angular vs React, which is better?" is the wrong question. Both are mature, well-supported, and can build the same things. The better question is: which one fits this specific project, team, and timeline? Here's how I actually think about it.

When I reach for Angular

Large, long-lived enterprise apps -Angular's opinionated structure (modules, services, DI) pays off when a team of 10+ devs needs consistency over years, not just weeks.
Teams that want batteries included - routing, forms, HTTP client, and testing tools all come built-in. Less time spent choosing libraries, more time building.
TypeScript-first teams - Angular is TypeScript by default, so if your team already thinks in strict typing, it feels native rather than bolted on.

When I reach for React

Fast-moving products, startups, MVPs React's flexibility means you can ship quickly without committing to a rigid structure upfront.
Teams that want to pick their own stack state management, routing, styling React lets you choose (Redux vs Zustand, React Router, Tailwind vs CSS-in-JS), which is powerful if your team has strong opinions.
Hiring pool matters - React's ecosystem is larger, so if you're scaling a team fast, there's usually a deeper talent pool to pull from.

The trade-off nobody talks about enough

Angular's structure feels restrictive early on but saves you from "a thousand ways to do the same thing" chaos later. React's flexibility feels great early on but can turn into inconsistency across a codebase if the team doesn't agree on conventions upfront.

In other words: Angular front-loads discipline. React front-loads speed and asks you to add discipline yourself, later.

My rule of thumb

Enterprise app, long timeline, larger team → Angular
MVP, startup, small team, need to move fast → React
Not sure? Default to whichever your team already knows well — consistency beats "the better tool" almost every time.
What's your experience?

I'd love to hear how others make this call, especially if you've switched from one to the other mid-project. Drop your take in the comments.