Next Direction

Where AI is going 2026

2026-01-10T13:00:00Z

Oh-My-OpenCode: Because Who Doesn’t Love Burning Through API Credits at Lightning Speed?

A comprehensive exploration of the future of coding, where multiple AI agents collaborate beautifully to drain your wallet

In the wild, wonderful world of AI-assisted coding, a new champion has emerged to save us all from the terrible burden of having money left in our bank accounts. Meet oh-my-opencode, “The Best Agent Harness” featuring Sisyphus: “The Batteries-Included Agent that codes like you.” And if that name doesn’t scream “Greek mythology about eternal, futile labor,” I don’t know what does. But hey, at least the irony is baked right into the branding!

With over 12,800 stars on GitHub, this project has clearly struck a chord with developers everywhere who looked at their API usage dashboard and thought, “You know what? These numbers are just too low. I need more agents talking to more agents, generating more tokens, accomplishing… well, something.”

The Revolutionary Promise: Multi-Agent Orchestration (AKA Token Tornado)

Oh-my-opencode lets you “run background agents, call specialized agents like oracle, librarian, and frontend engineer” while using “crafted LSP/AST tools, curated MCPs, and a full Claude Code compatibility layer.” Because why have one AI agent do something efficiently when you can have multiple agents pass the same task back and forth like a corporate email chain where everyone hits “reply all”?

The architecture is truly breathtaking. You’ve got your oracle agent, presumably consulting the ancient digital spirits about whether that function should return null or undefined. You’ve got your librarian agent, carefully cataloging all the documentation that the main agent could have just read directly. And let’s not forget the frontend engineer agent, which I can only assume spends most of its time debating whether to use div or span tags while racking up those sweet, sweet token charges.

It’s the coding equivalent of having a committee meeting where everyone needs to weigh in before you can decide what to have for lunch. Except this committee costs you $0.01 per opinion, and they really like to share their thoughts.

The “$24,000 Promise” – Now That’s What I Call Quality Assurance!

Here’s where it gets truly impressive. The project proudly declares it’s “Certified, Verified, Tested, Actually Useful Harness in Production, after $24,000 worth of tokens spent.” Twenty-four thousand dollars! That’s not a red flag; that’s a crimson banner waving majestically in the wind, visible from space.

Now, some cynics might argue that spending $24,000 in API costs during development suggests that maybe, just maybe, the system isn’t exactly optimized for token efficiency. But those people are clearly missing the point. This isn’t about efficiency; it’s about thoroughness. It’s about making absolutely certain that every possible way to consume tokens has been explored, tested, and implemented into the core functionality.

Think of it this way: if the developers burned through $24,000 in testing, just imagine how much you’ll get to spend in production! It’s like they’re providing a roadmap directly to API bankruptcy, and they’ve thoughtfully tested every step of the journey for you. How generous!

“No Stupid Token Consumption” – The Punchline That Writes Itself

In what can only be described as the comedy gold of technical documentation, the README boldly proclaims: “No stupid token consumption massive subagents here.” Let’s unpack this delicious piece of irony, shall we?

The project literally implements multiple specialized agents (oracle, librarian, frontend engineer, and presumably more) that coordinate with each other through a main orchestrator. Each agent needs its own context, its own reasoning loops, and its own API calls. When Agent A needs to consult Agent B, that’s double the context loading, double the token processing, and double the fun watching your API credits evaporate like morning dew in the Sahara.

But don’t worry, it’s not stupid token consumption. It’s smart token consumption. The kind where agents spawn subagents, which might spawn their own subagents, creating a beautiful fractal pattern of API calls that would make Benoit Mandelbrot weep with joy. The system even encourages spawning subagents “to save context”, because nothing says “context efficiency” like creating entirely new agent instances!

The Greek Mythology We Deserved

Let’s take a moment to appreciate the naming choice: Sisyphus. In Greek mythology, Sisyphus was condemned to roll a boulder up a hill for eternity, only to watch it roll back down each time he neared the top. The developers could have named it after Prometheus (who gave fire to humanity) or Athena (goddess of wisdom) or literally any other mythological figure associated with, you know, success.

But no, they chose Sisyphus, the poster child for futile, repetitive labor. It’s almost like they’re telling us something. Maybe it’s a subtle hint about the experience of watching multiple AI agents pass code back and forth, each one making tiny adjustments, each iteration consuming more tokens, the boulder of your feature request slowly rolling back down the hill as your API credits depleting faster than you can say “context window exceeded.”

The metaphor is so on-the-nose it’s practically doing a headstand.

The Multi-Model Money Pit

The project proudly supports “ChatGPT, Claude, Gemini SUBSCRIPTIONS” and claims “WE ALL COVER THEM.” Because why limit yourself to burning through credits with just one AI provider when you can establish a diversified portfolio of API expenditures?

It’s like going to an all-you-can-eat buffet, except instead of food, it’s AI models, and instead of getting full, you get broke. You can mix and match! Have Claude handle the orchestration, GPT-4 run your oracle agent, and Gemini… well, Gemini can just stand there looking pretty while consuming tokens in the background.

The beauty of this approach is that you’re not just dependent on one company’s pricing model, you’re dependent on all of them! When OpenAI raises their prices, no problem, you’re also paying Anthropic and Google. It’s the financial equivalent of not putting all your eggs in one basket, except every basket has a hole in it and the eggs are made of money and they’re all falling onto an expressway.

The “Ultrawork” Philosophy: Because Regular Work Wasn’t Expensive Enough

The documentation cryptically advises: “If this all seems overwhelming, just remember one thing: include the word ultrawork in your prompt.” Ah yes, “ultrawork”, not just work, not even extra work, but ultra work. Because regular work is for people who want to keep their API costs below their mortgage payment.

The term perfectly encapsulates the entire philosophy of the project. Why have an agent perform a task once when you can have it perform “ultrawork”, presumably involving multiple agents, multiple iterations, multiple model calls, and multiple opportunities to spend money? It’s not inefficiency; it’s “ultra-efficiency” so advanced that it loops back around to looking exactly like inefficiency.

The Discord Community: A Support Group for the Token-Addicted

Users are invited to “join our Discord community to connect with contributors and fellow oh-my-opencode users.” One can only imagine the conversations happening there:

“Hey guys, I just ran a simple refactoring task and my API bill was $47. Is that normal?”

“Only $47? Are you even using all the agents? Let me share my config where I have seven specialized agents working in parallel…”

“Check out this cool setup where the oracle agent consults the librarian agent, which spawns a research subagent, which calls back to the main orchestrator! My code quality went up 2% and my costs went up 300%!”

It’s probably the only developer community where bragging rights are inversely proportional to fiscal responsibility.

The Industry’s Dirty Little Secret: Everyone’s Just Cooking With Water

Here’s the thing that makes oh-my-opencode so perfectly representative of the current AI coding assistant landscape: everyone in the industry is just cooking with water. That’s a German saying, “mit Wasser kochen”, which means everyone’s using the same basic ingredients, the same basic methods, despite whatever mystique they try to project.

Every AI coding tool right now is essentially doing the same thing: making API calls to large language models. Some add a thin wrapper here, some add specialized prompts there, some create multi-agent architectures that sound impressive in blog posts. But fundamentally, they’re all just different ways to convert your money into API calls.

Oh-my-opencode’s genius, and I mean this with the most sarcastic possible tone, is that it’s completely transparent about this. While other tools try to hide their token consumption behind vague promises of “efficiency” and “optimization,” oh-my-opencode just… does it. Loudly. Proudly. With multiple agents. $24,000 worth of token consumption proudly displayed like a badge of honor.

It’s almost refreshing in its honesty. There’s no pretense here. No claims that their special sauce makes LLMs work 10x better. No proprietary magic that reduces token usage by 90%. Just pure, unfiltered, multi-agent token consumption served straight up. It’s like going to a restaurant where the menu openly admits “Our food is overpriced and mediocre, but at least we’re honest about it!”

The Real Cost of “Free” Open Source

The project is open source, which is wonderful. You don’t have to pay for the software itself! You just have to pay for:

Claude API credits (unless you want to use that 20-request-per-day free tier)
GPT-4 API credits (because GPT-3.5 isn’t going to cut it for your oracle agent)
Gemini API credits (for good measure)
The inevitable therapy you’ll need after seeing your first monthly API bill
The financial advisor you’ll hire to explain where all your money went
The second mortgage on your house to fund your “simple refactoring project”

But hey, the software itself? Totally free! It’s like offering someone free kindling for their fireplace, where the fireplace is made of hundred-dollar bills and the kindling is soaked in gasoline.

The Perfect Storm of Modern Over-Engineering

What makes oh-my-opencode truly special is how it perfectly encapsulates the current state of software development: complex multi-agent systems that sound impressive in architecture diagrams but in practice just multiply complexity and cost without proportional benefits.

We’ve entered an era where developers look at a problem that could be solved with a single, well-crafted prompt to an LLM and think, “You know what this needs? An orchestrator agent that delegates to specialized sub-agents that each maintain their own context and reasoning chains!” It’s like using a cruise missile to hang a picture frame. Sure, it’ll get the job done, but was it really necessary? And who’s paying for the missile?

The sad truth is that for most coding tasks, you don’t need multiple specialized agents deliberating in committee. You need one good AI model with proper context and a well-written prompt. But that doesn’t sound nearly as cool in a GitHub README, does it? “Simple, efficient, single-agent coding assistant” just doesn’t have the same pizzazz as “Multi-Agent Orchestrated AI Coding Harness with Background Task Delegation and Specialized Domain Agents.”

The Emperor’s New Codebase

Throughout tech history, we’ve seen this pattern repeat: new technology emerges, everyone rushes to make it as complicated as possible, and then eventually someone realizes that simple was better all along. We did it with microservices (take a working monolith, split it into 47 services that all need to talk to each other). We did it with blockchain (take a database, make it slower and more expensive). And now we’re doing it with AI coding assistants.

Oh-my-opencode is the emperor’s new codebase, everyone’s admiring the sophisticated architecture, the multiple agents, the clever orchestration, while quietly ignoring that it’s accomplishing similar results to much simpler solutions at multiples of the cost. With 12,800 stars, clearly a lot of people are buying into the vision. Or at least starring the repo, which costs nothing unlike actually using the tool.

A Love Letter to Inefficiency

In fairness to oh-my-opencode, they’re solving a real problem: the existing AI coding tools aren’t always great. The creator’s stated goals included being “free of cost concerns,” requiring “no tedious configuration,” and to “just work, and work well.” These are noble goals! The irony is that multi-agent architectures are, by their very nature, the opposite of “free of cost concerns.”

Every time you add another agent to your system, you’re adding: - More context that needs to be loaded - More token generation for inter-agent communication - More API calls to coordinate activities - More potential for cascading errors - More points of failure - More complexity to debug - And most importantly, more cost

It’s like deciding to solve your high water bill by installing more faucets. Sure, you’ve got more options for where to get water now, but your bill isn’t going down.

The Testimonials: When Marketing Meets Reality

The README features glowing testimonials, including one that claims “If Claude Code does in 7 days what a human does in 3 months, Sisyphus does it in 1 hour.”

Let’s do some math here. If we take this at face value, and Claude Code costs roughly $0.10-0.30 per thousand tokens depending on the model, and a typical coding session might use 50,000-200,000 tokens… multiply that across your multi-agent architecture where each agent is maintaining its own context…

You know what? I don’t want to do this math. It’s too depressing. Let’s just say that yes, Sisyphus might do it in 1 hour instead of 7 days, but it’ll cost you enough that you might want to consider just hiring a human developer for those 7 days instead.

The Future Is Multi-Agent (And Expensive)

The real tragedy of oh-my-opencode isn’t that it’s a bad project, the developers clearly put significant work into it. The tragedy is that it represents where the industry is heading: increasingly complex systems that sound intelligent and sophisticated but fundamentally just create more abstraction layers between your wallet and the actual LLM providers.

We’re in a gold rush era where everyone’s trying to build the fanciest pickaxe, and nobody’s asking whether we actually need pickaxes at all when we’ve got excavators. Every new AI coding tool adds more features, more agents, more complexity, and somehow manages to use more tokens than the last one.

Oh-my-opencode is just honest about it. Brutally, $24,000-worth-of-testing honest about it.

The Verdict: It’s Perfect! (If Money Is No Object)

So, should you use oh-my-opencode? Absolutely! If you:

Have disposable income you need to dispose of quickly
Think your API bills are too readable and need more digits
Enjoy explaining to your finance department why the “coding tool” line item exceeds your office rent
Find satisfaction in watching multiple AI agents have long conversations with each other about your code
Believe that more complexity always equals better results
Want to experience what it’s like to be Sisyphus, eternally pushing the boulder of multi-agent coordination up the hill of token consumption

Then oh-my-opencode is absolutely the tool for you! With “no stupid token consumption” and “no bloat tools”, just smart token consumption and definitely-not-bloated multi-agent architectures!

Conclusion: Embracing the Absurd

At the end of the day, oh-my-opencode is a fascinating microcosm of where we are with AI tooling in 2026. We’ve got powerful language models that can assist with coding tasks, and we’ve managed to wrap them in so many layers of abstraction and complexity that we’ve multiplied the cost while providing… well, it depends on who you ask.

The project works. People use it. It has genuine fans. But the gap between the promise of AI-assisted coding (“save time and money!”) and the reality of multi-agent architectures (“watch your API bills soar!”) has never been more apparent.

Everyone in the industry really is just cooking with water. Some are using fancier pots, some are adding more burners, some are orchestrating multiple pots in parallel with specialized water-heating agents. But at the end of the day, we’re all just making API calls to the same handful of language models, watching the same tokens get consumed, and paying the same providers.

Oh-my-opencode’s greatest achievement might be serving as a mirror to the entire AI coding assistant industry: complicated, expensive, occasionally brilliant, often excessive, and somehow both the future of programming and a parody of it at the same time.

Just like Sisyphus eternally pushing his boulder, we’ll keep pushing our code up the hill of AI-assisted development, watching our tokens roll back down, and somehow convincing ourselves that this time, with just one more specialized agent, we’ll finally reach the top.

Your API credits will be sorely missed.

Disclaimer: oh-my-opencode is a real project made by real developers who put real effort into it. This post is satirical commentary on the broader trends in AI coding tools, not a serious technical review. If multi-agent token consumption is your jam, more power to you. Just remember to set up billing alerts.

