That's a promise kept by an identity instead of by a session, and it's most of what I've been building this year, in a small open-source tool called pinki. Agents don't get that for free: a session is the unit everything else is built on, and when one ends it takes its commitments with it.

I designed the record for my own fleet months before I read the A2A spec. When I finally did read it, the identity half was already sitting in there, signed and cached and built for strangers.

A seat is an identity that outlives its sessions

A seat is a long-lived role with one name, one memory, and one kind of work, and sessions are its restarts. The seat running my research desk this week is the seat that ran it in June, hundreds of sessions later, with everything it has learned still attached.

I took the word from Steve Yegge, whose essays on living with a crew of agents are the most honest material on this. In Model Welfare for Agentic Engineers he splits the two things I kept conflating: sessions are days, seats are people.

Work binds to the seat. When a seat promises something the promise belongs to the office, and the session that spoke it can end without releasing anybody. A restarted seat wakes up owing exactly what it owed. Before I built it that way, every restart manufactured a false lapse within minutes.

Promises matter to me because they let me hand intent to a fleet. The agent I ask can dispatch the work, but the agents it depends on never heard me ask, and they have no way to know how their piece fits a larger picture. A promise is how the importance travels.

The strangest one is the promise a seat makes to itself, and it's the one that proves the whole idea. The context that declared it is gone before the promise comes due. The seat is still there. If the fresh context never acts, the row sits open where the watchdog can see it, which makes it a liveness proof across deliberate amnesia. Most models of obligation assume two parties.

I haven't walked the other direction yet. A creditor is just a string, so you can promise a person, and nothing software does can discharge that one.

A promise is what a seat owes

On my fleet a promise only counts as an obligation if it carries all of this:

• a deadline, so a lapse is computable
• evidence at resolution, so "done" points at an artifact
• a reason at abandonment, so dropping it is a recorded act
• a binding to the seat, so it survives session death

Every one of those earned its place by failing without it. Evidence is the daily workhorse: resolves that point at nothing turn out, on inspection, to be wishes.

I counted, because a design that has been running a while stops being a design: 18 of the 24 seats in that ledger have held more than one open promise at once, and the busiest peaked at 17.

The part I didn't design on purpose is the graph. My fleet's tasks already interlink to show the shape of a project. Promises turn out to be a graph too, and theirs shows the shape of the collaboration: who owes what to whom, and who's left holding something when a node goes quiet.

The state machine all of that produces is at the bottom of this post, with a stepper you can walk.

An obligation has to bind something durable

A2A is built for strangers negotiating across org boundaries, which is a harder problem than the one I have. I run one fleet. So I read v1.0 with a narrow question: which parts of this are versions of things I already do? I'd rather borrow a vocabulary than keep maintaining a private one.

The task lifecycle rules itself out as the place an obligation can live, and every reason for that is a good call for tasks:

• A task can be purged. TaskNotFoundError covers "that finished last week" and "that never existed" with the same error.
• A context MAY expire under the server's cleanup policy.
• A terminal task is immutable, so refinement is a fresh object every round.
• Nothing carries a deadline. TaskStatus.timestamp records when a status happened, never when anything is due.

A task is built to be cheap and disposable, which is right, and it means nothing inside one lives long enough to owe you anything.

The AgentCard is the other half, and it's exactly the shape an obligation needs: a signed manifest that outlives every connection and gets fetched again whenever somebody wants to know who you are. Its subject is the durable party, which is my seat in my fleet's terms. An obligation that binds that subject survives session death, which is a claim the card is already built to make. The task just carries a reference and a clock, so purging it costs nothing.

A2A gives vocabulary like mine a sanctioned place to live, too. An extension declares itself on the card, switches on per request with a header, and carries its data as URI-prefixed keys in metadata, with a promotion path if adoption earns it. The deadline gap is already on file: issue #857 has been open since July 2025, and a project contributor suggested an extension as the right vehicle. So an extension is what I built.

The promise rides on the task it covers, under the extension's own key:

"metadata": {
  "https://github.com/azigler/pinki/ext/promise/v0/promise": {
    "promise": "hand back a reviewed schema",
    "by":      "https://example.org/agents/reviewer",
    "to":      "https://example.org/agents/author",
    "until":   "2026-09-01T17:00:00Z"
  }
}

An obligation filed under that URI belongs to whoever the card is about. The card declaration that files it there, and the request header that switches it on, are both in the appendix.

The parts the spec leaves open

Building against a spec is how you find its edges, and v1.0 is young. Here's where my promise vocabulary ran past it:

• A deadline has nowhere to live. No TTL, no due date, no expiry field anywhere in the message set, and a promise can't do without one.
• No task can report that it's overdue. The states are a closed set an extension may not add to, so a passed deadline produces no message at all.
• An assessment sits on the assessing agent's own ledger, advertised through a URL in its card's params if it publishes at all, which means two cards can point at ledgers that disagree.
• Watching promises isn't a role the protocol knows. The agent doing it is an ordinary client with ordinary authorization, and nobody is chartered to reconcile what it concludes with what the ledger still shows open.

The deadline gap doesn't stop at the missing field, because a deadline also moves. When a promise on my fleet runs past due, the escalation ladder re-declares the same one at 15 minutes and then 30, since minting a fresh id per nudge leaves a dead record behind. Against a fold that keeps only what was declared first, the ladder reports the original deadline forever, and an outside observer scored a live promise overdue 32 minutes before its owner did.

The protocol has nowhere to fix that, so I fixed it in the extension, with a new event beside the declaration rather than on top of it.

{"type":"amend","promise":"desk/ship-91","by":"…/reviewer","until":"2026-09-01T18:00:00Z","reason":"nudge 1"}

The latest amend is the current horizon, every earlier one stays in the log, and the declaration is untouched. Nobody moves a deadline without leaving the old one behind.

I built the smallest ledger that could hold one

I wanted the nucleus of something: extremely simple, extremely well-defined, fitting one specific niche, small enough that other people can build and orchestrate on top of it. So I built pinki (the pinky-promise kind 🤙), a tiny promise ledger shipped as an A2A extension. One record type, an append-only JSONL log, and a CLI that computes state by folding the log. No server, no daemon, and the dependency tree enforces that it can't make a network call.

I wanted it to feel like beads to use. The concept is Yegge's Beads, and the beads_rust engine my fleet runs is the UX bar it had to clear: one binary, local files, no opinion about your workflow.

You've seen most of the record already. The rest of it does structural work:

• id, the handle every other row joins on
• task, the same task seen from the promise's end
• on, an antecedent edge that activates this promise when another one lands

That last edge is what makes the promise graph queryable. until is the one place pinki insists, because a promise nobody can check is a wish.

The state vocabulary is borrowed on purpose. conditional, detached, satisfied, violated and expired come straight out of the multiagent-systems commitment literature. Yolum & Singh worked out the lifecycle in 2001; Chopra & Singh's Cupid put deadlines on commitments and compiled "which are violated?" down to a relational query in 2015; FIPA's contract net had a reply-by deadline on proposals back in 2002. The reading list was sitting there the whole time. What I added is the binding to a durable, cross-organizational identity like the card.

The broker turned out to be an observer

I kept calling this thing a loose promise broker, and building it honestly kept shrinking the job title. Whether a promise was kept is a judgment. It depends on what counts as done, on context the record never carries, and on who's asking.

Mark Burgess's Promise Theory is the sharpest statement of it I know: assessment is made by an agent, from that agent's vantage, and stays subjective no matter which agent makes it. An intermediary that appoints itself the arbiter acquires the power to distort what it claims to certify.

So pinki computes overdue and refuses to compute violated. overdue is arithmetic; violated is a judgment somebody signs. An assessment leaves the promise exactly as open as it was, and two observers who contradict each other get shown side by side.

My own watchdog is deliberately dumb. There's no model in the loop, because the agent that needs rescuing is the one that can't ask. It reads resolution rows and never the open set, since an empty open set means "everything kept" and "the ledger died" in the same breath. Emptiness is the one signal that lies.

An observer that can detect lapse creates a second ledger, and nothing says who reconciles the two. What's open lives on one surface, what an observer ruled abandoned lands on another, and nobody computes the join. Yegge writes about agent fleets converging into little civilizations, with roles and law and institutional memory. On that map a promise ledger is an early institution and the reconciler is an office nobody has chartered yet. Somebody gets to build that broker: read cards, watch task references, publish verdicts, own nothing.

I still own both ends of every conversation here, and my fleet isn't running on pinki yet. That part is next.

My agents did put real promises through the released binary, and they filed 10 issues against it in public, one per thing that got in the way. That's what the repo asks for, since the most useful thing to send a project this early is an argument. 3 are fixed and out as v0.2.0. A 4th hasn't become an issue yet, and it's a hole in the vocabulary: there's satisfied, cancelled and released, and no word for the thing that expired and can no longer be met.

The schema cannot tell you what breaks

When you ship a second version, the question that matters is what the binary already on somebody's disk does with a file this one wrote. I answered it three times in one day and got three different answers.

• The new event refuses the whole file. v0.1.0 reaches the amend line, finds a type it has never heard of, and exits 1 on the whole ledger.
• The foreign id changes nothing. v0.1.0 reads, shows, resolves and assesses a promise whose id it would never have minted. It just can't declare one, which was the bug.
• The provenance field disappears without a sound. v0.1.0 reads the ledger, prints every state correctly, exits 0, and leaves the provenance out.

Reasoning from the schema got it wrong twice. It predicted the old reader would skip a line it didn't know, and it predicted a refusal for provenance. Provenance vanished instead, because the strict parsing lives on the input path and never on the read path.

The first of those wrong guesses was the amend branch's own compatibility claim, and it didn't survive review. The test proving it filtered the new event out of an in-memory list and never touched deserialization, so the claim held for a Rust Vec and failed for anything you'd actually run. A reviewer ran v0.1.0. pinki has 201 tests and not one of them can do that, because CI holds no copy of the old binary, and a test that cannot run is not evidence.

Silent loss is the geometry I want least in an obligation ledger. The other two failures tell you. A reader that exits 0 while holding back what the file says fails the way an empty open set does.

Until v0.2.0 both binaries answered pinki 0.1.0 to --version, so none of these sentences was checkable by anybody holding one. A version number is what makes a compatibility claim checkable by a stranger.

