DEV Community: Sebastian Wrzalek

AI Helps Us Write Code Faster. So Why Aren’t Projects Moving Faster?

Sebastian Wrzalek — Sat, 27 Jun 2026 08:40:00 +0000

We can generate code faster than ever.

Features that once took several days can now be implemented in a few hours. Boilerplate disappears almost instantly. Tests, migrations, API clients, and entire components can be produced before we have finished describing the task.

On paper, software teams should be moving at an incredible speed.

But that is often not what happens.

The code is produced faster, yet the project itself does not feel much faster. Pull requests become larger. Reviews take longer. Debugging becomes less predictable. Engineers spend more time trying to understand changes they did not write.

Anyone who has used coding agents in a real business environment has probably noticed this contradiction:

AI accelerates code generation, but it does not automatically accelerate software development.

In many teams, code review is already becoming the new bottleneck. Adding another AI agent to review the output may help catch local issues, but it does not solve the deeper problem.

The problem is not necessarily the quality of the generated code.

The problem is that our ability to understand the system is no longer keeping up with our ability to change it.

A recent paper by Margaret-Anne Storey gave me a useful framework for thinking about this. It describes software health through three connected forms of debt: technical debt, cognitive debt, and intent debt.

Together, they form the Triple Debt Model.

Technical Debt Is Only One Part of the Problem

Most developers are already familiar with technical debt.

We introduce a workaround because a deadline is approaching. We duplicate some logic because extracting the correct abstraction would take longer. We leave a poorly designed module in place because replacing it would be risky.

The decision helps us move faster today, but makes future changes more expensive.

The Triple Debt Model argues that technical debt is only one dimension of software health.

There are two other forms of debt that become especially important when AI generates a growing percentage of the code.

Technical debt lives in the code

Technical debt is the structural mess we already know how to identify:

duplicated logic,
unclear abstractions,
tightly coupled modules,
missing tests,
outdated dependencies,
temporary solutions that became permanent.

It makes the system harder to modify, but it is usually visible.

We can inspect it. Static-analysis tools can detect parts of it. Tests can expose it. Refactoring can reduce it.

AI is also reasonably good at helping with this type of debt. It can find duplication, suggest cleaner abstractions, add tests, and refactor repetitive code.

Unfortunately, clean code does not guarantee a healthy project.

Cognitive debt lives in people

Cognitive debt accumulates when the team’s understanding of the system erodes.

The application may still work. The code may even look clean. However, fewer people can confidently explain how the important parts fit together.

This can happen naturally as a system grows, but AI can accelerate it.

An agent can generate several hundred lines of code in a few minutes. A developer can verify that the tests pass, scan the implementation, and approve the change.

What may never happen is the slower process of building a mental model:

Why was this approach chosen?
Which assumptions does it rely on?
What other parts of the system depend on it?
What would make this design stop working?
Which alternatives were considered?

The code enters the repository, but the corresponding understanding never fully enters the team.

Do this repeatedly and the project slowly becomes something that engineers operate without truly understanding.

Intent debt lives in artifacts

Intent debt appears when the reasoning behind a system is not recorded.

The code shows us what the system does today. It rarely tells us what the team originally intended, which constraints shaped the design, or which outcomes must be preserved.

For example, imagine finding an unusual caching mechanism in a critical module.

Is it there because of a previous production incident? Is it protecting an external API with strict rate limits? Is it compensating for a temporary infrastructure limitation? Or is it simply an old implementation that nobody removed?

Without the original context, both humans and AI agents are forced to guess.

That missing context is intent debt.

It can live in many places:

undocumented architectural decisions,
incomplete requirements,
outdated tickets,
missing domain explanations,
pull requests that describe what changed but not why,
comments that explain implementation details without explaining constraints.

Intent debt has always existed. The difference is that agents now make decisions at a speed and scale that greatly increases the cost of missing intent.

AI Changes the Kind of Debt We Accumulate

Before AI-assisted development, producing code required a significant amount of human effort.

That effort was not always efficient, but it forced developers to spend time thinking about the system. While implementing a feature, we naturally built some understanding of the surrounding modules, dependencies, and constraints.

Coding agents remove part of that friction.

That is useful, but some of the removed friction was also where learning happened.

