DEV Community: Scott Molinari

The Ball and Chain: Why Git is an Anti-Pattern for AI-Native Engineering

Scott Molinari — Sat, 07 Feb 2026 11:10:40 +0000

In our previous discussions on The Human-Centric AI-Native Distributed Systems Manifesto and Intent Driven Development (IDD), we established a clear vision: the future of software belongs to Architects of Intent, not laborers of syntax.

But there is a problem. A massive, silent friction point is dragging us backward.

We are attempting to build fluid, intent-driven, AI-generated systems, but we are storing them in a rigid, line-based history tool designed in 2005 for the Linux Kernel. We are trying to fly a starship with a steering wheel made of stone.

It is time to say the quiet part out loud: Git is becoming the bottleneck of the AI Era.

To fully realize the promise of Intent Driven Development, we cannot continue treating Git as the engine of our engineering. We must recognize it for what it truly is: a legacy file system that doesn't understand logic.

The "Text-Blind" Problem

Git is a marvel of engineering, but it is fundamentally "dumb." It sees the world in lines of text.

If you rename a function in auth.ts from loginUser to authenticateUser, Git sees this as:

- loginUser(creds)
+ authenticateUser(creds)

Git does not know you refactored a symbol. It only knows you deleted a line and added a line. It sees text; it does not see Logic.

For human-to-human collaboration, this was acceptable. We could read the diff and infer the intent. But in an AI-native world, this "text-blindness" creates a critical disconnect.

In a true AI-Native development environment, the AI shouldn't just look at a flat directory of files. It needs to operate on a System Graph. It must understand the relationships between things—not just their proximity in a file. It needs to know that the User object is semantically connected to the Billing service.

If the AI modifies the User object, it isn't just editing text; it is propagating a ripple effect of logical changes across the entire graph. When we force that rich, multi-dimensional logic into a flat, line-based diff, we are downsampling the intelligence of our system. We are taking a 3D model and smashing it into a 2D drawing. We lose the "Why" (The Intent) and keep only the "What" (The Text).

In other words, we continue to use Git, we suffer from a Cognitive Impedance Mismatch. We take a high-fidelity concept (The Intent) and force it through a low-fidelity medium (The Text File). Then, every time a human or an AI needs to reason about the system, they must burn energy trying to reconstruct the original architectural picture from thousands of lines of syntax. This is a massive waste of computational power and human intellect. We are throwing away the map, shredding it into strips of paper, and then trying to tape it back together every single day.

The Merge Conflict is a Syntax Error, Not a Logic Error

The ultimate symptom of this mismatch is the Merge Conflict.

In a distributed system where multiple agents (human or AI) are working on different Intents simultaneously— say, "Integrate Stripe Payments" and "Enforce Age Verification"— Git often fails to merge them simply because they touched adjacent lines of code.

These conflicts are artificial. Logically, the two changes might be perfectly compatible. But because Git manages Files instead of Functions, it throws a conflict.

We spend hours of our lives resolving these text-based collisions. In an IDD world, this is wasted life. We should be resolving Logical Conflicts, not text conflicts.

A logical conflict looks like this: "You cannot remove the 'Email Address' field from the User object because the 'Send Receipt' intent explicitly relies on it."

That is a valuable conflict. That protects the business. Git cannot see that conflict; it can only see that two people edited line 45.

The Database Must Become the Repo

If Git is the "Assembly Language" of version control, what is the high-level language?

The logical evolution is Database-as-Code.

In an AI-Native future, the "Source Code" cannot remain a folder of text files on a hard drive. It must become structured, versioned data in a Temporal Database.

If you aren't familiar with the term, a "Temporal Database" is simply a database that has a built-in concept of Time. It doesn't just store the current value of a record; it stores the entire history of how that record changed. It is like a Time Machine for your data.

Imagine a world where:

Granularity is Logical: You don't version a "File." You version a Node, a Function, or a Policy.
History is Queryable: You don't ask "What changed in this file?" You query: "Show me the exact state of the 'Billing Logic' as it existed last Tuesday."
Refactoring is Instant: If you rename a verified business concept, the system updates the pointer in the database. There is no "Search and Replace." There is no diff. The entity simply evolves.

This is the architectural reality we need to support Intent Driven Development.

If the AI generates the implementation, why do we need to store the implementation in a text file? We don't. We need to store the Intent (The Horizon Node) and the Verification Policy (The Test). The implementation code is just a compiled artifact—a transient output that serves the intent.

The "Ball and Chain" of Transparency

So, do we kill Git?

Not yet. And this is the paradox.

We cannot abandon Git today because it is the Universal Protocol of Trust. It is our audit log, our backup, and our "break glass in case of emergency" tool. Developers (rightfully) fear vendor lock-in. If the code lives in a proprietary database, they feel trapped.

But we must change our relationship with it.

Git must become the Display, not the Engine.

In this new architectural vision, the Database is the Source of Truth. It holds the rich, structured, intent-based graph of your application. Git becomes a Projection—a mirror. The system automatically syncs the state of the database to a Git repository so you have a human-readable backup.

But the work—the actual engineering—happens in the Graph, in the Intent, and in the Policy.

Moving from "Commits" to "Intents"

This shift allows us to finally clean up the history of our software.

We have all seen a Git log that looks like this:

fix typo
update styling
trying to fix build again
wip

This is noise. It is the frantic scribbling of a human trying to make a machine work.

In an Intent-Based future, we stop caring about the scribbles. We care about the Completed Horizon.

Intent: "Implement GDPR Compliance."
Status: Verified & Sealed.

The "Commit" is too small a unit of measure for a business. The Intent is the atomic unit of value. By moving the "Source of Truth" to a database backed system that understands these high-level concepts, we can finally have a history log that reads like a story of business evolution, not a transcript of syntax errors.

Conclusion: Let Go of the Files

The transition to IDD requires us to let go of our security blankets. For decades, the text file was our safety. If we had the file, we had the power.

But in the age of AI, the power is no longer in the text of the code. The power is in the Context, the Constraint, and the Intent.

Yes, these are still written in text — of course, language is how we define meaning — but that text represents high-level Abstractions, not low-level machine instructions.

Git served us well in the era of manual coding. It was the perfect tool for the "Human Compiler." But as we ascend to become Architects, we need tools that understand the architecture, not just the bricks.

It is time to stop managing lines, and start managing logic.

Intent Driven Development (IDD) is our Current Future

Scott Molinari — Thu, 29 Jan 2026 08:36:54 +0000

For decades, the measure of a software engineer was their command of syntax. We spent our careers acting as human compilers, translating business requirements into machine code, line by painstaking line. But as we transition into the AI-native era, that metric is shifting. We are moving away from a world where we focus on how to implement a feature, and into a world where we focus entirely on what that feature is intended to accomplish.