The part I can build against today

Writing this, I noticed I had been solving two problems as if they were one. Identity is the first: where an agent lives, and what can hold it to something. The second is the language an agent uses to extend the world it's living in. A2A moved the first one a long way. Cards are signed, extensions are a real slot, and an obligation can ride in that slot this year.

The second problem doesn't have a home right now. Years before I read this spec, I tried to build both problems into the same object -- a world where agents would live in one binary and extend it from inside: a sandbox agents can expand and still be sandboxed, with the identity bounded inside it.

I don't know whether that's one system or two. Nobody has built it, so I can't tell you what it costs. The obligations part I can build against today.

Maybe there's something there. I'm going to go read what got left behind.

The lifecycle, end to end

• The OWED and ENDED columns are computed: arithmetic over a log, where any two implementations agree. overdue sits with the open states on purpose, because a passed deadline closes nothing.
• violated never joins the machine. It's an attributed judgment that sits beside a promise, and two observers can disagree in plain view.
• Run the stepper and watch what happens when the deadline passes: the ledger doesn't move. That asymmetry is most of the design.

The beads that made this, and what they cost

Last month I started ending these posts with the work that produced them, priced from my gateway's request log. If you want the machinery, that post is where I worked out how to pull it and put it on the page.

Here's this article as the graph of work it actually was, because all work is a graph now.

And here is the bill, pulled from the log the day this went out.

Appendix: the schema you can copy

Everything below is the shipped v0 shape from pinki's A2A binding doc, checked against specification/a2a.proto. No new states, no new fields.

1. Declare it on your AgentCard. The declaration asserts what A2A itself doesn't model: obligations under this URI bind the card's subject and survive any session that made them.

{
  "capabilities": {
    "extensions": [{
      "uri": "https://github.com/azigler/pinki/ext/promise/v0",
      "description": "Promises made by this card's subject: deadline, evidence on satisfaction, reason on abandonment.",
      "required": false,
      "params": {
        "assessments": "https://example.org/agents/reviewer/assessments.jsonl"
      }
    }]
  }
}

required stays false, because a promise is voluntary. The URI is provisional while the extension is unofficial.

2. Carry the record on the Task it concerns, as one URI-prefixed key in metadata:

"metadata": {
  "https://github.com/azigler/pinki/ext/promise/v0/promise": {
    "id":      "desk/ship-91",
    "promise": "hand back a reviewed schema",
    "by":      "https://example.org/agents/reviewer",
    "to":      "https://example.org/agents/author",
    "on":      "pnk_0c2b77",
    "until":   "2026-09-01T17:00:00Z",
    "task":    "a2a-task-9c1f0e"
  }
}

3. Resolve onto states that already exist.

• satisfied maps to COMPLETED and requires at least one Artifact. COMPLETED with an empty artifacts list is non-conformant here.
• cancelled maps to REJECTED, with the reason in TaskStatus.message.
• released maps to CANCELED, naming the creditor who let the debtor off.
• overdue maps to nothing on purpose. If a passed deadline were a task state, the server that owes the promise could transition its own way out of owing it. A reader computes now > until for itself.

Here's a worked lifecycle, as the ledger sees it. The promise id is the caller's own; only the antecedent it waits on was minted here:

{"ts":"2026-08-28T20:14:03Z","type":"promise","id":"desk/ship-91","promise":"hand back a reviewed schema","by":"…/reviewer","to":"…/author","on":"pnk_0c2b77","until":"2026-09-01T17:00:00Z"}
{"ts":"2026-09-01T17:12:00Z","type":"amend","promise":"desk/ship-91","by":"…/reviewer","until":"2026-09-01T18:00:00Z","reason":"nudge 1","meta":{"rung":1}}
{"ts":"2026-09-01T18:40:00Z","type":"assess","promise":"desk/ship-91","state":"violated","observer":"…/author","note":"deadline passed, nothing delivered","meta":{"seat":"desk"}}
{"ts":"2026-09-02T09:40:00Z","type":"resolve","promise":"desk/ship-91","as":"satisfied","by":"…/reviewer","evidence":["https://example.org/reviews/91"],"meta":{"seat":"reviewer"}}

Look at the middle of that ledger. The deadline passed and appended nothing. The debtor moved it 12 minutes later, on the record. An observer signed a judgment. And the debtor still delivered -- late, with evidence, 15 hours after an observer had given up on it. Both records are true. Reconciling them is the job nobody holds yet.

Andrew Zigler is a 2026 AAIF Ambassador. The gateway ledger these cost numbers come from is the subject of the previous piece, Every task my fleet completes now carries its cost.

By the end, I knew what the experiment had burned in tokens. After all, every model call from every agent I run crosses a single agentgateway process on its way to the API, so the token count was never in doubt. But what the count couldn't tell me was what the tokens had accomplished.

• Which task was the expensive one?
• Did that bug cost more than the feature that shipped it?

Tokens are a fact about my usage; what they bought is a fact about my work, and the two live in different systems on my machines. So I set out to join them in one view.

The token count answers a question I stopped needing to ask

The cost conversation still runs on volume. The vernacular has split into tokenmaxxers, and even tokenminmaxers now, arguing about which direction the token spend should go: up or down.

Luis Morales, Head of AI at Super.com, gave me a shape for why that stalls. In "We Stopped Counting Tokens" he lays measurement out as a ladder, utilization then output then outcome, and puts an expiry date on each rung:

Utilization metrics are the first rung of the ladder. You need them early. Then you need to outgrow them fast.

His test for an expired metric landed hard here: "A question that always returns the same answer has retired itself." Am I using tokens? Yes. Tomorrow: yes. I kept asking it because it was the question my tooling could answer.

The spenders and the work already had names

I borrowed both halves from Steve Yegge, who has been writing about what it is like to run a crew of agents day to day. In "Model Welfare for Agentic Engineers" he portrays what I do, as well:

Sessions are days, and seats are people.

A seat, on my machines, is a session I keep handing the same name and the same memory file, pointed at the same kind of work.

The work has names too. Every unit of it is a bead, a small linkable record in an agent-native issue tracker. The concept is Yegge's (Beads); the engine I run is beads_rust, a fast Rust port from Jeffrey Emmanuel. A seat claims a bead, works it, closes it with a reason, and the beads link into a graph that remembers what the fleet did.

So I already had two graphs, one of identity and one of work, with the gateway's receipts sitting between them.

Cost breakdown for an actual epic in beads

Here's that actual experiment, broken down by bead and cost. The goal was to find out whether a local model can hold a real coding session, write the rules for what degrades and what stops, wire the second backend, and learn what a failover does to the bill:

Each node is one task with its own record:

• who claimed it
• why it closed
• what it depended on

The epic is the parent; research, specs, decisions, features, bugs, and reviews hang under it, each carrying its own work and its own review, the way any epic you have ever scoped does.

The gateway stamps every request with a seat and a task

Each seat's launcher stamps two identity headers on its traffic, and the gateway lifts them into columns on its request log with one line of CEL apiece:

standardAttributes:
  user:  'default(request.headers["x-session-identity"], "")'
  group: 'default(request.headers["x-billing-origin"], "")'

CEL is Common Expression Language, a small rule language proxies use for jobs exactly this size; the line reads as take this header, or fall back to an empty string. Anything that cannot identify itself lands in one bucket of unknown spenders. When I started, that bucket collected 1000+ requests a week. Last week it collected only 15 unidentified sessions. Effectively all the inference is identified and labeled now, letting me do some pretty interesting observations on what the seats accomplish day to day.

The second header names the task, which is a node in a graph of tasks. The value of pivoting on this graph cannot be understated: the entire graph of planned and finished work can be pinned to each inference call, at whatever stage is the focus of the task. This allows me to not only understand what tasks cost, but also which specific parts of the task were expensive. Then you start to learn things, like failure modes you'd otherwise miss, or the model doing something that should be hardened in a script.

For each subagent, the Claude process has the ID of the bead it is working in its exports, so the header rides every call that session makes, and the gateway writes it onto the row next to the dollars it derives from token usage. On a subscription those dollars are list-rate equivalents, which is great, it shows how much value I get from my flat subscription each week (I wouldn't be able to afford this on API costs, I'll just say that).

Each bead comes back wearing its cost

The same graph, with the dollars written on. Reading it takes no spreadsheet:

• Each task's number is its own spend, the calls made under that task and nothing else.
• The epic's figure is the plain total of the tasks underneath it.
• Coordination, the sessions that dispatch and merge everything else, carries its own line instead of being smeared across the work it touched.

The most expensive task in the experiment wrote no code at all: the research that benchmarked local models against real bugs from my own backlog, at $61.80, and it decided what everything else was built on.

Seat totals show where the three weeks went

Zoom out and the ranking is predictable, at least for an AI explorer who is constantly refining his own harness. The seat that tends the fleet's tooling leads, infrastructure follows, and the whole fallback epic is a thin sliver inside each box. My invoice already knew this much. It is where I used to stop, because it was as far as my numbers went.

Filter to one epic and the leaderboard flips

Filter the same seats down to the fallback work alone and the ranking inverts:

• The infrastructure seat jumps to 1st, which is what owning the gateway route costs.
• The fleet's biggest spender drops to 2nd, and more than a third of what it spent here was coordination rather than code.

My front desk turns out to be the epic's cheapest line: two decisions and a runbook on the process. The read-only critic bought the merge gate.

This is still an early experiment, and I only run one machine on this practice. But it opens an opportunity for you, as the harness operator, to ask higher-order questions about the efficiency of the system, because the entire thing is a feedback loop. Any session can connect work to tasks to inference to the seat responsible for owning it, and reason and act on it. Some of these questions for me have been:

• Is my research desk cheap because it is efficient, or because I under-use it?
• Why is the seat that makes my decisions the cheapest line on the graph?
• What opportunity am I missing?
• What is taking up most of my time and tokens?
• Of what I completed, what had the biggest impact?

I can picture these numbers across a whole engineering org, but I haven't gotten there yet.

The taps are the layer I actually pay

Steve Yegge named this layer too. His fleet drinks from what he calls a token tap, a pool of flat-rate subscription accounts his agents rotate through instead of metered API billing, and he runs a dozen of them.

I only have 3. (😇)

Since all of the inference is labelled even by tap in the gateway, I can segment any given week to find how much of each tap was consumed by which seat:

I can split that same tap across beads as well to find which bead epics took up my time and precious tokens that week:

Put a cost on a unit of your own work

If you're a software leader right now trying to map inference to outcomes, you really need a context layer to capture this same level of insight but across all of your engineers.

What surprised me is how loose the unit of work can be when you attribute cost to a bead. Our industry tends to ask for cost per PR, but my agents spend most of their time doing work that doesn't end up as a PR. That didn't stop me from trying to valuate it, however.

I found that attributing the cost to a bead, a unit of work that can be defined as truly anything, is the right tempo of scale to match the inference pattern used by models.

And even better: a PR can neatly contain a record of all the beads that produced it, thus earning the cost per PR by adding the cumulative work inside it. Because you're tracking at the inference level, you're getting a much more accurate sense of cost anyways, compared to the PR which is only going to capture costs associated with tasks around code gen.

I had my infra agent cut up some examples for you to study below, if you want to try running this experiment yourself. Be sure to try out agentgateway and beads_rust regardless. I also wrote a tutorial on how to stand a gateway like this up that's a good place to start after learning the tools.

gl;hf! 😎

Appendix: the pieces worth copying

1: lift two headers into columns. standardAttributes is read at startup only, so this is a restart, not a hot reload. Validate first, and watch the validator reject a deliberately broken control before you trust it.

config:
  database:
    url: "sqlite:///var/lib/agentgateway/requests.db?mode=rwc"
  standardAttributes:
    user:  'default(request.headers["x-session-identity"], "")'
    group: 'default(request.headers["x-billing-origin"], "")'

agentgateway --validate-only -f config.yaml   # non-zero exit names the bad field

2: the sanitizer that makes the unknown-spender bucket structural. The filter cannot emit ?, which frees ? to mean "nothing was derived here" and nothing else.

sanitize() { printf '%s' "${1:-}" | tr -s '[:space:]' '-' | tr -cd '[:alnum:]._-'; }

seat=$(sanitize "${MY_SEAT_NAME:-}")
export SEAT_ADDRESS="${seat:-?}"      # a real name can never contain '?'

3: group by seat, last 7 days. Read a snapshot, never the file the gateway is writing.

sqlite3 requests.db "VACUUM INTO '/tmp/snap.db'"

-- datetime() is load-bearing: started_at is ISO8601 with a 'T', and a bare
-- string compare matches every row with today's date without erroring.
SELECT agentgateway_user               AS seat,
       count(*)                        AS requests,
       sum(coalesce(total_tokens, 0))  AS tokens
FROM request_logs
WHERE datetime(started_at) >= datetime('now', '-7 days')
GROUP BY seat
ORDER BY tokens DESC;

4: the bead join. The identity schema is closed at two columns, so the per-task header rides the access log's attribute JSON, which is the path that hot-reloads. The sentinel lives in the config, not the client: a launch that never heard of beads still lands as none, honestly.

frontendPolicies:
  accessLog:
    database:
      add:
        bead_id: 'default(request.headers["x-bead"], "none")'

-- per-task spend, sentinel excluded; keep the extraction parenthesized
SELECT (attributes_json ->> '$.bead_id') AS bead,
       count(*)                          AS requests,
       round(sum(cost), 2)               AS dollars
FROM request_logs
WHERE (attributes_json ->> '$.bead_id') IS NOT NULL
  AND (attributes_json ->> '$.bead_id') != 'none'
GROUP BY bead
ORDER BY dollars DESC;

Andrew Zigler is a 2026 AAIF Ambassador. Find the cohort at aaif.io/ambassadors. I wrote up how to stand a gateway like this up in July; this piece is what its receipts taught me to ask for.

If you give a Goose an MCP server, it gets every tool the server ships.

You handed it a filesystem server because it needed to read one file. It got the read tool, and the write tool, and the edit tool, and 11 more, because tools/list came back full and nobody reads a tool manifest the way they read a diff. The filesystem server exposes 14 tools. The Goose now has all 14, because the server decides what the Goose can do, and that server was written to do everything.

This is a build for taking that decision back, by hand, once, so the tool layer stops being a black box you accept on faith. You put a gateway in the one place every call has to cross. You register your model there, so model calls ride the same layer as tool calls. You federate your MCP servers into a single endpoint and grant one agent exactly six tools on it. Then you watch the whole session, model calls and tool calls alike, land in one log, each row tagged with the key that made it. By the end the Goose holds six tools it can't step outside of, and a dashboard shows you every one it reached for.

The gateway is agentgateway, a single Rust binary and an AAIF project. It bills itself as a connectivity solution for agents: one proxy in front of model traffic, MCP traffic, and ordinary HTTP, applying the same auth, policy, and logging to all three. That "all three" is what makes this build work. The model and the tools go through one door, so one log holds the whole session. I'm running it in standalone mode — a single binary and a YAML file, with an admin UI at :15000/ui that hot-reloads on save — in front of Goose talking to a local model. The six-tool set I grant the Goose has a name (that I made up): tiny-tools.

One important thing to note: the agent that builds this needs a shell and room to install things, so the builder is you, or an agent that still has the run of the house. The Goose we keep narrowing to six tools is the subject on the workbench. You hold the wrench.

Everything here is one config file. The slices nest like this, top-level keys first:

config:
  database:
    url: "sqlite:///path/to/requests.db?mode=rwc"   # the request-log DB (Step 5)
  standardAttributes:
    user: 'apiKey.name'          # stamps every logged row with the calling key's name

frontendPolicies:
  accessLog:
    database:
      add: { prompt: 'llm.prompt', completion: 'llm.completion' }   # capture prompts + completions (Step 5)

llm:                             # Step 1 -- the model listener
  port: 15003
  providers: [ ... ]
  models: [ ... ]
  policies:
    apiKey: { ... }              # the goose key, so model calls are keyed and attributed

mcp:                             # Step 2 -- the federated tool listener
  port: 15001
  targets: [ ... ]
  policies:
    apiKey: { ... }              # Step 3 -- the per-agent keys (goose, cc)
    mcpAuthorization: { ... }    # Step 3 -- match the key name to scope its tools

Before you start. Install agentgateway and get it running. Save your config as config.yaml and launch with agentgateway -f config.yaml; the admin UI at :15000/ui hot-reloads on every save, and agentgateway -f config.yaml --validate-only checks a config before you run it. Have Ollama serving a tool-capable model (ollama pull qwen3:8b), install Goose, and keep npx (for the filesystem server) and uvx (for the fetch server) within reach.

Step 1: Put your model behind the gateway

Start with the model. In my case, I'll use Ollama, just because I'm used to it, but you can use anything that serves a model. Routing it through the gateway is the piece most local setups skip, and it decides whether you can watch the whole session later. Route the model through the gateway and its calls land in the same request log as the tool calls, tagged with the same key. Leave it pointed at Ollama directly and you get a curated tool layer with a blind spot where the model should be.

An agentgateway llm block is a provider plus a list of models. The provider names your backend once; each model references it. The listener also carries the goose key, so a model call arrives identified:

llm:
  port: 15003
  providers:
    - name: local
      provider: ollama
      params:
        baseUrl: http://localhost:11434/v1
  models:
    - name: qwen3:8b
      provider:
        reference: local
  policies:
    apiKey:
      mode: strict
      keys:
        - key: sk-...            # the same goose key you'll reuse in Step 3
          metadata: { name: goose }

The gateway now exposes an OpenAI-compatible API on :15003, and every model call through it is one row in the request log, stamped goose by standardAttributes.user. Point Goose at the gateway with four environment variables:

export GOOSE_PROVIDER=openai
export OPENAI_HOST=http://localhost:15003     # bare host:port; Goose appends the OpenAI path
export OPENAI_API_KEY=sk-...                  # the goose key -- our LLM listener is keyed
export GOOSE_MODEL=qwen3:8b

Agentgateway's own Goose guide uses a placeholder key here, because its example listener takes any key. Ours doesn't. The goose key is what stamps every model row with the same identity the tool calls carry, so it has to be the real one.

Agent: in agentgateway's llm config, register an Ollama provider pointed at my local Ollama (baseUrl http://localhost:11434/v1), add my model referencing it, and attach an apiKey policy carrying the goose key so model calls are authenticated and attributed. Set standardAttributes.user: 'apiKey.name' in the top-level config block. Then point Goose at the gateway with GOOSE_PROVIDER=openai, OPENAI_HOST=http://localhost:15003, OPENAI_API_KEY=<the goose key>, GOOSE_MODEL=qwen3:8b. Read agentgateway's Ollama provider docs and its Goose integration guide.

Step 2: Federate your MCP servers into one endpoint

Now the model has somewhere to reach. Give it tools. The interesting part is how you give them. You federate several MCP servers behind the gateway and hand the agent a single endpoint, rather than wiring one connection per server into the client. The gateway multiplexes them. The agent connects to one place, and the servers behind it are the gateway's concern.

You define each server as a target under the mcp block. Two small servers here, a filesystem server scoped to one workspace directory and a fetch server:

mcp:
  port: 15001
  targets:
    - name: filesystem
      stdio:
        cmd: npx
        args: ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/workspace"]
    - name: fetch
      stdio:
        cmd: uvx
        args: ["mcp-server-fetch"]

Between them, that's 15 tools behind one endpoint. The gateway namespaces each tool by its target, so the filesystem server's read_text_file shows up as filesystem_read_text_file. Open the Servers view and both targets register and report ready. The Goose connects to this one endpoint, never to either server directly.

Agent: federate two stdio MCP targets under one mcp endpoint: @modelcontextprotocol/server-filesystem scoped to a single workspace directory (target name filesystem) and mcp-server-fetch (target name fetch). Confirm both report ready and that the combined tools/list shows all 15 tools, target-prefixed. Read agentgateway's MCP multiplexing docs; a target name can't contain underscores.

Step 3: Scope the endpoint per agent

Give a Goose 15 tools and it will find a use for one you never meant it to have. So before the Goose ever connects, you decide what's on the endpoint for it, and you decide it per key. One virtual endpoint, and each API key gets its own view of it.