A developer can now describe a task, review the output, run the tests, and merge the result without ever constructing a complete mental model of the implementation.

The team appears to be moving faster because more code reaches production.

At the same time, cognitive and intent debt may be accumulating underneath that velocity.

This creates a dangerous trade:

We reduce the cost of producing code while increasing the cost of understanding and safely changing it later.

At first, the trade looks extremely profitable. Features ship faster and backlogs shrink.

The cost appears later, when the system needs to be debugged, extended, migrated, or redesigned.

How Development Velocity Starts to Collapse

The slowdown rarely happens through one dramatic failure.

It usually appears through small changes in team behaviour.

Developers stop deeply reviewing generated code

Reading code is difficult.

Reading a large amount of code that you did not write is even more difficult. When AI produces changes continuously, reviewers eventually begin to focus on surface-level signals:

Does the implementation look reasonable?
Are the tests passing?
Are there any obvious security problems?
Does the pull request solve the requested task?

These are useful checks, but they are not the same as understanding the change.

Over time, reviewers may stop asking whether the implementation fits the deeper design of the system. Authors may also struggle to explain the code because they guided its generation rather than constructing it themselves.

The pull request is approved, but no one has fully absorbed the new behaviour.

Agents optimize for the wrong objective

An advanced coding agent needs more than access to the repository.

It needs to understand the goal of the system and the constraints that shaped it.

Suppose an agent discovers two services performing similar work. From the code alone, merging them may look like an obvious improvement.

What the agent may not know is that the services were intentionally separated because they have different security boundaries, deployment schedules, ownership models, or regulatory requirements.

Without that context, the agent can produce a technically elegant solution that is completely wrong for the business.

This is where intent debt becomes particularly dangerous.

Agents are very capable of optimizing the implementation they can see. They are much less reliable when the real objective was never recorded.

Code review turns into an investigation

As shared understanding disappears, code review changes.

Instead of discussing whether a solution is appropriate, reviewers first have to reconstruct how the relevant part of the system works.

A seemingly simple pull request leads to questions such as:

Why does this module depend on that service?
Is this behaviour intentional?
Who owns this workflow?
Will changing this break another customer path?
Why was the existing implementation designed this way?

The review takes longer, but the answers remain uncertain.

Eventually, the safest response becomes: “Let’s not change it yet.”

That is the moment when a productive codebase starts becoming a fragile one.

Warning Signs of Cognitive and Intent Debt

Unlike a failing test, cognitive debt does not produce a clear error message.

You have to look for it in the way the team works.

Engineers avoid particular modules

Every mature project has difficult areas.

The stronger warning sign is when developers avoid a module not because the code is obviously bad, but because nobody knows what might break.

The module has become a black box. Changes are delayed, wrapped in additional conditions, or assigned only to the one person believed to understand it.

Important knowledge exists in one or two people

A project becomes fragile when critical design decisions exist only in someone’s memory.

You may hear phrases such as:

“Ask Anna; she built that part.”
“I think Mark knows why this works that way.”
“We should wait until they are back from holiday.”

This is not only a staffing risk. It is evidence that the system’s intent has not been externalized.

Pull requests take longer to review

Large AI-generated pull requests can look complete while being difficult to reason about.

Review comments become vague:

“This seems fine.”
“I think this should work.”
“The tests are green.”
“Let’s monitor it after deployment.”

When both the author and reviewer are uncertain, review becomes a ceremony rather than a transfer of understanding.

Small architectural changes cause unexpected side effects

A team with a strong mental model can usually predict the approximate impact of a change.

When simple modifications regularly break unrelated functionality, it suggests that the actual dependency structure is no longer understood.

The problem may involve technical debt, but repeated surprise is also a strong signal of cognitive debt.

Automated AI Review Will Not Fix This

It is tempting to respond by adding another agent.

One agent writes the code. Another reviews it. Perhaps a third checks the architecture and generates documentation.

These tools can help, but they do not automatically restore shared understanding.

An AI reviewer can identify a potential race condition or missing validation. It cannot recover a business constraint that was never documented. It cannot guarantee that the engineering team understands the resulting design.

The risk is that we create a closed loop in which agents produce, review, explain, and approve changes while humans supervise the process from an increasing distance.

