DEV Community: Anthony Viard

Upgrading OtakuShelf to JHipster 9.1.0

Anthony Viard — Wed, 27 May 2026 21:43:08 +0000

JHipster 9.1.0 just dropped. For years, that sentence put a specific knot in Sam's stomach — version bumps meant a git-merge adventure, surprise conflicts, and the nagging fear of a file you'd customized getting quietly overwritten. OtakuShelf is on 9.0.0 and Sam actually likes it the way it is. So the real question isn't "how do I upgrade," it's "should I, and what will it cost me?" The agent can answer both before a single file changes.

First, how big is this really?

Sam starts by scoping it:

How risky is upgrading /Users/sam/projects/otakushelf to JHipster 9.1.0?

The upgrade_advisor tool reads OtakuShelf's .yo-rc.json and entity configs and reports back the shape of the jump:

current 9.0.0 → 9.1.0, a minor bump;
risk: low — no blueprints, a plain monolith, a handful of entities;
a couple of project-specific notes (nothing alarming here) and a short checklist;
links to the 9.1.0 release notes.

One thing Sam appreciates: the advisor doesn't invent a list of breaking changes. A minor release shouldn't have many, but for the authoritative word it points Sam at the release notes rather than bluffing. It gives the facts and the scope; the specifics live where they actually live. For a minor, low-risk bump, the verdict is "go for it" — but Sam still wants to see the damage first.

The preview that doesn't touch a thing

Show me what upgrading OtakuShelf to 9.1.0 would change.

This is the one Sam wishes had existed years ago. preview_upgrade regenerates OtakuShelf's own model in an isolated temp copy using generator 9.1.0 — fetched on the fly via npx generator-jhipster@9.1.0, so Sam doesn't even have to install it globally first — and diffs the result against the current project:

Upgrade preview → generator-jhipster@9.1.0:
  +1 added  -0 removed  ~14 modified
Added (1): ...
Modified (14): build dependency bumps, a few Vue components, Liquibase config, ...

OtakuShelf itself is never touched — it's a diff against a throwaway regeneration. And there's an honest caveat the tool states plainly: that modified list mixes two things — changes the new generator makes and files Sam has customized. Telling them apart is the real work of any JHipster upgrade. The difference now is that Sam sees the whole list up front, on a calm afternoon, instead of discovering it mid-merge at 11pm.

Fourteen modified files, mostly dependency bumps and regenerated boilerplate, nothing touching Sam's hand-edited Franchise view. This is a Tuesday, not an adventure.

Applying it Sam's way

Notice what the MCP did not do: it didn't run the upgrade. The official jhipster upgrade is a git-based merge, and this server stays deliberately out of your git — so it previews instead of merging. With the diff in hand, Sam drives the actual change through a normal workflow: commit the current state, run the upgrade (the agent can kick off jhipster upgrade through the escape hatch, or Sam runs it by hand), and resolve the handful of spots the preview already flagged. Because Sam committed first and knew the blast radius in advance, the merge is a quick, confident review rather than a leap of faith.

A ./mvnw verify and an npm test later (the MCP told Sam those commands back in part 1, remember), OtakuShelf is happily running on 9.1.0.

What Sam got out of the experiment

Four sittings ago, OtakuShelf was an empty folder and a vague idea, and Sam was skeptical about letting an AI near a generator. Now there's a paginated, DTO-backed catalog of manga and anime — scaffolded, grown, polished, and version-bumped — and at no point did the agent's involvement mean less control. The pattern that emerged was simple and stuck:

describe the change in plain language;
validate and dry-run before touching the project — for free, because the MCP previews by isolation, not by trusting a flag that lies;
apply, occasionally with a backup;
and let the agent read the real project so its edits stay surgical.

The MCP didn't replace Sam's JHipster judgment. It deleted the friction around it — the JDL typing, the CLI prompts, the upgrade dread — and left the decisions where they belong.

That's the shelf built. Time to actually add some manga to it. 📚

Want the precise arguments and edge cases behind any of this? The story motivates; the docs specify — start with the tools reference. And the server itself: jhipster-mcp on npm.