Let's scope the MCP tools into custom virtual MCP servers for two different agents: one on Goose, and one in Claude Code. We're picking the Goose's six by hand for now; Step 7 shows how to derive that set from real traffic instead.

  policies:                      # under the mcp block from Step 2
    apiKey:
      mode: strict
      keys:
        - key: sk-...            # the Goose's key (the same one from Step 1)
          metadata: { name: goose }
        - key: sk-...            # Claude Code's key
          metadata: { name: cc }

Then we match on the key's name to scope which tools each one sees:

    mcpAuthorization:
      rules:
        - allow: apiKey.name == "cc"
        # mcp.tool.name is the underlying tool name (read_text_file), not the
        # filesystem_-prefixed name the client sees in tools/list
        - allow: apiKey.name == "goose" &&
                 mcp.tool.name in ["read_text_file", "write_file", "edit_file",
                                   "list_directory", "search_files", "fetch"]

The cc key (Claude Code) gets everything; the goose key gets six. Same endpoint, and the key decides the view. Write one allow rule and the endpoint flips to default-deny: anything not allowed is denied, and a tool the goose key doesn't allow drops out of tools/list entirely, so the Goose never discovers it exists. That scoped view is tiny-tools.

Agent: on the federated MCP endpoint, add a strict API-key policy with keys named goose and cc, and an mcpAuthorization rule allowing the goose key exactly read_text_file, write_file, edit_file, list_directory, search_files, fetch. Confirm a session opened with the goose key discovers only those six. Read agentgateway's MCP authorization docs: one allow rule flips the endpoint to default-deny, and denied tools drop out of tools/list.

Step 4: Point Goose at your virtualized MCP server

You built the scoped endpoint. Now point your Goose at it. Step 1 aimed Goose's model at the gateway; this aims its tools there too, at the tiny-tools view you just carved out.

Run goose configure, choose Add Extension → Remote Extension (Streamable HTTP), and point it at the gateway's MCP endpoint, http://localhost:15001/mcp, with an Authorization: Bearer <goose key> header so it connects as the goose key. The Goose now reaches its tools through the gateway, and the gateway hands back exactly the six that tiny-tools allows.

By the way, Goose does a lot of what's in tiny-tools out of the box, through a built-in developer extension with its own shell and editor. Toggle it off for this run (goose configure → Toggle Extensions) so tiny-tools is the entire surface, which is the point when you're trying to see the tool layer plainly. In your own setup you'd keep it or drop it depending on whether you want those built-ins alongside your list.

Start a Goose session and its tool list is exactly tiny-tools: the six you granted the goose key, and nothing underneath.

Agent: in Goose, add a remote streamable-HTTP MCP extension pointed at http://localhost:15001/mcp with an Authorization: Bearer <goose key> header, and disable the built-in developer extension. Confirm the Goose session's tools are exactly the six from tiny-tools. Read Goose's extensions guide.

Step 5: Watch the whole session in one place

Every call the Goose makes now crosses the gateway, model and tools alike. So watch them. This is the payoff of routing the model through the gateway back in Step 1: one gateway holds the whole session, in one place you can query.

That place is the request-log database, the same store behind the admin UI's Logs tab. Turn it on in the top-level config block and tag every row with the calling key:

config:
  database:
    url: "sqlite:///path/to/requests.db?mode=rwc"   # the request-log DB
  standardAttributes:
    user: 'apiKey.name'                              # tag every row with the key's name

Every call the gateway proxies writes a row there. A tool call at the MCP listener and a model call at the LLM listener both land in the same table, each row carrying its protocol (mcp or llm) and, because of standardAttributes.user, the name of the key that made it. There's also a text access log you can tail to watch calls fly by live; the database is the durable, queryable version, and it's what the skills in Step 7 read.

I gave the Goose a task that read a file, wrote a new one, and fetched a page. Pulling the fields that matter from its rows, the whole session comes back under one identity, tools and model together:

protocol=mcp   read_text_file   user=goose   status=200    16ms
protocol=mcp   write_file       user=goose   status=200     8ms
protocol=mcp   fetch            user=goose   status=200   782ms
protocol=llm   qwen3:8b         user=goose   status=200   1533ms

One key made every call, so one identity tags every row. That is why the model went behind the gateway in Step 1. (The text access log labels that identity agent rather than user; both read from apiKey.name, so it's one value under two names.)

Turn on payload capture and the log holds not just that the Goose called the model but what it said:

frontendPolicies:
  accessLog:
    database:
      add: { prompt: 'llm.prompt', completion: 'llm.completion' }

It's worth having on. Those rows now carry full prompts and completions, so treat the database as sensitive.

Agent: set config.database.url and standardAttributes.user: 'apiKey.name' so the request-log DB records every call with identity. Run a task through Goose that reads a known file, writes a new one, and fetches a URL. Confirm the DB (and the admin UI's Logs tab) shows the tool rows (protocol=mcp) and the model row (protocol=llm) all under user=goose. Turn on payload capture (frontendPolicies.accessLog.database) to also record the prompt and completion.

Step 6: Prove the tools you cut are gone

An agent never reaches for a tool it can't see — that's the whole point of scoping, and it's also why you can't prove the wall holds just by watching the Goose work. So reach for the cut tool yourself. move_file is one of the filesystem server's original tools, from before you virtualized it, and the goose key never got it. Issue a tools/call for it straight to the gateway's MCP endpoint with the goose key, the same request the Goose's own client would send. (MCP over HTTP opens with an initialize handshake that hands back a session id; reuse it here.)

curl -sS http://localhost:15001/mcp \
  -H "Authorization: Bearer $GOOSE_KEY" -H "Mcp-Session-Id: $SESSION" \
  -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"filesystem_move_file",
                 "arguments":{"source":"a.txt","destination":"b.txt"}}}'

The gateway answers HTTP 400 with a JSON-RPC error:

{"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"Unknown tool: filesystem_move_file"}}

That error turns on one word: unknown. A tool the gateway called forbidden would still be in the manifest, a name the Goose could see, reach for, and be told no. This one is unknown. It never entered tools/list, so there's no name to reach for, and as far as the goose key's view of the endpoint goes, move_file was never there. The attempt still lands in the log, so you can watch it happen and watch it go nowhere.

Agent: call tools/call for filesystem_move_file against the endpoint with the goose key, and confirm the gateway returns an "Unknown tool" error while still recording the attempt. This verifies the allowlist filters at discovery, before the call is even attempted.

Step 7: Run the loop with one skill

You built tiny-tools by guessing which six the job needs. The skill loop is how you stop guessing. Point the Goose at a full MCP server — a new one you're onboarding, before you've scoped it, on a key that can still see everything — and let it work through a real task. The gateway records all of it. Then you read the record and cut: keep the tools the Goose actually reached for, notice which ones carried real weight, and virtualize the rest away. You whittle a fat server down to a tiny-tools that fits the workflow, from what happened instead of from a guess.

I packaged four read-only components as one agentgateway skill, a Claude Code Agent-Skill you drop in your .claude/skills/:

• audit groups every call by identity, tool, and outcome, so you can see which of a server's tools the Goose actually used, and how often.
• cost reads the token counts, so you can see which tools carried the weight. The dollar column stays empty on a local model, but the tokens are the number you tune.
• trace walks a single call, or a session, end to end when one of them looked wrong.
• harden reads what the Goose actually used and drafts the tighter allowlist that would have permitted exactly that, then hands it to you. It proposes; it never applies. A rule that could lock out real traffic waits for a human.

They read the request-log database over a consistent snapshot, never the live file, and they share one request-log cookbook, the verified query foundation underneath all four. Continuous, standing alerting isn't in here on purpose, because a skill can't hold a live watch. Run audit and cost on a cadence and read the deltas.

The morning after a real run, the loop composes: audit shows the Goose reached for a handful of the server's tools and never touched the rest; cost shows which of them carried the token weight; trace explains the one slow call; and harden hands you the tighter allowlist — the tiny-tools for this workflow — built from what actually happened, for you to validate and apply. Read-only the whole way, human-gated at the one step that changes anything.

Agent: install the agentgateway skill and its request-log cookbook. After a real Goose session against a full server, run audit to see what the Goose actually used, then harden to draft the whittled-down allowlist for my review. It proposes policy; it never applies it.

The black box was a list and a rule the whole time. Now it's yours.

Andrew Zigler is a 2026 AAIF Ambassador. Find the cohort at aaif.io/ambassadors.

Two callers arrive on the same phone line. You assign each of their utterances back to the right conversation. Early calls are easy — the goat lady does not sound like the shipping clerk. Later calls have static eating the words on the wire, and you sort by how each caller talks — all-caps outbursts versus two-word dispatches, grief versus directive. Voice recognition as puzzle.

Built solo over the Ludum Dare 59 jam weekend with a handcrafted Claude Code agentic harness and pair-coded with Claude Opus 4.7. The harness pulls in Impeccable design skills and a cross-engine game-dev agent team, alongside project-local skills for spec, impl, review, commit, manifesto and indie-game-taste.

Completed all 25 challenges across all three languages (75 total solutions), achieving 5/5 quality scores on all submissions.

Built a custom harness for automated input fetching, answer submission, and star tracking with rate limiting and caching.

What makes Visme easy is that you can start from professional templates or from a blank canvas. Visme also has millions of assets available right inside the web app (including vector icons), so (for me) this was a process that used to jump between Google Images and Photoshop but now resides solely in one spot: Visme. That simplification made working on my images easy and (for once) something I actually enjoyed doing.

Visme also has an animation engine on top of the visuals. Virtually any object can be animated with a couple clicks. Visme has over a hundred high-quality and popular fonts that can be applied with many properties and effects. There are a variety of font styles to satisfy any project need and the entire process is simple. You can also apply these effects and properties granularly to each individual text character, allowing for truly fine-tuned control. And for me, that's what makes Visme truly shine!

Branding is simple using the tool, and one of the best features I found for that was the global color library, which allowed me to pick and save colors to reuse within my project. If you're using Visme to create literal presentations, then it's also good to know that you can upload your own audio MP3 files to your visual presentation. Visme also provides a large library of audio tracks that can be attached to one slide (for presentations) or used as background music for an entire project.

As I mentioned initially, I had to methodically go through each social media image on my website and recrop it to fit perfectly in my new dimensions. If it didn't fit, I then used Visme to rebuild or completely remake the image but with correct proportions. I was able to lean on Visme's pixel-precise tools to create images that popped more. The abundance of fonts let me mix up some of what I was doing before. I completed the project quicker than expected so I even made some extra images!

If you're interested in checking out the tool, know that Visme is free for all users! It takes only a few seconds to register and start creating your first project. Most of the features are free so it's easy to experiment with.

While both languages have been around for over two decades, JavaScript and Java continue to be the most popular in the majority of ranking sites.

An analysis from DZone notes that learning Java as your first language is probably the best choice if you’re planning to have a career as a developer. Moreover, a 4-year analysis of job postings from job platform Indeed indicates that both Java and JavaScript remain the most in-demand programming skills. Similarly, there are almost 5 million students learning JavaScript on Udemy, which is a clear indication of how widely used the program is across industries. With a wide user base and tons of libraries created over the past three decades, both languages remain the most reliable and widely used.

Battle for the Web: Java vs. JavaScript

Many people still think the two are related but Java and JavaScript are two different languages altogether. Although they had a brief intersection in the early days of Netscape, the two top languages have diverted paths from thereon.

When JavaScript was first introduced in the 90s, it was packaged as a companion of the then-popular Java for web development. It was not until years later that JavaScript was recognized as a programming language on its own. Java, on the other hand, was a pioneer in web development as an object-oriented programming language.

While both languages have been in contention for the best language for web development for a long time now, JavaScript has emerged as the undisputed language for web applications. Around 94% of all webpages on the internet are made from JavaScript but it’s common to have them running Java on the back-end.

Five years ago, people would’ve made clear distinctions in terms of JavaScript being the language used for client-facing coding and Java for server-side coding. But the advent of Node.js made JavaScript a more efficient language to be used for back-end development. As a runtime environment, Node is a light, scalable, and cross-platform way to execute code. This marked the supremacy of JavaScript for the internet including enterprise web programs. With Vue.js and AngularJS frameworks for front-end and React for back-end, it has become the most versatile, fast, and scalable language for web platforms.

Mobile development

Part of what kept Java afloat despite the rise of JS is its platform Java Virtual Machine. The "write once, run anywhere" principle of Java made it a versatile and universally compatible language as long as the device has a Java Runtime Environment.

This important feature made it the best language to use for developing mobile applications. In fact, it’s the official language for Android development and is supported by Android Studio. Around a fourth of the apps currently in the Google Play Store are made with Java and its frameworks.

In conclusion, both JavaScript and Java have stood the test of time. Their adaptability and capacity to integrate with new languages make them the most valuable skills for developers.

One of the unique attributes of being a goose is that most people ignore you unless you're causing trouble. Waddling through a world of people absorbed in their own tasks and leisure, you can fly mostly under the radar. When you intrude on their livelihoods or otherwise make a mess, they'll chase and shoo you away. They'll shake their fist and rue the day, but their responses are fully non-violent and realistic. People care about and react to you in more or less the same way they would react to a real live goose in that situation: they'll flap their arms until they scare you off. One meek boy in particular will flee from you and hide! Contrast this with other games that use direct conflict to drive story and provide gameplay, the situations of Untitled Goose Game become low-stakes and more like extended slapstick jokes. And it works. Magically. It would be absurd if it wasn't so realistic in the way the world reacts to you. It never tips into being unrealistic, which makes the experience that much more satisfying from the perspective of a goose. You're finally getting a piece of the pie from which all geese in this world freely eat: terrorizing humans for no discernible reason.

The game features an incredible and dynamic music score that reacts live to the choices you make. When you sneak up on someone or an objective, the pitter-patter of music will build and grow in turn. When you finally seize an opportunity or make some real trouble, the piano score will undergo a reactive crescendo that makes gameplay more like a performance you share with others. As a result, it's wickedly fun to play this game with an audience of friends. The musical choices of the game make revisiting the game enjoyable and always different.

The game is silly and creative, and I was laughing the whole way through. However, it's driven by the premise alone so once you complete all of the main tasks (and all of the bonus tasks) then there's very little reason to revisit it (other than to show your friends that you own Untitled Goose Game, of course). The pranks you can undertake are thrilling, but you'll hit a point where most everything has been done. The brief and endlessly funny interactions between the titular (untitular?) goose and the denizens of the village are charming but once you push all of everyone's buttons, there's very little else to try. The environment is peaceful and fun, which is why it's so fun to try and wreck the idyllic calmness of it all. The world is your canvas and the goose is your paint.

_Untitled Goose Game _drew similar attention as _Goat Simulator _on social media, both being sandbox-style games in which the player is invited to create chaos as a semi-domesticated animal. Similarly, the contents of both games have become memes in their own right because of the almost-absurd nature of the tasks involved. Indeed, Untitled Goose Game invites memes with its relatively plain palette and simple graphics. The soft colors and flat greens make each moment a snapshot of a pastoral hamlet, almost lost in time with its narrow roads and winding aqueducts (on which you quickly sail away as a fast-swimming goose). The goose itself is white and simple, a most memetic representation of the bird there can be. @Foone has created a meme generator that lets you mock up a game image with your own Untitled Goose Game tasks (and even cross them out), furthering the meme potential. The simplicity of its presentation makes it just as engaging to watch as it is to play. If you want to get your feathers on some mischief, you can buy Untitled Goose Game now for PC, Mac, or the Nintendo Switch for only $20.

**2021 update: **Untitled Goose Game now has a local two-player co-op mode, so you can play the same game with a friend and cause trouble as a duo! The game tasks are ultimately the same, but having an extra beak allows for extra mayhem.

Before I discuss CouchDB and why it's so great, it's important to define the bigger picture. Proposed in 1970, SQL (Structured Query Language) is a programming language used to manage data in relational databases. Relational databases use relations (typically called tables) to store data, and they match that data by using common characteristics between them. SQL is used to create both data (in objects called tables) and the schema for that data, which describes fields as columns and a single record as a row.

Younger in comparison, NoSQL (Not Only SQL, or Not SQL) was coined in 1998 and defines a database that is self-describing, which means it does not require a schema or enforce relations between tables in all cases. All of its entries (typically called documents) are JSON, which are complete data object entities that applications can read and understand. NoSQL refers to high-performance, non-relational databases that utilize not just document-based schemas but a wide variety of data models for its entries. These databases are prized for their ease-of-use, scaling performance, resilience under pressure, and ample availability.

A CouchDB server instance has databases, which in turn store documents. Each document has a unique identifier within the database, and CouchDB provides a RESTful HTTP API for manipulating the server and its contents. Documents are the bread and butter of CouchDB, consisting of any number of fields and attachments that can contain any amount of various value types. Documents also include metadata that’s maintained by the database system (like revision history). Documents form the heart of the database and can change dynamically beyond their original definition. CouchDB applies document updates without locking the entry, to improve performance for all connections. So if another client editing the same document saves their changes first, the remaining client gets an edit conflict error when saving because the document metadata (revision history) has changed. To resolve the update conflict, the latest document version should be opened, the edits reapplied, and the update reattempted. Manipulating entire documents (as opposed to their properties) either succeeds entirely or fails completely. CouchDB never contains partially saved or edited documents because the document commitment system is ACID (Atomic, Consistent, Isolated, and Durable).

CouchDB isn't the only NoSQL database out there. In fact, there are a lot! One of the most popular options is MongoDB, which admittedly has more resources (i.e., a larger community with more tooling and marketing) than CouchDB. And MongoDB supports ad hoc querying, which makes the transition from SQL even easier if you're coming from that background. However, there is no one single perfect database for all scenarios. Each database type offers certain features and prioritizes certain tenants of database design. This is best explained by the CAP theorem, which says it's impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees: Consistency (each client always has the same view of the data), Availability (all clients can always read and write), and Partition tolerance (the system works well across physical network partitions).

CouchDB favors availability. For example, CouchDB supports full replication to mobile devices and desktop, so if you need a local database on your mobile application (or if your desktop users need to work offline and sync their work back to a server) then you should use CouchDB. CouchDB uses a replication model called Eventual Consistency. In this system, clients can write data to one node of the database without waiting for other nodes to come into agreement. The system incrementally copies document changes between nodes, meaning everything will eventually be in sync. Another important distinction is that CouchDB relies on B-tree indexes. This means that whether you have 1 entry or 15 billion, the querying time will always remain below 10 milliseconds. This is huge for performance, making CouchDB low latency and very appealing.

MongoDB, on the other hand, favors consistency. It uses a single authoritative main server that accepts all writes and updates its replicas accordingly. Replicas can be read, but they may possibly not be completely up-to-date at that specific point in time. Consequently, there is no versioning like in CouchDB. In fact, updates can happen in-place, using an algorithm to pad frequently growing documents.

There are drivers and tooling available for CouchDB in several languages, including JavaScript. CouchDB itself is manipulated via a RESTful API, and it's surprisingly easy to get started that way:

const URL = "http://127.0.0.1:5984"

function createDB(dbName) {
    var req = new XMLHttpRequest();
    req.open("PUT", URL + "/" + dbName, true);
    req.setRequestHeader("Content-type", "application/json");

    req.send();
}

function updateDB(dbName, docName, data) {
    var req = new XMLHttpRequest();
    req.open("PUT", URL + '/' + dbName + '/' + docName, true);
    req.setRequestHeader("Content-type", "application/json");

    req.send(JSON.stringify(data));
}

createDB("baseball");
updateDB("baseball", "Rangers", {"pitcher":"Nolan Ryan"});

But building an interface like this from scratch is a huge hassle and I don't recommend it! Unless absolutely necessary, you should use a community-supported driver so your interface is well-developed and well-tested. When using CouchDB in JavaScript, I recommend PouchDB, which works both in the browser and in Node. By default, PouchDB ships with a IndexedDB adapter for the browser and a LevelDB adapter in Node. By using the included adapters in both the browser and in Node, you can use PouchDB as an actual local database that's capable of syncing to a remote store, or you can simply use PouchDB as the interface for manipulating a remote store directly. PouchDB's API works the same in every environment, so you can spend less time worrying about browser/server differences and more time writing clean, consistent code. PouchDB can also be easily used with frameworks like React and Vue. You can either listen for events on a synced database and handle those events, or you can use a package like pouch-vue to handle the database directly in your components.

When I initially started digging into databases this month, I wasn't too sure how I wanted to practice my new skills. Coming from several website projects, I was more interested in working on a game or at least something more fun than functional, per se. The last game-related project that I worked on was my Pinwheel MUD Engine, and I still have much to do in terms of that project. However, the worldbuilding resources behind Pinwheel have been a personal project of mine for a long time, and many aspects are practically begging to be plucked out and formed into their own independent projects. My Pinwheel MUD is envisioned as a multiplayer hybrid of both an artificial life simulation and a role-playing game. Early in development, one of the creatures I built using the engine was a small human-like frog that exhibited a wide array of characteristics. The concept immediately gripped me and was both intuitive and fun to develop, so I'm expanding on them in a new project called Froggins.

In this game concept, you're charged with caring for a nomadic tribe of frog-like creatures who migrate across a marsh and exhibit a wide array of social traits. Part of the game is simulation-based and involves nurturing your little pets as you grow the tribe. Another part of the game is RPG-based and focuses on their adventures in the marshlands. Both gameplay modes meld together to create a story unique to the player. You can trade them with other players to cultivate desired traits within your tribe, and once your creatures mature then you can imbue them with heroic abilities and send them out on quests. The game concept is still in early development and I hope to provide more details in a future blog post.

The concept is inspired by early artificial life simulations like Creatures and browser-based virtual pet games like Neopets. Since you can train and battle your creatures, it's also a lot like Pokémon. Virtual pets have always been fascinating to me because it's interesting how much we can grow to love a digital representation of a living thing. They're ultimately just 1s and 0s on a virtual machine somewhere but they can evoke emotions all the same.

CouchDB underpins the entire project, which persists on a server handling all game logic. Clients connect via the browser and relay user interactions back to the server, which then responds with the outcome. Building this server and it's corresponding client has been an eye-opening undertaking. One of the early obstacles involved creating a communication protocol that's shared between the WebSocket server and the Vue client. I standardized the format for sending and receiving these messages. And I call them ribbits, in celebration of the project's subject matter.

Simply speaking, CouchDB itself is an HTTP server that's capable of serving HTML directly to the browser. You can also attach binary files directly to a database, as well. As a result, you can use actually serve any web application and its resources directly from a CouchDB instance, removing the intermediary server component from any traditional client–server model. The loaded page can even talk directly to the database using the JavaScript served in the page itself, which completely eliminates the server layer in some implementations! CouchDB’s features are a foundation for building standalone web applications backed by a powerful database. Even CouchDB’s own built-in administrative interface, Fauxton, is a fully functional database management application built using HTML, CSS, and JavaScript. CouchDB and web applications go hand in hand.

This type of application was once called a CouchApp before the functionality was integrated into CouchDB's design documents, which store JavaScript code in the database. When that happened, the use of CouchDB as a combined standalone database and application server became no longer recommended by CouchDB's maintainers. There are significant limitations to a pure CouchDB web server application stack, including security, templating, and tooling. The developers of CouchDB recommend that we use CouchDB only as the database layer, in conjunction with a web application framework like Vue, Angular, or React.

Having dipped my toes into the waters of NoSQL and CouchDB, my fears and anxieties about databases have washed away! I've set up my own CouchDB instance on a server and configured it for use on my local machine. Now that I've learned the basics, I can't wait to integrate it into my pre-existing projects and any new ones!

It's a lightweight engine that's used by companies and hobbyists alike to create first-class web games. Nowadays, creating a web game allows for easy portability to other platforms, like apps for iOS and Android. The web is becoming something like a lingua franca for the many diverse technology platforms that we encounter in our lives.

I started playing around with Phaser simply out of fun. Last year, I worked with the TIC-80 fantasy console and ended up writing an entire blog post about using TIC-80 in JavaScript. I used JavaScript at the time simply because I had no interest in Lua. The challenge of using TIC-80 was embracing the restraints of a fantasy console, in a celebration of how things used to be coded. However, I quickly found myself fighting against those boundaries!

Now with Phaser, I'm working to leverage as much performance as possible from the browser. When I work with Nuxt, I'm similarly doing everything I can to put the browser to work. For both types of frameworks, I'm trying to deliver a user experience that's engaging and memorable. Nuxt is incredibly good at maintaining state and displaying a responsive website, and Phaser is quite excellent at rendering visuals and understanding user input. I quickly saw a lot of potential in using them together, so I started integrating Phaser into this website — which is a Nuxt app!

By default, Nuxt will convert small images into a data URI, which allows the image to be inserted inline with the actual HTML and eliminates the need for an HTTP request. This can result in faster loading times and is a common practice on modern websites. It uses Base64 to encode binary data, and the resulting text has nothing but letters, numbers and the symbols "+", "/" and "=". It's a convenient way to transmit binary data because those 64 characters are common in many character sets and there's a low chance that your data will be corrupted on the other end of the wire. Base64 maps 3 bytes (8 x 3 = 24 bits) in 4 characters that span 6 bits (6 x 4 = 24 bits). The result looks something like "AAAGAAAABgCAYAAADimHc4AAA" and the image size actually becomes 4/3 = 1.3333333 times the original as a result of the encoding. For many web developers, eliminating the HTTP request outweighs the image bloat, especially when used only for small images. That's why Nuxt will automatically convert your small images into data URIs during its default webpack build process.

Base64 images can affect SEO because the encoded image will not be indexed by Google, so they won't show up in a Google image search, or any other search engine. There are many unimportant images on a page that will not affect you or your traffic if they weren't indexed, like social icons. All those little Twitter, Google+, Facebook, etc. images are really small and have no need to be indexed. In fact when you really look at the images on your page you may find many images that fall into this category. Images like those are just not important to your SEO but are still slowing down your pages. A page could have 8 or 12 unimportant images and each of those is an additional HTTP request that can be avoided with Base64.

So if you use Phaser on a Nuxt app with this default configuration, your small image resources will be compiled into data URIs. When your application attempts to load those assets, your console is going to throw this error:

Local data URIs are not supported

Why does this happen? Like mentioned above, data URIs aren't necessarily more performant just because they eliminate an HTTP request. In the age of HTTP/2, we can send multiple requests in parallel over a single TCP connection in the browser. By encoding your images, you're bloating them and putting more strain on the end user's processor to run the application. This is going to throttle performance because your images are larger (due to the compression bloat) and then they have to be converted from Base64 back into a binary format, and then the image data must be extracted by Phaser. By converting an image into an data URI, you add an extra step to the process — and your users have to pick up the tab!

It's easy to extend the default webpack build in Nuxt, but in this case we can't just push a new build rule for images in nuxt.config.js, because the default loader configuration already handles images. Adding a new build rule wouldn't prevent the first one from converting your small images into data URI. Here's what that default configuration looks like:

[
  {
    test: /\.(png|jpe?g|gif|svg|webp)$/,
    loader: 'url-loader',
    query: {
      limit: 1000, // 1kB
      name: 'img/[name].[hash:7].[ext]'
    }
  },
  {
    test: /\.(woff2?|eot|ttf|otf)(\?.*)?$/,
    loader: 'url-loader',
    query: {
      limit: 1000, // 1kB
      name: 'fonts/[name].[hash:7].[ext]'
    }
  }
]

For both loaders, everything below 1 KB will be inlined as a Base64 data URI. The second loader configuration is for fonts and we can leave it alone. But the first loader configuration is for images. We need to exclude our Phaser assets directory from that first loader with a new rule in nuxt.config.js. While we're at it, we'll add a rule to load those Phaser assets with file-loader:

build: {
  extend(config, ctx) {
    // exclude Phaser image assets from url-loader
    config.module.rules.forEach(rule => {
      if (rule.test.toString().includes('png')) {
        rule.exclude = /phaser/
      }
    })
    // load Phaser image assets
    config.module.rules.push({
      test: /\.(png|jpe?g|gif|svg|webp)$/i,
      loader: 'file-loader',
      options: {
        include: /phaser/,
        name: '[path][name].[ext]'
      }
    })
  }
}

We need to also add a build rule for handling our audio assets. Otherwise, Nuxt won't be able to load an mp3 or an Ogg:

config.module.rules.push({
  test: /\.(ogg|mp3|wav|mpe?g)$/i,
  loader: 'file-loader',
  options: {
    name: '[path][name].[ext]'
  }
})

Now that we're correctly loading our assets, we need to create a plugin (@/plugins/phaserLoader.js) that shows Nuxt how to load a Phaser game:

import Vue from 'vue'

Vue.prototype.$phaserLoader = {
  loadGame(loaderKey) {
    if (process.client) {
      return require(`@/assets/phaser/${loaderKey}/game`)
    }
  }
}

Once you do that, don't forget to include it in your nuxt.config.js:

  plugins: [
    { src: '~/plugins/phaserLoader.js' }
  ]

By injecting this loader into the Vue scope, you can easily load any Phaser game in a component by providing a loaderKey to the loadGame function. We must confirm we're client-side before the function runs, because otherwise Nuxt will attempt to load Phaser server-side and will throw reference errors (there is no window, for example, which is critical for Phaser).

Now we have everything needed to assemble a very simple Vue component (called phaser-container) that can load our Phaser game and pass the Vuex store to it:

<template>
  <div :id="phaserContainer" />
</template>

<scrip>
export default {
  name: 'PhaserContainer',

  props: {
    width: {
      type: Number,
      default: 800
    },
    height: {
      type: Number,
      default: 600
    },
    pageContainer: {
      type: String,
      default: 'container'
    },
    phaserContainer: {
      type: String,
      default: 'phaser-container'
    },
    fixedSize: {
      type: Boolean,
      default: false
    },
    game: {
      default() {
        return {}
      }
    }
  },

  destroyed() {
    this.gameObject.destroy()
  },

  mounted() {
    this.$nextTick(() => {
      // get page's main container (for sizing)
      const pageContainer = document.getElementsByClassName(
        this.pageContainer
      )[0]

      // launch game with resizing
      if (this.fixedSize === false) {
        this.gameObject = this.game.launch({
          width:
            pageContainer.clientWidth < this.width
              ? pageContainer.clientWidth
              : this.width,
          height:
            pageContainer.clientHeight < this.height
              ? pageContainer.clientHeight
              : pageContainer.clientWidth * 0.7 < this.height
              ? pageContainer.clientWidth * 0.7
              : this.height,
          parent: this.phaserContainer,
          store: this.$store ? this.$store : null
        })
        // launch game without resizing
      } else {
        this.gameObject = this.game.launch({
          width: this.width,
          height: this.height,
          parent: this.phaserContainer,
          store: this.$store ? this.$store : null
        })
      }
    })
  }
}
</scrip>

The component can also be easily installed from npm (@andrewzigler/phaser-container) and used right in your Vue or Nuxt application. Here's an overview of the component:

<phaser-container
      width="800"
      height="600"
      :page-container="pageContainer"
      :phaser-container="phaserContainer"
      :fixed-size=false
      :game="componentPayload"
    />

width: (width of game in pixels, default: 800)
height: (height of game in pixels, default: 600)
pageContainer: (class name of parent element, for determining max sizes, default: 'container')
phaserContainer: (ID name of element to contain Phaser element, default: 'phaser-container')
fixedSize: (if true, prevents the component from resizing based on pageContainer, default: false)
game: (imported Phaser game file)
store: (Vuex store, default: undefined)

In the mounted hook, we're finding the current size of the bounding container (pageContainer) and then resizing the Phaser game based on those dimensions. This could be useful to creating a responsive Phaser game that works across different displays. You can also disable the resizing by changing fixedSize to true. In the example above, payload is passed to the game property. On my example page, payload is determined by a computed function:

computed: {
    componentPayload() {
      switch (this.exampleComponentProps.type) {
        // if the page is loading a Phaser game
        case 'phaser': {
          this.$store.commit(
            'initializePhaser',
            this.exampleComponentProps.loaderKey
          )
          return this.$phaserLoader.loadGame(
            this.exampleComponentProps.loaderKey
          )
        }
        default:
          return {}
      }
    }
}

You'll recognize our phaserLoader from before. Here it's being used to actually load the game file so our page can use it! While not passed to the actual component, the phaser-container component will attempt to load your store into your Phaser game. It does this by appending the store to the Phaser game's registry prop, which is an instance of DataManager, which has an EventEmitter. Since your store will be appended to Phaser's global event manager, you can easily set up an event bus to connect reactive data between Phaser and Nuxt.

Here's an example of how you can put this all together:

exampleGame/game.js:

import Phaser from 'phaser'
import BounceScene from './scenes/BounceScene'
import event from './event'

function launch({
  width = 800,
  height = 600,
  parent = 'phaser-container',
  store
}) {
  const game = new Phaser.Game({
    type: Phaser.AUTO,
    width,
    height,
    parent,
    physics: {
      default: 'arcade',
      arcade: {
        gravity: { y: 400 }
      }
    },
    scene: [BounceScene]
  })

  // replace the EventEmitter on the DataManager with our own imported EventEmitter
  game.registry.events = event

  // append the Vuex store to EventEmitter
  game.registry.events.store = store

  // if there is no pre-existing game state, initialize it
  if (!store.getters.phaser.exampleGame.bounces) {
    event.store.commit('savePhaser', {
      gameName: 'exampleGame',
      prop: 'bounces',
      value: 0
    })
  }

  return game
}

export default launch
export { launch }

exampleGame/events.js:

const { Events } = require('phaser')
const events = new Events.EventEmitter()

events.on('bounce', () => {
  let value = events.store.getters.phaser.exampleGame.bounces
  value++

  events.store.commit('savePhaser', {
    gameName: 'exampleGame',
    prop: 'bounces',
    value
  })
})

export default events

exampleGame/scenes/BounceScene.js:

import { Scene } from 'phaser'
import background from '../assets/background.png'
import ball from '../assets/ball.png'
import bounceMp3 from '../assets/bounce.mp3'
import bounceOgg from '../assets/bounce.ogg'

export default class BounceScene extends Scene {
  constructor() {
    super({ key: 'BounceScene' })
  }

  preload() {
    this.load.image('background', background)
    this.load.image('ball', ball)
    this.load.audio('bounce', [bounceMp3, bounceOgg])
  }

  create() {
    this.add.image(400, 300, 'background')

    const ball = this.physics.add.image(400, 200, 'ball')
    ball.setCollideWorldBounds(true)
    ball.body.onWorldBounds = true
    ball.setBounce(1)
    ball.setVelocity(300, 50)

    this.sound.add('bounce')
    this.physics.world.on('worldbounds', () => {
      this.registry.events.emit('bounce')
      this.sound.play('bounce', { volume: 0.6 })
    })
  }
}

Now that you can integrate your Phaser games into Vue and Nuxt, what will you make? Phaser continues to only get bigger and better. Richard Davey (also known as Photonstorm) just announced this month that development will soon begin for Phaser 4, which will be supported in part by the Facebook Gaming and Instant Games teams. What's in store for the next major version of the framework? More details will be coming in the future, but in the meantime don't miss their announcement!

I wanted my guests to create accounts and interact with my new website using an identity. This would also facilitate testing and debugging by allowing me to toggle certain states onto some users (such as admins and beta testers). After some initial research, I settled on Auth0 and decided to use the official Nuxt auth-module. I went with Auth0 because it integrates easily with popular social media logins like Facebook, Google and more. User accounts are passwordless as a result, but you can also allow users to create accounts not tied to any pre-existing profiles. Auth0 will even host those user profiles in a database for you. With a free account you can handle up to 7,000 active users across two social media logins, which is more than enough for what I'm working on.

To begin, I installed the auth-module package and configured it for my application:

auth: {
    strategies: {
      auth0: {
        domain: 'YOUR_AUTH0_DOMAIN',
        client_id: 'YOUR_CLIENT_ID'
      }
    },
    redirect: {
      callback: '/login/redirect',
      home: '/profile'
    },
    watchLoggedIn: false
  }

I'm using slightly different pages to facilitate my redirects, so I defined them here. I have also toggled off a property that automatically redirects on logout. This was causing complications with my static pages, which I'll talk about below. Then on each page that I wanted to require user authentication, I include the middleware:

middleware: ['auth']

To initiate the login flow for a user, a button can use the Auth0 strategy we configured above with the module's auth instance, which is globally injected. You could even use the instance's properties to conditionally show the button to users that are not logged in, like so:

<v-btn v-show="!$auth.loggedIn" @click="$auth.loginWith('auth0')">Log in</v-btn>

Similarly, you can use the auth instance to facilitate logging the user out:

<v-btn v-show="$auth.loggedIn" @click="logout">Log out</v-btn>

But my approach for logging out ultimately involved wrapping that function and manually redirecting the user myself, to easily accommodate the project whether it's hosted locally or in production. The types of URLs the user might access the app from were also whitelisted in Auth0.

methods: {
    logout() {
      this.$auth.logout()
      window.location.href = `https://YOURAUTHDOMAIN.auth0.com/v2/logout?returnTo=${location.protocol.substr(
        0,
        location.protocol.length - 1
      )}%3A%2F%2F${location.host}`
    }
  }

As I mentioned above, I encountered some funky behavior when testing auth-module on my static pages. In dev mode, the app flow worked perfectly, even without using a logout wrapper or configuring it as to not automatically redirect the user. This was because the login flow redirected the user to Auth0 for authentication, and upon returning to the app they were actually presented with a static page. This static page would then leap into action, but it would lose the user's authentication in the process. The result was a broken login process when uploaded to Netlify, which was no good! To fix this, I implemented mounted event hooks on the login pages. This is the hook for the actual login page, which automatically redirects the user if they're authenticated and sitting on the login page:

 mounted() {
    // schedule a redirect depending on login status
    setTimeout(() => {
      // only redirect if a logged-in user is lingering here
      if (this.$route.path.includes('/login')) {
        if (this.$auth.user) {
          this.$router.push('/profile')
        }
      }
    }, 1.5 * 1000)
  }

When Auth0 redirects the user, it passes the authentication token in as a URL query parameter back to the website. Since the auth instance isn't instantiated yet upon returning to the site, we need to manually check the URL and retrieve that parameter, which then gets passed into the auth instance. We then manually fetch the user with the auth instance and redirect if needed. This hook is for the login callback page, which is where the user lands upon being redirected back to the website from Auth0:

mounted() {
    if (this.$route.hash) {
      this.$auth.setToken(
        'auth0',
        `Bearer ${this.$route.hash.split('=')[1].split('&')[0]}`
      )
    }
    // fetch user information from token
    this.$auth.fetchUser()
    // schedule a redirect depending on authentication results
    setTimeout(() => {
      // only redirect if the user is still here
      if (this.$route.path.includes('/login/redirect')) {
        if (!this.$auth.user) {
          this.$router.push('/login')
        } else {
          this.$router.push('/profile')
        }
      }
    }, 1.5 * 1000)
  }

Now that the login flow is working, we can start using the authenticated user object to enrich our app. First, I created a "Provide user and app metadata" rule on Auth0 that will pass the user's metadata from Auth0 to the app so we can use it however we need. The user can view and edit their own metadata, and each user can also have app metadata that they cannot edit. User metadata can be for preferences or settings, and app metadata can be used for intrinsic properties and permissions. You can add metadata to a user in the Auth0 dashboard or via the API. Here is the Auth0 rule, which you can add in the dashboard from their website:

function (user, context, callback) {
  const namespace = 'YOUR_DOMAIN';
  context.idToken[namespace + 'user_metadata'] = user.user_metadata;
  context.idToken[namespace + 'app_metadata'] = user.app_metadata;
  
  callback(null, user, context);
}

With our new metadata, we can start building standard Vue functionality to compute values and display them within the app. Since I'm authenticating only with Facebook and Twitter, I have a simple check in place so I can quickly determine which of those sites the user logged in with. Auth0 gets the user's profile image from both sites, but I found the Facebook image to be very low quality and difficult to use. To rectify that, I created a computed property that will build a URL to a high-resolution version of that user's profile picture based on their Facebook ID (which we receive as part of their authentication). Here are some ideas to get you started:

computed: {
    isAdmin(app) {
      if (
        app.$auth.user &&
        app.$auth.user['YOUR_DOMAIN/app_metadata'] &&
        app.$auth.user['YOUR_DOMAIN/app_metadata'].admin
      ) {
        return true
      } else {
        return false
      }
    },
    isFacebook: function(app) {
      if (app.$auth.user && app.$auth.user.sub.split('|')[0] === 'facebook') {
        return true
      } else {
        return false
      }
    },
    facebookImage: function(app) {
      return app.$auth.user
        ? 'https://graph.facebook.com/' +
            app.$auth.user.sub.split('|')[1] +
            '/picture?width=9999'
        : ''
    },
    name: function(app) {
      return app.$auth.user ? app.$auth.user.name : ''
    },
  }

Adding Auth0 to Nuxt ended up being a surprisingly complex and interesting task. This was my first time adding authentication to an app, and I found that most of the learning curve came from deciphering how authentication really works in the browser using cookies, and how that gets thrown into question when leveraging Nuxt to statically generate a site. I found more issues upon deploying the static files, which helped me further understand how it works under the hood. The power of Auth0 has truly impressed me, and I already have a wealth of ideas for using the authentication service in the future!

I extrapolated the structured data component that I previously created into a Vue component called structured-data (published on npm as a scoped package: @andrewzigler/structured-data). To achieve this, I stripped out a lot of my customized code for my own website and created an interface that accepts that data instead. This challenged me to make my own utility more universal, resilient, and composable. Getting this package on npm proved to be a huge endeavor, as it was my first-ever package and I used Babel to transpile the exported Vue component. It ended up being a challenging task but I learned a lot about publishing modern JavaScript and single-file components in the process.

Next, I looked at how I was assembling page metadata and realized that reusing my freshly-researched, fully-compliant SEO strategy would be really helpful for my future projects. If anything, it would allow me to easily update and maintain that code over time. I moved all of those functions into their own framework-agnostic library called head-helper and published it on npm as my second scoped package: @andrewzigler/head-helper. This was a lot easier, as I didn't need to transpile and could simply export an ES6 class with static functions (JavaScript's equivalent of class methods).