The pipeline may look efficient.

The team’s ability to reason about the system may still be declining.

Understanding Has to Become a Deliverable

For years, software teams have treated code as the main output of development.

In an AI-assisted environment, that is no longer enough.

Every meaningful change should also preserve or improve the team’s understanding of the system.

That does not mean documenting every line of code. It means recording the information that cannot be reliably reconstructed from the implementation:

why a solution was selected,
which constraints influenced it,
which alternatives were rejected,
what assumptions must remain true,
which business outcome the implementation protects,
what future developers and agents should avoid changing.

Pull requests should not only prove that the code works. They should make the intent of the change visible.

Architecture Decision Records, focused design notes, meaningful test names, short diagrams, and clear pull-request descriptions become more valuable—not less—when agents are involved.

The goal is not to slow development down for the sake of process.

The goal is to prevent short-term coding speed from destroying long-term development speed.

Final Words

AI is changing the economics of software development.

Producing code is becoming cheaper. Understanding code is not.

That difference explains why teams can generate more code without seeing the same improvement in overall project efficiency.

Technical debt still matters, but it is no longer the full picture. A codebase can be clean and well-tested while the team has lost the knowledge required to change it safely. It can contain detailed implementation documentation while still missing the reasons behind its most important decisions.

Today, high cognitive debt may feel like a small drag on the engineering team.

Tomorrow, it can become a system that nobody feels safe modifying.

The teams that benefit most from AI will not simply be the ones that generate the most code. They will be the ones that find a way to generate code without losing their understanding of what they are building and why.

In the next articles, I plan to explore practical frameworks and engineering processes that can help teams reduce cognitive and intent debt while still taking advantage of AI-assisted development.

Stop Making These 5 Common Vue Mistakes!

Sebastian Wrzalek — Fri, 27 Jun 2025 22:12:38 +0000

1. Treating Everything as Reactive

Vue's ref is an excellent way to manage reactive state, but not everything should be reactive. When using Vue, developers often mistakenly treat all variables as reactive. For values that will remain static and never change, define them using const. Reserve ref or reactive exclusively for state that truly needs to update the view.

Incorrect:

const createdBy = ref('JohnDoe'); // If username never changes, this is unnecessary.

Correct:

const createdBy = 'JohnDoe';

2. Using `watch()` Without Understanding State Flow

It's easy to misuse watchers (watch()) when you don’t fully grasp how your application's data flow works. Watchers can create hidden side-effects and subtle race conditions if logic is scattered and improperly managed.

❌

const comments = ref([]);
const article = ref({});

fetchArticle().then((data) => article.value = data.article);

watch(article, () => {
  fetchComments(article.value.id).then((data) => { comments.value = data.comments });
});

✅

const comments = ref([]);
const article = ref({});

const fetchArticleAndComments = async () => {
  const { article: articleData } = await fetchArticle();
  article.value = articleData;

  const { comments: commentsData } = await fetchComments(articleData.id);
  comments.value = commentsData;
};

fetchArticleAndComments();

Use watchers only as escape hatches, not as the default approach.

3. Using `v-if` Where `v-show` Fits

Many Vue developers use v-if unnecessarily. v-if mounts and destroys elements or components, making it ideal for one-time, conditional rendering. However, frequent toggles should use v-show, as it simply toggles CSS display, making it much more efficient.

Use v-show when:

Elements toggle frequently.
The cost of mounting/destroying elements repeatedly is high.

❌

<div v-if="isVisible">Toggle me frequently!</div>

✅

<div v-show="isVisible">Toggle me frequently!</div>

4. Computed Properties Mutating State

Computed properties in Vue should always be pure and free from side effects. A common subtle mistake is directly mutating state within computed properties, especially with array methods like reverse() or sort().

❌

  const reversedNumbers = computed(() => numbers.reverse()) // This mutates the original array!

✅

  const reversedNumbers = computed(() => [...numbers].reverse()) // Creates a new array, maintaining purity

5. Overusing Pinia/Vuex Store

State management libraries like Pinia or Vuex are powerful, but it's important not to overuse them. As Dan Abramov says, "Flux libraries are like glasses: you'll know when you need them."

Initially, manage state with props, emits, and local state. Consider using a store when you have deeply nested components or need shared state across multiple component branches. Excessive reliance on stores can lead to unintended complexity and side effects.