In our Human-centric AI-Native Distributed Systems Manifesto (if you haven't read it yet, please do), we outlined a future where we prioritize "Verifiable Intent over Syntactic Correctness." To ground this philosophy in reality, we need a new operating model. We need to move beyond the traditional boundaries of Domain Driven Design and Test Driven Development.

We need Intent Driven Development (IDD).

The Inescapable Reality of Distributed Systems

To understand why IDD is necessary, we must first accept the current state of the global economy. It is no longer possible to conduct significant business today without applications that are, in some manner, distributed. The era of the "isolated application" is dead.

Whether you are a logistics giant or a local fintech startup, your digital footprint is inherently fragmented. You are consuming APIs from payment providers, syncing data to mobile devices, replicating databases across regions for latency, and relying on third-party authentication services. "No application is an island," as our manifesto states. Every piece of logic exists within a complex, fragile web of dependencies, network latency, and eventual consistency.

This complexity creates a dangerous trap. As systems become more distributed, the cognitive load required to maintain them explodes. If we rely solely on manual coding, we move too slowly to compete. But if we recklessly hand the keys to an AI, we invite chaos. An AI can write a function that works perfectly in isolation on a developer’s laptop but fails catastrophically when introduced to the latency of a real-world network.

This is where IDD becomes the critical bridge.

The Engine of Intent

Intent Driven Development is the natural evolution of software engineering, accelerated by the "engine" of Artificial Intelligence. In an IDD workflow, the engineer’s primary responsibility shifts from being the manual laborer laying every brick to becoming the Architect defining the destination.

In the past, methodologies like Domain Driven Design (DDD) gave us the vocabulary—the maps of our system—but still required us to manually write the glue code to make those words interact. Test Driven Development (TDD) gave us verification, but required us to write "intent" buried inside unit tests that were often as complex as the code they were testing.

IDD elevates these concepts. DDD becomes the strict Schema that prevents the AI from hallucinating business concepts. TDD becomes Policy Verification, where we define high-level behavioral contracts, and the AI navigates the route to satisfy them.

So, What is IDD?

We have established the philosophy, but how does Intent Driven Development manifest in a daily engineering workflow?

IDD is an "Implementation-Last" methodology.

In traditional software development, we spend 80% of our time writing the implementation and 20% verifying it. IDD flips this ratio. We spend 80% of our time defining the Constraints and the Verification, and we let the AI handle the implementation in the seconds remaining. Specifically, IDD is a three-stage lifecycle:

1. The Definition Phase (The Human Context)
This is where the "Intent" is crystallized. Before a single line of executable code is written, the human engineer constructs the "Immutable Skeleton." This is not a vague prompt like "Make a user system." It is a rigorous set of artifacts:

The Contract (Schema): You define the exact input and output.

The Environmental Constraints: You explicitly select the technology (e.g., Vue, NestJS and MongoDB, or Angular, Spring Boot, and MySQL, etc. etc.). We call these "Foundries" in m8a.

The Behavioral Policy: Instead of writing code, you write the criteria for success (e.g., "Must retry 3 times with exponential backoff").

2. The Generation Phase (The AI Engine)
Once the Skeleton and Policy are locked, the AI is engaged. It is tasked with filling the void between the Input Contract and the Output Contract. Because the AI is constrained by your pre-selected stack and pre-defined business rules, it generates the boilerplate and logic required to satisfy your intent without "guessing."

3. The Verification Phase (The Automated Judge)
This is where "Verifiable Intent" supersedes "Syntactic Correctness." As soon as the AI generates the code, the system runs the Policy Tests. If the output fails the Schema or the Behavior check, it is rejected and regenerated. The human only reviews the solution that has already proven it meets the intent.

The "Intent File"

To make this concrete, IDD relies on a tangible "Intent File."

We are already seeing primitive shadows of this in the developer community today. Many developers are now adding files like CLAUDE.md or GEMINI.md to their repositories to "prep" the AI with context. While this is a step in the right direction, these local files are severely limited. They are static snapshots that only understand the code sitting next to them in the folder; they lack the global awareness of the living system. They are passive suggestions, not active architectural drivers.

In true IDD, the "Intent File" is not limited to a rigid format like YAML, JSON, or a static markdown file. The "Intent" can be anything made of text. It can be a structured design document, a technical spec, or—in advanced platforms like m8a—it can be context injected dynamically via Retrieval-Augmented Generation (RAG). By pulling context from your existing documentation, knowledge bases, or previous system states, the "Intent File" becomes a living entity.

Regardless of the source, the concept remains the same: The Intent is the Source Code; the actual Python or TypeScript files that get generated are merely the compiled artifacts of that intent.

The Non-Negotiable Human Layer

However, a critical distinction must be made to separate IDD from the chaotic "AI-generated" workflows often hyped today. In a true IDD architecture, AI drives the car, but the Human builds the road.
We do not ask the AI to "imagine" an architecture. We do not ask it to pick a database, choose a framework, or decide on a logging strategy. These are the "Rigid Structures" of our system, and they must remain under strict human ownership.

This is not a matter of preference; it is a matter of accountability.

1. The "3 AM" Rule
The primary reason humans must define the stack is simple: Accountability cannot be automated. When a production database locks up at 3:00 AM, the AI is not the one answering the pager. The engineer is. Therefore, the engineer must possess total agency over the tools they are required to debug. If we allow an AI to whimsically choose an obscure library because it "fit the prompt," we burden the human team with technical debt they did not consent to.

2. Guardrails Against Entropy
AI is inherently probabilistic; it craves novelty. If you ask an AI to "build a service" ten times without constraints, it might give you ten slightly different architectural variations. In a distributed system, this inconsistency is fatal. By locking the architecture into "Immutable Skeletons"—human-defined templates—we force the AI to adhere to organizational standards.

3. Strategic Homogeneity
Finally, architecture is rarely just technical; it is strategic. An AI cannot know that we use a specific cloud provider because of a corporate discount, or that we avoid a certain language because it conflicts with our hiring strategy. AI lacks the global context of the business.

The Architects of "Done"

This brings us to the ultimate role of the human in IDD: we are the Architects of "Done."

The AI can iterate indefinitely, generating code that is syntactically perfect but semantically void. It is the human engineer who must review the outcome, not for style, but for meaning. We provide the "Why" and the "Where." We set the hard guardrails, the frameworks, and the templates. The AI simply provides the "How."

By embracing Intent Driven Development, we stop being the manual laborers of syntax and finally become what we were always meant to be: the Architects of Intent.

The Human-centric AI-Native Distributed Systems Manifesto

Scott Molinari — Thu, 29 Jan 2026 06:10:11 +0000

Preamble

We are uncovering better ways of building software with AI at breakneck speed, but at the same time, we must acknowledge that in the modern enterprise, no application is an island. Every piece of logic exists within a complex web of dependencies, latency, and state. We also recognize that AI is not a replacement for engineering, but a powerful engine for realizing intent.

Through this work with AI, we have come to:

Core Values

Verifiable Intent over Syntactic Correctness: We value code that provably matches the system's objective via automated policy and testing, not just code that compiles without error.

System Resilience over Local Optimization: We value the stability and survival of the entire network over the raw execution speed of a single node or function.

Deterministic Execution over Probabilistic Agents: We value AI as a builder of rigid, predictable automation scripts, rather than as a real-time, probabilistic decision-maker for critical processes.

Architectural Guardrails over Manual Review: We value automated, platform-level constraints that physically prevent anti-patterns over relying on human vigilance to catch them during code review.

Managed Metadata over Generative Novelty: We value strict, pre-defined structures and contracts (schemas/templates) over loosely coupled or "reimagined" AI-generated logic.

Human Augmentation over Human Replacement: We value AI as a tool to increase the capacity, velocity, and insight of the engineer, not as a means to reduce the engineering workforce.

That is, while there is value in the items on the right, we value the items on the left more.

The Principles of AI-Native Engineering

1. The Logic is Ephemeral; The State is Permanent

We treat AI-generated components as stateless workers. The AI writes the logic, but the Platform manages the persistence. This ensures that when the logic fails or scales, no data is lost in the wreckage of a hallucinatory variable.

2. The Transition to Determinism

AI is a tool for discovery and construction, not permanent execution. Once a process is fully understood and automated, the AI steps aside, leaving behind rigid, deterministic code to perform the task. We do not ask AI to "think" about a solved problem twice.

3. Contracts are King

The "Handshake" between services (APIs, Data Models, Event Schemas, etc.) must be defined by humans before generation begins. The AI may write the code that fulfills the contract, but it is never permitted to alter the contract alone.

4. Context is Global

We reject the illusion of the "local environment." AI must be prompted and constrained to generate code that assumes the network will fail, the database will be locked, and the service will be unavailable.

The Human Responsibility

We are the Context Bearers

AI cannot see the world outside the prompt. We are responsible for identifying and injecting the external conditions - legal, ethical, physical, and business - that the code must survive in.

We are the Governors of Semantics
Code is math, but Systems are meaning. The AI can ensure a string is 10 characters long, but only a Human can decide if that string should be a Customer ID or a Product Code.

We are the Architects of "Done"
An AI can iterate indefinitely. Only a human can declare that a system satisfies the business need and is safe for deployment.

What do you think of this manifesto?
It is the first document (of hopefully many), which I'll make public while building the m8a platform (working on alpha). I've made this manifesto public, because it is the rules and the perspective I'm working with and I'd love to hear thoughts about this from others.

Next article in our m8a series: https://dev.to/smolinari/intent-driven-development-idd-is-our-current-future-5fh4

NestJS - Circular Dependency Hell and How to Avoid it

Scott Molinari — Thu, 25 Sep 2025 05:58:40 +0000

Before you begin, if you haven't read my other article about project structure, please do. It is important in your journey to learning Nest.

The Conundrum

Many development teams, especially those building CRUD apps, frequently run into the dreaded circular dependency error. That cryptic message signals a deeper issue in your application’s architecture. A circular dependency is a code smell because it makes your modules tightly coupled, difficult to test and reuse, and hard to refactor.

So, why does this happen to so many of us? The most common reason is a simple, yet fundamental, mental model error.

The Mental Model Mistake: Confusing the Data in the Database with a Module's "Work"

This is the central flaw that leads to most circular dependencies in NestJS. Developers building applications often try to model their database relationships directly in their modules.

Database relationships can be bi-directional: An Author can have many Books, and a Book can have one Author. This is a two-way relationship that a database and ORMs are designed to handle with ease.
Module dependencies must be uni-directional: An AuthorModule can expose an AuthorService that's consumed by the BookModule. But if the BookModule then tries to import something from the AuthorModule— and the AuthorModule already depends on the BookModule— you've created a cycle. I'm absolutely certain everyone has faced this.

Your application's modules are not a mirror of your database. Their purpose is to encapsulate functionality, and their dependencies should reflect the flow of application logic, not the structure of your data.

The Right Mental Model: Modules as a City with One-Way Streets

Let's use your application as an analogy of a city. But, instead of thinking about your city with two-way streets, picture them as a city with strictly one-way streets. Each module is a neighborhood in the city (e.g., UserModule, AuthModule, AuthorModule, BookModule, etc.), and the dependencies are the roads. A car can travel from the BookModule neighborhood to the AuthorModule to get author information, yet that same car cannot travel from AuthorModule back to the BookModule.

What you are visualizing with your module dependencies in this city of one-way roads is a directed acyclic graph (DAG): .

Directed: The relationships flow in a single direction. A depends on B, not the other way around.
Acyclic: There are no cycles. You cannot start at A, follow the dependencies, and end up back at A.

The Package Carrier Analogy: Your Delivery Route in the City

This is where your NestJS application becomes a delivery service. Think of a request coming into your application as a package carrier starting a delivery route. The carrier enters the city and proceeds down the one-way streets, visiting each module to perform a task. The key rule is that the carrier never turns around and goes back to a house they've already visited.

The entire "delivery route" forms the directed acyclic graph. The carrier starts at the beginning (AppModule), proceeds through the dependencies, and at the end of the route, the last module sends a result back, confirming the "delivery is complete." This model reminds us that the flow of execution should always be forward and purposeful, never circling back on itself.

Practical Rules to Avoid the Cycle

Define a Clear Hierarchy: Arrange your modules in layers. Core modules should be at the bottom, feature-specific modules in the middle, and entry-point modules at the top. Dependencies should only flow down the hierarchy. This principle is a cornerstone of architectural patterns like Clean Architecture, popularized by Robert C. Martin ("Uncle Bob").
Separate Shared Logic: If two modules both need the same shared utility, create a third, separate UtilModule that both can import. This is the "extract common concerns" rule. These things go into a "common" or "shared" module.
Use a Higher-Level Module to Orchestrate: Rather than having two modules directly depend on each other, create a higher-level module that depends on both. This module acts as the "middleman," orchestrating the flow of data without creating a circular dependency. This kind of module should be "doing things" and not representing a specific data(base) model.

A Concrete Example: Counting an Author's Books

Let's use the Author and Book example. We need to get the number of books an author has written.

AuthorsModule: Responsible for all things authors.
BooksModule: Responsible for all things books.

Instead of having AuthorsModule import BooksModule (to get the book count) and BooksModule import AuthorsModule (to find author info), we introduce a new, higher-level module: PublishingModule. This module acts as our "package carrier," orchestrating the request.

src/authors/authors.module.ts

import { Module } from '@nestjs/common'
import { AuthorsService } from './authors.service'

@Module({
  providers: [AuthorsService],
  exports: [AuthorsService],
})
export class AuthorsModule {}

src/books/books.module.ts

import { Module } from '@nestjs/common'
import { BooksService } from './books.service'

@Module({
  providers: [BooksService],
  exports: [BooksService],
})
export class BooksModule {}

src/publishing/publishing.module.ts

import { Module } from '@nestjs/common'
import { AuthorsModule } from '../authors/authors.module'
import { BooksModule } from '../books/books.module'
import { PublishingService } from './publishing.service'
import { PublishingResolver } from './publishing.resolver'

@Module({
  imports: [
    AuthorsModule,
    BooksModule,
  ],
  providers: [PublishingService, PublishingResolver],
})
export class PublishingModule {}

The PublishingModule correctly models the package carrier's route. It orchestrates the process by visiting the AuthorsModule to get the author and then the BooksModule to get the books, all while maintaining a unidirectional dependency flow. The AuthorsModule and BooksModule know nothing about the PublishingModule and remain decoupled and reusable.

Taking it a Step Further: Abstraction with an Interface

The concrete example above is a great starting point, but what if our application grows? What if we add new content types like Blogs or Articles? We would have to update our PublishingModule to import BlogsModule, ArticlesModule, and so on, making the module cluttered and difficult to manage.

This is where the power of abstraction comes in. Instead of depending on concrete implementations, we can rely on a shared contract, or interface. This makes our code more flexible and scalable.

1. Define the Interface and a Shared Token

First, you need a shared interface to establish a common contract for all your services. This provides type safety. Additionally, define a unique token using a Symbol to avoid naming conflicts and serve as the key for your injection.

src/publishing/interfaces/publishable.interface.ts

export interface IPublishable {
  getPublishableType(): string;
  getContentCountByAuthorId(authorId: string): Promise<number>;
}

src/publishing/interfaces/publishable-service-token.ts

export const PUBLISHABLE_SERVICE_TOKEN = Symbol('PUBLISHABLE_SERVICE');

2. Implement the Interface in Each Service

Each of your services, like BooksService and a new BlogsService, will implement the IPublishable interface. They will each have a getPublishableType() method to uniquely identify themselves.

src/books/books.service.ts

import { Injectable } from '@nestjs/common';
import { IPublishable } from '../publishing/interfaces/publishable.interface';

@Injectable()
export class BooksService implements IPublishable {
  getPublishableType(): string {
    return 'book';
  }

  getContentCountByAuthorId(authorId: string): Promise<number> {
    // Logic to get book count
    return Promise.resolve(10);
  }
}

src/blogs/blogs.service.ts

import { Injectable } from '@nestjs/common';
import { IPublishable } from '../content/interfaces/publishable.interface';

@Injectable()
export class BlogsService implements IPublishable {
  getPublishableType(): string {
    return 'blog';
  }

  getContentCountByAuthorId(authorId: string): Promise<number> {
    // Logic to get blog count
    return Promise.resolve(25);
  }
}

3. Create a Multi-Provider Factory in the Central Module

This is the most crucial step. Instead of each module exporting a provider with the same token, you'll create a single, central module that gathers all the individual services and provides them as an array under the shared token. This prevents the previous providers from being overwritten.

In this pattern, the central module knows about all the concrete implementations and orchestrates their provision. Other modules, like BooksModule and BlogsModule, can be simple and focused on their specific business logic.

src/publishing/publishing.module.ts

import { Module } from '@nestjs/common';
import { PUBLISHABLE_SERVICE_TOKEN } from './interfaces/publishable-service-token';
import { BooksService } from '../books/books.service';
import { BlogsService } from '../blogs/blogs.service';
import { PublishingService } from './publishing.service';

@Module({
  imports: [], 
  providers: [
    BooksService,
    BlogsService,
    {
      provide: PUBLISHABLE_SERVICE_TOKEN,
      useFactory: (booksService: BooksService, blogsService: BlogsService) => {
        return [booksService, blogsService];
      },
      inject: [BooksService, BlogsService],
    },
    PublishingService,
  ],
  exports: [PUBLISHABLE_SERVICE_TOKEN],
})
export class PublishingModule {}

4. Inject and Use the Array in the Service

Now, your PublishingService can correctly inject the array of IPublishable services. NestJS's container will use the factory we defined to provide a single array containing all the services. This allows you to iterate over them and perform actions polymorphically.

src/publishing/publishing.service.ts

import { Injectable, Inject } from '@nestjs/common';
import { IPublishable } from '../content/interfaces/publishable.interface';
import { PUBLISHABLE_SERVICE_TOKEN } from './token';

@Injectable()
export class PublishingService {
  constructor(
    @Inject(PUBLISHABLE_SERVICE_TOKEN)
    private readonly publishableServices: IPublishable[],
  ) {}

  async getAuthorTotalContentCount(authorId: string): Promise<number> {
    const counts = await Promise.all(
      this.publishableServices.map(service =>
        service.getContentCountByAuthorId(authorId),
      ),
    );
    return counts.reduce((sum, count) => sum + count, 0);
  }

  async getAuthorCountByPublishableType(authorId: string, type: string): Promise<number> {
    const service = this.publishableServices.find(s => s.getPublishableType() === type);

    if (!service) {
      throw new Error(`No service found for publishable type: ${type}`);
    }

    return service.getContentCountByAuthorId(authorId);
  }
}

This is the real power of the one-way street analogy. Our PublishingService doesn't care if the content is a book, a blog, or a new content type we create next week. It only cares that it can talk to a service that fulfills the IPublishable contract, maintaining a clean, decoupled architecture. This new method shows how the carrier can use a key ('book') to bypass all other modules and go straight to the one it needs, all while following the one-way streets.

The Bottom Line

The next time you're building a new module, pause for a moment. Instead of thinking about data retrieval ("I need to get posts for this user"), think about the process being accomplished ("I need to get all content published by this author"). This subtle but powerful shift in perspective, combined with the one-way street mind-frame, will guide you toward a clean, maintainable, and scalable architecture. And you'll finally avoid the hair pulling issue of circular dependency hell.

How do you avoid circular dependencies? Or how do you work to make your modules even less dependent? Let me know in the comments below.

NestJS and Project Structure - What to Do?

Scott Molinari — Sun, 03 Sep 2023 12:42:21 +0000

So, you're just getting going with Nest, ey? You might not yet completely understand why you want to use Nest or why it is one of the most popular NodeJS frameworks on the planet. But, you are saying for sure, "if this many people are using it, it must be good", right?

Well, this article will get you a few steps closer to that better understanding of why you've chosen Nest.

The Onion/ Clean -> Nest Architecture

You hopefully know about Onion Architecture, or Clean Architecture or you have a basic understanding of what Separation of Concerns is all about.

And, some other knowledge you should have is a rough idea of what Domain Driven Design is. Especially what a "domain" is (and it's not about the names of websites).

Check out this image.
Puh! Overwhelming, right? Image borrowed from herbertograca.com

Don't get too caught up in this image, but yeah, this is practically everything you have to juggle to make sure a full stack application will work (in any language, with any framework).

And, Nest is only a part of it. The "core" part to be exact.

Since Nest is the core part of your system, it also covers some of the "layers" of the architecture for your stack, namely:

the communication layer via controllers for REST/ resolvers for GraphQL or Gateways for Websockets (and a lot more for microservices)
the database abstraction layer with ORM repositories or ODM models or Prisma clients
the business logic layer with services
the access control layer with guards
the data validation and transformation layer with pipes
a CQRS/ Bus system
presentation layer too, if you go for MVC architecture

..and a good bit more.

The point being, your Nest application can do a whole lot of things, and wondering how to put all of those things in their right places AND also somehow model the overall business domain problems the application needs to help solve, is a daunting task. At the very beginning, very often the question arises - How do I structure my Nest application?

This question arises usually because you are just learning Nest. And yet, for sure, you have a fairly clear idea about what your app should do.

..and that is a really good thing, because we can take advantage of that to build the Nest application!

But for now, just keep in mind that Nest will build the final "onion" or "clean" architecture for you. It's one of the reasons why Nest has its module system (and why you need to add all this new verbosity to your app) and also why Nest is so popular. It's kind of a paradox, in a way.

Two Domains

As just mentioned, you have two main Domains to juggle as an app developer. Those two domains are the

"Developer Domain" - knowledge about how to make an app work in the framework and language in use, in our case Nest and TypeScript/JavaScript

and the

"Business Domain" - knowledge about what the app should do to solve your business problems

When you write code with Nest, you have to fit these two domains together, when in fact, they really don't fit together in any way at all. Again, the paradox....

So, it's at this point the questions arise...

Do I organize my code to the domain of creating the code and the framework and somewhere inside, I'll be able to put in the business logic?

or -

Do I try to model my business domain and figure out how to fit in the development domain into that?

The latter should be the one you choose and Nest's module system simplifies it for you.

Domains, Features and Modules

As we noted earlier, as a beginner with Nest, you probably know your business domain much better than you know the development domain. So, in that sense, why not start with what you know best?

Let's move forward with a new Nest app.

If you haven't already, install the Nest global CLI and create a new project too.

app.controller.ts and app.service.ts are just examples to give you a running app. You can delete them. Keep app.module.ts though. That is your "root" module.

Now, let's take your business domain and work with it right now. Let's say you want to build a blog application like Wordpress, but it will be the next best thing. It will be even bigger and better than Wordpress! Haha! We all want world domination, right!

IMAGE CREDIT: DOOMSTEADDINER.ORG

Ok. Ok. Maybe not. But for sure, you do want your business domain problems solved. So, either way, you definitely know what you want. For our example, it's a blog application.

Ask yourself, what are the overall "features" you might want to give your blog application? We'll start relatively simple of course. How about..

Blog management:

Draft a blog
Publish a blog
Comment on a blog

And, what about user management?

User Management:

Create a User
Remove a User
Edit a User
Show users

And lastly, what about getting the users into the app with the right permissions?

Auth Management:

Login a User
Logout a User
Register a User
Set permissions for a user

That is simple enough, right?

Creating the Onion's Layers

Now you can use the Nest CLI's commands to build your app.

Let's create the high level "management" domains. Inside your project folder, run these commands:

nest generate module blog
nest generate module user
nest generate module auth

Notice three things have happened.

You have folders with the names of these domains
You have modules TS files with those names
(the kicker) the modules are already imported into your app.modules.ts. How cool is that?

Now could be a good time to think even farther into the future. You could continue with the module creation process for the management features, but it might be overkill depending on what must actually be done in terms of code to make the features a reality.

You think the user and auth modules will be fairly straight forward, so you don't continue with adding modules there. But with with blog, hmmm.... you aren't so certain. It could get hairy and more complex, especially the commenting part. So, you carry on inside the blog folder.

Change into the blog folder and run the following commands:

nest generate module drafting
nest generate module publishing
nest generate module commenting

You end up with the below image and again, the modules are automatically registered in blog.module.ts

Let's move on to the auth module.. ehem...domain, um...management. (See how this DDD stuff is getting in here?)

Ok. We only need the three processes. Login, Logout and Register. Theoretically, we only see these being three methods, but the methods might get somewhat large. So, we decide to make singular classes for each process. Change into the auth directory and run the following command:

nest generate service login
nest generate service logout
nest generate service register

You now have this:

And again, the services are auto-registered into the auth module. Nice!

Hopefully by now, you are catching on.

But, we need more things to make the auth feature work. How about a controller to get the calls routed to the service? Controllers should be small, so you know you can fit them all in one class.

nest generate controller auth --flat

Note the --flat argument. It tells Nest not to create a folder named auth with the controller in it. It puts the controller file in the current directory. And once more, the controller is automatically registered in auth.module.ts.

Ok. We have our controller, what now?

We've learned about guards, and thus know we'll also need a guard of some sort to protect certain other paths in our future API. Let's create that.

nest generate guard auth --flat

And our guard is created. Note though, guards aren't automatically registered in your module.

We can continue on with even more creation of Nest providers, like adding the ORM files (repositories, entities), creating classes for DTOs, pipes for validation and a whole bunch of other stuff, but you are more than likely getting the idea by now.

The important part to note with this exercise is, we are putting all the layers of the architecture in a module (a mini-onion). When compiling, Nest aggregates all of the modules to create the finished application (the big final kick-ass onion).

There are some very nice advantages to this module system:

You can basically take any module and reuse it somewhere else (with some modification). Code reuse for the win!
You get a powerful dependency injection system. We didn't even start on that subject, but such a system is hugely important for enterprise grade code bases and at some point for your sanity.
When you have an issue with a feature, you can quickly find the code you need to work on. For instance, let's say you have a problem with validation of a blog input. You go to the /blog/draft folder and there you'll have either the DTO you need defining the validation rules or the pipe that works the validation. All together. No searching through tons of files to find the right pieces of the puzzle.
Lastly, Nest's modularization pushes you more into the direction of a Service Oriented kind of thinking. That, in turn, will help you make the jump to microservices easier. Remember, we wanted world domination! Right? Haha!

Joking aside. Basically, you could say, Nest tries to get out of your way as a dev, by making you follow a process of modularization, where Nest is sort of secondary. It is a means to an end, but your domain problem is the first class citizen (or rather it should be). Your business problems at hand should determine how you build the app. Nest just adds the neat tools to make it happen.

Hmm....Something is Missing!

You might be saying, "wait a sec! What about those things in an application, which don't belong to any business domain, but only to the developer domain? Things like connecting to a database -or- generating the API via Swagger -or- configuration?"

Great question!

How about a core domain... uh...ehem...module?

Change directory up to the root and run:

nest generate module core

Let's also create some services for the things mentioned above. Change back down to the core folder and run:

nest generate module database
nest generate module swagger
nest generate module config

There you go! (Note: image shows common, as I originally used common, but this module should be named "core". Common should be for things commonly shared like utilities.

Now you can tackle your problems logically.

Conclusion

I hope this got you to a better understanding of why Nest's module system is so potent for your work as a developer. There are a good number of other features in Nest that make it a pleasure to work with. Yes, it seems verbose at the beginning. But, now you know why. And once you use Nest more and more, you'll wonder how you did your backend applications without it before.

Enjoy Nest and have fun!

Additional Note: After helping someone in the Nest Discord server once more about project structure, I realized one more advantage to Nest's modules. In our blog example, we had higher level user and auth modules. In effect though, they could be considered "things I would always need in any app". I mentioned code reuse, and if you know these modules would always be added to any app together, you might want to end up with a "core" module holding such other modules like "auth", "authz" and "user". The cool things being (and the advantage) you can refactor this fairly easily. Create a "Core" module and move the folders and register them in the module as imports and if need be, break it out into its own library for use in any other of your apps.Awesome, right? 🙂

Additional Note 2: One of the things I see people often attempt, is to try and fit "DDD" into the file structure of a Nest project. Nest is flexible enough to allow for this, however, you end up with two problems.

Actually fixing a problem requires sifting through those different layers of the file system you've determined to be "proper" for fitting your app to "DDD". Whereas, if you just keep the DDD within each module, as Nest prescribes, you just need to go to that one module to fix the problem.
The bigger issue, you've broken up Nest's module system and thus the ability to reuse code/ modules as libraries. Maybe not a big deal for those just starting, but it will be when you realize you could take a lot of code and reuse it in new or other Nest projects.

To me, and this is my personal opinion, DDD should be a guide to how you think about your application, not necessarily how you design your file system/ project structure. When you come across a problem in the real world, either it being to enhance or to fix the application, nobody should need to rethink about the locality of code according to DDD to fix it. That is just going to waste a ton of time. Use Nest's "way of modularization". That is the standard you should work with. Keep DDD in your mind, when dealing with the overall problem and keep it away from the code structure. It just isn't necessary.

Additional Note 3: I just ran into this article today. I think it helps make my points above.

https://medium.com/@stevebishop_89684/clean-architecture-is-not-a-project-structure-b158c9c4163f

m8a scenario #1 - Using Coder to Develop Keycloak Templates Live (almost)...

Scott Molinari — Thu, 09 Feb 2023 10:32:34 +0000

This article will be one of many posts about the trials and tribulations, the learnings and sharings of information as we build out the m8a.io platform (in POC).

The goal of these scenario articles will be to highlight one or more technologies and explain what we did with them.

We want to share these learnings and experiences, because we do believe we are making some cutting edge decisions for our new platform and/ or are coming up with alternative ways to do things that haven't yet been discovered before. And the publication of this knowledge is all in the name of giving back to those technologies that are helping us with our very lofty endeavour. It's a start.

In this article, two of the technologies being highlighting are:

Coder and Keycloak

From their websites:

Coder offloads development from local workstations to your on-prem and public cloud infrastructure. Boost developer productivity with instant onboarding and powerful server resources. Keep code and data under control within your network.

Add authentication to applications and secure services with minimum effort. No need to deal with storing users or authenticating users.
Keycloak provides user federation, strong authentication, user management, fine-grained authorization, and more.

As you can imagine, these are two pretty powerful sounding applications, right?

Scenario Description

Above and beyond these two great applications, we are also using Kubernetes.

Note: This article will assume you have some fairly good knowledge of Kubernetes and Helm and how they both work together. You should also be familiar with Terraform.

As you hopefully know, Kubernetes (k8s) is a very powerful platform for orchestrating container workloads. If you are still reading this and you don't know about k8s, I highly recommend learning about.

Getting back to our two main technologies....we have implemented Keycloak as our Identification and Authorization Management system (IAM). However, as these things go, Keycloak has its own tech stack. One of the technologies, of course, is the language they used, which is Java. And being it is Java, they chose to use a templating engine called Freemarker.

To keep this article as short as possible and because it isn't the intention of this article, we won't go into the deeper details of Keycloak's templating system and how to use it. Instead, I'll refer you to two good articles that explain it all well:

Customizing Themes for Keycloak
How to Customize Keycloak Themes

That being said, if you are familiar with any other templating system for the backend, you'll understand Freemarker fairly quickly too.

And, because Keycloak uses this template system, setting up your Corporate Identity within Keycloak is very much possible and not entirely difficult.

However, despite knowing about templating and Keycloak you'll quickly understand the first hurdle of having Keycloak in k8s.

Above and beyond designing the templates, how can we even get those new templates into the Keycloak pods for use by the application?

There are two suggested ways to get customized templates into the Keycloak pod or pods.

using an init container to "load" the new templates over a shared volume.
using a secret to load in a tarballed archive of the files.

Why won't this work?

Both require a number of steps to make the template contents usable by Keycloak and as you can imagine, are miles away from any kind of live development.

With either of these two steps, you'd need to have a local version of Keycloak to design on, then create a container with the files or create a tarball and load it into a secret and then restart Keycloak. Restarting Keycloak alone takes about a minute until it is ready to go. And if you happen to see a mistake, as it always happen, it's wash, rinse and repeat (pulling out hair or getting grey from the process).

Coder to the Rescue!

Coder is going to be an integral part of the m8a platform. And as it may be, we can also use it for the purpose of (almost) live development of custom templates in a running Keycloak pod.

Point #1 above of getting a template set into Keycloak via a shared volume gave us the initial idea. Why not just use another pod, a Coder agent/ workspace pod in parallel and share the volume between them? That way you can develop on the files in the volume and Keycloak would use them directly. Yes!

So, off we went looking to resolve this challenge.

Installing and Setting up Coder

To get going with Coder, you'll need to install Coder into your k8s cluster via Helm. Follow the instructions carefully and you should have Coder up and running in cluster in no time.

Next, you'll need a workspace template to be able to create a workspace. Again, the Coder's docs explain how to do this well and there is an example k8s template you can start from.

You'll also need to install the Coder CLI onto your local machine for working on the templates.

Coder's templates are basically Terraform modules. So, you'll need knowledge of how Terraform works and the config language itself, to develop them. If you know k8s though, it's fairly easy to pick up.

Getting Everything Set Up

Coder's service account permissions

In order to have Coder work with k8s objects outside its own workspace, we have to give the Coder service account (which should have been installed while installing Coder's Helm chart) enough permissions to work across namespaces. We did this by creating an admin cluster role and binding it to the service account via kubectl.

Keycloak setup

This was the trickier part. And of course, this will require a development environment, and not your production Keycloak. Setting up a complete development environment in k8s is way beyond the scope of this article, but if you are a good with k8s, you'll know what to do, if you haven't done it already (i.e. you really should!).

Ok. So, with Keycloak in a dev environment, you'll need to have only one Keycloak pod running, to not run into caching issues. And, you'll be setting this up in the Helm chart (we are using the Bitnami chart):


extraStartupArgs: >-
  --spi-theme-static-max-age=-1 --spi-theme-cache-themes=false --spi-theme-cache-templates=false

...

replicaCount: 1

These startup args will turn off the Keycloak caching process for templates.

Or, you can also do this:


extraEnvVars:
  - name: KEYCLOAK_PRODUCTION
    value: 'false'

This will start the pod in dev-mode, which should also mean template caching is turned off.

Set up the volume

We are using Longhorn as a more capable storage system inside our k8s clusters. To set up the volume with Longhorn, you can go into the UI and create a new Persistent Volume Claim (pvc)/ Volume.

You can also do this via kubectl, and with any other storage system in k8s.

Once you have the pvc created (making sure it is in the keycloak namespace) you are halfway there.

As a next step, you'll need to bind the pvc to the Keycloak pod via a Persistent Volume (pv). To do this, add the following to the Helm chart and upgrade it:

extraVolumeMounts:
  - mountPath: /opt/bitnami/keycloak/themes/m8a-theme
    name: theme
extraVolumes:
  - name: theme
    persistentVolumeClaim:
      claimName: pvc-keycloak-theme

The mountPath is dependent on where Keycloak is installed in the pod. The path above it where the Bitnami chart puts it.

The claimName is the name of your pvc. Ours is pvc-keycloak-theme. Keep that in mind.

Now you have the Keycloak instance working with a volume that can be attached to other pods. Let's do that now with a Coder workspace.

Setting up the Coder workspace (the pod)

As mentioned above, you can use the example Coder template to create the workspace. The only difference is now, you'll need to have the volume also bind to the workspace pod. To make that happen, you'll need to add this to the template:

resource "kubernetes_pod" "main" {
  count = data.coder_workspace.me.start_count

   ...


      env {
        name  = "CODER_AGENT_TOKEN"
        value = coder_agent.main.token
      }
      volume_mount {
        mount_path = "/home/template-dev/my-theme"
        name       = "theme"
        read_only  = false
      }
    }

    volume {
      name = "theme"
      persistent_volume_claim {
        claim_name = "pvc-keycloak-theme"
        read_only  = false
      }
    }
  }

The volume_mount and volume entries are the important additions. volume_mount is the location of the files you'll be working on. volume is the binding of the pvc to the pod.

Push up or add your template to your Coder instance via the Coder CLI and you are almost ready for development.

The new development workflow

Ok. Now that we have pretty much everything set up. Go into your Coder installation (either via port forward or if you set everything up properly, via the URL), go to the Templates tab and fire up a new workspace.

I like to use my local VSCode, so I press on the button, which will open the workspace in VSCode.

Coder will also let you work directly in the browser too, if that is what you want. We removed that feature from our template and why you don't see the option above.

Remember, this is a pod working inside a k8s cluster. It's true remote development in a just-like-production dev environment.

Once you've clicked on the button shown above, you'll be greeted with this a few seconds later:

With the workspace running, you can add your files as necessary and start developing directly on your Keycloak templates.

Note1: In the image above, the login folder is the one I was working in. You'll need to add the different folders yourself for the different areas you want to customize Keycloak's templates.

Note2: In the future, you'll be able to determine which folder the Workspace should open up in. The suggestion wasn't yet implemented in Coder at the time of writing.

Note3: Don't make the same mistake as I did and have browser caching turned on (and have forgotten about it). If you aren't seeing changes made directly after refreshing the Keycloak page you are customizing, see if it works with Ctrl + F5. Or turn off your browser's cache.

So, that is it. I searched very hard to find something like this and couldn't find anything remotely similar. I hope this will help others, at least those wanting to customize their Keycloak instance more efficiently inside k8s.

Happy Coding!!!! 😁

QuasarConf 2022 - Speakers and Schedule

Scott Molinari — Tue, 28 Jun 2022 19:26:29 +0000

Get out your calendar, and save the date!

When will it be?

Saturday the 9th of July, 2022 - 3 p.m. GMT

Where will it be?

Streamed Live on Youtube (bookmark the link!)

The Speakers, Topics and Schedule

(all times GMT)

Quick Welcome and Intro - 3 p.m.

Talk 1 - 3:05 p.m. - Five Refactoring Tips For Gorgeous, Reusable Code

Let's make our Quasar code crystal clear and easy to follow, by breaking it into smaller pieces. Luke will show how you can truly separate concerns with little known, powerful refactoring techniques... Techniques that will have your coworkers smiling when they dive into your codebase!

Talk 2 - 3:30 p.m. - Quasar and TypeScript: A Deep Dive

Yusuf will take us on a deep dive into Quasar's TS generation pipeline and JSON API structure. The history behind these, the progress we've made over the years, and future plans will also be covered.

Talk 3 - 3:55 p.m. - All is Well, When There is Quasar!

Hari will explain how his and his team used Quasar/VueJS along with AWS & Feathers JS to help them in developing an academic platform in record time. He'll cover how they used the Quasar Ecosystem - and how they built up their Resume Builder, Simple CRUD User Interfaces, Social Feed and a Subscription & Licensing System including short demos showcasing the real world use of their use of Quasar components.

Talk 4 - 4:20 p.m. - Using the Composition API with TypeScript to Build Better Forms

In this talk, Bruno will cover how you can leverage the Composition API by creating composables to abstract the logic out of your forms, making that logic reusable.

Talk 5 - 4:45 p.m. - Quasar Themes and Theming

In the talk Bart will give you a look at the state of Quasar and theming. We'll go into the provided light and dark themes provided by Quasar and then look at how to expand into more custom themes, based on the gathered knowledge on how Quasar works.

Talk 6 - 5:10 p.m. - Component Testing Tip & Tricks with Quasar

Quasar has supported Cypress Component Testing out of the box for some months, but there are some caveats due to Quasar feature-packed components having a much more complex HTML structure than native input elements.

Paolo will cover how you can add Cypress Component Testing to your Quasar project and show you some tips and tricks about testing some of the most complex Quasar components.

--- 20 Minute Break ---

Talk 7 - 5:55 p.m. - Wrapping and Extending Quasar Components using TypeScript

Evert will showcase 2 options on how to wrap and extend Quasar components. This can be used to set defaults for properties and use your wrapped component instead of the default Quasar one throughout your application. Of course doing all this while preserving as many TypeScript/IDE features that are currently out there, like:

property autocompletion and type checking
property documentation on hover
typed component methods
typed slots

Talk 8 - 6:20 p.m. - Embedding Quasar Apps Into Lightweight Hardware

Mike will cover workflow and methodology for incorporating Quasar/Vue Apps into resource constrained embedded systems hardware such as the ESP32 processor.

Talk 9 - 6:45 p.m. - Building Engineering Tools with Quasar

Carlos will show two examples of Quasar apps he developed as engineering tools. He'll demonstrate how Quasar helped him with the rapid development of the tools and how these benefits can also help you.

Talk 10 - 7:10 p.m. - Lessons Learned Migrating an App to Quasar and Vue3

In early 2022, Martin decided to upgrade one of his side projects from Vue2+Buefy to Vue3+Quasar. His application gets hundreds of thousands of visitors per day, so he had to tread carefully. Martin's talk will go into why he made the decision to migrate, what the migration was like, and how he rolled out the new version.

Should you have any questions, please post them in the comments below or join us on Discord.

Although we are planning to carry out the conference as advertised, the schedule is subject to change, without notice.

Twitter
Facebook

It's Back! QuasarConf 2022 - Call for Proposals

Scott Molinari — Mon, 23 May 2022 11:09:03 +0000

We are happy to announce the comeback of our yearly online conference about all things Quasar Framework and Vue. We had success with our first ever conference and we'd like to continue with what we intend to be a tradition.

When will it be?

Saturday the 9th of July, 2022 - 3 p.m. GMT

Would you like to do a talk?

We are looking for devs in the community, who would like to present their knowledge about anything related to Quasar and/or Vue.

Your talk should go for 20 minutes max. We'll also be offering the viewers the ability to ask questions in the chat, so after the talk, we'll have a 5 minute Q&A with the speaker.

If you are interested, please sign up by filling out our Call for Proposals form.

There is a limited number of available spaces for talks.
Deadline for proposal acceptance is the 9th of June, 2022.

What to expect?

At our last (and first) conference 2 years ago, we had over 700 live viewers and the video has been watched over 17k times since then. Not too shabby for a first conference!

We hope to be breaking these firsts this year and with your help, it's pretty certain we can.

If you have any questions, you can either write them down below or use our Discord.

We'll be making more announcements about the conference, the participants and content in later posts.

We are looking forward to your talk proposals!!

If you'd like to stay in-tune with conference and other Quasar news, please follow our channels.

Facebook
Twitter
Follow the tag #quasarconf on Twitter

Quasar and Vite - Frontend Application Development at Light Speed

Scott Molinari — Mon, 14 Mar 2022 19:50:22 +0000

This week notes the accomplishment of a major milestone in Quasar's roadmap. The integration of Vite as a driver of the Quasar CLI, and as a much better alternative to the slower and more complicated Webpack based CLI.

Quick Introduction Video

Why Vite?

If you haven't heard about Vite yet and why it is so good, Vite has the following main selling points:

(from the Vite docs)

A dev server that provides rich feature enhancements over native ES modules, for example extremely fast Hot Module Replacement (HMR).

A build command that bundles your code with Rollup, pre-configured to output highly optimized static assets for production.

In other words, the main goal Evan You (creator of Vue) had for creating Vite (pronounced like veet) was to majorly improve the developer experience. He saw that the current process of bundling and then loading the application into the browser and developing with Hot-Module-Replacement (HMR) could be improved upon with the new ES Module resolution system available in all browsers.

That is the TLDR version. If you'd like, you can also read the much more technical reasons.

Bottom line, the avoidance of the bundling or packing step for the initial build, also during HMR, saves a ton of time, even with the smallest of projects (see below). But, this advantage is especially noticeable, once your project gets even remotely bigger.

Initial Loading of a new Quasar project with Webpack

Initial Loading of a new Quasar project with Vite

Ok. The difference with an initial project isn't so predominant, but it is there. Think about this though. Once your project starts growing, the Vite-based CLI's performance in building your app stays about the same or will only slow a little for the initial startup. The Webpack performance will degrade much worse as your project size grows. In other words, what you see here as the initial startup speed is about what you'll have for any size project. On top of that, any updates from HMR will be instantaneous with Vite. With Webpack, this performance also degrades with the size of your project.

It was clear to the team instantly, when Vite came out, that Quasar would need to integrate it. So, it wasn't a matter of "If", but rather "When?". It was just a matter of time, dev availability with Razvan and our prerogatives for it to happen. Our first major goal was to get Quasar onto Vue 3. That happened last year. All the while, Vite was getting better and more stable. And this year, Quasar now has a Vite based CLI.

How cool is that? 🤩

Getting Started

If you'd like to just get started with Vite in a new project, all you have to do is run...

$ yarn create quasar
# or:
$ npm init quasar

Note: The command quasar create is no longer usable for a Quasar project with the new CLI (>1.3.0).

NOTE2: the Vite CLI was still in BETA at the time this article was published. So, it is not production ready, if it is still in beta or RC status!!!

While running the command above, the creation process will pose question to you for the project creation. Answer the questions as best you can. Hit enter for the defaults (except for the Vite CLI), if you are uncertain what to answer. Once the creation process is done, navigate to the newly created project folder and run...

$ quasar dev

And off you go.. with Lightning fast development at your fingertips!!!

Migration

Maybe you have a Quasar project and wish to move it to the new Vite CLI. If that is the case, then let's get you up to.....Vite, with the official migration guide.

Roughly, the migration guide takes you through the following steps:

Create a new project with the newest version of the (global) Quasar CLI
Copy specific folders into the new project from your old project, also doing some small edits on specific files.
Update the quasar.config.js file notice it's changes from quasar-conf.js) with the new settings, should you need them.
Update package.json to remove the browserlist entry (if you want). It is no longer valid and not needed, at least for Vite.
Delete a folder for SSR and move another.
For PWA, you'll need to move your manifest to quasar.config.js
If you are using BEX mode, you'll also need to port over your manifest files manually.

So, not too much work necessary to get a much better DX.

Again, more details can be found in the migration guide.

That's it!

Let us know in the comments about what you think! Is Vite with Quasar awesome or what?

Keep in touch with Quasar news.

Quasar on Twitter
Quasar on Facebook
Quasar on Discord
Quasar on Github

Quasar Hack-a-May Results and Winners!

Scott Molinari — Thu, 11 Jun 2020 13:20:29 +0000

Firstly - Thanks to all the participants for their entries.

Next, we'd like to remind everyone of the rules we put in place for this contest.

Ok. So let's get to the awards.

Drum roll please!..........

First place goes to: BBex

Author: Kurtis Fields

BBex is a bookmark tool, which helps you better manage large numbers of book marks. It uses Dexie as a storage system in your browser and also uses Fuse for powerful searches in your bookmarks.

This BEX is easily installed and works from the gitgo. In fact, it loads up first with a simple button to run the setup, which indexes your bookmarks. After that, you have a great system to manage your bookmarks.

Congrats to Kurtis on this great little tool and winning the contest.

Second place goes to: Quasar App Extension GH Pages Auto-Deploy

Author: Roland Doda

Coming in a very close second is Roland's GH-Pages Auto Deploy App Extension (AE).

We were really impressed with this little AE. Simply have your app's repo on Github (locally, your app's repo needs to have a GH repo as a remote origin), then install this AE into your app and you have a one-stop script to build and upload/publish your apps to Github Pages via yarn gh-pages-deploy.

A great AE utility for those who use Github Pages and it also shows the versatility of Quasar's App Extension system and thus earns second place.

Third place goes to: GBTuls Translator

Author: huy-tran

This is another interesting BEX. It is also a great little tool for the translation of highlighted text on any web page. No longer do you need to cut and paste to get a translation. Had the "Language Target" persisted, it might have even gotten more votes. We also know there are other extensions out there to do the same thing. The fact it was written in Quasar makes it special to us and a well-earned third place.

Honorable Mention #1: Covid Game Bex

Author: siauderman

As we did the voting, totally subjective and with no guidance between the core Quasar team, this remarkable BEX just missed out of placing among the winners.

This BEX is an interesting game, which not only is a game, but also an interactive way to learn about Covid and how the body fights such diseases on its own. There is even music!

Awesome work done here and well worth the honorable mention.

Honorable Mention #2: Quasar Grouped Table

Author: Narcis13

This little AE is the last honorable mention. It shows how the AE system can also work for extended Quasar components. Need a grouped table? Just run quasar ext add q-grouped-table and you have it.

Conclusion:

Thanks again to all the participants. It was amazing to see the diversity of ideas, which just goes to show how Quasar can be used for practically any idea to make an application frontend a reality.

Those who won, would you please contact me via DM on Discord - Scott (EN-DE)#0052 - to arrange getting the prizes to you. Thanks!

Introducing Quasar.Conf

Scott Molinari — Wed, 03 Jun 2020 18:23:25 +0000

The first Quasar Conference - Online!

UPDATED: 30.06.2020
We asked the community where the conference should be held and we noticed Quasar is popular across the world. Also, with the Covid-19 situation, it just made good sense to have it online.

The Venue

You'll find us on Youtube Live!
Subscribe to the channel or click the "Set Reminder" button to get reminded of the conference's live stream.

Save the Date!

Sunday - July 5th, 2020 at 15:00 GMT

Current Speaker Line-up and Topics

Razvan Stoenescu - Quasar Lead Dev and Founder
@rstoenescu
CEO of Pulsardev SRL

Update: Razvan has fell ill, and won't be able to be present.

Guest Speakers

Natalia Tepluhina - Vue Core Dev
@N_Tepluhina
Staff frontend engineer at GitLab

Wondering how $attrs will behave in Vue 3? What should you do when you have a multi-root component? What is the new 'emits' component option and should you add it to all existing components when migrating to v3? Natalia will cover all these cases in her Lightning Talk.

Danny Connell - Quasar Content Contributor
@dannyconnell
Indie App Dev & Course Creator

Danny will demonstrate his neat PWA app called "Quasagram" - a gorgeous Instragram Clone built with Quasar & Firebase.

During the demo, he'll show how he integrated the following core PWA features into the app:

Precaching
Caching
Background Sync
Push Notifications
Home Screen Installation

If you are interested in building a PWA, then this is a must-see!

Joseph "Yev" Angeles - Full Stack Developer
@vycoder
Founder of Night Owl Studios

Yev is going to be demonstrating his Productivity App called "Qodo". He'll also be introducing some of the techniques he used with the intention of giving new developers coming to Quasar some inspiration via his experiences with developing the app.

Wilson Foo - Lawyer by Day, Developer by Night
@siauderman
Managing Director at Custom Automated Systems Pte Ltd

Wilson will also be demonstrating his Quasar-built "Covid Game" app. He designed it as a game, but it is also a learning experience about how the body copes and fights diseases. Wilson will be demonstrating how Quasar can even be used to build a game application. Quite exotic, but should be interesting.

Quasar Dev Speakers

Allan Gaunt - Quasar BEX Mode Lead and Senior Dev
@webnoob
Freelance Contractor

Have you heard about Quasar's new Browser Extension (BEX) mode which helps you build Browser Extensions with Quasar? Whether you have or not, Allan will introduce you to the new mode by demonstrating a neat little BEX he built and in doing so, show you how to get the most out of the new BEX mode. If you are a Quasar aficionado, you'll probably also want this BEX installed yourself!

Paolo Caleffi - Quasar TypeScript and Testing Lead and Senior Dev
@IlCallo
Co-founder and CTO at Dreamonkey

Looking into working with TypeScript, Jest and Cypress without the integration hassle? Paolo will explain why those tools are important for enterprises, how you can set them up in a Quasar project quickly and more.

Jeff Gallbraith - Quasar App Extension and ESLint Lead and Senior Dev
@hawkeye64
Sr. Lead Developer at Intelliview Technologies

Did you know Quasar is very extensible? Learn to build your first Quasar Framework App Extension as Jeff goes through the topics of using the Quasar Framework UI kit to build an app extension, demonstrates the power of render functions, how to best organize your code and test your work.

Scott Molinari - Quasar Marketing and Support Lead
Business Systems and CRM Sr. Manager at Terex

Moderator and Organizer of Quasar.Conf

Quasar and Browser Extension Development - Getting BEXy - Part 3

Scott Molinari — Thu, 30 Apr 2020 10:01:59 +0000

Part 3 - Building and Publishing your Extension

If you are coming here for the first time, please do start with the first Part, as it will get you started with Quasar and a BEX project.

This article series has 3 parts:

Part 1 - Introduction
Part 2 - Developing your Browser Extension
Part 3 - Building and Publishing your Extension (You are here now)

In the past part of the article, we went over our Todo app and how to program it as a browser extension (BEX) with Quasar's BEX mode of development. It was just a general run-through to get you familiar with how a Quasar app and the components are needed to make a browser extension work together.

Now that you have your latest and greatest app finished, it is ready to be offered to the rest of the world. To do that, it needs to be built and published.

Building your Project

This is probably the easiest part of process of creating a BEX and it is all because of Quasar's great CLI.

In your project's root/ working directory, simply run this command:

$ quasar build -m bex

# ..or the longer form:
$ quasar build --mode bex

Once the build process is finished, you should see something like this in your console showing the build was successful.

Go to the noted output folder to get your distributable app and publish it.

Publishing your Project

Ok, now that you have your project built for production and are in the newly created dist folder, have a look at what is waiting for you there under the Packaged folder.

There are two zip files under their respective folders for either the Chrome's Web Store or Firefox Add-on Extensions Store.

You can use these zip files to publish to those market places. Each market place has their own process and rules, so please do take care to learn about them.

Chrome Extension Publication

Firefox Extension Publication

In theory, the browser extension you have built should work in any other Chromium based browser, however only these two are currently 100% supported. If you are interested in support for other browsers, please let us know on Github. Better yet, become a contributor and help us develop BEX mode and the publication process for those other browsers!

Conclusion

That's it! You are off to the races as a new browser extension developer with Quasar's BEX mode.

What do you think of Quasar's new BEX mode? Are you intrigued by how simple it is in the end? We hope you are. Let us know about what you are thinking in the comments below.

For more Info:

The Quasar Website
More on BEX Mode
More about Icon Genie