Usually I show you the next direction, but I fear this is just the wrong direction, so please don’t follow it blindly!

AI-Powered Development: Months of Iteration

2026-01-06T06:30:00Z

After several months of experimenting with AI-assisted development, I’ve finally settled into a workflow that feels natural, efficient, and actually sustainable. Like many developers exploring this space, I started with enthusiasm, tried every tool and methodology I could find, and eventually circled back to something simpler and more aligned with how I actually think and work.

This post is a reflection on that journey and a detailed look at the setup I’ve landed on. If you’re working with AI coding assistants and feeling overwhelmed by the options, or if you’re curious about what a practical, day-to-day AI development workflow looks like beyond the hype, this might resonate with you.

The Foundation: Windows, WSL2, and VSCode

Let me start with the basics. I work in a Windows environment, but like many modern developers, I’ve found that WSL2 (Windows Subsystem for Linux) gives me the best of both worlds. I can use Windows for my daily computing needs while having access to a full Linux environment for development. This setup has become incredibly stable over the years, and it handles the demands of AI-assisted development without breaking a sweat.

VSCode serves as my primary editor, which probably doesn’t surprise anyone. It’s become the de facto standard for a reason, the extension ecosystem is unmatched, the performance is solid, and the integration with WSL2 is seamless. I can edit files in my Linux filesystem with the full power of a native Windows application, and everything just works.

But here’s where my setup diverges from what you might expect: despite using VSCode, I don’t primarily rely on its AI extensions. Instead, I’ve gravitated toward using the Codex CLI for the bulk of my AI-assisted coding work.

Why the CLI? Understanding My Tool Choice

When I first started exploring AI coding assistants, I naturally installed the VSCode extensions that everyone was talking about. They’re convenient, they’re integrated, and they work reasonably well for many use cases. But after several weeks of use, I found myself increasingly drawn to the Codex CLI instead.

The CLI interface is simply more advanced and capable for the kind of work I do. It gives me more granular control over context, better handling of multi-file operations, and more sophisticated reasoning about my codebase. When I’m working on a complex feature that spans multiple files and requires understanding of intricate dependencies, the CLI’s ability to maintain that context and reason about it holistically makes a significant difference.

There’s also something to be said for the mental model of using a CLI tool. It creates a clearer separation between “I’m writing code” and “I’m collaborating with AI on code.” With an inline extension, these boundaries blur in ways that sometimes made me feel like I was fighting the tool rather than working with it. The CLI feels more like pair programming with a colleague, there’s a conversation happening, proposals being made, and I’m clearly the one deciding what gets implemented.

That said, VSCode remains essential to my workflow. I use it for editing, debugging, and all the traditional IDE tasks. The Codex CLI and VSCode complement each other beautifully, they each do what they’re best at, and I switch between them fluidly throughout my day.

The Workflow: From Idea to Implementation

Over the past month, my workflow has crystallized into four distinct phases. Each one leverages AI in different ways, and understanding when and how to use AI in each phase has been key to maintaining both productivity and code quality.

Phase 1: Brainstorming and Ideation

Every feature or project starts with brainstorming, and this is where AI has proven surprisingly valuable. I used to keep these sessions entirely in my head or in scattered notebook entries, but now I use AI as a sounding board for initial ideas.

The beauty of this phase is its low stakes. I’m not committing to code or architecture decisions yet; I’m just exploring possibilities. I’ll describe what I’m trying to build, the constraints I’m working within, and the problems I’m trying to solve. The AI helps me think through edge cases I might not have considered, suggests alternative approaches, and sometimes points out potential issues before I’ve written a single line of code.

What I appreciate most about using AI for brainstorming is that it’s infinitely patient with half-formed thoughts. I can ramble, contradict myself, change direction mid-sentence, and the AI simply rolls with it. It’s like having a colleague who never gets frustrated when you’re still figuring out what you’re trying to say.

This phase is purely conversational. I’m not generating code, I’m not making commitments, I’m just thinking out loud with something that can think back at me. By the end of a good brainstorming session, I usually have a much clearer picture of what I actually want to build and a few different approaches to consider.

Phase 2: Planning and Task Definition

Once I have a clear direction, I move into planning. This is where my workflow has evolved the most over the past month, and where I learned some important lessons about the difference between what sounds good in theory and what actually works for me in practice.

Initially, I tried using formal specification tools like SpecKit and BMAD. These tools promise structured, comprehensive planning with detailed specifications and clear acceptance criteria. In theory, they sound perfect, who wouldn’t want complete, unambiguous specs for their features?

In practice, I found them far too verbose for my needs. I’d spend an enormous amount of time writing specifications that felt more like documentation for an enterprise project than planning for actual implementation. The overhead was killing my momentum, and I’d finish a planning session feeling drained rather than energized about building.

So I simplified. Radically.

Now I use either backlog.md or vibe-kanban, depending on the project. What drew me to these tools is their philosophy: they’re full-featured task management systems, complete with kanban boards, milestone tracking, and task organization, but built on markdown and designed to stay out of your way rather than impose rigid workflows.

Backlog.md is particularly interesting because it gives you a proper task management system while keeping everything in readable, editable markdown files. I can organize tasks into sprints or milestones, move items between stages (backlog, in progress, done), add priorities and tags, and even track time estimates. But unlike heavyweight project management tools, I’m never locked into a particular structure. If I want to reorganize my milestones, create custom statuses, or completely restructure how I’m tracking work, I can do it instantly because it’s all just markdown under the hood.

The kanban view provides the visual organization I need to see what’s in flight and what’s coming next. The milestone tracking helps me group related tasks and maintain focus on larger goals. But there’s no ceremony, no mandatory fields, no fighting with a UI that assumes I work a certain way. I define the structure that makes sense for my project, and the tool adapts to me rather than the other way around.

Vibe-kanban takes a similar approach with its own spin on lightweight, markdown-based task management. It excels at giving you that visual kanban experience while maintaining the simplicity and control of working with plain text files. I can drag tasks between columns, nest subtasks, set due dates, and track progress, all the functionality you’d expect from a proper task manager, but without the bloat of enterprise tools that assume you’re managing a team of fifty.

The key insight here was realizing that I needed real task management functionality, kanban boards, milestone tracking, the ability to break down work and track progress, but I didn’t need the complexity and rigidity of traditional project management tools. These markdown-based systems give me the structure and features I need while maintaining the flexibility and control that keeps me productive.

When I work with AI during this phase, I use it to help break down larger features into implementable tasks. The AI is good at thinking through dependencies and suggesting a logical order of implementation. I can ask it to suggest milestone groupings or help me estimate the scope of different tasks. But the final task organization lives in my chosen system, where I maintain complete control and can iterate on the structure as I learn more about the project.

Phase 3: Implementation with MCP Servers

The implementation phase is where everything comes together, and it’s where my use of MCP (Model Context Protocol) servers really shines. I learned quickly that not every available tool needs to be in my toolkit. In fact, loading up too many MCP servers just adds noise and confusion.

I’ve settled on a small, carefully chosen set of MCP servers that each serve a specific purpose:

Codanna handles code inspections and quality checks. When I’m implementing a feature, Codanna can analyze the code for potential issues, suggest improvements, and help ensure I’m following good practices. It’s like having a senior developer doing code review as I write, catching problems before they make it into a commit.

Context7 provides access to framework documentation. Rather than constantly switching to a browser to look up API references or check how a particular framework feature works, I can query Context7 directly through the CLI. This keeps me in flow and ensures the AI has access to accurate, up-to-date information about the frameworks I’m using.

Playwright gives me browser control, which is essential for web development. I can automate testing, take screenshots, verify functionality, and even debug issues in real browsers without leaving my development environment.

Finally, I have MCP servers connected to my task management tools, whether that’s a custom server for my backlog.md or an integration with vibe-kanban. This lets the AI understand what I’m working on, check off completed tasks, and help me stay organized without manual context switching.

The restraint in this selection is deliberate. Early on, I had nearly a dozen MCP servers loaded, convinced that more tools meant more capability. Instead, it just meant more confusion, both for me and for the AI, which would sometimes suggest using the wrong tool or get overwhelmed by options.

With this focused set of tools, the AI can be genuinely helpful. It knows what’s available, knows what each tool does, and can make smart decisions about when to use them. The implementation phase becomes a smooth collaboration where the AI understands both my code and my workflow.

Phase 4: Memory and Verification

One of the challenges I encountered early on was that AI has no persistent memory of what we’ve done in previous sessions. Each conversation starts fresh, which is great for privacy but terrible for multi-day projects where context matters.

My solution is simple but effective: I maintain a markdown file that tracks the current technical progress. Think of it as a journal for the project, but written for the AI’s benefit as much as mine. After each significant session, I update this file with what we accomplished, decisions we made, and any important context that would be expensive to regenerate.

This file might include notes like “Implemented authentication using JWT with refresh tokens. Token expiry is 15 minutes, refresh is 7 days. Tokens stored in httpOnly cookies.” Or “Decided against using Redux for state management, project is small enough that Context API is sufficient.” These are the kinds of details that would take paragraphs to re-explain but are crucial for the AI to give good advice in future sessions.

When I start a new session, I simply provide this markdown file as context. The AI immediately understands where we are, what we’ve built, and why we made certain decisions. It’s like bringing a colleague up to speed with a quick status update rather than a lengthy meeting.

The other critical piece of this phase is testing. I write tests not just for the usual reasons, ensuring code works, preventing regressions, but also because tests are something the AI can run and verify. I can ask the AI to implement a feature, have it write or update tests, run those tests, and get objective feedback on whether the implementation is correct.

This verification loop is crucial. Without it, I’d need to manually test every AI-generated code suggestion, which would slow me down significantly. With good test coverage, I can move faster while maintaining confidence that things actually work.

Tests also serve as a form of specification that’s harder to misinterpret than English. I can tell the AI “make sure all these tests pass” and have much higher confidence in the result than if I’d just described the desired behavior in prose.

Reflections and What I’ve Learned

A month isn’t a long time in the grand scheme of things, but it’s been long enough to move past the initial excitement and hype and start understanding what actually works. A few key lessons have emerged:

Simplicity beats features. The most sophisticated tools aren’t always the most useful. The lightweight, flexible solutions that adapt to my thinking often outperform the comprehensive, structured ones that try to impose their own methodology.

The CLI is underrated. While everyone talks about inline coding assistants and IDE extensions, the CLI interface has proven more powerful and flexible for my needs. It’s worth trying even if it seems less convenient at first.

Context is everything. Whether it’s through MCP servers, markdown memory files, or test suites, giving the AI the right context is far more important than having the most advanced model. A slightly older model with perfect context will outperform the latest model working blind.

Less is more with tools. Curating a small set of well-understood tools beats having every possible option available. It reduces cognitive load and helps the AI make better decisions.

Looking ahead, I’m sure this workflow will continue evolving. New tools will emerge, I’ll discover better approaches, and my needs will change as I work on different types of projects. But I feel like I’ve found something sustainable, a workflow that enhances my productivity without trying to replace my judgment or push me into somebody else’s idea of how development should work.

If you’re building your own AI-assisted development workflow, I hope some of these ideas spark thoughts about what might work for you. The key is experimentation, willingness to change what isn’t working, and focusing on tools and processes that genuinely make you more effective rather than just more busy.

What’s your AI development workflow look like? I’d love to hear what’s working for you, feel free to reach out and let me know.

Sails.js & Vue.js - Part 4

2025-11-23T11:00:00Z

The fleet is assembled, the ships are enchanted, and the Chart Room is alive with data. But a true commander needs to see the entire theatre of operations at a single glance. Our components can communicate with the server, but they cannot yet speak to each other. It is time to establish a fleet-wide comms channel. It is time for the Admiral’s Spyglass.

Part 4: The Admiral’s Spyglass (Advanced State & Capstone)

Current Rank: Lord High Admiral
Objective: To master global state management by integrating Pinia, allowing disconnected Vue components to share data. We will complete our journey by building a real-time fleet dashboard that updates instantly across the entire application using Sails Sockets.

Chief Architect’s Briefing (Background and Theory)

Our current architecture is powerful. Inertia passes data from a Sails controller directly to a page component as props. But what happens when a different, separate component needs that same data?

Imagine a component that needs to display the number of ships in the fleet, and a component that needs to list them. The data (ships) is passed to our main Dashboard.vue page. How do we get it to both the navbar and the overview without complex “prop drilling” (passing data down through layers of components)?

This is the role of a global state management library. Pinia is the current official, lightweight, and intuitive choice for Vue 3 frontendmasters.com.

Think of a Pinia “store” as the ship’s Quartermaster. Instead of every crew member having their own small inventory list, there is one central Quartermaster who holds the master list for the entire ship. Any crew member, from any part of the ship, can ask the Quartermaster for information or ask them to update the master list.

Here’s how it works with Inertia:

Initial Load: Our Sails controller fetches the fleet data and passes it as a prop to our main page component (Dashboard.vue) via res.inertia().
Populate the Store: The first thing Dashboard.vue does with these props is hand them off to the Pinia store (the Quartermaster) to initialize the central state.
Component Access: Now, any other component in our app (Navbar.vue, FleetStatus.vue, etc.) can completely ignore props and instead directly ask the Pinia store for the data it needs.
Real-Time Updates: When our Sails app receives new information (e.g., a new ship is commissioned), it can use Sails Sockets to blast a message to all connected clients. A listener in our app will hear this message and tell the Pinia store to update its state. Because the store is reactive, every single component that uses its data will update automatically and instantly.

This creates our capstone: a true real-time Single-Page Application.

Key Concepts Checklist

Pinia: The official global state management library for Vue 3.
Store: A Pinia container for state, getters, and actions.
defineStore: The function used to create a new store.
State: The raw, reactive data in a store (e.g., the array of ship objects).
Getters: Computed values derived from state (e.g., the total count of ships).
Actions: Functions that can modify the state (e.g., addShip(), setShips()).
Sails Sockets: The real-time communication layer built into Sails.
sails.sockets.blast(): A Sails method to broadcast a message to all connected clients.

Mission Log: Quest - “The Fleet Command Dashboard”

We will build on our inertia-flagship project.

Task 1: Recruit the Quartermaster (Install Pinia)
1. In your inertia-flagship terminal, add Pinia to the project.
```
npm install pinia
```

Task 2: Swear in the Quartermaster (Configure Pinia)