Guidelines for using a store wisely:

Use local state or component props/emits first.
Consider a store when dealing with shared state across unrelated components.
Avoid overloading the store with local, component-specific state.
Avoid circular dependencies - store A in store B and store B in store A

Thanks for reading

If you liked it leave some ❤️

Building a Microfrontend Architecture with Vue 3, Vite, Single-SPA

Sebastian Wrzalek — Sun, 02 Mar 2025 15:05:01 +0000

Microfrontends with Vue 3, Vite, and Single-SPA

Microfrontends have become a popular approach for scaling frontend applications, especially in environments where multiple teams work on various parts of the app independently. In this guide, we'll explore how to build a simple microfrontend application using Vue 3, Vite, Single-SPA, and vite-plugin-single-spa.

Introduction to Microfrontends
Understanding Single-SPA Framework
Demo Project
Prerequisites
Creating the Secondary (Microfrontend) Application
Configuring the Secondary App
Handling Different Bundle Locations
Registering the Microfrontend in the Root Project
Testing the Setup
The Problem
The Second Problem
Final Words

Introduction to Microfrontends

"The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specializes in. A team is cross-functional and develops its features end-to-end, from database to user interface."

Microfrontends are an architectural approach that extends the concept of microservices to the frontend. Instead of building a single monolithic frontend application, the app is divided into smaller, manageable pieces called microfrontends. Each microfrontend is a self-contained application with its own codebase, framework, and deployment pipeline.

Benefits of Microfrontends:

Scalability – Multiple teams can work independently on different features.
Flexibility – Each microfrontend can use its own tech stack.
Resilience – Failures in one microfrontend don’t affect others.

Understanding Single-SPA Framework

Single-SPA is a framework that allows multiple microfrontends, potentially using different frameworks (e.g., Vue, React), to coexist and operate within the same application. It manages the lifecycle of each microfrontend, enabling them to load and unload dynamically based on routing configurations.

Single-SPA Components:

Root Configuration – Responsible for rendering the HTML page and registering applications. Each application is registered with:
- A name
- A function to load the application’s code
- A function to determine when the application is active or inactive
Applications – Microfrontends functioning as SPAs packaged into modules. Each application must implement methods to bootstrap, mount, and unmount itself from the DOM.

Core Concepts of Single-SPA:

Application Registrations – Register each microfrontend as an application.
Lifecycle Methods – Each microfrontend has lifecycle methods (mount, unmount, etc.).
Routing – Single-SPA can load microfrontends based on URL paths.

Example:

A React or Vue SPA can be registered as an application. When active, it listens to URL routing events and renders content on the DOM; when inactive, it stops listening to routing events and is fully removed from the DOM.

Demo Project

In this article, we’ll build both the root application—responsible for orchestrating the mounting and unmounting of microfrontends—and a sample microfrontend for demonstration. Although the official recommendation discourages using a framework in the root configuration, this project uses a Vue application at the root to provide a consistent layout, global navigation, and cohesive styling across all microfrontends.

Prerequisites

Let’s create our root application. This project uses Vue as its framework:

npm create vue@latest

✔ Project name: … root
✔ Add TypeScript? … Yes
✔ Add JSX Support? … No
✔ Add Vue Router for Single Page Application development? … Yes
✔ Add Pinia for state management? … No
✔ Add Vitest for Unit Testing? … No 
✔ Add an End-to-End Testing Solution? › No
✔ Add ESLint for code quality? …  Yes
✔ Add Prettier for code formatting? …  Yes
✔ Add Vue DevTools 7 extension for debugging? (experimental) … No

cd root
npm install
npm run format
npm run dev

After creating the root application, install the necessary dependencies:

npm install --save single-spa-vue vite-plugin-single-spa single-spa

Next, integrate vite-plugin-single-spa within your vite.config.ts:

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

// https://vite.dev/config/
export default defineConfig({
  plugins: [
    vue(), 
    vitePluginSingleSpa({ 
      type: 'root', 
      imo: '3.1.1' 
    })
  ],
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  }
})

Creating the Secondary (Microfrontend) Application

Before we configure the root application to load a microfrontend, let’s create another Vue app:

npm create vue@latest

✔ Project name: … app
✔ Add TypeScript? … Yes
✔ Add JSX Support? … No
✔ Add Vue Router for Single Page Application development? … Yes
✔ Add Pinia for state management? … No
✔ Add Vitest for Unit Testing? … No 
✔ Add an End-to-End Testing Solution? › No
✔ Add ESLint for code quality? …  Yes
✔ Add Prettier for code formatting? …  Yes
✔ Add Vue DevTools 7 extension for debugging? (experimental) … No

cd app

Install additional dependencies for this new app:

npm install --save single-spa-vue vite-plugin-single-spa

Below is the directory structure so far:

single-spa-demo
├── root
│   ├── src
│   ├── vite.config.ts
│   └── package.json
└── app
    ├── src
    ├── vite.config.ts
    └── package.json

Configuring the Secondary App

We must configure the Vite Single-SPA plugin so the Vue application outputs a microfrontend:

// ### app/vite.config.ts ###
import { fileURLToPath, URL } from 'node:url'
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import vitePluginSingleSpa from 'vite-plugin-single-spa'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    vue(),
    vitePluginSingleSpa({
      type: 'mife',
      serverPort: 4101,
      spaEntryPoints: 'src/main.ts',
    })
  ],
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  },
  // Ensure the dev server uses the same port as set in the plugin
  server: {
    port: 4101
  }
})

Here, vitePluginSingleSpa({ type: 'mife', serverPort: 4101 }) configures the plugin, identifying this build as a microfrontend and setting the development server to port 4101.

Main File Modifications

The microfrontend must know how to bootstrap, mount, and unmount itself from the DOM. Update main.ts accordingly:

// ### app/main.ts ###
import App from './App.vue'
import './assets/main.css'
import singleSpaVue from 'single-spa-vue'
import { createApp, h } from 'vue'
import router from './router'

const vueLifecycles = singleSpaVue({
  createApp,
  appOptions: {
    render() {
      return h(App, {
        props: {
          name: this.name,
        },
      });
    },
  },
  handleInstance: (app) => {
    app.use(router);
  },
});

const mountVue = () => {
  const app = createApp(App)
  app.use(router)
  app.mount('#app')
}

// Only mount the app in standard SPA mode during development
if (import.meta.env.MODE === 'development') {
  mountVue();
}

export const bootstrap = vueLifecycles.bootstrap;
export const mount = vueLifecycles.mount;
export const unmount = vueLifecycles.unmount;

Because Single-SPA handles mounting and unmounting, we cannot mount the application in production in the usual way. However, we still want to support standalone development, so we only mount if import.meta.env.MODE is development.

Below is an example of how to differentiate development modes in your package.json:

{
  "scripts": {
    "dev": "vite --mode development",
    "dev:sspa": "vite --mode staging"
  }
}

With these changes, the microfrontend is ready to be consumed by the root project.

Handling Different Bundle Locations

One challenge is that the microfrontend’s entry file (main.ts) is served at different URLs in development vs. production:

Development: http://localhost:4101/src/main.ts
Build: http://localhost:4101/main.js

We will address this discrepancy using native import maps. Within the root project, create two files for mapping these paths:

`root/src/importMap.dev.json`

{
  "imports": {
    "@howlydev/app": "http://localhost:4101/src/main.ts"
  }
}

`root/src/importMap.json`

{
  "imports": {
    "@howlydev/app": "http://localhost:4101/main.js"
  }
}

These files instruct the root application to resolve the microfrontend’s path differently based on environment.

Registering the Microfrontend in the Root Project

Create a file named single-spa.setup.ts in your root app:

// ### root/single-spa.setup.ts ###
import { registerApplication, start } from "single-spa"

const apps = {
  "app": "@howlydev/app"
}

export function registerSpas() {
  for (const [route, moduleName] of Object.entries(apps)) {
    registerApplication({
      name: route,
      app: () => import(/* @vite-ignore */ moduleName),
      activeWhen: `/${route}`,
    })
  }
  runSpas();
}

export function runSpas() {
  start();
}

registerApplication: Tells Single-SPA which application to load and on which route path.
start(): Initializes Single-SPA, enabling the lifecycle of registered applications.

Testing the Setup