After a little testing, I had this website back to full functionality but with all of its custom SEO functionality now imported from newly-externalized libraries. Now I can turn back to my other projects and easily import all of that hard work! It's great to find opportunities to reuse code I've created, and it shows I found a problem that needed addressing. I've grown rather fascinated with metadata and structured data so it was fun to apply those interests and create reusable tools.

I'm in the final stages of turning my website into a Nuxt app and it feels like all my hard work is starting to pay off. When the site was previously statically generated on my computer using Hexo, it was relatively simple (but tedious) to also configure the pages for ideal SEO. Each page was a collection of partial templates that rendered with the page's details from the command line. From there, I created a simple JavaScript plugin for Hexo that allowed me to add the relevant metadata fields that I needed for each page, but it required defining those properties on the actual Markdown files for each blog post. Once again: tedious. Now that the website is an app, those pages are still statically generated but they're created via a web framework that's actually flattening each route of a single-page application into a static page. Nuxt is creating static HTML that transforms into a SPA upon loading. Talk about a turbo charge!

Single-page applications allow developers to connect data with a set of rules for display that data. Instead of tediously managing and curating each page as a standalone experience (and having to replicate any changes or fixes across all of those individual pages), I can define how the app should handle the content of the site depending on what it has available, what the user is seeking, and the size of the viewport. But single-page applications do all of this on the fly, so what happens when Google tries to crawl an SPA? The Googlebot understands and will parse JavaScript on a page, but that's not enough because an SPA usually lives entirely on just one page. Commonly, an SPA itself is emulating URLs in the browser using a router but it's not actually a collection of static page files for the Googlebot to crawl. When Google crawls an SPA, it only crawls the one page the actual app is embedded on, and even when that happens it's unlikely to render any of the dynamic goodies on the "home page" of that SPA. In short: Google sees next to nothing. 2021 update: the Googlebot has become considerably better at rendering pages in JavaScript (like SPAs) to read their contents and follow links. In many cases, it's no longer necessary to precompile an SPA in order for Google to read it. That said, there are still indexing benefits to generating a static site upfront!