We need to tell our Vue app to use Pinia. Open assets/js/app.js.

// assets/js/app.js
import '../css/app.css';
import { createApp, h } from 'vue';
import { createInertiaApp } from '@inertiajs/vue3';
import { createPinia } from 'pinia'; // <-- IMPORT THIS

const pinia = createPinia(); // <-- CREATE THE INSTANCE

createInertiaApp({
  /* ... existing config ... */
  setup({ el, App, props, plugin }) {
    createApp({ render: () => h(App, props) })
      .use(plugin)
      .use(pinia) // <-- TELL VUE TO USE IT
      .mount(el);
  },
});

Task 3: Create the Master Fleet Roster (The Pinia Store)

Create a new directory: assets/js/stores/.

Inside, create fleetStore.js. This will be our single source of truth for fleet data.

// assets/js/stores/fleetStore.js
import { defineStore } from 'pinia';

export const useFleetStore = defineStore('fleet', {
  state: () => ({
    ships: [],
  }),
  getters: {
    shipCount: (state) => state.ships.length,
    isFleetReady: (state) => state.ships.length > 0,
  },
  actions: {
    setShips(initialShips) {
      this.ships = initialShips;
    },
    addShip(newShip) {
      this.ships.unshift(newShip); // Add new ships to the top
    }
  },
});

Task 4: Prepare the Backend Data & Real-Time Broadcast

Create a model, controller, and route for a list of ships.

sails generate model Ship name:string class:string
sails generate controller DashboardController

In config/routes.js, add the dashboard routes:

'GET /dashboard': 'DashboardController.show',
'POST /ships': 'DashboardController.createShip',

In api/controllers/DashboardController.js, add the logic. Note the sails.sockets.blast call.

module.exports = {
  show: async function (req, res) {
    if (req.isSocket) {
      // Join a room to hear about new ships
      sails.sockets.join(req, 'fleet-dashboard');
    }
    const ships = await Ship.find().sort('createdAt DESC');
    return res.inertia('Dashboard', { ships });
  },

  createShip: async function (req, res) {
    const newShip = await Ship.create({
      name: req.body.name,
      class: req.body.class
    }).fetch();

    // Broadcast the new ship data to all listening clients!
    sails.sockets.blast('ship_added', { newShip });

    return res.ok(); // Just send a 200 OK, no redirect needed for API-like calls
  }
};

Task 5: Build the Dashboard and Components

Create the main page component assets/js/pages/Dashboard.vue. Its only job is to initialize the store.

Create assets/js/components/FleetStatus.vue. This component knows nothing about props; it only knows about the store.

Create assets/js/components/ShipList.vue, which also uses the store.

Task 6: Test the Final System
1. sails lift your application. Navigate to http://localhost:1337/dashboard. You should see the dashboard with “Total Ships: 0”.
2. Open a second browser window or tab and navigate to the same page.
3. In a terminal, use curl (or Postman/Insomnia) to simulate commissioning a new ship:
```
curl -X POST http://localhost:1337/ships -d "name=The Endeavour&class=Frigate"
```
4. Witness the final magic: Instantly, without a page refresh, both browser windows will update. “Total Ships” will become 1, and “The Endeavour” will appear in the roster.

Mission Debrief (Review & Outcomes)

Mission Accomplished, Lord High Admiral.

You have reached the pinnacle of modern web application development. Your flagship is not just a collection of pages; it is a living, breathing application. Data flows seamlessly from the Sails database, through Inertia into a central Pinia store, and is shared across your entire Vue front-end. With Sails Sockets, that data is now updated in real-time, providing an instantaneous experience for all users.

You have mastered the entire process, from laying the first keel with sails new to commanding a real-time fleet with Pinia and Sockets. You are no longer just a captain; you are the architect and commander of a truly modern armada.

The seas of development are vast, but you now possess the charts, the tools, and the command experience to sail anywhere.

Rewards

+1000 Doubloons
Achievement Unlocked: You have built a full-stack, globally-managed, real-time single-page application.
- Final Badge Earned: The Grand Fleet Admiral 🎖️🌟

Sails.js & Vue.js - Part 3

2025-11-16T11:00:00Z

Excellent. The enchanted shipyard has provided us with a state-of-the-art vessel. Now it’s time to step inside and bring its instruments to life. We will begin with the most crucial room on any ship: the Chart Room.

Part 3: The Living Chart Room (Building with Inertia & Vue)

Current Rank: Lord High Admiral
Objective: To transform a static information page into a dynamic, data-driven Vue component using Inertia, learning to pass data from Sails, navigate between pages without reloads, and submit forms.

Chief Architect’s Briefing (Background and Theory)

Our inertia-flagship is ready. The core task now is to build out a feature. We will create a “Chart Room” where the captain can view a list of known destinations and plot new ones.

This process will demonstrate the complete, magical end-to-end flow of the Modern Monolith:

A user will click a component on our homepage to navigate to /chartroom.
Our Sails router (config/routes.js) will direct this request to a new ChartRoomController.
The controller will use a Destination model to fetch all known destinations from the database.
The controller will then pass this list of destinations as props to a Vue page component using res.inertia('ChartRoom', { destinations: allDestinations }).
Our ChartRoom.vue component will receive the destinations array as a prop and use a v-for loop to display it.
Inside the ChartRoom.vue component, we will build a form. When submitted, this form will use an Inertia helper (useForm) to POST data to a new Sails endpoint. This helper gracefully handles loading states and validation errors for us.
The Sails controller action will process the form data, create a new Destination in the database, and then issue a res.redirect('/chartroom').
Inertia intercepts this redirect, automatically re-fetches the props for /chartroom (which now include the new destination), and updates the page.

Notice: no manual fetch calls, no manual JSON parsing, no manual page refreshing. It’s a seamless conversation between the backend and frontend.

Key Concepts Checklist

defineProps: A Vue 3

Task 4: Create Navigation to the Chart Room

We need a way to get to our new page. Open assets/js/pages/Homepage.vue.

Import the component and add a link to /chartroom.

Task 5: Test the Data Flow
1. Lift your sails: sails lift.
2. Visit http://localhost:1337. Click the “Enter the Chart Room” link.
3. Observe: The URL changes to /chartroom and you see the new page without a full page refresh. It will say “No destinations plotted yet.” This confirms the link, controller, and component are all wired up correctly.
Task 6: Add the Form to Plot New Courses
1. Now for the interactive part. Let’s add a form to assets/js/pages/ChartRoom.vue.
2. Update the

Task 7: Create the Form-Handling Endpoint

The form POSTs to /destinations. Let’s create that route and controller logic.

In config/routes.js, add the POST route:

'POST /destinations': 'ChartRoomController.createDestination',

In api/controllers/ChartRoomController.js, add the createDestination action:

module.exports = {
  show: async function (req, res) {
    // ... same as before
  },

  createDestination: async function(req, res) {
    await Destination.create({
      name: req.body.name,
      eta: req.body.eta,
    });
    // This redirect is caught by Inertia, which then reloads the page's props!
    return res.redirect('/chartroom');
  },
};

Task 8: Final Test
1. Relaunch your app (sails lift).
2. Go to the Chart Room. Fill out the form (e.g., Name: “Tortuga”, ETA: “3 days”) and click “Plot Course”.
3. Witness the magic: The form submits, the button briefly says “Plotting…”, and then the new destination instantly appears in the “Known Destinations” list above, without a full page reload.

Mission Debrief (Review & Outcomes)

Outstanding, Admiral. The Chart Room is now a living instrument. You have mastered the fundamental workflow of a modern Sails + Inertia application. You’ve passed data as props, navigated with , and handled form submissions with useForm, all while keeping your controller logic clean and familiar.

You can see how this pattern removes immense complexity. The front-end doesn’t need to know how to re-fetch the list; it just submits a form. The back-end doesn’t need to return special JSON; it just creates data and issues a standard redirect. Inertia handles the complex conversation between them, letting each side focus on what it does best.

Rewards

+600 Doubloons
Achievement Unlocked: You have built a fully functional, data-driven, interactive SPA page.
- Badge Earned: The Living Cartographer 🗺️✨

Sails.js & Vue.js - Part 2

2025-11-09T11:00:00Z

The traditional refit was a success, but it revealed the friction of the old ways. Now, we unleash the full power of the modern armada. We will cast the magical enchantment that fuses our Sails backend and Vue front-end into a single, seamless entity.

Part 2: The Magical Enchantment (Introducing Inertia.js)

Current Rank: Lord High Admiral
Objective: To understand what Inertia.js is, how it works, and to use the modern create-sails tool to scaffold a new Sails + Vue + Inertia project, creating the perfect foundation for our SPA.

Chief Architect’s Briefing (Background and Theory)

In our last mission, we had our Vue crew “shouting across the deck” to the Sails crew via API calls. It worked, but it was noisy and required building two separate communication systems.

Inertia.js is the magical, telepathic link between the two crews.

It’s not a framework; it’s a new approach to building classic server-driven web apps. It allows us to create fully client-side rendered, single-page apps without the complexity of building and consuming a separate API. As the team behind Inertia says, it’s “The Modern Monolith.”

Here’s how the magic works:

A Link is Clicked: A user clicks a special component in your Vue front-end (e.g., ).
Inertia Intercepts: Instead of a full page reload, Inertia intercepts this click and makes a background request (an XHR/fetch request) to the Sails server.
Sails Responds: Your Sails config/routes.js and controller work exactly as they did before. The controller fetches data from the database.
The New Response: This is the key. Instead of calling res.view('logbook', { data }) or res.json({ data }), your controller calls a new response: res.inertia('LogbookPage', { data }).
The Magic Payload: Sails sends back a special JSON response that contains two things: the name of the Vue component to render (LogbookPage) and the data as “props.”
Vue Takes Over: Back in the browser, Inertia receives this payload, automatically finds the LogbookPage.vue component, and seamlessly swaps it into the view, passing the data directly to it as props.

The result? You write your back-end logic in Sails controllers as you always have, and your front-end logic in self-contained Vue components. Inertia handles the “glue” in between. The official inertia-sails adapter is designed precisely for this, letting you “have the power of Sails and the client-side framework of your choice in one codebase” blog.sailscasts.com.

Setting this up manually is complex. Thankfully, the Sails community has provided a powerful shipwright’s tool to do it for us.

Key Concepts Checklist

Inertia.js: The “glue” that connects a classic server-side framework (Sails) with a modern client-side framework (Vue).
Modern Monolith: The architectural style of a single codebase that provides the feel of an SPA.
Adapter: Server-side code (like inertia-sails) that teaches Sails how to speak the “Inertia language.”
res.inertia(): The new response method used in controllers to render a client-side component.
Props: The mechanism for passing data from a Sails controller directly to a Vue component.
: The Inertia component that replaces traditional tags for SPA navigation.

create-sails: A scaffolding tool that generates a new Sails project pre-configured with Inertia and your choice of front-end framework docs.sailscasts.com.

Mission Log: Quest - “The Enchanted Shipyard”

We will not refit our old ship. We will build a new one from the ground up using the most modern tools available, creating the perfect foundation.

Task 1: Commission the New Shipwright (create-sails)
1. This tool will build our project’s skeleton for us. In your terminal (outside of any existing project), run the following command:
```
npx create-sails@latest
```
Task 2: Issue the Building Orders
1. The command will launch an interactive setup wizard. Answer the prompts as follows to build an Inertia-powered Vue ship:
  - What is the name of your app?: inertia-flagship
  - Choose a template: Web App
  - Which front-end framework would you like to use?: Vue
2. The tool will now download all the necessary dependencies and configure the project. This may take a minute or two. Once finished, navigate into your new vessel: cd inertia-flagship.
Task 3: Inspect the Enchanted Blueprints
1. Open the inertia-flagship project in your code editor. You’ll notice some new and important files that create-sails built for us:
  - vite.config.js: This configures Vite, a blazing-fast, modern build tool that now manages our front-end assets instead of the old Grunt-based system.
  - assets/js/app.js: The main entry point for our Vue/Inertia application on the client-side.
  - assets/js/pages/: This is where your Vue components will live. You’ll see a Homepage.vue already created.
  - api/responses/inertia.js: The server-side code that provides the res.inertia() response.
  - views/layouts/app.ejs: A very minimal layout file. Its only job is to provide a single
    for Inertia to hook into.
Task 4: The Maiden Voyage
1. create-sails already ran npm install for you. All we need to do is lift the sails.
```
sails lift
```
2. Open your browser to http://localhost:1337. You will see a stylish welcome page. This entire page, unlike our previous projects, is a Vue component (Homepage.vue) rendered by Inertia!

Mission Debrief (Review & Outcomes)

Magnificent! You have just constructed a state-of-the-art vessel’s foundation in a fraction of the time it would have taken manually. You didn’t just build a ship; you built an enchanted shipyard, a development environment where the back-end and front-end are perfectly integrated from day one.

You now have a project where:

Vite provides lightning-fast development builds.
Sails handles routing and data logic.
Vue handles the view layer.
Inertia seamlessly bridges the two.

We haven’t built any custom features yet, but we have established the most powerful foundation possible. In our next mission, we will use this enchanted vessel to begin replacing static pages with fully interactive, data-driven Vue components.

Rewards

+500 Doubloons
Achievement Unlocked: You have mastered the modern scaffolding process and understand the core theory of Inertia.js.
- Badge Earned: The Shipwright Enchanter ✨

Sails.js & Vue.js - Part 1

2025-11-02T11:00:00Z

Lord High Admiral. We will begin the refit. Before we outfit the fleet with the latest enchantments, a true commander must understand the traditional craft. This first step will ground us in the fundamentals of how a modern front-end communicates with our Sails vessel using the ship’s existing systems.

Part 1: The Traditional Refit (Vue & The Asset Pipeline)

Current Rank: Lord High Admiral
Objective: To manually integrate a Vue.js component into a classic Sails EJS view, using the built-in asset pipeline and standard fetch requests to create a reactive island on a traditional web page.

Chief Architect’s Briefing (Background and Theory)

Our ships are currently built with EJS templates rendered on the server. When you visit /logbook, Sails compiles the HTML and sends a complete page to your browser. Our goal is to enhance these pages, not replace them entirely… yet.

We will treat Vue.js as a specialist crew member that we bring aboard to manage one specific, complex part of the deck. To do this, we will leverage Sails’ built-in Asset Pipeline.