Run both the root and microfrontend applications in separate terminals:

# In the root folder
npm run dev

# In the app folder
npm run dev:sspa

Open the URL for your root application (e.g., http://localhost:5173/). The microfrontend should be dynamically loaded and displayed when its route is accessed.

The Problem

When you navigate to the route that initializes the microfrontend, you may notice unexpected behavior: because both the root application and the microfrontend use Vue, there are two Vue instances running. Additionally, the microfrontend is not rendered within the router-view controlled by the root’s Vue Router.

Inspecting the DOM reveals that both the root and microfrontend instances are active, but the microfrontend content is appended directly to the body (or another top-level element) rather than where the root router expects it.

To fix this, you can leverage Vue’s Teleport feature to “teleport” the microfrontend’s content into a specified container within the root application:

<!-- ### app/App.vue ### -->
<template>
  <Teleport to=".container" :disabled="isTeleportDisabled">
    <div style="background-color: lightcoral">
      <h1>Hello From the Microfrontend</h1>
      <router-view />
      <ul>
        <li>
          <router-link to="/foo">Go to Foo</router-link>
        </li>
        <li>
          <router-link to="/bar">Go to Bar</router-link>
        </li>
      </ul>
    </div>
  </Teleport>
</template>

<script setup lang="ts">
const isTeleportDisabled = import.meta.env.MODE === 'development'
</script>

Meanwhile, in your root application, ensure there is a .container element available to receive this teleported content:

### root/App.vue ###
<template>
    <main>
      <div class="container">
        <router-view />
      </div>
    </main>
</template>

Here, the microfrontend’s content is rendered where you want it, and the teleport is disabled during standalone (development) mode so you can still see the microfrontend by itself.

The Second Problem

A common requirement is that each microfrontend can handle its own internal routing. In this example:

The root application doesn’t “know” about /app.
The microfrontend expects its base route to be /.

When you visit "/app", you might see a warning in the console:

[Vue Router warn]: No match found for location with path "/app"

Though you can’t fully suppress these warnings (see this Vue Router issue), you can enable routing in the microfrontend by changing the base path, we will go even further and pass it from root application:

### root/single-spa.setup.ts ###

export const apps = {  
  app : "@howlydev/app"  
}  

export function registerSpas() {  
  for (const [route, moduleName] of Object.entries(apps)) {  
    registerApplication({  
      name: route,  
      app: () => import(/* @vite-ignore */ moduleName),  
      activeWhen: `/${route}`,  
      customProps: {  
        basePath: `/${route}` /* <-- this is new */
  }  
    });  
  }  

  runSpas();  
}  

export function runSpas() {  
  start();  
}

Next we will pass our basePath to the router.

### app/src/main.ts ###

import App from './App.vue'  
import './assets/main.css'  
import singleSpaVue from 'single-spa-vue'  
import {createApp, h} from "vue";  
import router from './router'  

type Props = {  
  name: string,  
  basePath: string,  
}  

const vueLifecycles = singleSpaVue({  
  createApp,  
  appOptions: {  
    render() {  
      const { name, basePath } = this as unknown as Props;  
      return h(App, {  
        name: name,  
        basePath: basePath,  
      });  
    },  
  },  
  handleInstance: (app, props: Props) => {  
    app.use(router(props.basePath));  
  }  
});  

const mountVue = () => {  
  const app = createApp(App)  
  app.use(router())  
  app.mount('#app')  
}  

if (import.meta.env.MODE === 'development') {  
  mountVue();  
}  

export const bootstrap = vueLifecycles.bootstrap;  
export const mount = vueLifecycles.mount;  
export const unmount = vueLifecycles.unmount;

### app/src/router/index.ts ###

import { createRouter, createWebHistory } from 'vue-router'  
import FooView from "@/views/FooView.vue";  
import BarView from "@/views/BarView.vue";  

const router = (basePath = '/app') => createRouter({  
  history: createWebHistory(basePath),  
  routes: [  
        {  
          path: "/foo",  
          name: "foo",  
          component : FooView,  
        },  
        {  
          path: "/bar",  
          name: "bar",  
          component : BarView  
        }  
  ],  
})  

export default router

Our router is now a function that accepts basePath as an argument and returns Router instance that can be used by a Vue app.

Final Words

Microfrontends can be highly beneficial for large-scale applications, but they’re not always straightforward to implement. As shown here, multiple Vue instances and routing complexities can create unexpected issues. Despite these trade-offs (and alternatives such as vite-plugin-federation), microfrontend architecture is worth knowing about. You might ask: is it solving a real problem?

It depends.

If you need to build a simple Todo app, it’s probably overkill.
If you’re building a Cloud ERP, it might be worth exploring.

I’ll quote Uncle Bob here:

You should be able to structure your code in a clean, modular fashion within a monolith before considering distribution. If you cannot form clear boundaries in a single-process system, you are unlikely to succeed by splitting it into microservices.

The full GitHub repository can be found here:

https://github.com/swrzalek/vue3-vite-sspa-demo/tree/main

If you’d like to see a more complex, real-world microfrontend example, let me know in the comments!

If you found this article helpful, please leave a like! ❤️

How to deploy Nuxt 3 app to Netlify with Github Actions

Sebastian Wrzalek — Wed, 19 Apr 2023 23:04:57 +0000

Deploying a Nuxt 3 app to Netlify seems like a easy job. You can connect repository to Netlify site and it is automatically deployed when you pushed your changes to the origin branch.
Me in the other hand, prefer to have everything in one place, so I wanted to control my CI/CD from Github Actions. In this article I will show you how, let's go!

As you might not know Nuxt 3 works with Nitro (open engine powering Nuxt) so normally, the deployment to Netlify does not require any configuration. Nitro will auto-detect that you are in a Netlify build environment and build the correct version of your server. But our scenario is not normal so we need to take some additional steps.

Create empty project

Make sure you have installed yarn, npx (included by default with npm
v5.2+) or npm (v6.1+) and node with at least
16.x version installed

yarn create nuxt-app <project-name>

Inside of the nuxt.config.ts file change the preset to netlify

export default defineNuxtConfig({  
    nitro: {  
        preset: 'netlify'  
  },  
  ...
})

Create workflow configuration

mkdir -p .github/workflows && touch .github/workflows/main.yml

Here is the inside of main.yml file

name: 'My Workflow'  

on:  
  push:  
    branches:  
    - main  

jobs:  
  deploy:  
    # Operating system to run job on  
  runs-on: ubuntu-latest  

    # Steps in job  
  steps:  
      # Get code from repo  
  - name: Checkout code  
        uses: actions/checkout@v1  
      # Install NodeJS  
  - name: Use Node.js 16.x  
        uses: actions/setup-node@v1  
        with:  
          node-version: 16.10.0  
      # Run npm install and build on our code  
  - run: npm install  
      - run: npm run build  
      # Deploy to Netlify using our dev secrets  
  - name: Deploy to netlify  
        uses: netlify/actions/cli@master  
        env:  
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_TOKEN }}  
          NETLIFY_SITE_ID:  ${{ secrets.SITE_ID }} 
        with:  
          args: deploy