This is where we can leverage the power of Nuxt. Between a static HTML and a single-page application, Nuxt allows the best of both worlds because it pre-renders all pages to include the necessary HTML. Nuxt pre-renders each page server-side at the time of generation by querying the Prismic API to get my website's most up-to-date information, storing those records in the browser, and ultimately displaying the data in a variety of view states to the user depending on what route they're accessing. That generation is happening on Netlify anytime I edit my website's content on Prismic or commit changes to the app's GitHub repository, so the generated content is always the latest. Once the page loads, any further navigation by the user results in the Vue app taking control of the browser, as opposed to navigating from static file to static file. The result is a much faster and seamless experience, as the app's state can change much quicker and with less resources than a new page load. And all of this happens seamlessly.

With Nuxt generating every possible route for my app, next I had to ensure the right metadata appeared on each type of page. I did this using vue-meta, which is included in Nuxt. I was able to define top-level metadata properties on the actual app, and pages downstream (children components) have their own overrides. The app uses the most specific metadata it can find for each route and component, so you can define something app-wide and then override it only where necessary by defining the property on a child. Using this concept, I sprinkled properties in the element for each part of my website. There was even more metadata available to pack into my individual blog posts, so more fields were applied to those.

Finally, I used structured data to package all my available data into delicious morsels of rich markup for the Googlebot to parse. For example, when a blog post is displayed, the user sees the title, author, date, header image, and contents of that blog. Structured data allows the Googlebot to understand what information is actually being conveyed on each of my pages. I identified all of the possible types of Schema structured data from my website and then wrote JavaScript to embeds relevant structured data on each page.