The assets/ directory in your Sails project is a special place. Sails automatically processes the files within it. Any JavaScript file you place in assets/js/ will be automatically included as a

Task 3: Prepare the Workstation (The Mount Point)

Open the default homepage view: views/pages/homepage.ejs.
Replace its content with a simple structure, including the
where our Vue app will live.
```
  Live Cargo Manifest
  Loading manifest from the ship's hold...
  
    
      {{ item.name }} - Quantity: {{ item.quantity }}
    
  
```
Notice the Vue-specific syntax like v-if and v-for. This will be inert HTML until Vue takes control of it.

Task 4: Create the API Endpoint

Generate a new controller to serve our manifest data.
```
sails generate controller ManifestController
```

Open api/controllers/ManifestController.js and create an action to return JSON data.

module.exports = {
  get: function(req, res) {
    const cargoData = [
      { id: 1, name: 'Barrels of Rum', quantity: 50 },
      { id: 2, name: 'Crates of Cannonballs', quantity: 100 },
      { id: 3, name: 'Secret Treasure Maps', quantity: 5 }
    ];
    return res.json(cargoData);
  }
};

Create a route for this endpoint in config/routes.js:
```
'GET /api/v1/manifest': 'ManifestController.get',
```

Task 5: Write the Vue App Logic

Create a new file: assets/js/manifest-app.js.

Add the Vue code that will mount to our div, fetch data from the API, and manage the state.

const { createApp } = Vue;

createApp({
  data() {
    return {
      cargo: [],
      loading: true
    }
  },
  async mounted() {
    console.log('Vue app has mounted, fetching manifest...');
    const res = await fetch('/api/v1/manifest');
    this.cargo = await res.json();
    this.loading = false;
  }
}).mount('#manifest-app');

Task 6: Hoist the Sails

Start your server: sails lift.
Open your browser to http://localhost:1337.
You will briefly see “Loading manifest…” and then, almost instantly, the list of cargo items will appear. This list was not rendered by EJS; it was rendered on the client-side by Vue after it fetched data from your Sails API.

Mission Debrief (Review & Outcomes)

Excellent work, Admiral. You have successfully refitted a traditional vessel with a modern, reactive component. You now understand the fundamental mechanics: a server-rendered page loads, a JavaScript library is included, it mounts to a DOM element, and it fetches data from an API to manage its own small piece of the world.

However, consider the complexities. We had to manually create API endpoints for our front-end. We have Vue syntax sitting inside an EJS file. We wrote a manual fetch call. If we wanted to add a form to add new cargo, we’d have to write more manual fetch calls with POST requests and handle the response.

This approach works, but it feels… disconnected. It’s like our specialist Vue crew has to shout across the deck to the Sails crew to get anything done. What if they could communicate telepathically?

This is the very problem that Inertia.js was born to solve.

Rewards

+400 Doubloons
Achievement Unlocked: You have successfully bridged the gap between a classic back-end and a modern front-end framework.
- Badge Earned: The Traditional Refitter 🛠️

Learn Sails.js - Part 10

2025-10-26T11:00:00Z

You have mastered this vessel and are ready for the final trial. It is time to step onto the quarterdeck, take the spyglass, and look toward the horizon. This isn’t just about one ship anymore; it’s about commanding a fleet.

Part 10: Becoming a Fleet Admiral (Capstone Project & Next Steps)

Current Rank: Captain
Objective: To synthesize all acquired knowledge by building a complete Sails.js application from scratch, solidifying your skills and creating a flagship project for your portfolio.

The Captain’s Briefing (Background and Theory)

Captain, you began this journey with nothing but an empty hull (sails new). You learned to frame the ship with MVC, stock its holds with Models and Waterline, and hire a specialist crew with Services. You installed a magical telegraph with WebSockets, posted guards with Policies, drilled your crew with automated Tests, and finally charted a course for the open sea of production.

This part is the culmination of that professional development. There are no new concepts to learn. Instead, this is your final examination, a solo voyage where you will apply everything you have learned to build your own flagship. This is where theory becomes practice, where knowledge becomes wisdom. You will face challenges and have to consult the charts (the documentation), but that is the essence of command.

By completing this capstone project, you will have more than just a passing knowledge of Sails; you will have tangible proof of your ability to architect, build, secure, and deploy a modern, real-time web application. This project becomes the crown jewel of your fleet, a testament to your skill that you can show to others.

After this, the world is yours. We will look at where you can sail next, from exploring advanced shipwrighting with custom hooks to forming alliances with powerful front-end frameworks.

Mastery Checklist (Concepts You Command)

You are now proficient in the following arts of web development:

MVC Architecture: Organizing code into Models, Views, and Controllers.
Waterline ORM: Defining models, associations, and validations.
Blueprint API: Leveraging automatic CRUD routes for rapid development.
Custom Controllers & Actions: Writing bespoke logic for requests.
Services: Encapsulating reusable business logic.
WebSockets & sails.io.js: Implementing real-time communication.
Authentication: Managing user sessions and securely handling passwords.
Policies & Authorization: Securing endpoints with access control rules.
Automated Testing: Writing unit tests with Mocha to ensure code quality.
Environment Configuration: Managing settings for development and production.
Deployment: Launching a production-ready application with a process manager.

Mission Log: Quest - “The Fleet Admiral’s Flagship”

Your orders are to construct a new ship, superior to any you’ve worked on before. This will be your personal flagship.

The Mission: Build a “Live Fleet Log.” This application will allow multiple registered captains to post log entries, which will then appear in a real-time feed for all connected users to see.

Admiral’s Orders (Project Requirements):

From Scratch: Create a new Sails project: sails new flagship.
Models & Associations:
- Create a User model (emailAddress, fullName, encryptedPassword).
- Create a LogEntry model (text, priority).
- Establish a one-to-many association: A User can have many LogEntry records.
Authentication & Security:
- Implement user signup, login, and logout. Passwords must be hashed.
- Use policies to ensure that only logged-in users can create new log entries.
- A user should only be able to edit or delete their own log entries.
Services:
- Create a FormattingService with a method like formatTimestamp(date) that you can use to make the timestamps on log entries look nice.
Real-Time Dashboard:
- Create a main dashboard page that is visible to everyone (even logged-out users).
- When a user creates a new LogEntry, it should be broadcast via WebSockets and appear instantly at the top of the dashboard on every connected client’s browser without a page refresh.
Automated Drills:
- Write at least one unit test for your FormattingService.
- Write at least one “request” test that attempts to create a log entry without being logged in and asserts that it is forbidden.

Bonus Challenge: “Beyond the Horizon”

Integrate a Third-Party API: A key skill for any developer is integrating external services. Add a feature where, upon creating a log entry, you use its text to call out to an external API.
- Idea 1: Use a weather API to attach the current “sea conditions” to every new log entry.
- Idea 2: Use a sentiment analysis API to determine if a log entry is “positive,” “negative,” or “neutral” and display an icon next to it.
This will require you to use an HTTP request library like axios (npm install axios) inside a Sails action or service.

Mission Debrief (A Captain’s Legacy)

Upon completing this quest, you have not just finished a tutorial; you have built a complex, portfolio-worthy application. You have faced the challenges of development head-on and emerged victorious. Your flagship is complete. The title is earned.

Congratulations, Fleet Admiral.

Your journey with Sails is just beginning. The charts are now yours to read.

Where to Sail Next:

Study the Official Charts (Sails Docs): The official Sails.js documentation is your bible. Dig into concepts you’re curious about, like custom hooks, file uploads, and advanced model settings.
Advanced Shipwrighting (Custom Hooks): Learn to build your own custom hooks to add reusable functionalities, like a hook that connects to a special service on every startup.
Form Alliances (Front-End Frameworks): Learn how to use Sails as a pure API backend for a powerful front-end fleet like React, Vue, or Angular.
Join the Council of Admirals (The Community): Engage with the Sails community on GitHub or other forums. Contribute to the open-source project, help others, and continue to learn from your fellow captains.

Final Rewards

+1000 Doubloons
Achievement Unlocked: You have achieved total mastery, from building the hull to commanding the fleet. You are a true Sails.js architect.
- Badge Earned: Fleet Admiral 🎖️

Fair winds and following seas, Admiral. Your fleet awaits its orders.

Learn Sails.js - Part 9

2025-10-19T10:00:00Z

All preparations are complete. The crew is drilled, the ship is secure, and the holds are managed. But we are still anchored in a safe, familiar harbor. The time has come to chart a course for the open sea, the unpredictable, high-performance world of production.

Part 9: Charting the Open Seas (Configuration & Deployment)

Current Rank: First Mate
Objective: To prepare your Sails application for a live production environment by managing environment-specific configurations and learning the process of deploying it to a server.

The Captain’s Briefing (Background and Theory)

So far, we have operated in a private shipyard (localhost). Here, the waters are calm. Mistakes are cheap, our tools are laid out for us (sails lift auto-restarts the server), and performance isn’t a primary concern.

The open sea, a production environment, is different. It’s treacherous and demanding. Visitors expect a ship that is fast, efficient, and always available. We can’t have our First Mate on the deck constantly restarting the engine by hand. The ship must be configured to be lean, resilient, and ready for battle.

Environment-Specific Blueprints

Sails has a brilliant system for this: the config/env/ directory. Sails knows which environment it’s in based on a system-level flag called NODE_ENV.

When you run sails lift, by default NODE_ENV is development. Sails will look for a file at config/env/development.js and merge its settings.
When you run your app for production, you set NODE_ENV to production. Sails then looks for config/env/production.js and uses its settings instead.

This allows you to have completely different configurations for your shipyard and your sea voyages. Common differences include:

Datastores: Using the temporary sails-disk in development, but a powerful, persistent database like PostgreSQL in production.
Logging: Verbose, detailed logs in development to help you debug, but quieter, more essential logs in production to save resources.
Security: Using different API keys, secrets, and credentials. You must never commit production secrets to your code repository. They should be set as environment variables on the server itself, which production.js can then read.
Performance: Sails automatically does amazing things in production mode, like minifying your CSS and JavaScript files and bundling them together into single files. This makes your ship “lighter” and drastically reduces page load times for your visitors.

Launching the Fleet: The Dockmaster (PM2)

You don’t just run sails lift on a production server and walk away. What happens if the app crashes? Who restarts it? This is the job of a Process Manager.

A process manager is a dockmaster for your live application. The most popular one for Node.js apps is PM2. It’s a simple tool that you run your app with. It will:

Keep your app running in the background.
Automatically restart the app if it ever crashes.
Help you run your app on multiple CPU cores for better performance.
Manage and rotate log files.

The command to launch your ship for its maiden voyage will be sails lift --prod. The --prod flag is the crucial signal that tells Sails to enable all its production optimizations and use your production.js configuration file.

Key Concepts Checklist

Environment Configuration: Using different settings for development, testing, and production.
NODE_ENV: The environment variable that tells Sails which mode to run in.
config/env/production.js: The file containing all settings overrides for a live environment.
Asset Minification/Bundling: Sails’ automatic process of optimizing CSS/JS for production.
Process Manager: A tool (like PM2) that keeps your live application running reliably.
sails lift --prod: The command to start Sails in production mode.
Secrets Management: The practice of keeping sensitive data like API keys out of your code.

Mission Log: Quest - “The Maiden Voyage Simulation”

We will prepare our ship for launch, configure its production-ready blueprints, and use a professional process manager to launch it, all safely on our local machine.

Task 1: Prepare the Production Blueprints

In your config/ directory, create a new folder named env.
Inside config/env/, create a new file named production.js.

Add the following configuration. This tells Sails how to behave on the open sea.

// config/env/production.js
module.exports = {
  datastores: {
    /***************************************************************************
    *                                                                          *
    * In production, you'll want to use a real database like PostgreSQL or     *
    * MySQL. This is where you'd configure the connection settings.            *
    *                                                                          *
    ***************************************************************************/
    // default: {
    //   adapter: 'sails-postgresql',
    //   url: 'YOUR_PRODUCTION_DATABASE_URL',
    //   ssl: true,
    // },
  },

  log: {
    // In production, we only want to log 'info' level messages and above
    level: 'info'
  },

  session: {
    // A secure, long, random secret for signing session cookies.
    // Replace this with your own secret!
    secret: 'a4f434a2a163aed4b72449856f6b158b'
  }
};

Task 2: Install the Dockmaster (PM2)
1. PM2 is a command-line tool that should be installed globally. In your terminal, run:
```
npm install pm2 -g
```
Task 3: Simulate the Maiden Voyage
1. We will now launch our ship in production mode. Notice the difference in the log output compared to sails lift.
2. In your terminal, run:
```
sails lift --prod
```
  You’ll see much less chatter, just the essential “ship is online” message. The log level from production.js is working! Press CTRL+C to stop it.
Task 4: Launch with the Dockmaster
1. This is the professional way to launch. We tell PM2 to start our app.
2. Run this command from your project root:
```
pm2 start app.js --name "the-sea-serpent" -- --prod
```
  - pm2 start app.js: The basic command to start the app.
  - --name "the-sea-serpent": Gives our running process a memorable name.
  - -- --prod: This is critical. The double-dash (--) tells PM2 to pass the --prod flag directly to our app.js script, putting Sails in production mode.
Task 5: Manage Your Fleet
1. Your app is now running in the background! How do we check on it?
2. List running processes:
```
pm2 list
```
  You will see “the-sea-serpent” in the list with a status of “online”.
3. Check the ship’s logs:
```
pm2 logs the-sea-serpent
```
4. Stop the ship:
```
pm2 stop the-sea-serpent
```

Mission Debrief (Review & Outcomes)

Land ho! The maiden voyage was a roaring success. You have successfully taken your application out of the development shipyard and prepared it for the rigors of the open ocean.

You now understand the critical difference between development and production environments and how to manage configurations for both. You have wielded a professional process manager, PM2, to launch, monitor, and control your application like a true fleet commander. While we only simulated this locally, these are the exact skills and commands you would use when deploying to a real server on a host like DigitalOcean or AWS.

Rewards & Promotion

+350 Doubloons
Achievement Unlocked: You have successfully configured and launched your application for a production environment. Your ship is ready to sail the world.
- Badge Earned: Seasoned Mariner 🌊
Promotion to: Captain

Take the helm, Captain. You have proven your mastery of this vessel, from its initial construction to its final launch. There is only one challenge remaining: to command a fleet of your own.