Next we need to add secrets to our repository settings, you can find it here
https://github.com/{GITHUB_USERNAME}/{REPOSITORY_NAME}/settings/secrets/actions

Obtain a token in the Netlify UI

You can generate an access token manually in your Netlify user settings for Personal access tokens.

Under Personal access tokens, select New access token.
Enter a description.
Select Generate token.
Copy the generated token to your clipboard. Once you navigate from the page, the token cannot be seen again.
Save the token as a NETLIFY_AUTH_TOKEN environment variable in your terminal settings or in the UI of a Continuous Integration (CI) tool.

Obtaining Site ID

On your Netlify account

Go to Site settings > General > Site details > Site information, and copy the value for Site ID.

Push Your Code

Make sure you have pushed your code to the main branch, this way you will trigger Github Workflow and deploy your app to the world.

Three Concepts you need to know as Senior Software Engineer

Sebastian Wrzalek — Wed, 19 Apr 2023 17:16:07 +0000

As a software engineer, you have likely amassed a great deal of technical knowledge and experience in your field. However, there are certain key concepts that are worth knowing. In this article, we will discuss three concepts that every experienced engineer should be familiar with in order to stay ahead of the game.

Cohesion

In programming, cohesion refers to the degree to which the elements of a module or a software component work together to achieve a single, well-defined purpose or function. In other words, it's a measure of how closely related the parts of a module are to each other.

