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!