Learn Sails.js - Part 8

2025-10-12T10:00:00Z

Posting guards is only half the battle. A truly professional crew constantly runs drills to ensure every system is in perfect working order before the storm hits. It’s time to build your safety net.

Part 8: Running Ship Drills (Automated Testing)

Current Rank: Quartermaster
Objective: To write automated tests for your application, ensuring code quality, preventing regressions, and building a safety net that allows you to make changes with confidence.

The Captain’s Briefing (Background and Theory)

Our ship is complex now. It has a routing system, a view layer, a database interface, authentication guards, and specialist services. If you change a single line of code in the AppraisalService, how can you be certain you didn’t accidentally break the login system? Do you manually click through every single feature of the entire ship after every single change?

That is the path to madness. A professional crew runs drills. An automated test is a drill for your code. It’s a script you write that checks if a piece of your application behaves exactly as you expect. You can run thousands of these drills in seconds, giving you immediate feedback.

The Drill Sergeant: Mocha

Sails.js comes equipped with a battle-hardened testing framework called Mocha right out of the box. Mocha provides a simple structure for organizing your tests:

describe('the system being tested', ...): This creates a “test suite,” a collection of related drills. For example, describe('AppraisalService', ...)
it('should do this specific thing', ...): This is the individual drill or “test case.” Its description should read like a sentence explaining what should happen. For example, it('should calculate the correct tax', ...)
Assertions: Inside the it() block, you perform an action and then assert that the outcome is what you expected. An assertion is a simple check that throws an error if the condition is false. For example: assert.equal(actualValue, expectedValue). If they aren’t equal, the test fails.

The Test Environment

Crucially, you never want your drills to interfere with your real cargo. blog.sailscasts.com explains that Sails is configured to use a special test environment when you run your tests. As part of this setup, it’s common practice to use an in-memory or separate test database, ensuring your tests run in a clean, isolated environment and don’t touch your development data. Good tests clean up after themselves, a principle mentioned in the Sails docs for effective testing app.studyraid.com.

The Bootstrap File: Hoist the Sails!

To test any part of Sails, the app itself needs to be running. Sails provides a special file, test/bootstrap.test.js, for this purpose. Before any of your drills are run, this bootstrap file runs sails.lift() to start the app in the test environment. After all your drills are complete, it runs sails.lower() to shut it down cleanly. You don’t need to touch this file, but it’s important to know it’s working for you behind the scenes.

Today, we will write a Unit Test. A unit test focuses on the smallest possible “unit” of code—in our case, a single service function—in complete isolation.

Key Concepts Checklist

Automated Test: A script that verifies the correctness of your application code.
Mocha: The JavaScript testing framework that comes with Sails.
describe(): Defines a test suite.
it(): Defines a single test case.
Assertion: A statement that checks if a condition is true (e.g., assert.equal()).
Unit Test: A test for a small, isolated piece of functionality.
Test Environment: A separate configuration used for running tests to prevent side effects.
npm test: The universal command to run all automated tests in a project.

Mission Log: Quest - “The Appraiser’s Examination”

We hired a new Appraiser in part 5, but how do we know they are trustworthy? We will write a formal examination (a unit test) to verify that the AppraisalService is, and always will be, calculating taxes correctly.

Task 1: Prepare the Examination Room
1. Test files live in the test/ directory. By convention, we’ll create a folder for our unit tests.
2. In your code editor, create a new folder named unit inside the test/ directory.
3. Inside test/unit/, create a new file named AppraisalService.test.js.

Task 2: Write the Examination Questions

Open test/unit/AppraisalService.test.js and add the following test code. This is a classic Mocha test suite.

const assert = require('assert');

// We are testing our AppraisalService
describe('AppraisalService', function() {

  // This is the specific test case
  it('should correctly calculate the 15% Crown\'s Tax on a value', function() {

    // Step 1: Arrange - Set up our inputs and expected outputs
    const originalValue = 1000;
    const expectedTaxedValue = 850; // 1000 - 15%

    // Step 2: Act - Run the code we are testing
    const actualTaxedValue = AppraisalService.getTaxedValue(originalValue);

    // Step 3: Assert - Check if the result is what we expected
    assert.equal(actualTaxedValue, expectedTaxedValue, 'The calculated tax was not correct.');

  });

  it('should handle a value of zero', function() {
    assert.equal(AppraisalService.getTaxedValue(0), 0);
  });

});

Task 3: Run the Drill
1. You run tests from the command line using the npm test command. This command is pre-configured in your package.json file by Sails.
2. In your terminal, inside the project root, run:
```
npm test
```
3. You should see output from Mocha showing your tests running. If all is well, it will end with a satisfying green message:
```
  AppraisalService
    ✓ should correctly calculate the 15% Crown's Tax on a value
    ✓ should handle a value of zero


  2 passing (20ms)
```
  This confirms your AppraisalService is working as expected.
Task 4: Witness a Failed Drill (The Safety Net in Action)
1. Now, let’s see what happens when we break something. This is the most important part of testing.
2. Open your service file: api/services/AppraisalService.js.
3. Temporarily change the tax rate. Let’s say the crown gets greedy. Change 0.15 to 0.20.
```
// In AppraisalService.js
const CROWN_TAX_RATE = 0.20; // Changed from 0.15
```
4. Save the file and run the drill again from your terminal:
```
npm test
```
5. This time, the test will fail. Mocha will give you a detailed, bright red report showing you exactly what went wrong.
```
  AppraisalService
    1) should correctly calculate the 15% Crown's Tax on a value
    ...

  1 passing (21ms)
  1 failing

  1) AppraisalService
       should correctly calculate the 15% Crown's Tax on a value:

      AssertionError [ERR_ASSERTION]: The calculated tax was not correct.
      + expected - actual

      - 800
      + 850
```
  Your test just acted as your safety net! It caught a bug (a “regression”) automatically. You now know precisely what you broke.
6. Go back to AppraisalService.js, change the rate back to 0.15, and run npm test one more time to see everything pass.

Mission Debrief (Review & Outcomes)

Flawless execution! The drill was a success. You have now established a fundamental process for ensuring the quality and stability of your ship.

You’ve created a unit test that verifies your business logic, and more importantly, you’ve seen how that test protects you from introducing new bugs down the line. As your application grows, your test suite will become your most trusted advisor, giving you the confidence to refactor code, add new features, and sail your application into new waters without fear of capsizing. You can even integrate tools like Istanbul to measure your test coverage, as noted by Packt packtpub.com.

Rewards & Promotion

+300 Doubloons
Achievement Unlocked: You have built an automated safety net to protect your application from regressions.
- Badge Earned: Shipshape Scrutineer 🔬
Promotion to: First Mate

Incredible work. As First Mate, you are now second-in-command. You have mastered the ship’s internal workings, its crew, its defenses, and its procedures. There is only one task left: to prepare this vessel for its maiden voyage into the wider world.

Learn Sails.js - Part 7

2025-10-05T10:00:00Z

The locks and coffers are in your charge. A ship carrying valuable cargo in open waters without guards is not a warship; it’s a target. It’s time to post the watch and secure this vessel.

Part 7: Guarding the Gangway (Authentication & Policies)

Current Rank: Quartermaster
Objective: To secure your application by implementing a robust user authentication system (login/logout) and using Policies to enforce access control rules.

The Captain’s Briefing (Background and Theory)

So far, our ship has an open-gangway policy. Anyone can wander aboard, read the Captain’s Log (/logbook), and even create new treasure using our API. This is untenable. We need to distinguish between an anonymous visitor and a verified member of the crew. This process involves two distinct concepts: Authentication and Authorization.

Authentication: “Show Me Your Papers”

Authentication is the process of verifying who someone is. On the web, this is the classic login form. The user provides credentials (like a name and password), and the server checks if they are valid.

How does the server remember the user after they log in? Through a Session. When a user logs in successfully, the server gives their browser a special, secret cookie that acts like a temporary crew pass. On every subsequent request, the browser sends this cookie back, and the server uses it to retrieve that user’s session data (e.g., their user ID), confirming they are still “logged in.”

A critical part of authentication is securely storing passwords. You must never, ever store plain-text passwords in your database. We will use a one-way cryptographic hashing algorithm (bcrypt) to turn passwords into a long, irreversible string of characters. When a user tries to log in, we hash the password they provided and compare it to the hash in our database. The passwords are never stored in a readable format.

Authorization with Policies: “Are You on the List?”

Authorization happens after authentication. Now that we know who the user is, we must decide what they are allowed to do. An Able Seaman can access the mess hall, but only the Quartermaster can access the cargo manifest.

In Sails, authorization is handled by Policies. A Policy is a small middleware function that you place in api/policies/. It’s a guard who stands at the gangway of a specific controller action. The guard checks the request (e.g., “Does this person have a valid session ID?”) and decides to either: 1. Let them pass by calling next(). 2. Deny them access by sending a response like res.forbidden().

You assign these guards to their posts in the config/policies.js file. sailsjs.com explains that this file acts as your application’s master Access Control List (ACL). You create a map that says, “To access this action, you must first pass through these policies.” This provides a powerful, centralized place to manage your entire application’s security rules. blog.sailscasts.com highlights the most common and powerful pattern: deny access to everything by default, then explicitly grant access to specific actions.

Key Concepts Checklist

Authentication: Verifying a user’s identity (e.g., login).
Authorization: Determining what an authenticated user is permitted to do.
Session: Server-side data linked to a browser cookie, used to “remember” a logged-in user.
Password Hashing: The non-reversible process of scrambling a password for secure storage. We’ll use the bcryptjs library.
Policy: A middleware function in api/policies/ that guards a route.
config/policies.js: The file where you assign policies to controllers and actions.
req.session: The object where you can store data for the current user’s session.
sails generate policy: The command to create a new policy file.

Mission Log: Quest - “Secure the Quarterdeck”

We will now lock down the Captain’s Log (/logbook). It will only be accessible to a logged-in Captain. We will create signup, login, and logout functions to manage this access.

Task 1: Prepare for Secure Passwords

We need the bcryptjs library. From your terminal, inside your project folder, run:
```
npm install bcryptjs --save
```

Update your Captain model to store a secure password. Open api/models/Captain.js and add the encryptedPassword attribute.

module.exports = {
  attributes: {
    name: { type: 'string', required: true, unique: true },
    rank: { type: 'string', defaultsTo: 'Captain' },
    encryptedPassword: { type: 'string', required: true },

    treasures: {
      collection: 'treasure',
      via: 'owner'
    }
  }
};

Task 2: Assemble the Guard (Create the Policy)

Generate the policy file:
```
sails generate policy isLoggedIn
```

Open api/policies/isLoggedIn.js and add this logic. This guard checks for a valid session.

module.exports = async function (req, res, next) {
  // If the user isn't logged in...
  if (!req.session.userId) {
    // ...then forbid access and stop.
    return res.forbidden('You are not logged in.');
  }
  // Otherwise, if they are logged in, continue to the requested action.
  return next();
};

Task 3: Post the Guard Duty Roster (Configure Policies)

Open config/policies.js. This is where we tell our ship which areas need guarding.

Replace the entire contents with this “default deny” configuration. We lock everything down, then open up only the specific routes needed for authentication.

module.exports.policies = {
  // By default, require users to be logged in to access any action.
  '*': 'isLoggedIn',

  // Allow visitors to access the login, signup, and logout actions
  // in the AuthController.
  AuthController: {
    'login': true,
    'signup': true,
    'logout': true
  },

  // The default homepage should be accessible to all.
  // We target the specific route action for the homepage.
  'view-pages-homepage': true
};

Task 4: Build the Authentication System

Generate a new controller to handle login/logout/signup: sails generate controller AuthController.

Open api/controllers/AuthController.js and fill it with these actions:

const bcrypt = require('bcryptjs');

module.exports = {

  signup: async function (req, res) {
    const { name, password } = req.allParams();
    if (!name || !password) {
      return res.badRequest('Name and password are required.');
    }

    const encryptedPassword = await bcrypt.hash(password, 10);
    const captain = await Captain.create({ name, encryptedPassword }).fetch();

    // Log the user in immediately after signup
    req.session.userId = captain.id;

    return res.ok(captain);
  },

  login: async function (req, res) {
    const { name, password } = req.allParams();
    if (!name || !password) {
      return res.badRequest('Name and password are required.');
    }

    const captain = await Captain.findOne({ name });
    if (!captain) {
      return res.unauthorized('Invalid credentials.');
    }

    const isPasswordMatch = await bcrypt.compare(password, captain.encryptedPassword);
    if (!isPasswordMatch) {
      return res.unauthorized('Invalid credentials.');
    }

    // If we made it here, the credentials are valid. Log the user in.
    req.session.userId = captain.id;

    return res.ok('Login successful.');
  },

  logout: async function (req, res) {
    req.session.destroy(function (err) {
      if (err) { return res.serverError(err); }
      return res.ok('Logout successful.');
    });
  }

};

Task 5: Chart the Authentication Routes
1. Open config/routes.js and add the new routes, preferably near the top. We use POST as it’s the correct verb for sending data to create sessions or users.
```
'POST /signup': 'AuthController.signup',
'POST /login': 'AuthController.login',
'GET /logout': 'AuthController.logout',
```
Task 6: Test Your Security
1. Restart your server with sails lift.
2. In your browser, first try to access http://localhost:1337/logbook. You will be blocked! The isLoggedIn policy is working.
3. This time, we need to use curl or Postman to test the POST routes properly. From a new terminal:
4. Sign up a new Captain:
```
curl -X POST http://localhost:1337/signup --data "name=AnneBonny&password=secretpassword" -c cookies.txt
```
  The -c cookies.txt command saves the session cookie from the server.
5. Attempt to access the logbook with your credentials:
```
curl http://localhost:1337/logbook -b cookies.txt
```
  Success! Because you sent the cookie back (-b cookies.txt), the server knew who you were and the policy let you pass. You should see the HTML for the logbook page.

Mission Debrief (Review & Outcomes)

Excellent work, Quartermaster. The gangway is secure. The ship is no longer open to just any port visitor.

You have successfully implemented a professional-grade authentication and authorization system. You learned how to securely handle passwords, manage user sessions, and use policies as intelligent guards for your application’s sensitive areas. By adopting the “default deny” strategy in config/policies.js, you have established a robust security posture that will serve you well as your application grows in complexity. The ship and its cargo are now safe under your watch.