High cohesion means that the elements within a module are highly related and work together closely to achieve a specific task or function. Low cohesion, on the other hand, means that the elements within a module are loosely related and may not work together efficiently to achieve a specific purpose.
High cohesion is generally considered desirable because it leads to more maintainable and reusable code. It makes it easier to understand and modify a module without affecting the rest of the program. On the other hand, low cohesion can lead to code that is difficult to understand, modify, and maintain, which can result in bugs, errors, and inefficiencies.
Sound great but how to achieve high cohesion and low coupling?

Single Responsibility Principle (SRP): Each class or module should have only one responsibility.
Interface Segregation Principle (ISP): Interfaces should be designed to be as small as possible, with only the methods that are necessary for the implementation of the interface.
Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules, but both should depend on abstractions.

Cognitive Complexity

Cognitive complexity is a measure of the difficulty of understanding and reasoning about a piece of code. It takes into account the number of distinct paths through the code, the nesting depth of control structures, and the number of logical operators and operands.

A higher cognitive complexity indicates that the code is more difficult to understand and reason about, which can lead to more bugs, slower development time, and more difficult maintenance.
Code with a low cognitive complexity, on the other hand, is easier to read and understand, which can lead to more efficient development and maintenance.
To make code less complex and easy to read apply Clean Code practice, you can find them for every programming languages, here for Javascript.

Design Patterns

Design patterns are reusable solutions to commonly occurring problems in software design. They are general solutions that can be applied to different situations in software development, making the design and development process more efficient and effective.

Design patterns provide a common vocabulary and a set of best practices for software designers and developers. They help to ensure that software is maintainable, flexible, and extensible, and that it meets the needs of its users.
Design patterns can be used in a variety of programming languages and environments, including object-oriented programming, functional programming, and web development. They are widely used in software development and are an important tool for creating high-quality, maintainable, and reusable software.
If you want to learn more about design patterns I highly recommend checking out Refactoring Guru, they provide great examples and graphics that help you understand it quicker.

DEV Community: Sebastian Wrzalek

AI Helps Us Write Code Faster. So Why Aren’t Projects Moving Faster?

Technical Debt Is Only One Part of the Problem

Technical debt lives in the code

Cognitive debt lives in people

Intent debt lives in artifacts

AI Changes the Kind of Debt We Accumulate

How Development Velocity Starts to Collapse

Developers stop deeply reviewing generated code

Agents optimize for the wrong objective

Code review turns into an investigation

Warning Signs of Cognitive and Intent Debt

Engineers avoid particular modules

Important knowledge exists in one or two people

Pull requests take longer to review

Small architectural changes cause unexpected side effects

Automated AI Review Will Not Fix This

Understanding Has to Become a Deliverable

Final Words

Stop Making These 5 Common Vue Mistakes!

1. Treating Everything as Reactive

2. Using watch() Without Understanding State Flow

3. Using v-if Where v-show Fits

4. Computed Properties Mutating State

5. Overusing Pinia/Vuex Store

Thanks for reading

Building a Microfrontend Architecture with Vue 3, Vite, Single-SPA

Microfrontends with Vue 3, Vite, and Single-SPA

Table of Contents

Introduction to Microfrontends

Benefits of Microfrontends:

Understanding Single-SPA Framework

Single-SPA Components:

Core Concepts of Single-SPA:

Example:

Demo Project

Prerequisites

Creating the Secondary (Microfrontend) Application

Configuring the Secondary App

Main File Modifications

Handling Different Bundle Locations

root/src/importMap.dev.json

root/src/importMap.json

Registering the Microfrontend in the Root Project

Testing the Setup

The Problem

The Second Problem

Final Words

How to deploy Nuxt 3 app to Netlify with Github Actions

Create empty project

Create workflow configuration

Obtain a token in the Netlify UI

Obtaining Site ID

Push Your Code

Three Concepts you need to know as Senior Software Engineer

Cohesion

Cognitive Complexity

Design Patterns

2. Using `watch()` Without Understanding State Flow

3. Using `v-if` Where `v-show` Fits

`root/src/importMap.dev.json`

`root/src/importMap.json`