Polishing the catalog (and reading the agent's receipts)

Anthony Viard — Wed, 27 May 2026 21:42:51 +0000

OtakuShelf models everything now, but it's a prototype with prototype habits: the anime entities Sam added last week aren't paginated, there are no DTOs anywhere, and — Sam just noticed while adding Attack on Titan — there's nowhere to record that a franchise comes from Japan vs. Korea vs. wherever. Time for a polish pass. And since OtakuShelf is a real project Sam has hand-tweaked, this is also where a safety net earns its keep.

Making it look production-shaped

First, consistency. Sam wants pagination on the new anime entities too, and a DTO + service layer across the board so the API isn't exposing entities directly:

In /Users/sam/projects/otakushelf, paginate every entity, and put all of them behind MapStruct DTOs and a service layer.

The agent reaches for set_option, the tool for exactly these JDL option lines, and applies:

paginate * with pagination
dto * with mapstruct
service * with serviceClass

Same dryRun habit from last time — Sam previews, sees it's just regenerating resource/service layers and Vue services, and applies. Nothing dramatic, which is the point: option changes should be boring.

The field Sam forgot

Now the missing field. This is the moment that makes people nervous about regenerators — Sam has hand-edited the Franchise Vue detail view and hasn't committed yet. Adding a field means re-running the generator with --force over files Sam touched. So Sam asks for a belt and suspenders:

Add an originCountry (string) to Franchise. Take a backup first so I can roll back if it stomps my edits.

Two things happen. The agent reads the current Franchise (via the project's entities resource) and re-declares it with all its existing fields plus originCountry — re-declaring an entity in JDL replaces it, and the agent knows not to emit a half-defined one, so title/synopsis/status/startYear survive. And because Sam asked for a backup, the server snapshots the project into a temp folder before the --force run and hands back a paste-ready escape route:

Backup taken before this run: /tmp/jhipster-mcp-backup-otakushelf-9fA2
To roll back:
  cp -R "/tmp/jhipster-mcp-backup-otakushelf-9fA2/." "/Users/sam/projects/otakushelf/" && rm -rf "/tmp/jhipster-mcp-backup-otakushelf-9fA2"

It's a plain backup directory, not git — the MCP never touches Sam's repo. (Honestly, if Sam's tree had been clean, a commit would've done the same job; the backup is for exactly this not-committed-yet situation.) As it turns out the regeneration is clean and Sam's edit survives, so the backup goes unused — which is the best kind of safety net.

Reading the receipts

Sam doesn't take "done!" on faith. Every time the agent runs the generator, the MCP hands back two things: the human-readable output Sam knows from the terminal, and a small structured summary the agent actually reasons over — exit code, success flag, the list of files changed, any warnings, and (when taken) that backup path. So when the agent reports "added originCountry, 9 files changed, no conflicts," it's reading those numbers off real data, not vibing. That's why Sam can trust a one-line summary instead of re-reading a wall of create/force lines.

For a broader sanity check, Sam asks for the dashboard:

What's the current setup of OtakuShelf — versions, database, entities?

The info tool runs jhipster info and lays it out: JHipster 9.0.0, PostgreSQL, and the full entity list — Franchise, BookSeries, Book, Anime, Season, Episode. Everything Sam expects, nothing it doesn't. (There was also a steady trickle of progress lines during each generation, by the way — so the longer runs never felt like a hang, just JHipster doing its thing.)

Where this is going

OtakuShelf is now a tidy, paginated, DTO-backed catalog of manga and anime, and Sam has a comfortable rhythm: describe the change, validate, dry-run, apply, occasionally with a backup. Then JHipster ships 9.1.0. In the old days that release note would trigger a small dread. Next, Sam finds out whether an agent makes a version upgrade boring too.

Next in the series: "Upgrading OtakuShelf to JHipster 9.1.0" — scoping and previewing a version bump, git-free, before a single file changes.

Adding the anime side without holding my breath

Anthony Viard — Wed, 27 May 2026 21:42:34 +0000

A week later, OtakuShelf has a few franchises and their manga in it. Now Sam wants the other half: anime. That means new entities — Anime, Season, Episode — wired into the existing Franchise. The difference from last time is important: this is a live project with data and a model Sam cares about. Running the generator blind on it is how you end up with a clobbered entity and a bad afternoon. So Sam slows down by exactly one habit: preview first.

A quick gut-check before anything else

Before even applying, Sam sketches the new shape and asks the agent to validate it:

Validate this without changing anything: an Anime (title, studio) linked many-to-one to Franchise, a Season (number, title, episode count) under an anime, and an Episode (number, title, air date, duration in minutes) under a season.

The validate_jdl tool runs a fast local lint first (is the JDL even well-formed?), then generates the whole thing in a throwaway directory and reports any error — all without touching OtakuShelf. It comes back clean. Good: the idea is sound. Now, what would it actually do to the project?

The dry run that's actually dry

Here's the part every JHipster veteran needs to hear, because it bit us too: in JHipster 9, --dry-run still writes files. It only prints conflicts. So you cannot trust that flag to keep your project pristine.

The MCP sidesteps the whole problem. When Sam asks for a preview:

In /Users/sam/projects/otakushelf, show me what adding the anime entities and their relationships would change — don't write anything yet.

…the agent calls the apply tool with dryRun: true, and the server does something more honest than a flag: it makes a temp directory, copies OtakuShelf's .yo-rc.json and existing entities into it for fidelity, generates there, lists what would change, and throws the temp away. The real project sees zero writes. Sam reads the file list — new Anime, Season, Episode sources, updated Liquibase changelogs, a couple of Vue components — nods, and only then drops the dryRun. The exact same call, now for real.

This is the rhythm Sam settles into for the rest of the project: validate → dry-run → apply. It costs a few seconds and removes all the adrenaline.

The agent already knows the shelf

There's a quieter thing happening that makes this safe. When Sam says "link Anime to Franchise," the agent doesn't guess what Franchise looks like — it reads the project's current entities through a resource (jhipster://project/entities). So it knows Franchise already exists with its title/synopsis/status/startYear, and it adds the relationship without redefining and accidentally trimming those fields. It's working from the real model, not from a fuzzy memory of last week's chat.

For this batch Sam lets the agent do it all in one shot — three new entities and their relationships belong together, so the agent composes a single import_jdl call instead of three separate ones:

entity Anime { title String required, studio String }
entity Season { number Integer required min(1), title String, episodeCount Integer min(0) }
entity Episode { number Integer required min(1), title String, airDate LocalDate, durationMinutes Integer min(0) }

relationship OneToMany {
  Franchise{animes} to Anime{franchise}
  Anime{seasons} to Season{anime}
  Season{episodes} to Episode{season}
}

One generator run, one diff to review. (If Sam had wanted just a single entity, there's an add_entity tool that builds the JDL from a plain description — handy for one-offs. For a coordinated batch like this, one import_jdl is tidier and faster.)

Why the preview habit pays off here specifically

The anime side touches the manga side — Franchise gains an animes collection. That's precisely the kind of cross-cutting change where a blind regeneration makes you nervous. With the dry run, Sam saw in advance that Franchise.java and its Vue views would be regenerated, confirmed nothing surprising was in the list, and proceeded with a clear conscience. The MCP didn't make the change safe by being clever; it made it safe by letting Sam look first, for free, as many times as wanted.

Where this is going

OtakuShelf now models both halves of a franchise — manga and anime — from Franchise down to individual Episodes. It works, but it's a little rough: no DTOs, and Sam already realized a field is missing. Next, the polish pass — and a look at how to read what the agent actually did to your code.

Next in the series: "Polishing the catalog (and reading the agent's receipts)" — options, a forgotten field with a backup, and trusting what the agent did.

Pairing up: scaffolding OtakuShelf with an agent

Anthony Viard — Wed, 27 May 2026 21:41:51 +0000

Sam has shipped a dozen JHipster apps the old-fashioned way: open an editor, write the JDL, run the CLI, answer its questions, repeat. This time Sam wants to try something different — keep the JHipster expertise, but hand the typing to an AI agent. The guinea pig is a personal project that's been on the back burner forever: OtakuShelf, an app to catalog manga and anime, grouped by franchise. Naruto is one franchise — it has a manga side and an anime side, and Sam wants both under one roof.

The agent needs hands

An AI agent is great at turning "a franchise has many book series" into correct JDL. What it can't do on its own is run your jhipster binary. That's the gap the JHipster MCP fills: it's a small server that exposes JHipster to the agent as a set of safe actions. Three flavors, and that's the whole mental model:

tools — things the agent does (scaffold, add an entity, validate);
resources — things the agent reads (the JDL grammar, your project's current entities);
prompts — ready-made recipes you launch.

Crucially, it doesn't bundle JHipster — it drives the same global jhipster Sam already has (version 9.0.0 here). So nothing about the generator changes; the agent just operates it, non-interactively.

Wiring it into Sam's editor is one line:

claude mcp add jhipster -- npx -y jhipster-mcp

Restart, confirm the tools show up, done. (Other hosts and options live in the install guide.)

One sentence, one monolith

Sam decides to start with just the manga side — get the shape right before piling on anime. So:

Create a JHipster monolith in /Users/sam/projects/otakushelf called otakushelf: JWT auth, PostgreSQL in prod with H2 in dev, Vue, Maven, package com.otakushelf. Add a Franchise (title, synopsis, a status that's ONGOING/COMPLETED/HIATUS, start year), a BookSeries (title, total volumes), and a Book (title, volume number, release date). A franchise has many book series; a book series has many books. Paginate everything.

The agent first glances at the jhipster://docs/jdl-grammar resource so it doesn't fumble syntax, then builds one JDL document and calls the create_app_from_jdl tool with roughly:

application {
  config {
    baseName otakushelf
    applicationType monolith
    authenticationType jwt
    databaseType sql
    prodDatabaseType postgresql
    devDatabaseType h2Disk
    clientFramework vue
    buildTool maven
    packageName com.otakushelf
  }
  entities *
}

enum FranchiseStatus { ONGOING, COMPLETED, HIATUS }

entity Franchise { title String required, synopsis TextBlob, status FranchiseStatus, startYear Integer }
entity BookSeries { title String required, totalVolumes Integer min(0) }
entity Book { title String, volumeNumber Integer required min(1), releaseDate LocalDate }

relationship OneToMany {
  Franchise{bookSeries} to BookSeries{franchise}
  BookSeries{books} to Book{bookSeries}
}

paginate * with pagination

A minute later (PostgreSQL, a Vue front-end, and an npm install aren't instant), OtakuShelf exists. Sam didn't write a line of JDL — but, being Sam, read every line the agent did.

"Here" is not a place

One habit to build immediately: the MCP has no current directory. Every tool wants an absolute workingDirectory, and create_app_from_jdl flatly refuses to scribble into a folder that isn't empty. "Make me an app here" goes nowhere; "make me an app in /Users/sam/projects/otakushelf" works. Say where, every time. (It's also a nice guardrail — the agent can't wander off and generate in some surprising place.)

Okay, how do I actually run this thing?

The files exist, but the MCP draws a hard line: it scaffolds and edits, it does not build, run, start, or git-commit your app. That's your shell's job, on purpose. So Sam asks the obvious follow-up:

What are the build and run commands for /Users/sam/projects/otakushelf?

The project_commands tool reads the project and answers from facts — it sees Maven with the wrapper present and a Vue package.json, so it reports ./mvnw to start the backend, npm install then npm start for the Vue dev server, ./mvnw verify for tests, and so on — and reminds Sam it's reporting these, not running them. Two terminals later, OtakuShelf is live at localhost:8080, empty and waiting for its first franchise.

Where this is going

In one sitting Sam went from empty folder to a running, paginated CRUD app for the manga side — by describing it, not typing it. But a catalog of manga without anime is only half a shelf. Next, Sam comes back to a live project to add the anime side — and that's where a careful developer reaches for previews before touching anything.

Next in the series: "Adding the anime side without holding my breath" — coming back to a live project to add the anime entities, previewing every change first.

Drive JHipster with your AI agent: introducing jhipster-mcp (v0.0.4)

Anthony Viard — Tue, 26 May 2026 23:08:35 +0000

TL;DR — jhipster-mcp is an open-source Model Context Protocol server that lets an AI agent generate and evolve JHipster applications for you. You describe what you want in plain language; the agent writes JDL and drives the JHipster CLI. It's on npm — point your MCP host at it with one line. v0.0.4 is the first public release.

📦 npm: https://www.npmjs.com/package/jhipster-mcp
🧑‍💻 GitHub: https://github.com/avdev4j/jhipster-mcp

The idea

JHipster has always been about speed: scaffold a production-grade Spring Boot + modern frontend app in minutes, model your domain with JDL (JHipster Domain Language), and let the generator write the boilerplate.

AI coding agents are great at intent: you tell them what you want, they figure out the steps.

jhipster-mcp connects the two. It exposes JHipster as a set of MCP tools an agent can call. So instead of remembering JDL syntax and CLI flags, you say:

"Create a JHipster monolith in /tmp/shop with PostgreSQL and an Angular frontend, plus a Product entity (name, price) and a Category with a one-to-many to products. Paginate everything."

…and the agent composes valid JDL, runs the generator, and streams the result back.

Goals

Make JHipster conversational. Natural-language intent → correct JDL → real generated code.
Stay safe and predictable. Non-interactive, no shell, validated input, no surprise writes.
Be machine-friendly. Return structured results an agent can reason about, not just logs.
Lean on JHipster, don't reinvent it. It spawns your JHipster CLI; the generator stays the source of truth.

Who it's for

JHipster developers who want to scaffold and evolve apps faster from their AI editor.
Teams standardising on JHipster who want guardrails around how the generator is invoked.
AI / MCP tinkerers curious about wrapping a real, stateful developer CLI as MCP tools.

If you use Claude Code, Claude Desktop, Cursor, or any MCP-compatible host, you can plug it in today.

What you can do with it

The server ships 9 tools, JDL-first:

Tool	What it does
`create_app_from_jdl`	Scaffold a brand-new app from a full JDL block.
`import_jdl`	Apply JDL (entities, relationships, options) to an existing project.
`add_entity`	Add one entity with fields, validations, and per-entity options.
`add_relationship`	Add a typed relationship between two entities.
`set_option`	Toggle JDL options (`paginate`, `dto`, `service`, `search`, …).
`validate_jdl`	Check JDL for errors without modifying anything.
`generate_ci_cd`	Scaffold a CI/CD pipeline (GitHub, GitLab, Jenkins, …).
`info`	Inspect project versions, config, and entities.
`run_jhipster`	Escape hatch — run an allowlisted subcommand safely.

It also exposes a JDL grammar cheat-sheet as an MCP resource, so the agent writes valid JDL on the first try.

What's in v0.0.4 — the highlights

This first release focuses on making every tool call trustworthy and legible to the agent:

🔄 Live progress streaming

Full app generation can take 30–90 seconds. Instead of looking frozen, the server streams the generator's output as MCP progress notifications in real time.

✅ Validation + a true dry-run

You can validate JDL or preview a change without touching your project.

There's a fun gotcha here: JHipster's own --dry-run flag only prints conflicts — it still writes files (I confirmed this against the real CLI). So a flag-based "preview" would silently modify your project. jhipster-mcp instead does a real preview: it generates in a throwaway temp directory (copying your project's .yo-rc.json and .jhipster/ for context), parses what would be produced, and discards everything. Your project is never modified.

📦 Structured output

Every tool returns machine-readable JSON alongside the human-readable text, so the agent reasons on data instead of scraping logs:

{
  "command": "jhipster jdl changes.jdl --force --skip-git",
  "exitCode": 0,
  "success": true,
  "dryRun": false,
  "entities": ["Customer", "Order"],
  "filesChanged": [{ "action": "create", "path": "src/main/java/..." }],
  "warnings": []
}

Why it's safe by design

No shell. The CLI is spawned with shell: false and an argument allowlist — no command injection.
Validated JDL builders. Entity/field/type names are checked against strict patterns before any JDL is written.
Non-interactive always. Runs with --force --skip-git and CI=true; never hangs on a prompt.
Bounded. Every tool takes an explicit workingDirectory; the server won't act outside it.

Under the hood it's TypeScript on the official MCP SDK, with 70 tests and CI on Node 22/24.

How to use it

1. Prerequisites

Node.js 20+
A working global JHipster CLI:

  npm install -g generator-jhipster
  jhipster --version

2. Add it to your MCP host

Claude Code:

claude mcp add jhipster -- npx -y jhipster-mcp

Claude Desktop / Cursor / others — add to your MCP config:

{
  "mcpServers": {
    "jhipster": {
      "command": "npx",
      "args": ["-y", "jhipster-mcp"]
    }
  }
}

No clone, no build — npx fetches and caches the package for you.

3. Just ask

"In /Users/me/projects/shop, add a Customer entity with firstName (required, 2–50 chars), lastName, and email, then a one-to-many from Customer to Order."

The agent reads the JDL grammar, builds the snippet, and applies it — streaming progress as it goes.

Want to look before you leap? Ask it to preview first:

"Show me what adding a Tag entity would change — don't write anything yet."

…and it runs the same tool with dryRun: true.

What's next

This release completes the "Tier 1" experience work (progress, validation/dry-run, structured output). On the roadmap:

Project-state resources — let the agent read .yo-rc.json, the entity list, and exported JDL directly.
Guided prompts — reusable workflows like "scaffold a CRUD monolith" or "convert to microservices".
Safe-apply with rollback, elicitation for missing config, and sandboxing.

Try it

npx -y jhipster-mcp@0.0.4

⭐ Star it, break it, and tell me what's missing: https://github.com/avdev4j/jhipster-mcp

Built with ❤️ for the JHipster community.

#jhipster #ai #mcp #java #springboot #opensource

The AI Triforce of seed4j: Power, Wisdom, and Courage for Your Dev Agent

Anthony Viard — Mon, 25 May 2026 11:12:20 +0000

The AI Triforce of Seed4j: Power, Wisdom, and Courage for Your Dev Agent

In the Legend of Zelda, the Triforce is the ultimate relic: three golden triangles that together grant the wish of whoever holds them. Alone, each fragment is dangerous in the wrong hands. Together, they bring balance to Hyrule.

I've been thinking about Seed4j's relationship with AI agents through that lens. Not as a finished story, but as a reflection. What would it take to make Seed4j truly AI-native? What are the three fragments we need to forge?

This article is that reflection.

Seed4j is an open-source application generator built around hexagonal architecture. It scaffolds the structure (ports, adapters, configuration, modules) but deliberately stops there. It has never generated business code, and that's a conscious design decision. The domain logic belongs to the developer. Seed4j hands you a well-structured, empty shell, and you fill it.

At the era of AI agents, that boundary gets interesting. An agent can write business code. The question is: can Seed4j guide it to do so correctly, within its own philosophy? Can the agent become the missing piece, not replacing Seed4j's intentional silence, but completing it?

That's what led me to think about three principles: the MCP (Power), the Harness (Wisdom), and the Skills (Courage). Together, they sketch what a Seed4j augmented might look like, an AI-compatible version of the project, without betraying what makes it Seed4j.

Fragment 1: The MCP, The Triforce of Power

"Power without direction destroys. Power with the right interface builds."

The first question is simple: how does an AI agent actually do something with Seed4j, rather than just talk about it?

The answer is a Model Context Protocol server, seed4j-mcp. MCP is an open standard that lets AI agents call tools exposed by external servers. Instead of a human typing commands into a CLI, an MCP-aware agent (Claude Code, Claude Desktop, Cursor, and others) can discover and invoke Seed4j's functionality directly.

The seed4j-mcp server exposes a set of tools that map to the full Seed4j workflow:

Tool	Purpose
`list_modules`	List every available module, grouped by category
`search_modules`	Keyword search across slugs, descriptions, and tags
`get_module_details`	Property definitions for a given module
`get_module_dependencies`	Prerequisite graph before applying a module
`validate_properties`	Dry-run schema check (no side effects)
`list_presets`	Curated pre-ordered stacks (e.g. "Webapp: Vue + Spring Boot")
`apply_preset`	Resolve a preset and apply all its modules in one call
`create_project`	Initialize a new base project
`apply_modules`	Apply an ordered list of modules in a single batch

A typical agent flow: list_presets → get_preset_details → apply_preset. Or for a custom stack: search_modules → get_module_dependencies → validate_properties → apply_modules.

The MCP server acts as a boundary layer. The agent doesn't need to understand Seed4j's internals, it just needs to know what tools exist and what they accept. Every action goes through a defined, typed interface. Power, channeled.

🗡️ What could be done

Publish seed4j-mcp to the official MCP registry, so any agent, regardless of the client, can discover and wire up Seed4j with a single reference. This is the lowest-friction path to making Seed4j a first-class citizen in the AI agent ecosystem.

Fragment 2: The Harness, The Triforce of Wisdom

"Wisdom is knowing where you are, what the rules are, and what not to touch."

Even with the right tools, an agent can still drift. It might apply modules out of order, ignore architectural conventions, or, worse, start writing code where it doesn't belong. Raw power without wisdom is Ganondorf with the Triforce: capable of anything, guided by nothing.

The Harness is how we give the agent a sense of place.

In practice, a harness is a set of files that speak directly to the agent, not documentation written for humans but context written for AI. The most common form today is a file like CLAUDE.md, which Claude Code reads automatically at the start of every session. It tells the agent what the project is, what conventions govern it, and what it should or should not attempt on its own.

Here's where Seed4j has an interesting starting point: it already generates a /documentation folder inside every project. That folder contains explanations of the hexagonal architecture, the module system, and how the generated structure is meant to be used. It was written for developers, but it could become the foundation of an AI-oriented harness.

That's the gap worth closing. The documentation exists, but it wasn't designed with an agent in mind. An AI-ready harness would go further: explaining not just what Seed4j generated, but how an agent should reason about it. Which parts of the codebase are Seed4j's territory (don't touch), which parts are the agent's responsibility (the domain), and where the boundary between the two sits.

This matters because Seed4j's hexagonal structure has a clear separation of concerns (ports, adapters, domain, application layer) and an agent that doesn't understand that separation will eventually violate it. Not out of malice, but out of ignorance. The harness is what turns ignorance into awareness.

🗡️ What could be done

Generate an AI-oriented documentation layer alongside the existing /documentation folder, in a dedicated /ai-context (or similar) that describes the architecture, the conventions, and the agent's role in terms an LLM can act on. Unlike the existing docs, this wouldn't be written for a developer to read linearly; it would be structured to be loaded as context at the start of an agent session, answering the questions the agent would otherwise guess at.

📄 Example: .ai/context.md generated by Seed4j

# Seed4j Project Context

> This file is auto-generated by Seed4j. Do not edit manually.
> Re-generated on every `seed4j apply` command.
> Applied modules history: see `.seed4j/modules/history.json`

## Project
- Name: my-app
- Architecture: Hexagonal (Ports & Adapters)

## Package structure
com.example.myapp
├── domain/
│   ├── model/         ← business entities, pure Java, no framework
│   └── port/
│       ├── in/        ← use case interfaces (input ports)
│       └── out/       ← repository interfaces (output ports)
├── application/       ← use case implementations
└── infrastructure/
    └── adapter/
        ├── in/rest/   ← REST controllers (Spring MVC)
        └── out/persistence/ ← JPA repositories and entities

## What Seed4j owns — do not modify
- All configuration files (application.yml, pom.xml, Docker files)
- Infrastructure wiring and module setup
- Base package structure and adapter boilerplate

## What you (the agent) are responsible for
- Domain model: entities and value objects in domain/model/
- Ports: use case and repository interfaces in domain/port/
- Use cases: business logic implementations in application/
- Adapters: framework wiring in infrastructure/adapter/

## Rules
- NEVER import infrastructure or framework classes into domain/ or application/
- NEVER implement business logic in adapters
- ALWAYS go through a port interface, never call an adapter directly
- Run `./mvnw test` after each implementation step

## Available skills
- .ai/skills/hexagonal-feature.md  → implement a business feature end-to-end
- .ai/skills/apply-module.md       → safely apply a new Seed4j module
- .ai/skills/tdd-domain.md         → TDD workflow for domain logic

💡 There is no universal standard for AI context folders yet. .ai/ is a pragmatic choice: readable, non-conflicting with existing tools, and scoped to the project. A root-level CLAUDE.md or AGENTS.md can simply point to .ai/context.md for compatibility with agents that expect a specific filename.

Fragment 3: The Skills, The Triforce of Courage

"Courage isn't acting blindly. It's knowing the path and walking it, step by step."

This is where the reflection gets most interesting, and where Seed4j's design philosophy creates the most productive tension.

Seed4j gives you a shell. A well-architected, hexagonal, configuration-complete shell, but a shell. It has never generated business logic, and it never will. That's not a limitation; it's a statement. The domain belongs to the developer.

But here's the question worth sitting with: if an AI agent can write the domain code, who teaches it to do so correctly within Seed4j's framework?

That's the role of Skills: not tools (those are the MCP's job), not context (that's the Harness), but workflow. Step-by-step guidance for complex, multi-stage tasks that live in the space Seed4j deliberately leaves empty.

Link didn't walk into Ganon's castle on day one. He completed the dungeons in order, acquired the right items, and followed the critical path. A skill is the dungeon map: a structured sequence the agent follows to reach a goal without going off the rails.

For Seed4j, skills could operate at two levels:

Module-level skills: guiding the agent through the correct application of Seed4j modules. Apply in the right order, resolve dependencies, validate before committing. This is the mechanical layer: making sure the shell is assembled correctly before writing a single line of business code.

Feature-level skills: this is the more ambitious and more interesting layer. A skill that guides an agent through implementing a business feature the Seed4j way: domain object first, then the use case, then the port, then the adapter, tests at every step. Or a TDD-oriented skill: write the failing test, implement the minimum domain logic, make it pass, then wire the infrastructure. All of it respecting the hexagonal boundaries that Seed4j established.

The agent doesn't replace the developer's judgment, it follows a workflow that encodes that judgment. Seed4j's silence on business code wasn't a gap; it was a boundary. Skills are what allow an AI agent to operate inside that boundary without erasing it.

🗡️ What could be done

Develop a library of Seed4j skills for common agent workflows, starting with the most frequent pain points:

Module application skill: apply a module correctly, resolve its dependency graph, validate before committing.
Hexagonal feature skill: implement a business feature end-to-end following the hexagonal layering Seed4j establishes.
TDD skill: red-green-refactor loop with an AI agent, domain-first, infrastructure last.

These skills would live in the Seed4j ecosystem and be referenced by the harness, so the agent knows they exist and when to invoke them.

📄 Example: hexagonal-feature.md skill

# Skill: Implement a Hexagonal Feature

## Goal
Guide the agent through implementing a business feature
respecting Seed4j's hexagonal architecture boundaries.

## Prerequisites
- Project initialized with Seed4j base module
- Persistence module applied (`seed4j apply persistence`)

## Steps

### 1. Define the domain object
- Create the entity in `src/main/java/{package}/domain/model/`
- Pure Java: no framework annotations, no infrastructure imports
- Write a unit test before implementing (red phase)

### 2. Define the ports
- Create the input port (use case interface) in `domain/port/in/`
- Create the output port (repository interface) in `domain/port/out/`
- Ports are Java interfaces only, no implementation here

### 3. Implement the use case
- Implement the input port in `application/`
- Inject the output port by interface, never the adapter directly
- Write the unit test (mock the output port), then implement

### 4. Implement the adapter
- Persistence adapter in `infrastructure/adapter/out/persistence/`
- REST adapter (if REST module applied) in `infrastructure/adapter/in/rest/`
- Wire to the framework (JPA, Spring MVC, Quarkus REST...)

## Rules
- NEVER import infrastructure classes into `domain/` or `application/`
- NEVER skip the port layer to call an adapter directly
- ALWAYS write the failing test before the implementation
- If a layer doesn't exist yet, check which Seed4j module provides it

## Notes
This skill is available because the persistence module is applied.
If the REST module is also applied, expose the use case via a REST adapter in step 4.

The Triforce, Complete

These three fragments are not independent: they form a system, and each one only makes full sense in relation to the others.

The MCP (Power) gives the agent the ability to act on Seed4j. The Harness (Wisdom) anchors it in the reality of the project: its architecture, its conventions, its boundaries. The Skills (Courage) guide it through the workflows that Seed4j intentionally leaves to the developer, without violating the philosophy that makes Seed4j what it is.

Strip any fragment away and the balance breaks. Power without Wisdom is chaos. Wisdom without Courage is paralysis. Courage without Power is intention without effect.

What excites me about this vision is that it doesn't ask Seed4j to become something it's not. It doesn't generate business code, the agent does. It doesn't instruct the developer, the skills do. Seed4j remains the generator of structure. The Triforce is what makes that structure legible to an agent, navigable in its architecture, and extensible through AI-guided workflows.

This is a reflection, not a roadmap. But it feels like the right direction for a Seed4j augmented, a version of the project where AI agents are first-class participants, not afterthoughts bolted on from the outside.

The fragments are out there. Time to find them.

Seed4j is an open-source application generator. The MCP server is available at github.com/avdev4j/seed4j-mcp.

Let Your AI Agent Scaffold Apps With seed4j-mcp

Anthony Viard — Mon, 18 May 2026 20:51:07 +0000

If you've ever bootstrapped a Spring Boot + Vue project by hand, you know the routine: pick a build tool, glue in a frontend, add JPA, choose a database driver, wire Liquibase, remember the Maven wrapper, look up that one annotation for the seventh time this year. By the time you reach initial commit, half your motivation is gone.

seed4j already solves most of that. It's an open source application generator that applies modules to a project folder — click click click, project done.

But seed4j is still a tool a human drives. You read the docs, you pick the module slugs, you remember whether the property is packageName or basePackage this release. Fine, but not exactly thrilling.

seed4j-mcp is a Model Context Protocol server that hands seed4j to your AI agent instead. Plug it into Claude Code, Claude Desktop, or Cursor, and the agent can:

browse the seed4j catalog,
pick a coherent stack,
validate properties before applying anything,
and scaffold a project end to end.

You stay in the conversation. The agent does the orchestration.

Heads up — this is an alpha. seed4j-mcp is a fresh first release. The tool surface, defaults, and behavior may change as feedback comes in. It's stable enough to play with, but don't wire it into anything critical yet. Bug reports and suggestions are very welcome.

How the pieces fit together

seed4j-mcp is intentionally thin. Three components:

A running seed4j instance — the actual generator, reachable over HTTP (default http://localhost:1339).
seed4j-mcp — a Node.js MCP server that translates MCP tool calls into seed4j REST calls.
Your MCP client — Claude Code, Claude Desktop, Cursor, etc., speaking MCP over STDIO to seed4j-mcp.

[Claude Code] ⇄ STDIO ⇄ [seed4j-mcp] ⇄ HTTP ⇄ [seed4j server]

That separation matters: seed4j-mcp does not embed seed4j as a library. It's a translator. seed4j can evolve on its own and the MCP server keeps doing its job — no version-pinning gymnastics.

One implementation detail worth knowing: seed4j-mcp speaks MCP over STDIO. The MCP framing lives on stdout, which means anything else writing to stdout will corrupt the stream and your MCP client will hang. The server routes its startup errors to stderr for that reason. If you fork the project and add logging, use console.error or write to a file — never console.log.

Tutorial

Prerequisites

Three things on your machine:

Node.js 20+ — seed4j-mcp ships as an npm package and runs under Node (yes, even if you're a Java person).
A running seed4j instance — see the seed4j docs for how to start one. Default URL: http://localhost:1339.
An MCP-aware client — I'll use Claude Code, but Claude Desktop and Cursor work the same way.

Quick sanity checks:

node --version            # v20.x or newer
curl http://localhost:1339/api/modules | head -c 200

If the curl call returns JSON, you're ready.

Getting started

You don't need to install seed4j-mcp globally. The package is published on npm and the recommended pattern is to let your MCP client launch it on demand via npx. First run pulls it down, later runs use the cache.

If you'd rather install it globally:

npm install -g seed4j-mcp

Or build from source if you want to contribute:

git clone https://github.com/avdev4j/seed4j-mcp.git
cd seed4j-mcp
npm install
npm run build

Run it with Claude Code

Claude Code has an mcp subcommand built for exactly this. Pick a scope based on how widely you want the server available:

# Local: just you, this project (default scope)
claude mcp add seed4j -- npx -y seed4j-mcp

# Project: committed to .mcp.json, shared with collaborators
claude mcp add seed4j --scope project -- npx -y seed4j-mcp

# User: available across all your projects on this machine
claude mcp add seed4j --scope user -- npx -y seed4j-mcp

Running seed4j on a non-default URL? Pass it as an env var:

claude mcp add seed4j --env SEED4J_BASE_URL=http://localhost:7471 -- npx -y seed4j-mcp

Verify the server is wired up:

claude mcp list

Restart Claude Code and the tools become available to the agent automatically.

Run it with Claude Desktop or Cursor

Both clients read a JSON config. Add an entry pointing at the npx entrypoint:

{
  "mcpServers": {
    "seed4j": {
      "command": "npx",
      "args": ["-y", "seed4j-mcp"],
      "env": {
        "SEED4J_BASE_URL": "http://localhost:1339"
      }
    }
  }
}

Restart the client and you're done.

Example usages

The real test is what the agent does once the tools are available. A few prompts that exercise different flows.

1. "Scaffold a Spring Boot + Vue webapp"

The curated stack path. You name the vibe, the agent picks a preset. Under the hood it will:

Call list_presets to see what's on offer.
Pick the one that matches (e.g. "Webapp: Vue + Spring Boot").
Call get_preset_details for the ordered module list.
Call create_project to initialize the folder.
Call apply_preset to apply every module in order with a shared property map.

Your prompt is one line:

Scaffold a new project at /tmp/my-webapp using a Vue + Spring Boot preset. Use com.example.webapp as the Java package and mywebapp as the base name.

2. "I want a custom stack, not a preset"

The custom stack path. The agent will:

search_modules to find candidates matching your description.
get_module_dependencies to learn the prerequisite ordering and any feature choices (yes, you have to pick a datasource flavor — the agent won't guess for you).
validate_properties to dry-run the property map before touching the filesystem.
apply_modules to apply the full ordered list in one batch, stopping at the first failure.

Example prompt:

Create a Java library project at /tmp/my-lib with Maven, Jacoco, and SonarQube wired up. Package com.example.lib.

3. "What's already in this project?"

When the folder exists, get_project_status tells the agent which modules have been applied and what properties are in play — so it suggests sensible next steps instead of stomping over existing state:

Look at /tmp/my-webapp and tell me what's wired up. What would you suggest adding next?

4. "Show me the catalog"

You can also use the agent as a guided browser. It will reach for search_modules and get_module_details and summarize the catalog:

What persistence modules does seed4j support? Compare Postgres, MySQL, and MongoDB options.

Available tools

The agent gets a small but expressive toolbox covering module discovery, preset lookup, property validation, and project application. Rather than reproducing the full list here (and watching it drift the next time a tool is added), check the up-to-date catalog directly in the repo:

github.com/avdev4j/seed4j-mcp

The README lists every tool with the description the agent actually sees.

See it in action

If you'd like to see what a project scaffolded through seed4j-mcp actually looks like, here's one I generated:

avdev4j/seed4j-mcp-sample-app

It's the output of a real agent session — useful as a reference for the kind of structure, files, and module combination you can expect when you hand the wheel to your AI agent.

Wrapping up

Application generators have always traded flexibility for speed: faster than handcrafting, less flexible than writing it yourself. Putting an LLM in front of one tips the balance — the agent handles orchestration, and you stay at the level of "build me a Java library with Jacoco and SonarQube". No memorizing slugs, no fighting property names.

And the scaffolded project isn't a dead drop. seed4j writes a documentation/ folder alongside the code with the conventions, code style, and recommendations specific to the modules you applied. That folder is a goldmine for the next step: pointing your AI agent at it while you write the business code keeps the generated structure and the hand-written code coherent — same package layout, same patterns, same style — instead of the usual drift between bootstrapped scaffolding and the features you add on top.

seed4j-mcp is Apache 2.0. Source at github.com/avdev4j/seed4j-mcp, published on npm as seed4j-mcp. Issues, PRs, and creative stack requests welcome.

If you ship something with it, I'd love to see it.

Composable Apps security practices with Entando on Kubernetes, featuring Ippon expert

Anthony Viard — Fri, 27 Jan 2023 14:23:36 +0000

Building composable apps means, without a doubt, understanding how it manages security and reliability. Composable apps offer a lot of advantages to streamline applications, provided by the modularity and reusability of Packaged Business Capabilities. Individual modules and PBCs help isolate problems and security design, separate frontend and backend concerns and allow patching at the component level. At the company level, and with a good hub policy, it turns into “patch once, secure all” because you can easily leverage security fixes if they are applied to centralized modules in a store that all your applications rely on.

However, security strategies should not be applied at the code or module level only. The infrastructure has to be fully resilient and secure. No one can imagine using a car with seat belts within an insecure chassis. It doesn't make sense. Security is everyone’s business.

Fortunately, solutions exist to help us design at all levels with security as one of the top priorities.

"Shift security left". It is more than a buzzword, It is good advice according to Lucas Ward in a recent article called Hardening Kubernetes and What That Entails With Entando. There, Ward describes how building applications with Kubernetes is challenging.

I agree, building a fully secured application with Kubernetes is a real adventure. If there is something we can't live without, it is security. Whatever business domain we work in, security should be at the center of the design and production processes.

Delaying its implementation is risky; executing it is time consuming.

As Ward spells out, we can rely on frameworks to bring a smooth and dependable way to secure applications, especially with Kubernetes. He says that using a platform such as Entando provides simplicity and a solid base with best practices you can count on to promote security from the ground up.

From solid structures and base setup with code generation to a well documented CI/CD process, and opinionated build pipelines, Ward asserts that "using Entando as your platform of choice covers a lot of ground in the Development, Build, and Infrastructure scape."

Saying more without spoiling it is just impossible, just read it! This is my only advice.

Explore Docker-based bundles with JHipster and Entando 7.1

Anthony Viard — Tue, 10 Jan 2023 10:08:27 +0000

At Entando we define a bundle as a package that contains one or more components. A bundle can be a single component, component collection, PBC, or solution template, based on the level of granularity. Any bundle built with Entando is an Entando Bundle.

Entando 7.1 introduces a major new change for bundles with a Docker-based structure. This article explores all the things you need to know about that feature.

A shift from Git-based bundles

If you’ve already built or used bundles with Entando, you should know that before v7.1, the bundles were Git-based. That means the source code (called project) and the built artifact (the deployable bundle) were stored under two different Git repositories.

Traditionally, the source code repository is used by the Creators team for coding and building components with development tooling. The coding flow is similar to what we find in any development team, pushing and merging branches to share and review the code within the team.

The second repository stores the result of the compiling process, the artifact, that Curators can register in a hub, and Composers can install on their Application Composition Platform.

The Docker-based bundle is a total shift from that point. The source repository is still present but, all the artifacts are now sent to a Docker registry using Docker images.

A structure modification

The publishing process was improved with the tool change, so we took the opportunity to streamline the bundle structure itself.

We have a more readable and consistent bunch of folders with the Docker-based bundles.

Git-based	Docker-based
bundle/descriptor.yaml The main bundle descriptor	entando.json The main Entando file that contains components definition and metadata
ui/ The micro frontends sources folder	microfrontends/ Centralized micro frontends folder
src/ The backend sources folder	microservices/ The microservices folder, one per component
src/main/docker The auxiliary service folder such as Docker compose files and Keycloack configuration for local usages	svc/ The auxiliary service folder such as Dockercompose files and Keycloack configuration for local usage
*.sh Shell script used by the CLI to compile and build the bundle
	platform/ The folder for any Entando related component such as pages, content, page templates… One sub-folder per component type

If you like to make a deep comparison between these implementations, our documentation provides a table here.

This means that the cli and commands are now following that structure and you can easily run them to create a new one.

Let’s start a new project to discover this

Create a new 7.1 bundle with the ent CLI

Prerequisites

Before moving forward, you have to ensure that your Entando CLI is up to date. If not, please run the following command:

bash <(curl -sfL https://get.entando.org/cli) --update

Don’t forget to activate it with the following command

source "$HOME/.entando/activate"

Initialize the project

From your favorite folder, run the following command to initialize the project.

ent bundle init my-bundle

Please note you can replace “my-bundle” according to your project name.

A new folder is created with this project name; open it as a project with your favorite IDE to check the new structure.

You can check the entando.json file content, and the metadata:

{
   "microservices": [],
   "microfrontends": [],
   "svc": [],
   "name": "my-bundle",
   "version": "0.0.1",
   "description": "my-bundle description",
   "type": "bundle"
}

Add a microservice

In the project folder, run the following command to add a new microservice.

ent bundle ms add sample-ms --stack=spring-boot

We specify the stack because of the dedicated metadata we may need with some stack types. This command creates a new folder, sample-ms, in microservices and adds an entry in the entando.json.

{
   "microservices": [
       {
           "name": "sample-ms",
           "stack": "spring-boot",
           "healthCheckPath": "/api/health"
       }
   ],
   "microfrontends": [],
   "svc": [],
   "name": "my-bundle",
   "version": "0.0.1",
   "description": "my-bundle description",
   "type": "bundle"
}

Please note this new folder is empty and you have to add your own code. We provide an easy way to start; let’s do it with JHipster.

Call JHipster with the following commands

cd microservices/sample-ms
ent jhipster --blueprints=entando

Then, select only the default values.

When the generation is done, the sample-ms folder contains all the files provided by JHipster.

Customize the bundle for JHipster

You just need to tweak a couple of things to make it work properly.

Edit the entando.json and update microservices/sample-ms to set the healthCheckPath and dbms properties:

   "healthCheckPath":"/management/health",
   "dbms":"postgresql"

Move the Blueprint-provided auxiliary service definitions into the svc directory in the bundle project:

mv microservices/sample-ms/src/main/docker/* svc/

This enables the ent CLI to start Keycloak:

ent bundle svc enable keycloak

For advanced use cases, you can add MFEs with this tutorial. Please note that for microservices, you have to execute some extra steps.

Discover the new publishing process

This new bundle structure comes with a simpler publishing process provided by new streamlined CLI commands.

You can find a graphic of the different steps below. It describes the overall process and helps you to understand the details involved in every step.

Let's follow it for our new 7.1 bundle.

Build

From the root project folder, run the following command:

ent bundle pack

Please note, you need to have Maven installed for this to execute. You also need Docker installed; you can check the installation procedure here regarding your environment.

You can run the docker image ls command to see your available images.

Publish

Once it’s finished, run the next command to publish the bundle to a Docker repository.

ent bundle publish

In this step, you need to be logged into the Docker hub, ensure you have an account or create a new one on this website: https://hub.docker.com

_Please note, you can decide to publish the images to another registry by providing the URL with the --registry parameter.

Deploy

This step is the same as the previous Entando version, even if the commands have been modified to keep the consistency. Here, you need to have an available running instance of Entando. Visit https://developer.entando.com to install a local one.

Please note that you need your ent CLI profile to be connected to your Entando instance. If you followed the previous steps and installed a local multipass VM, you might have to run this command:ent attach-vm entando where “entando” is the virtual machine name.

Otherwise, it is possible to attach a kubeconfig file with this: ent attach-kubeconfig {kubeconfig-file}.

From your bundle root folder, run the following command:

When the deploying process is finished, you can navigate to your Local Hub by clicking on the “Hub” menu.

Then, you should see your bundle.

Install

As you can see, the bundle is available in your Local Hub but not installed yet. That means nothing is running on your cluster from that bundle and the components are not available for composition.

To install them, you can use the UI and click on the install button in the Local Hub or, you can run the following command from your bundle root folder: ent bundle install

The micro frontends are now available in the App Builder to compose new pages. the microservices as pods and you can check them with ent kubectl get pods -n entando.

Conclusion

In this article, we discovered a few new features provided by Entando 7.1. The bundle structure has been rebuilt; they are now docker-based and the publishing process has been optimized with the ent CLI commands. The JHipster blueprint has been optimized to match this new paradigm.

You can find explanations of these features during our 7.1 live with Sohini.

Did you know the bundle we just created can be used like a template to create a new one? Maybe not, because it’s also a new feature on 7.1 and this is the topic of the next blog post in this series. Stay tuned.

Using Vue.js to create a Micro Frontend

Anthony Viard — Mon, 27 Jun 2022 13:15:56 +0000

Disclaimer

This article has been written with the help of the ModSquad Community. The related live session is available here:

Introduction

Hi, fellow developers!

After learning how to create micro frontends with Angular and React, we’re jumping into another world with Vue.js. Remember, we’re trying to create a micro frontend using the web component specifications for each of the following frameworks: Angular, React, and Vue.js.

Does Vue provide the best developer experience when creating a micro frontend social card? Let’s try it!

Create the Vue.js app

First, ensure that you have installed Node with npm (you can use Yarn instead) and Vue CLI.

npm install -g @vue/cli

Then you can create the application by running the following command in your target folder. I suggest using the default option Default ([Vue 3] babel, eslint).

vue create vue-social-card

That should create a folder named vue-social-card that contains a fresh Vue.js project.

Please note that by default the application is configured to include certain features, such as npm scripts to start your app and eslint to help you code.

Discover your application

Before making any changes and creating a micro frontend, let’s run the application locally using the command npm run serve. Your application should then be available at the following URL: http://localhost:8080/.

Create the social card component

Vue.js helps you organize yourcode with components. That means we need to create a file to contain all the card code. You can delete the default file called HelloWorld.vue.

Once you’ve created a new file named SocialCard.vue in the components folder, copy the following code into it:

<script>
export default {
  props: {
    card: {
      type: Object,
      required: true
    }
  },
};
</script>

<template>
 <div class="card">
  <h2>{{ card.name }}</h2>
     <span>{{ card.description }}</span>
  <img :src="card.image" :alt="card.image_alt"/>
 </div>
</template>

<style>
.card {
width: 320px;
height: auto;
min-height: 450px;
background: rgb(60, 62, 68);
border-radius: 20px;
overflow: hidden;
padding: 10px 15px;
margin-bottom: 24px;
margin-right: 10px;
transition: all 0.2s linear;
cursor: pointer;
color: white;
}
img {
margin-top: 5%;
 max-width: 100%;
 height: auto;
}
.card:hover {
transform: scale(1.01);
box-shadow: 0 3px 12px 0 rgba(0, 0, 0, 0.2),
 0 1px 15px 0 rgba(0, 0, 0, 0.19);
}
.card > .title {
margin: 0;
}
</style>

Our component is just a simple piece of HTML/CSS code that requires an entry object named card and defines the following properties: name, description, image and image_alt.

As it is, your application might be broken due to an error in the app.vue file. It’s time to update it.

Update App.vue

The reason your app doesn’t work is that the main component still includes the default component. To fix it, replace the file contents with the following code:

<script>
import SocialCard from "@/components/SocialCard";

export default {
  components: {
    SocialCard
  },
  data() {
    return {
      shiba_card: {
        id: 1,
        name: 'Shiba Inu',
        description: 'The Shiba Inu is the smallest of the six original and distinct spitz breeds of dog from Japan.\n' +
            '      A small, agile dog that copes very well with mountainous terrain, the Shiba Inu was originally\n' +
            '      bred for hunting.',
        image: 'https://material.angular.io/assets/img/examples/shiba2.jpg',
        image_alt: 'The Shiba Inu image'
      },
    }
  }
};
</script>

<template>
  <SocialCard :card=shiba_card></SocialCard>
</template>

This imports our social card component, defines a card object shiba_card in the data() function to store the different properties, then passes the card object to the social card component in the template section.

The application is working again and the default Vue landing page is replaced with the Shiba Inu social card.

However, we only built a classic single page application and need to migrate it to a micro frontend.

Define the custom element

In order to reuse this app as a web component, we need to define a custom element, which is a typical step we discovered when using Angular and React.

Replace the content of the main.js file with the following:

import App from './App.vue'

import { defineCustomElement } from 'vue'

const SocialCardElement = defineCustomElement(App)

customElements.define('social-card-element', SocialCardElement)

This code defines the social-card-element custom element and wraps the Vue app. As we saw before, this app is now rendering the card as expected.

Next, replace <div id="app"></div> in the public/index.html file with the custom element:

<body>
 <noscript>
   <strong>We're sorry but <%= htmlWebpackPlugin.options.title %> doesn't work properly without JavaScript enabled. Please enable it to continue.</strong>
 </noscript>
 <social-card-element></social-card-element>
 <!-- built files will be auto injected -->
</body>

Congratulations! You have just built a Vue.js micro frontend using a custom element.

Please note, as I’m writing this article there is an issue with styling and custom elements that is discussed in detail here: https://github.com/vuejs/core/issues/4662. Please follow this ticket to know when it will be fixed or for current workarounds.

Resources

The code above is available on GitHub: https://github.com/avdev4j/vue-social-card

Thanks to this repo for the card example: https://github.com/AlanPenaRuiz/vue-rick-and-morty

Are you already using Entando and looking for Vue.js components? Take a look at this sample: https://github.com/entando-samples/ent-project-template-vue

Watch micro frontend videos on our YouTube channel: https://www.youtube.com/c/EntandoVideos

Join us on Discord to share and learn about composable apps: https://discord.gg/SdMCvyzzHm

Using React to create a Micro Frontend

Anthony Viard — Mon, 20 Jun 2022 09:26:06 +0000

Disclaimer

This article has been written with the help of the ModSquad Community. The related live session is available here:

Introduction

Hi, fellow developers!

Having discovered micro frontend creation with Angular, we jump into another world with React. Remember, I’m trying to create a micro frontend using the web component specifications foreach of the following frameworks: Angular, React, and Vue.js.

Does React provide the best developer experience when creating a micro frontend social card? Let’s try it!

Create the React app

React offers a simple way to create React applications using the Create React App.

As seen in the previous blog, you need to have npm installed. You can then run the following command to create the application skeleton:

npx create-react-app react-social-card

Once complete, you should have a new React project available in the react-social-card folder.

Start it using the command npm start.

The default React page is reachable at http://localhost:3000.

Add the social card code

Before configuring the custom-element, we have to create the React social card component. After some research, here is an example of code we can use: https://codepen.io/leoraw/pen/ZjvRpL. Thanks to @leoraw for sharing this example.

Create the React components

The social card is split into two different React components: a button box and the card itself.

First, we create a new file for the button box in the components folder, name it ButtonBox.js and copy this code:

import React from "react";

const UiButton = props => {
   const classes = (props.isClicked) ?
     "ui-button clicked" : "ui-button";
   const number = (props.isClicked) ?
         (props.number + 1) : props.number;

   return (
     <button className={classes} id={props.text}
       onClick={() => props.onClick()}>
       <span className="ui-icon">{props.icon} </span>
       {number}
     </button>
   );
};

class ButtonBox extends React.Component {
   constructor(props) {
     super(props);
     console.log(props.likeIsClicked);
     this.state = {
       likeIsClicked: props.likeIsClicked

     };
   }

   toggle(index) {
     let state = {};
     state[index] = !this.state[index];
     this.setState(state);
   }

   render() {
     return (
       <div>
         <UiButton icon='♥' text='likes'
           number={this.props.likes}
           onClick={() =>
             this.toggle('likeIsClicked')}
           isClicked={this.state.likeIsClicked}/>
       </div>
     );
   }
}

export default ButtonBox;

Then, in the same folder, we create the SocialCard.js file and copy the following content.

Please note that this new component imports and use the previous one. Effectively, the internal architecture in the micro frontend allows us to use multiple components, and all the components are built into one custom element.

import React from "react";
import ButtonBox from "./ButtonBox";

const UiCard = props => {
 let {image, title, content} = props.content;
 return (
   <div class="card-wrapper">
     <div className='card-img'>
       <img src={image} />
     </div>
     <div className='card-content'>
       <h3>{title}</h3>
       <div>{content}</div>
     </div>
     </div>
 );
}

class SocialCard extends React.Component {
   render() {
     return (
       <div className='card-body'>
         <UiCard content={this.props.content}/>
         <div className='line'></div>
          <div style={{textAlign: 'right'}}>
             <ButtonBox
             likeIsClicked={this.props.likeIsClicked}
             likes={this.props.likes}/>
         </div>
       </div>

     );
   }
}

export default SocialCard;

Use the new components in the main App.js file

Once these two components are available, we can update the main App.js file and remove the old React demo code.

Update the App.js file by replacing the existing code with this:

import React from 'react';
import './App.css';
import SocialCard from "./components/SocialCard";

const cardDetails = {
   id: 0,
   content: {
       title: 'Shiba Inu',
       image: 'https://material.angular.io/assets/img/examples/shiba2.jpg',
       content: 'The Shiba Inu is the smallest of the six original and distinct spitz breeds of dog from Japan. A small, agile dog that copes very well with mountainous terrain, the Shiba Inu was originally bred for hunting.',
   },
   likeIsClicked: true,
   likes: 5
}

function App() {
 return (
   <SocialCard
     key={cardDetails.id}
     content={cardDetails.content}
     likes={cardDetails.likes}
     likeIsClicked={cardDetails.likeIsClicked}
     />
 );
}

export default App;

You can see here that we are instantiating a new social card component and giving it some data to display.

Now you can restart the application or refresh the page to see our social card appear. However, this is still a raw React application and we need to define the custom-element to finish our task.

Switch the app to a custom element

In the src folder, at the same level as the components folder, we create a new folder named custom-element.

Next, let’s create a new file named social-card-app.js to define the custom-element using the related API.

import ReactDOM from "react-dom"
import React from "react"
import App from '../App'

class SocialCardApp extends HTMLElement {
   connectedCallback() {
       this.mountPoint = document.createElement('span')
       this.render()
   }

   render() {
       ReactDOM.render(<React.StrictMode>
                   <App/>
           </React.StrictMode>,
           this.appendChild(this.mountPoint))
   }
}

customElements.get('react-social-card') || customElements.define("react-social-card", SocialCardApp)

The string “react-social-card” is used to define the custom-element tag and renders the React app using: <App/>.It’s analogous to Russian dolls: custom-element > React app > social card component > buttonbox component.

Then, in the file index.js import the custom-element and replace all the previous content with this code:

import './custom-element/social-card-app';
```



Then, in the following `public/index.html` file, replace the body with this:




```html
<body>
 <noscript>You need to enable JavaScript to run this app.</noscript>
 <react-social-card></react-social-card>
</body>
```




Reload your browser and check the HTML content:



![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pmajvoe2sxvzo4id2eoa.png) 


The `react-social-card` custom element is used and loads the React app content.

**Congratulations! You’ve just created your first micro frontend using React!**


## Resources:

The code above is available on GitHub: [https://github.com/avdev4j/react-social-card](https://github.com/avdev4j/react-social-card)

Watch micro frontend videos on our YouTube channel: [https://www.youtube.com/c/EntandoVideos](https://www.youtube.com/c/EntandoVideos)

Join us on Discord to share and learn about composable apps: [https://discord.gg/SdMCvyzzHm](https://discord.gg/SdMCvyzzHm)

Using Angular to create a Micro Frontend

Anthony Viard — Tue, 14 Jun 2022 12:10:59 +0000

Disclaimer

This article has been written with the help of the ModSquad Community. The related live session is available here:

Introduction to Web Components

Web components are a set of technologies, a meta- specification, with reusable isolated elements that make up a web application.

Basically, Web Components need 4 specifications:

Custom Elements: A set of Javascript APIs to define the components and their behaviors.
Shadow DOM: A set of APIs to render the element into a dedicated and isolated DOM.
HTML Templates: Allows you to use <template> and <slot> tags to define a portion of HTML to reuse in which slots could be filled with variable content.
ES Modules: A specification to import and use Javascript Modules to create an agnostic modular approach.

Modern Javascript frameworks offer some solutions to easily create a web component, using a custom element, leveraging all the framework features, and creating small business-oriented apps. This is what we call micro frontends.

Let’s see how to proceed using Angular and let’s see how to create our first micro frontend.

To continue, you need to have installed NodeJS (including npm) and the Angular CLI

npm install -g @angular/cli

Initiate the Project

Here we go. We are going to create our first web component using Angular. For this first exercise, let’s create a card to describe people in our community. We call it “social card”.

With your favorite terminal, create a new Angular project

ng new social-card

Create an Angular Component

Add Angular material

Because we want to use the Angular Material library to create our component, we need to add it as a dependency on our project. During the installation, I select the default values.

ng add @angular/material

Create the Material Card Component

From the example section of the Card component, I choose to implement the “Card with multiple sections” one. https://material.angular.io/components/card/examples

First, I create a new Angular component. Please note “components” here refer to the Angular Component, not Web Components defined in the introduction.

ng generate component card

The Angular CLI automatically creates all the needed files and updates the different files to make the application work out of the box.

In the src/app/card/ folder, open the HTML file and copy the following code into it:

<mat-card class="example-card">
   <mat-card-header>
     <div mat-card-avatar class="example-header-image"></div>
     <mat-card-title>John Doe</mat-card-title>
     <mat-card-subtitle>Dev Adcovate</mat-card-subtitle>
   </mat-card-header>
   <img mat-card-image src="https://material.angular.io/assets/img/examples/shiba2.jpg" alt="Photo of a Shiba Inu">
   <mat-card-content>
     <p>
       The Shiba Inu is the smallest of the six original and distinct spitz breeds of dog from Japan.
       A small, agile dog that copes very well with mountainous terrain, the Shiba Inu was originally
       bred for hunting.
     </p>
   </mat-card-content>
   <mat-card-actions>
     <button mat-button>LIKE</button>
     <button mat-button>SHARE</button>
   </mat-card-actions>
 </mat-card>

Then, open the CSS file and copy the following code:

.example-card {
   max-width: 400px;
}
 .example-header-image {
   background-image: url('https://material.angular.io/assets/img/examples/shiba1.jpg');
   background-size: cover;
}

Import Angular Material Modules in your App Module

Then, open the src/app/app.module.ts to import the MatCardModule and the MatButtonModule.

import {MatCardModule} from '@angular/material/card';
import {MatButtonModule} from '@angular/material/button';

imports: [
 MatCardModule,
 MatButtonModule

Run your application

Edit the app.component.html file from the src/app folder and replace the existing with the following:

<app-card></app-card>

You can start your application by running the following command at the project root level:

ng serve

So far, so good, but the following application is not yet a Web Component and we need to make some changes to transform it.

Transform the Application into a Web Component

Add Angular elements dependency

Angular elements is the name in the Angular ecosystem for custom elements. This dependency allows us to easily create a custom element from our existing application.

ng add @angular/elements

Update the app.module.ts

From the src/app/app.module.ts file, update the constructor, call the createCustomElement() method, and define the custom element tag, ng-social-card.

import {createCustomElement} from '@angular/elements';

export class AppModule {
 constructor(private injector: Injector) {
   const el = createCustomElement(AppComponent, { injector });
   customElements.define('ng-social-card', el);
 }

 ngDoBootstrap() {
 }
}

Remove the AppComponent in the bootstrap array. we don’t need it anymore and it could generate errors in the console log.

Update the index.html

Open the src/.html file and change the content to use the custom-element instead of the initial value. \

<body>
 <ng-social-card></ng-social-card>
</body>

We have now instantiated the application, using a custom element instead of the regular app-root tag.

Start the application again using ng serve and check that the application is still working.

Build and Run Your Web Component

Build it!

To build your component you have to run the following command:

ng build

A dist folder is now created containing an HTML file and all the Javascript and CSS files.

If you open the index.html, you can see it contains the custom elements previously defined.

<head>
 <meta charset="utf-8">
 <title>NgSocialCard</title>
</head>
<body>
 <ng-social-card></ng-social-card>
<script src="runtime.6ef72ee47cb5bc7a.js" type="module"></script>
<script src="polyfills.41cc36d27639541d.js" type="module"></script>
<script src="main.8609c098aeba9ec8.js" type="module"></script>
</body>

Run it!

To run it, you can install serve through npm to start a lightweight web server.

npm install -g serve

And from the dist/ng-social-card folder, run the following command:

serve

Congratulations! You’ve just created your first micro frontend using Angular.

Resources

All the code is available at the repository: https://github.com/avdev4j/ng-social-card

Find more micro frontends videos on our YouTube channel: https://www.youtube.com/c/EntandoVideos

Join us on Discord to share and learn about Composable apps: https://discord.gg/SdMCvyzzHm