Rewards

+300 Doubloons
Achievement Unlocked: You have mastered the arts of authentication and authorization, securing the ship from unauthorized access.
- Badge Earned: The Gatekeeper 🔑

Learn Sails.js - Part 6

2025-09-28T10:00:00Z

Excellent. The crew is organized, but our communication methods are antiquated. Sending a message to another ship requires a fast sloop and a fair wind. What if we could send messages instantly, as if by magic? It’s time to install the ship’s most advanced piece of equipment.

Part 6: Instant Dispatches (Real-time with WebSockets)

Current Rank: Navigator
Objective: To master the signature feature of Sails.js by upgrading your application with a real-time WebSocket layer for instantaneous, two-way communication.

The Captain’s Briefing (Background and Theory)

Navigator, thus far all our communication has followed the “message in a bottle” protocol (standard HTTP). We send a request from our browser, and some time later, the server sends a response back. The server can never speak first. If a new treasure is discovered somewhere in the world, our ship won’t know about it until we manually ask for an update by refreshing the page.

This changes today. We are installing a Magical Telegraph, a technology known in other worlds as WebSockets.

A WebSocket isn’t a single message; it’s an open, persistent, two-way communications channel between the browser and your Sails server. It’s like having a direct, magical link. Your server can now push information to the browser at any time, without being asked. This is the foundation of all modern real-time features: live chats, notifications, activity feeds, and collaborative applications.

Sails.js and Socket.io: The Telegraph Machine

Setting up WebSockets from scratch is a complex feat of engineering. Thankfully, Sails comes with a masterfully built telegraph machine called Socket.io integrated directly into its core. Sails provides a set of simple, elegant commands to manage this powerful technology.

Subscribing to a Channel (The Room)

The key to managing real-time communication is organization. You don’t want every message going to every person. You create channels, or “rooms.” A socket (a single browser connection) can be made to join a room. sails.sockets.join(req, 'some-room-name'); This command tells Sails, “The browser that made this request is now listening to the ‘some-room-name’ channel.”

Broadcasting a Message

Once sockets have joined a room, you can send a message specifically to that room from your server-side code: sails.sockets.broadcast('some-room-name', 'eventName', { some: 'data' }); This sends a message with the name eventName and a data payload to every single socket listening to that channel.

Blueprint Pub/Sub: The Auto-Magic

Here is where Sails ascends from useful to truly magical. This concept is called Publish/Subscribe, or “Pub/Sub.” When you use the Blueprint API from a browser over a socket connection, Sails automatically manages the room subscriptions for you!

When you make a request like io.socket.get('/treasure', ...), Sails sees this and thinks, “Aha! This browser is interested in treasure.” It automatically subscribes that socket to notifications about the Treasure model.
Later, if anyone in the world (via another browser or a script) creates, updates, or destroys a treasure, the Blueprint API will publish an event.
Sails automatically broadcasts this event to all subscribed sockets.

This means you get real-time model updates for free, just by using the API you already know over a socket connection.

Listening on the Client

How does the browser listen for these incoming telegraph messages? Sails provides a client-side JavaScript file, sails.io.js, which is included for you automatically. It gives you a global io object. The most important function is io.socket.on():

// On the front-end, in a

Add the route in config/routes.js: 'GET /tracker': 'TreasureController.trackerPage'

Task 2: Write the Client-Side Telegraph Operator

In your views/pages/tracker.ejs file, replace the empty script body with this JavaScript code. Read the comments carefully to understand the steps.

const treasureList = document.getElementById('treasure-list');

// Helper function to add a treasure to our  list
function addTreasureToList(treasure) {
  const newListItem = document.createElement('li');
  newListItem.textContent = `${treasure.name} (Value: ${treasure.value} doubloons)`;
  treasureList.appendChild(newListItem);
}

// --- Step 1: Get the initial list of treasures when the page loads ---
// We use io.socket.get() to make a request over a WebSocket connection.
// This automatically subscribes this browser to all "treasure" model events!
io.socket.get('/treasure', function (treasures, JWR) {
  if (JWR.statusCode === 200) {
    treasures.forEach(addTreasureToList);
  } else {
    console.error('Could not fetch treasures from server');
  }
});

// --- Step 2: Listen for real-time updates from the server ---
// The event name 'treasure' is automatically chosen by Sails based on the model name.
io.socket.on('treasure', function (event) {
  // The 'event' object tells us what happened.
  // We only care about newly created treasures for this quest.
  if (event.verb === 'created') {
    const newTreasure = event.data;
    addTreasureToList(newTreasure);
    console.log('A new treasure appeared by magic!', newTreasure);
  }
});

Task 3: Witness the Magic

Restart your server with sails lift.
Open Browser Tab 1: Navigate to http://localhost:1337/tracker. You should see a list of any treasures you created in Module 4.
Open Browser Tab 2: We need to create a new treasure. Use the Blueprint API create route. Assuming you have a captain with id of 1, navigate to this URL: http://localhost:1337/treasure/create?name=The Kraken's Eye&value=99000&owner=1
As soon as you press Enter in Tab 2, look at Tab 1. Instantly, without refreshing the page, “The Kraken’s Eye” will appear at the bottom of the list. You have just witnessed a real-time WebSocket push from the server!

Mission Debrief (Review & Outcomes)

Incredible! The magical telegraph is online. You have achieved one of the most powerful and sought-after features in modern web development.

You created a page that subscribed itself to model updates just by fetching its initial data over a socket. When another user (you, in another tab) modified the data, the Sails backend published an event, which was instantly pushed to your tracker page. Your client-side JavaScript caught the event and updated the display. This entire complex workflow was handled with just a few lines of code, demonstrating the immense power and productivity of the Sails.js framework.

Rewards & Promotion

+250 Doubloons
Achievement Unlocked: You have bent the laws of space and time, sending messages instantly from server to client. You are a master of real-time communication.
- Badge Earned: Socket Sorcerer ✨
Promotion to: Quartermaster

As Quartermaster, you are a master of the ship’s stores (Models) and now its communications (Sockets). You hold a position of immense trust and authority. Your next duty is to ensure the security of the ship.

Learn Sails.js - Part 5

2025-09-21T10:00:00Z

Excellent. The ship is seaworthy, the holds are filling with data, and you know how to steer. But a complex voyage requires more than just a single captain on the bridge shouting orders. It requires a specialist crew. It’s time to hire some experts.

Part 5: Assembling a Specialist Crew (Services)

Current Rank: Navigator
Objective: To learn how to organize and reuse your core application logic by creating Services, leading to cleaner, more maintainable, and more powerful code.

The Captain’s Briefing (Background and Theory)

Navigator, as your voyages become more ambitious, your Captain’s Log (the CaptainController.js file) will start to get cluttered. Imagine you need to perform a complex calculation, like determining the total value of a captain’s treasure, adjusted for inflation, tides, and the current price of rum.

Where would you put that code?

You could write a huge, messy function directly inside a controller action. But what if you need to perform that same exact calculation somewhere else, like in a different controller or in a script? You’d have to copy and paste the code. This is a cardinal sin in programming, a violation of the DRY (Don’t Repeat Yourself) principle. Copied code is twice as hard to maintain and twice as likely to have bugs.

This is the problem Services are designed to solve.

Services: The Specialist Crew

A Service is a dedicated specialist on your ship. It’s a file that lives in api/services/ and contains a collection of related helper functions. Think of them by their specialty:

EmailService.js: The ship’s messenger, responsible for sending all types of emails.
PaymentService.js: The ship’s purser, who knows how to handle all monetary transactions.
ImageManipulationService.js: The ship’s artist, skilled in resizing and watermarking images.
GeocodingService.js: Your master cartographer, who can turn a location name into latitude and longitude.

A controller’s job is to be the manager. It should be lean and decisive. It receives a request, calls on the appropriate specialists (models and services) to do the heavy lifting, and then decides what response to send. The controller gives the order; the service executes the skill.

Using Services

Once you create a service file like AppraisalService.js, Sails makes it globally available throughout your backend code. You don’t need to require() it. You can simply call its methods from any controller, policy, or even another service by using its global name.

If you have a function called calculateTax in AppraisalService.js, you can call it from anywhere like this: const taxedValue = await AppraisalService.calculateTax(treasure);

This makes your controllers incredibly clean and easy to read. Compare these two styles:

Bloated Controller (Bad):

// In a controller action
const treasure = await Treasure.findOne({ id: req.param('id') });
let taxedValue = treasure.value;
// ... 20 lines of complex tax calculation logic here ...
// ... what if the tax rules change? You have to find this code and change it.
return res.json({ taxedValue: taxedValue });

Clean Controller with Service (Good):

// In a controller action
const treasure = await Treasure.findOne({ id: req.param('id') });
// Call the specialist crew member!
const taxedValue = await AppraisalService.calculateTax(treasure);
return res.json({ taxedValue: taxedValue });

The logic is now neatly encapsulated in one place (AppraisalService.js), ready to be reused and easy to update.

Key Concepts Checklist

Service: A reusable module of helper functions for your core logic (api/services/).
DRY Principle: “Don’t Repeat Yourself.” The fundamental concept of not duplicating code.
Encapsulation: The practice of bundling related logic into a single, self-contained unit.
Business Logic: The core rules and processes that are unique to your application’s domain (e.g., how you calculate value, process an order, etc.). This is what belongs in services.
sails.helpers vs sails.services: While similar, services are traditionally seen as higher-level, stateless “buckets” of functions, while helpers are for smaller, granular tasks. For our purposes, services are the perfect place for our core “business logic.”

Mission Log: Quest - “Hire an Appraiser”

A new tax has been levied on all discovered treasure. We need to hire an Appraiser to calculate the value of a treasure after this new “Crown’s Tax” is applied.

Task 1: Recruit the Specialist (Create the Service File)
1. This is one of the few things there isn’t a generator for. We create it manually.
2. In your code editor, create a new folder named services inside the api/ directory.
3. Inside api/services/, create a new file named AppraisalService.js.

Task 2: Define the Specialist’s Skill

Open api/services/AppraisalService.js and add the following code. We’ll define a simple service with one method.

// api/services/AppraisalService.js
module.exports = {

  /**
   * Calculates the value of a treasure after applying the Crown's Tax.
   * @param {number} treasureValue The original value of the treasure.
   * @returns {number} The value after a 15% tax.
   */
  getTaxedValue: function(treasureValue) {
    const CROWN_TAX_RATE = 0.15; // 15%
    const taxAmount = treasureValue * CROWN_TAX_RATE;
    const finalValue = treasureValue - taxAmount;

    // We use Math.round to keep the value clean.
    return Math.round(finalValue);
  }

};

Task 3: Create a Controller to Use the Service

We need an endpoint to test this. Let’s add a new action to our CaptainController.js. This action will find a treasure and then use our new service to appraise it.

Open api/controllers/CaptainController.js and add this new action.

module.exports = {
  // ... your existing greet and logbook actions ...

  // Add this new action
  appraiseTreasure: async function(req, res) {
    try {
      // Find the first treasure we have in the database.
      const treasure = await Treasure.findOne();

      if (!treasure) {
        return res.status(404).json({ error: 'No treasure found to appraise.' });
      }

      // Here's the magic! Call the service.
      const taxedValue = AppraisalService.getTaxedValue(treasure.value);

      return res.json({
        treasureName: treasure.name,
        originalValue: treasure.value,
        taxedValue: taxedValue,
        message: `After the Crown's 15% tax, the value is ${taxedValue} doubloons.`
      });

    } catch (err) {
      return res.serverError(err);
    }
  }
};

Notice the use of async and await. This is modern JavaScript for handling asynchronous operations, like fetching from a database. It makes the code much cleaner.

Task 4: Chart the New Route

Open config/routes.js and add a route for our new action.

// ... previous routes
'GET /logbook': 'CaptainController.logbook',
'GET /appraise': 'CaptainController.appraiseTreasure', // <-- ADD THIS LINE
'/': { view: 'pages/homepage' },
// ... rest of the file

Task 5: See the Expert at Work
1. Restart your server with sails lift.
2. Make sure you have at least one treasure in your database (you can create one using the method from Module 4 if needed). For example, a treasure with a value of 1000.
3. Open your browser and navigate to http://localhost:1337/appraise.
4. You should see a JSON response detailing the original value and the new, lower taxed value (e.g., 850).

Mission Debrief (Review & Outcomes)

Mission complete, Navigator. Your command structure is now far more robust. You’ve successfully delegated a complex task to a specialist, keeping your controller clean and your core logic organized and reusable.

By creating the AppraisalService, you’ve built an asset that can be called from anywhere. If the Crown’s Tax rate changes from 15% to 20%, you only have to change it in one place: the service file. Every part of your application that uses this service will be instantly updated.

This is the path to building large, professional applications. Your ability to organize code is just as important as your ability to write it.

Rewards

+200 Doubloons
Achievement Unlocked: You’ve successfully abstracted business logic into a reusable service. Your crew is growing more capable!
- Badge Earned: Specialist Crew 🔧

Learn Sails.js - Part 4

2025-09-14T10:00:00Z

Aye, Captain. The ship looks magnificent, but its cargo hold is empty. A ship with no cargo has no purpose. It’s time to learn how to manage our treasure. This is the most critical part so far.

Part 4: Stocking the Cargo Hold (Models, Associations & Validations)

Current Rank: Boatswain
Objective: To define, store, retrieve, and protect your application’s most valuable asset: its data, using Models, the Waterline ORM, and the magical Blueprint API.

The Captain’s Briefing (Background and Theory)

This module introduces the ‘M’ in MVC: the Model. The Model is the single most important part of any data-driven application. It’s not just the data itself; it’s the definition and rules for the data. It’s the manifest that dictates what kind of treasure we can store, what it’s called, and how much it’s worth.

Waterline: The Universal Quartermaster

In Sails, your interface to the database is an incredibly powerful tool called Waterline. Waterline is an ORM, which stands for Object-Relational Mapper.

Think of it this way: there are many different types of vaults in the world (databases like PostgreSQL, MySQL, MongoDB, etc.). A normal Quartermaster would need to learn the specific, complex instructions for each one. But Waterline is a universal Quartermaster. You give Waterline simple commands in plain JavaScript (e.g., “Store this treasure chest”), and Waterline figures out how to translate that into the correct command for whatever vault (database) you’re currently using. By default, Sails uses a simple, file-based database called sails-disk which is perfect for development. Thanks to Waterline, you can switch to a powerful production database later without changing a single line of your application code.