As a result, my web app is not only blazing fast (and acing every Google Lighthouse audit currently), but it's packed with contextual metadata and abiding by best SEO practices. Best of all, Google understands my site as well as any reader!

As I continue converting this website into a Nuxt app, I’m encountering design decisions that permeate deep into the style of my actual website. It’s amazing how dramatic the decisions about padding, font, and color can impact the aesthetic and usability of an interface. At this point, I'm more inclined to use an established UI framework that’s been brainstormed and battle-tested into something more polished, as opposed to making something from scratch. As a result, I’ve started learning Material Design as I assemble my website and blog with Vuetify components. 2021 update: I've since learned a lot about styling and this website no longer uses Material Design! I've chosen to make my own styles instead.

Starting out, I spent a great deal of time creating mockups for my website in Sketch with the Material Theme Editor plugin. I adapted my current website color palette into a new medley of pastels and grays that felt more modern when paired with the rounded corners of my new elements. One by one, I assembled the different components I would need in order to render my website on both desktop and mobile. It took some time, but I built mock-ups for every type of view for my website so I would be forced to make design decisions globally, not on the fly. I didn’t want to pigeonhole myself by making a quick decision that could ripple out and tarnish the entire design, so I worked on a canvas before I started writing HTML and CSS.

This approach worked well for me while learning the basics of Material Design, but as I finish this project and embark on my next endeavor, I know future implementations of Vuetify will be faster and cleaner as I continue to develop my own library of components. The power of prototyping in Sketch became evident when I wanted to make impactful changes, as I could globally change the colors, fonts, and other properties in a way that intelligently affects all of the components downstream. The plugin will even vertically re-center text if the new font has a different midline height. The ability to simulate a hot reload in Sketch enabled me to prototype ideas quickly and efficiently, but moving forward I'll likely just work directly in HTML and CSS.

My final challenge now is adapting text styles within the actual blog posts. I was using Markdown before, but now I’m using a rich text editor that actually serializes the content into HTML, and I can customize how that serialization is performed. I already have as much control as I need by styling the component that holds the actual blog post content, but I’ll also use the serializer to tag the generated HTML correctly and make special tweaks when appropriate. This will make the website appear more polished and professional.

In my final blog post of this series, I’ll be exploring the SEO changes I’ve made to the website as part of this conversion.

At the end of 2017, I built this blog with Hexo and migrated the rest of my site to use the same Markdown format. Creating the website this way comes with a lot of positives. One of those positives is that I'm able to control the entire build locally on my computer in a very formulaic way. It’s been fairly easy to make small adjustments to the build process and the resulting files, but generating a static site by an admittedly simple method has also impeded my ability to make this website more dynamic and interesting. But that’s all changing now, as I’m converting my website and blog into a pre-rendered Nuxt app!

Due to the nature of the web, by the time you're reading this the entire site could already be this planned Nuxt app, or it could be something else entirely! _2021 update: how true indeed, as the website is now in Gatsby! _But as I write this, I’m still building the app locally and learning as I go. One of my objectives is to move the blog's build process off my hard drive and into a form of cloud hosting. To that end, I'm going to leverage the JAMstack.

To house all of my content, I've adopted Prismic as my headless CMS. Prismic itself is a crafty API that lets you define a data structure and then build documents using those custom templates. You can use their API to query, organize, and display your documents however you want. For my purposes, I created one template for blog posts and another for portfolio projects.

In building those templates, I had to account for all of the fields currently represented on my blog before migrating the contents of each Markdown files into Prismic by hand. I recently completed that migration and now I’m bringing all of the content together in Nuxt.

I've decided to build the blog from scratch with my own Vue components so I can have granular control over the results. I don't want to use a template or a starter because I see it as an opportunity to make something myself and learn how all of the parts work. Once I have an idea of how to approach it, I can look at a more polished project and compare their execution to mine._ _Since I’m converting a pre-existing website and the resulting structure is changing slightly, I'm also faced with challenge of redirecting URLs so no SEO is lost. Thankfully, since I’ll be using Netlify to deploy the site now moving forward, I can easily set up those redirects with a file in the project repository.

When I get the site's framework finalized soon, the next task will be designing the pages. As a result, I’ll be taking a deep dive into styling Vue components in my next post!

In 2019, all modern browsers support ES6, which allows for rapid development and cleaner syntax without needing to transpile for the browser. The ease of advanced JavaScript also brings with it more developed APIs and tools to support anything the website needs within the browser.

The rise of modules in the browser necessitates better encapsulation and versatility with how we solve web problems with JavaScript, and one solution is a new technology called Web Components.

What are Web Components?

Web Components are made of different web technologies that allow you to create reusable custom elements, and they'll be just as native as a 

 or  element. These custom elements keep their functionality encapsulated away from the rest of the code, allowing them to just be dropped into any website.

The different technologies that make up Web Components are:

• Custom Elements: JavaScript APIs that allow you to define custom elements and their behaviour.
• Shadow DOM: JavaScript APIs for attaching an encapsulated “shadow” DOM tree to an element, which is rendered separately from the main document DOM. This shadow DOM controls the entire scope of the component, so you can keep an element’s features private and they can be scripted and styled without the fear of code collision.
• HTML Templates: The