Models: The Cargo Manifest

A Model is a file you create in api/models/ that serves as a manifest for a single type of data. If we want to store treasure, we’ll create a Treasure.js model. This file defines the attributes of a Treasure—the properties that every piece of treasure must have.

// api/models/Treasure.js
module.exports = {
  attributes: {
    name: { type: 'string', required: true },
    value: { type: 'number' },
    location: { type: 'string' }
  }
};

Here, we’ve defined that every Treasure record will have a name, a value, and a location.

The Blueprint API: Your Automated Crane System

This is where the magic of Sails truly shines. Once you define a model, Sails automatically equips your ship with a set of fully functional cargo cranes, ready to handle that data. This is the Blueprint API.

Without writing a single line of controller code, by simply creating the Treasure.js model file, Sails instantly creates a set of API “routes” for you. These routes allow you to perform all the basic CRUD operations (Create, Read, Update, Delete) on your treasure:

POST /treasure: Create a new treasure.
GET /treasure: Read (find) a list of all treasures.
GET /treasure/:id: Read (find) one specific treasure by its unique id.
PATCH /treasure/:id: Update a specific treasure.
DELETE /treasure/:id: Delete a specific treasure.

Associations: The Trade Network

Rarely does data exist in isolation. A treasure belongs to a captain. A captain commands a ship. These are associations. Waterline makes it simple to define these relationships directly in your models. A one-to-many association, for example, lets one Captain model own many Treasure models.

Validations: Guarding the Vault

You don’t want someone stocking your hold with lead painted to look like gold. Validations are rules you add to your model attributes to ensure data quality. For example, you can require that a treasure’s name is always present (required: true) or that its value must be a positive number (min: 0). This is your first and most important line of defense against bad data.

Key Concepts Checklist

Model: The definition of a data structure (api/models/).
Waterline: The ORM that talks to the database for you.
sails-disk: The default development database.
Attributes: The properties of a model (e.g., name, email).
Validations: Rules on attributes to ensure data integrity (e.g., required, isEmail).
CRUD: The four basic data operations: Create, Read, Update, Delete.
Blueprint API: Automatically generated CRUD routes for your models.
Associations: Defining relationships between models (e.g., one-to-many).
sails generate model: The CLI command to create a new model file.

Mission Log: Quest - “The Treasure Fleet”

It’s time to build our treasure manifest and establish ownership. We will create Captain and Treasure, link them together, and add rules to protect our hoard.

Task 1: Sign Up the Captains (Create Captain Model)

In your terminal (inside the project), run the generator:
```
sails generate model Captain
```

Open api/models/Captain.js and define its attributes:

module.exports = {
  attributes: {
    name: { type: 'string', required: true, unique: true },
    rank: { type: 'string', defaultsTo: 'Captain' },

    // Add this association!
    treasures: {
      collection: 'treasure',
      via: 'owner'
    }
  }
};

The treasures attribute sets up the “one” side of our one-to-many relationship.

Task 2: Define the Booty (Create Treasure Model)

Run the generator:
```
sails generate model Treasure
```

Open api/models/Treasure.js and define its attributes, including validations and the other side of the association:

module.exports = {
  attributes: {
    name: { type: 'string', required: true },
    value: { type: 'number', required: true, min: 1 },
    location: { type: 'string', defaultsTo: 'Unknown' },

    // Add this association! This links back to the Captain.
    owner: {
      model: 'captain',
      required: true
    }
  }
};

Task 3: Stock the Hold (Interact with the Blueprint API)
1. Restart your server with sails lift to load the new models.
2. We’ll use curl from a second terminal window (or a tool like Postman) to act as our API client.
3. Create a Captain:
```
curl -X POST http://localhost:1337/captain -d "name=Redbeard"
```
  Sails will respond with the new captain object, including its unique id (e.g., {"id":1, ...}). Note this ID!
4. Create a Treasure FOR that Captain: (Replace 1 with your Captain’s ID if different).
```
curl -X POST http://localhost:1337/treasure -d "name=Cursed Doubloons&value=5000&owner=1"
```
5. Try to create invalid treasure: This should fail because of our validation rule (value cannot be 0).
```
curl -X POST http://localhost:1337/treasure -d "name=Fool's Gold&value=0&owner=1"
```
  Sails will respond with an error message, proving our validation is working!
6. Find all captains and their treasure: Open your browser and navigate to http://localhost:1337/captain?populate=treasures. The ?populate=treasures command tells Waterline to also fetch the associated treasures. You will see Captain Redbeard and an array of all the treasure he owns.

Mission Debrief (Review & Outcomes)

Outstanding, Boatswain. The cargo hold is no longer empty, and the manifests are in order. More importantly, the vault is secure.

You have now mastered the core of the Sails framework. By simply defining models, you have unlocked a massive amount of functionality. You’ve seen how Waterline’s validations protect your data integrity and how associations create meaningful relationships. You leveraged the Blueprint API to perform complex database operations without writing a single line of controller logic.

This is the power of “convention over configuration.” Because you followed Sails’ conventions, the framework did the heavy lifting for you.

Rewards & Promotion

+250 Doubloons
Achievement Unlocked: You have defined, created, and protected data using the framework’s most powerful features. The blueprints are now yours to command.
- Badge Earned: Blueprint Architect 🏗️
Promotion to: Navigator

You’ve earned your new title, Navigator. You can now chart a course and manage the cargo. The ship is truly taking shape. Next, we will organize our crew for more complex missions.

Learn Sails.js - Part 3

2025-09-07T10:00:00Z

Aye, aye, Boatswain! Let’s get this ship looking respectable. It’s time to hoist the banners and polish the quarterdeck.

Part 3: Designing the Quarterdeck (Views & Assets)

Current Rank: Boatswain
Objective: To learn how to make your application presentable by creating custom web pages and styling them with CSS via Sails’ Asset Pipeline.

The Captain’s Briefing (Background and Theory)

So far, our ship can respond to hails, but only by shouting back raw data (JSON). That’s fine for ship-to-ship communication, but it’s not very welcoming for distinguished visitors who expect to come aboard and see a polished deck. This module is about creating that polished deck: the View layer.

From Data to Decks: res.view()

In the last module, we used res.json() to send back data. To send back a full HTML page, we use a different command: res.view(). When you call res.view('some-page'), Sails looks inside your views/pages/ folder for a file named some-page.ejs and sends it to the user’s browser as a web page.

EJS: The Magic Parchment

The files inside your views/ folder are not plain HTML. They are .ejs files, which stands for Embedded JavaScript. Think of EJS as a magic parchment: it looks and feels like normal HTML, but you can embed special tags into it to print dynamic data.

<%= data %>: This tag is like a magic quill. It takes a variable from your controller and writes its value directly onto the page. For example, if you pass { captainName: 'Grace O'Malley' } from your controller, <%= captainName %> in your view file will become Grace O'Malley in the final HTML.

The Master Blueprint: Layouts

Building every single page from scratch would be tedious. You’d have to copy and paste your navigation bar, header, and footer on every page. Sails solves this with a layout file.

Look in views/layouts/layout.ejs. This is your master ship blueprint. It contains the common HTML structure for your entire site (, , , etc.). Notice the special tag somewhere in the middle: <%- body %>.

When you call res.view('pages/homepage'), Sails first renders homepage.ejs, then takes the resulting HTML and injects it into the layout.ejs file right where <%- body %> is. This way, you only need to define your main structure once!

Paint and Flags: The Asset Pipeline

How do you add styling (CSS), front-end interactivity (JavaScript), or images? You place these files into the assets/ directory.

Stylesheets go in assets/styles/.
Client-side JavaScript goes in assets/js/.
Images go in assets/images/.

This isn’t just a folder for storage. Sails has a powerful Asset Pipeline. When you run sails lift, Sails automatically scans these folders. It will compile, combine, and minify these files for you (in production), and most importantly, it will automatically inject the necessary and

Wie ihr seht, ist das überwiegend Standard Markup einer HTML5 konformen Webseite. Dazu kommen die beiden script Tags zum Einbinden von Vue.js und unserer eigenen JavaScript Datei, in der wir nun unsere erste Vue App erstellen werden. Um die App auf der Seite einhängen zu können, befindet sich im body noch ein div Element mit der ID app.

In die JavaScript Datei fügen wir nun folgenden Inhalt ein, der die minimale Logik für die Initialisierung unserer Vue.js App beinhaltet:

var app = new Vue({ el: '#app' })

Ihr könnt nun die index.html Datei über einen Doppelklick in eurem Standardbrowser öffnen. Für dieses einführende Beispiel brauchen wir nämlich keinen laufenden Webserver. Mit dem JavaScript Code, wird die App auf dem Element mit der ID app initialisiert.

Vue Dev Tools

Bevor wir nun mit der Programmlogik weiter machen, würde ich euch empfehlen, die Vue Dev Tools für euren Browser zu installieren. Damit wird die Überwachung des Programmzustands und die Fehlersuche extrem erleichtert. Falls ihr Chrome verwendet, müsst ihr für die Erweiterung in den Einstellungen noch den Zugriff auf die Datei URLs erlauben. Das ist notwendig, da wir die Datei per Doppelklick und damit mit dem file:// Protokoll geöffnet haben. Solltet ihr die index.html über einen Webserver öffnen, ist dieser Schritt nicht nötig.

Rechts oben im Browser sollte nun das Vue Logo erscheinen, das entsprechend gefärbt wird, wenn Vue.js auf einer Webseite erkannt wird. Wenn ihr nun die Entwicklerkonsole öffnet, findet ihr dort einen neuen Tab für die Dev Tools. Hier ein Bild, wie das Ganze im Chrome aussieht:

In der oberen Leiste findet ihr auf der rechten Seite vier Icons zur Navigation. Damit könnt ihr zwischen den drei Bereichen Komponenten, Vuex und Events umschalten sowie die Anzeige aktualisieren. Wir werden uns in dieser Einführung überwiegend im ersten Bereichen Komponenten aufhalten.

Bei den Komponenten findet ihr nun unten auf der linken Seite den Strukturbaum eurer Komponenten, in unserem Fall bisher nur den Wurzelknoten . Auf der rechten Seite könnt ihr euch den Zustand und die Eigenschaften der einzelnen Komponenten anschauen, mehr dazu im nächsten Abschnitt.

Reaktivität

Unter Reaktivität versteht man das Verhalten, dass wenn sich der Zustand einer Komponente ändert, direkt auch die Anzeige in der Seite geändert wird. Von diesem Begriff leitet sich im Übrigen auch der Name des Frameworks React ab, das von Facebook entwickelt wird und von den Konzepten her sehr ähnlich zu Vue.js ist.

Um das Ganze in Aktion zu sehen, erweitern wir das div Element in unserem HTML Code um den Platzhalter {{ message }}:

{{ message }}

Um diesen Platzhalter mit der eigentlichen Nachricht zu füllen, erweitern wir den JavaScript Code wie folgt:

var app = new Vue({ el: '#app', data: { message: 'Hallo Welt mit Vue!' } })

Wenn ihr nun die Seite im Browser aktualisiert, werdet ihr mit der entsprechenden Meldung begrüßt. Das Ganze ist nun auch bereits reaktiv. Um das zu testen, öffnet ihr den Konsolen Tab der Entwicklertools eures Browsers und gebt Folgendes ein:

app.message = "Tschüss Welt mit Vue";

Nun sollte sich die Meldung auf der Webseite entsprechend geändert haben. Wie ihr seht, kann man über die Variable app, die bei der Erstellung der Vue App zugewiesen wird, auf den Status der App zugreifen und diesen von außen beeinflussen. Ihr könnt nun im Übrigen auch in den Vue Dev Tools euer Element anklicken und seht dann auf der rechten Seite den Zustand dieser Komponente.

An dieser Stelle will ich die allgemeine Einführung auch schon beenden. Solltet ihr euch weiter mit den grundlegenden Funktionen von Vue beschäftigen wollen, gibt es dazu sehr viele Abschnitte in der Dokumentation. Für den Einstieg empfehle ich euch das Get Started Tutorial durchzuarbeiten. Dabei lernt ihr, wie Listen aus Arrays erstellt werden können, die bedingte Anzeige von Elementen funktioniert und die Eingaben von Benutzern in euren Komponenten verarbeitet werden können.

Komponenten

Komponenten ist dabei das richtige Stichwort. Jede Vue.js App besteht aus unzähligen Komponenten. Jede Komponente sollte dabei so einfach wie möglich aufgebaut sein und für genau eine Aufgabe zuständig sein. Für diese Einführung will ich eine Komponente erstellen, die eine einfache ungeordnete Liste anzeigt.

Zum Anlegen dieser Komponente, fügt ihr folgenden Quellcode am Anfang der JavaScript Datei ein:

Vue.component('nd-list', { data() { return { items: [ 'Apfel', 'Birne', 'Orange' ] } }, template: ` {{ item }} ` })

Damit wird eine Komponente namens nd-list global für die App registriert. Anders als bei der Root Komponente, wird data im Fall von allen weiteren Komponenten als Funktion umgesetzt. Das ist nötig, da es mehr als ein zugehöriges Element dieser Komponente geben kann. Würde data als Objekt umgesetzt sein, würden sich alle Elemente den gleichen Zustand teilen. Habt ihr also zwei Listen über diese Komponente erstellt und ihr ändert den Apfel in einer Liste zur Zitrone, würde auch die andere Liste geändert werden. Über die gezeigte data() Funktion, wird bei jeder Erstellung einer neuen Liste ein eindeutiges Objekt zurückgeliefert. Damit können die Zustände unabhängig voneinander verwaltet werden.

Da die registrierte Komponente initial an kein HTML Element gebunden ist, braucht sie selbst ein Template. In diesem Fall die gewünschte ungeordnete Liste. Darin wird eine sog. Direktive namens v-for verwendet, um aus den Elementen des Arrays eine entsprechende Liste zu erzeugen. Das Template einer Komponente muss übrigens immer ein eindeutiges Root Element haben, in unserem Fall
. Es dürfen also z.B. keine zwei div Elemente auf oberster Ebene verwendet werden.

Im HTML Code kann die registrierte Komponente nun als benutzerdefiniertes HTML Tag wie folgt verwendet werden:

Wenn ihr die Seite aktualisiert, seht ihr die Obstliste, die ihr wiederum über die Vue Dev Tools in den Entwicklertools eures Browsers untersuchen könnt. Ihr könnt dort übrigens auch den Zustand (also die Liste des Obstes) verändern und sehen, wie sich das auf die Liste in der Anzeige auswirkt.

Auch zum Thema Komponenten könnte man stundenlang schreiben. Ich möchte hier aber wieder auf die sehr gute Dokumentation dazu auf der Homepage des Projekts verweisen.

Routing

Oft werden Anwendungen, die mit einem Framework wie Vue.js oder React umgesetzt werden, als sog. Single Page Application (kurz SPA) entwickelt. Das heißt, es wird vom Webserver immer die index.html Datei geliefert, den Rest erledigt das jeweilige Framework. Um nun trotz dieser einen Datei unterschiedliche Inhalte auf der Webseite anzuzeigen, wird Routing benötigt.

Für diesen Abschnitt reicht das Öffnen der index.html per Doppelklick nicht mehr aus. Wir brauchen dazu einen Webserver. Wer meinen Beitrag zu Node.js gelesen hat, der weis, dass das mit Node.js kein Problem ist. Ich werde für die folgenden Ausführungen daher auch auf einen minimalen Server setzen, der für unsere Zwecke ausreicht. Ihr müsst dazu natürlich Node.js installiert haben. Folgt dazu am besten der Beschreibung in meinem anderen Beitrag.

Das verwendete Paket heißt vue-http-server und basiert auf dem sehr beliebten http-server. Es erweitert diesen um eine entscheidende Funktion. Sollte eine Route und damit eine Datei nicht gefunden werden, kann man eine Fallback Datei angeben, die stattdessen geliefert werden soll.

Um das nötige Paket global zu installieren, führt ihr auf der Konsole eures Betriebssystems folgenden Befehl aus:

npm i -g vue-http-server

Nun wechselt ihr in dieser Konsole in den Ordner, in dem euer Projekt liegt und führt folgenden Aufruf aus, um den Server zu starten. Stellt zuvor sicher, dass Port 8080 auf eurem System nicht anderweitig belegt ist.

http-server -f index.html

Wenn ihr nun im Browser http://localhost:8080 aufruft, solltet ihr unser letztes Beispiel mit der Obstliste sehen.

Ich möchte an dieser Stelle nur sehr einfaches Routing zeigen, welches ihr auch in der Dokumentation von Vue findet. Es gibt ein sehr beliebtes Paket namens Vue Router, welches quasi der Standard für Routing mit Vue ist. Dieser bietet natürlich wesentlich mehr Umfang und Konfigurationsmöglichkeiten als dieses Beispiel. Für unseren Zweck reicht es aber aus.

Löscht zunächst in der HTML Datei den Inhalt aus dem div mit der ID app. Nun ersetzt ihr den Inhalt der JavaScript Datei mit folgendem Code, auf den ich gleich näher eingehen werde:

const NotFound = { template: 'Seite nicht gefunden. Zurück zur Startseite' } const Home = { template: 'Startseite -> Über uns' } const About = { template: 'Über uns -> Startseite' } const routes = { '/': Home, '/about': About } new Vue({ el: '#app', data: { currentRoute: window.location.pathname }, computed: { ViewComponent () { return routes[this.currentRoute] || NotFound } }, render (h) { return h(this.ViewComponent) } })

Mit den ersten drei Zeilen, werden zunächst sehr einfache Templates erstellt. Es gibt also eine Startseite, eine Über uns Seite und eine Fehlerseite, falls die Route nicht gefunden wird. Bevor dann die eigentliche App initialisiert wird, werden noch die vorhandenen Routen definiert.

Im Vergleich zu unseren ersten Beispielen, gibt es zwei neue Eigenschaften, die eine App haben kann. Das erste sind sog. Computed Properties. Sie sind sehr ähnlich zu den Eigenschaften in data. Der Unterschied besteht darin, dass Computed Properties von mehreren anderen Eigenschaften aus data abhängen können und die Anzeige immer aktualisiert wird, sobald sich eine der Abhängigkeiten verändert.

Die zweite Neuerung ist die render Funktion. Sie wird aufgerufen, wenn die App initialisiert wird. Ich möchte nicht zu sehr auf die Implementierungsdetails eingehen, aber im Wesentlichen gibt sie den initialen Inhalt für das div mit der ID app zurück.

Wer nun ein bisschen mit der Anwendung spielt und auch mal verschiedene Routen testet, die nicht existieren, wird schnell merken, dass jeder Aufruf ein neuer Request an unseren Server ist. Normalerweise will man das vermeiden und sollte das Ganze dazu mit der History API des Browsers kombinieren.

Hier ein Ausschnitt, um unser bisheriges Beispiel darauf umzubauen:

const NotFound = { template: ` Seite nicht gefunden. Zurück zur Startseite ` } const Home = { template: ` Startseite -> Über uns ` } const About = { template: ` Über uns -> Startseite ` } // ... var app = new Vue({ // ... methods: { goto(path, title) { this.currentRoute = path; history.pushState({}, title, path); } }, // ... })

Wenn ihr nun zwischen Startseite und Über uns wechselt, wird die URL getauscht, der Inhalt der Seite entsprechend geändert und all das, ohne einen Request abzuschicken. Dazu wird in der Methode goto sowohl die Eigenschaft unserer App für die Route als auch die URL Zeile des Browsers über die History API verändert.

States

Kommen wir zum letzten wichtigen Konzept, das man verstanden haben sollte, bevor man größere Projekte mit Vue.js umsetzt. Bei unseren bisherigen Beispielen war der Zustand (englisch State) einer Komponente direkt in dieser gespeichert. Der Zustand befindet sich dabei innerhalb des data Attributs.

Wenn ihr größere Projekte plant, wird es nicht ausbleiben, dass Komponenten ihren Status austauschen sollen. Dabei gibt es im Wesentlichen zwei Richtungen. Wenn übergeordnete Komponenten Teile ihres Zustands an untergeordnete weitergeben wollen, können sie dazu Attribute verwenden. Diese funktionieren wie ganz normale HTML Attribute und müssen von der untergeordneten Komponente in Empfang genommen werden. Gehen wir davon aus, wir wollen unserer Obstliste zusätzliche Informationen geben:

Standardmäßig wird das angegebene Attribut erstmal ignoriert, da unsere Komponente nicht weis, was sie damit anfangen soll. Werfen wir also einen Blick auf eine neue Eigenschaft, die unsere Komponente haben kann:

export default { name: 'nd-list', props: ['itemNumber'], data() { return { items: [ 'Apfel', 'Birne', 'Orange' ] } }, }

Die neue Eigenschaft heißt props. Ihr müsst alle Attribute, die ihr innerhalb einer Komponente verwenden wollt, explizit in einer Liste erlauben. Beachtet auch, dass sich die Schreibweise in diesem Fall von der Definition im HTML Tag unterscheidet. Vue wandelt die Bindestriche dabei automatisch in Camel Case um, damit ihr einfacher innerhalb des JavaScript Codes damit arbeiten könnt. Ihr könnt nun auf den Wert des Attributes zugreifen, als wäre es innerhalb der data Eigenschaft:

Die Liste beinhaltet {{ itemNumber }} Elemente. {{ item }}

Natürlich hätte dieses Beispiel auch einfacher umgesetzt werden können, da ihr jederzeit die Länge eines Arrays ermitteln könnt. Ich hoffe es verdeutlicht euch trotzdem, wie ihr Daten nach unten in eurem Komponentenbaum weitergeben könnt.

Was ist nun, wenn wir Daten nach oben weitergeben wollen? Dazu gibt es das Eventsystem. Eine untergeordnete Komponente kann ein Event auslösen, worauf eine übergeordnete reagieren kann. Bleiben wir wieder bei unserer Obstliste und lösen ein Event aus, wenn ein Benutzer auf ein Element der Liste klickt:

{{ item }}

export default { name: 'nd-list', props: ['itemNumber'], data() { // ... }, methods: { triggerEvent: function(event) { this.$emit('clickEvent'); } } }

Dort wo die Liste verwendet wird, können wir das Event wie folgt verwenden:

Auch hier wandelt Vue die Schreibweise wieder automatisch zwischen Bindestrich und Camel Case um.

Super, ich weis jetzt, wie ich in beide Richtungen Daten austauschen kann. Bin ich damit bereit für größere Aufgaben?

-- ein vorschneller Entwickler

Theoretisch ja, aber ich will vorher auf ein Problem hinweisen, das mit der gezeigten Vorgehensweise einhergeht. Stellt euch vor, ihr habt einen Komponentenbaum mit mehreren Komponenten, die verschiedene Verzweigungen nach unten haben.

Wollt ihr in diesem Beispiel zwischen den Komponenten 4 und 8 den Status austauschen, führt der Weg nur über 1. Dazu müsstet ihr eine Menge Events, Funktionen und Attribute definieren. Zum Glück gibt es andere Wege. Zwei möchte ich kurz nennen, um den Artikel nicht zu lang werden zu lassen aber nicht im Detail beschreiben.

Event Bus: Für mittelgroße Projekte hervorragend geeignet, um größere Distanzen zwischen Komponenten zu überbrücken. Dabei wird eine globale Komponente registriert, auf der ihr eure Events auslösen und in anderen Komponenten dann darauf reagieren könnt.

Vuex: Zustand losgelöst von Komponenten. Definiert einen Zustand auf Anwendungsebene, auf den alle Komponenten zugreifen können. Benötigt einiges an Einarbeitung, aber ich verwende es persönlich für alle Projekte, da man nie weis, wie umfangreich eine Anwendung werden kann. Wenn man von Beginn an auf Vuex setzt, kann man die Architektur beliebig nach oben skalieren.

Single File Components

Ihr könnt euch sicher vorstellen, dass bei einem größeren Projekt, die Umsetzung über die oben gezeigten Codeausschnitte schnell unübersichtlich werden kann. Vue bietet sog. Single File Components (kurz SFC) an. Dabei wird der komplette Quellcode (HTML, CSS und JavaScript) einer Komponente in einer Datei mit der Endung .vue zusammengefasst. Da das Ganze aber nur in Verbindung mit einem Bundler funktioniert, können wir das nicht direkt testen. Ich möchte euch ein Beispiel zeigen, das unsere Obstliste von oben als SFC umsetzt:

Ihr müsst euch dabei alle drei Teile in einer Datei vorstellen. Leider konnte ich es wegen Hightlight.js, welches ich für Syntaxhighlighting verwende, nicht sinnvoll in einen Code Block zusammenfassen. Es gibt für mehrere Entwicklungsumgebungen aber Plugins, die mit dieser Syntax umgehen können und euch auch Highlighting und Auto-Vervollständigung anbieten.

Wie auch in der Einführung zu Komponenten gilt, innerhalb des

Next Direction

Where AI is going 2026

Oh-My-OpenCode: Because Who Doesn’t Love Burning Through API Credits at Lightning Speed?

The Revolutionary Promise: Multi-Agent Orchestration (AKA Token Tornado)

The “$24,000 Promise” – Now That’s What I Call Quality Assurance!

“No Stupid Token Consumption” – The Punchline That Writes Itself

The Greek Mythology We Deserved

The Multi-Model Money Pit

The “Ultrawork” Philosophy: Because Regular Work Wasn’t Expensive Enough

The Discord Community: A Support Group for the Token-Addicted

The Industry’s Dirty Little Secret: Everyone’s Just Cooking With Water

The Real Cost of “Free” Open Source

The Perfect Storm of Modern Over-Engineering

The Emperor’s New Codebase

A Love Letter to Inefficiency

The Testimonials: When Marketing Meets Reality

The Future Is Multi-Agent (And Expensive)

The Verdict: It’s Perfect! (If Money Is No Object)

Conclusion: Embracing the Absurd

AI-Powered Development: Months of Iteration

The Foundation: Windows, WSL2, and VSCode

Why the CLI? Understanding My Tool Choice

The Workflow: From Idea to Implementation

Phase 1: Brainstorming and Ideation

Phase 2: Planning and Task Definition

Phase 3: Implementation with MCP Servers

Phase 4: Memory and Verification

Reflections and What I’ve Learned

Sails.js & Vue.js - Part 4

Part 4: The Admiral’s Spyglass (Advanced State & Capstone)

Chief Architect’s Briefing (Background and Theory)

Key Concepts Checklist

Mission Log: Quest - “The Fleet Command Dashboard”

Fleet Command Dashboard

Fleet Status

Ship Roster

Mission Debrief (Review & Outcomes)

Rewards

Sails.js & Vue.js - Part 3

Part 3: The Living Chart Room (Building with Inertia & Vue)

Chief Architect’s Briefing (Background and Theory)

Key Concepts Checklist

The Chart Room

Known Destinations

Plot a New Course

Mission Debrief (Review & Outcomes)

Rewards

Sails.js & Vue.js - Part 2

Part 2: The Magical Enchantment (Introducing Inertia.js)

Chief Architect’s Briefing (Background and Theory)

Key Concepts Checklist

Mission Log: Quest - “The Enchanted Shipyard”

Mission Debrief (Review & Outcomes)

Rewards

Sails.js & Vue.js - Part 1

Part 1: The Traditional Refit (Vue & The Asset Pipeline)

Chief Architect’s Briefing (Background and Theory)

Live Cargo Manifest

Mission Debrief (Review & Outcomes)

Rewards

Learn Sails.js - Part 10

Part 10: Becoming a Fleet Admiral (Capstone Project & Next Steps)

The Captain’s Briefing (Background and Theory)

Mastery Checklist (Concepts You Command)

Mission Log: Quest - “The Fleet Admiral’s Flagship”

Mission Debrief (A Captain’s Legacy)

Final Rewards

Learn Sails.js - Part 9

Part 9: Charting the Open Seas (Configuration & Deployment)

The Captain’s Briefing (Background and Theory)

Key Concepts Checklist

Mission Log: Quest - “The Maiden Voyage Simulation”

Mission Debrief (Review & Outcomes)

Rewards & Promotion

Learn Sails.js - Part 8

Part 8: Running Ship Drills (Automated Testing)

The Captain’s Briefing (Background and Theory)

Key Concepts Checklist

Mission Log: Quest - “The Appraiser’s Examination”

Mission Debrief (Review & Outcomes)