DEV Community: Chuck Meyer

The Agent Factory: Building Consistent Agents at Scale

Chuck Meyer — Thu, 12 Mar 2026 23:17:15 +0000

Agents are suddenly everywhere. But deploying the same agent to multiple events, customers, or product lines is harder than it looks. How do you make sure every instance has the right configuration? And when something improves, how do you propagate it without touching each one by hand?

I developed the Agent Factory pattern while scaling a conference demo from one event to many. This post covers the pattern — and how to apply it to any project where agents need to be deployed consistently across multiple contexts.

The Three-Legged Stool

Before describing the pattern, it helps to be precise about what an agent actually is. Strip away the API surface and every agent is built from three things:

Model — the LLM provider and model name. This is the reasoning engine. It determines response quality, context window, and cost per query.

Tools — what the agent can do. For an Algolia-backed agent, this is typically an algolia_search_index tool pointing at one or more indices.

Prompt — the system instructions that shape how the agent behaves: its role, its tone, its constraints, and critically, how it should use its tools. This is where domain knowledge lives.

Typically in agent frameworks all three legs are configured at creation time. That's what makes agents predictable and auditable. But it also means that when you need the same agent experience across multiple contexts, each context needs its own correctly-configured instance. At meaningful scale, managing that by hand doesn't hold up.

When One Stool Isn't Enough

Recently, I used Algolia's Agent Studio to build a demo application for use at Algolia's conference booths. Attendees chat with an AI agent to check Pokemon card values. The agent retrieves all of the underlying data from a searchable index using an MCP-like tool.

Each conference gets a fresh set of cards. All three legs of the stool need to adapt: the tool must point at that event's searchable index. The prompt must reference the right event name, booth number, and context. Even the underlying model might change based on cost or event context (I should probably steer clear of Gemini models at an AWS event!).

At first, I considered a single agent with tool access to every event's index. But a shared agent has no way to know which event it's at, so it can't scope its searches or tailor its responses to the right context. It either searches everything indiscriminately or requires guardrails I couldn't enforce.

One agent per event was the only way to maintain scope. But how to keep them all consistent?

The Factory Pattern

The answer is to treat agent creation as a repeatable process: define the three legs as a templates, render them together with each new context, register the resulting agent ID, and manage the fleet as a unit. The diagram below shows how those pieces fit together. I call this the Agent Factory pattern.

One Template, Three Legs

The model, tools, and prompt all reference the same context — if you render them separately, they can drift. The solution is to store everything as templates with shared placeholder variables and render all three legs together in a single pass at creation time:

agent-config.json

{
  "name": "Demo Agent — {{event_name}}",
  "provider": "your-llm-provider",
  "model": "your-model",
  "instructions": "PROMPT.md",
  "tools": [
    {
      "type": "algolia_index_search",
      "index": "catalog_{{event_id}}",
      "description": "Product catalog for the {{event_name}} event."
    }
  ]
}

PROMPT.md (excerpt)

You are an agent at {{event_name}} (booth {{booth}}).
Use Algolia search to help attendees find cards in the vending machine.

{{event_id}}, {{event_name}}, and {{booth}} are resolved across both files together. A missing or mismatched variable fails before any API call is made. When the prompt improves or the tool configuration changes, both are updated atomically.

Registering What Was Built

Agent Studio exposes each agent as a managed endpoint with a unique ID returned at creation time. The ID isn't predictable in advance, so the factory writes it back to an event registry the application reads at runtime. This registry could be a database, a config file, or in our case, an Algolia index.

Managing the Fleet

Agent creation is only the beginning. When the prompt changes or new models drop, existing agents need to be updated. When an event is retired, its agent should be deleted. The factory exposes the full lifecycle:

# New event
python agent.py create shoptalk-2026 "Shoptalk 2026" 701 --publish

# Prompt improvement — preview then push to all existing agents
python agent.py update --all --dry-run
python agent.py update --all --publish

# Retire an event
python agent.py delete etail-palm-springs-2026

The update --all is the beating heart of the factory. One command re-renders the current templates against every event that has an agent. A prompt improvement or tool fix is now one command rather than N error-prone dashboard edits. Storing configuration as files rather than dashboard state means you can version, diff, and roll back changes like any other code.

Codifying the Factory

As the factory matured, a clear split emerged: generic Agent Studio API logic on one side, demo-specific domain logic on the other. I extracted the generic layer into a standalone open-source CLI — algolia-agent — so the pattern is reusable beyond this project.

algolia-agent init        # defines all three parts of your agent interactively
algolia-agent create      # renders templates and calls the API
algolia-agent update      # diffs and pushes changes to existing agents
algolia-agent publish     # promotes a draft to live

The Pattern in Action

A user at the booth asked: "Do you have any cards worth more than $50?"

With no guidance on numeric filters, the agent searched for "cards worth more than 50 dollars" as a keyword query — matching card descriptions that mentioned the word "worth," not cards filtered by actual value.

The fix was one line in the prompt:

For "more than" / "less than" questions on
numeric fields, use comparison operators in
searchParams filters rather than facets:
e.g.
    `searchParams: { filters: 'estimated_value > 50' }`

Before pushing to the fleet, I used --dry-run to preview the rendered configuration before any API call was made. A wrong change pushed to N agents is N times harder to debug than one caught before deployment.

Since I was running agents for multiple active events, one update --all pushed the improvement to every instance simultaneously. That's the payoff of treating the prompt as a versioned artifact and the fleet as a unit.

Conclusion

Building an agent demo that needed to scale across conference events forced me to think carefully about what an agent actually is. Strip it down and you get three legs: a model, a set of tools, and a prompt. Once I had that definition, it was easy to separate what was core agent configuration from what was event-specific context.

The factory pattern helped me formalize that separation into something repeatable: scaffold the agent definition, render it for each context, perform consistent CRUD operations across every instance. When something improves — a better prompt, a model upgrade, a tool fix — one command propagates it to every agent at once.

Feel free to try out my algolia-agent for yourself. I'd also love to hear if the factory pattern is useful to you, or how it can be improved!

Building a Javascript "Hello,World" MCP server in 2026

Chuck Meyer — Tue, 24 Feb 2026 03:43:56 +0000

The Model Context Protocol (MCP) is Anthropic's open standard for connecting AI models to external tools and data sources. I'd been reading, (and talking), about it for months before building one for myself. After reading through several existingg posts that built around complex APIs, I decided to go as basic as possible with a simple hello-mcp — a minimal MCP server I built in an evening, starting from a single tool that says "Hello, World!" and ending with a dual-transport server with error handling, protocol logging, and a design I'm actually happy with.

A moving target: how the MCP SDK has evolved

The best way to build MCP servers in Node.js is using the official JavaScript SDK: @modelcontextprotocol/sdk.

The McpServer class is the core abstraction: create an instance, register tools and resources on it, then connect it to a transport. Everything I built in this project sits on top of that.

But, first a word of warning. If you're learning MCP from blog posts or tutorials, check the dates carefully. The SDK is evolving rapidly and most of the blogs I found we already out of date. By the time you read this, this one might be as well.

For instance, most examples I found used a tool() method to register tools:

server.tool("hello_world", config, handler);

But by the time I was working with SDK v1.26, this was deprecated in favor of registerTool():

// Current pattern
server.registerTool("hello_world", config, handler);

Same story for resources: resource() is out, registerResource() is in. The new methods use a cleaner config object pattern that separates name, description, and schema more explicitly.

The other big shift is in how inputSchema works. In newer SDK versions, the field takes a plain object of Zod fields and the SDK wraps them in z.object() automatically. There's no need to construct the full Zod object manually:

// What you write
inputSchema: {
  name: z.string().describe("The name to greet"),
}

// What the SDK does with it
z.object({ name: z.string().describe("The name to greet") })

This is a minor thing, but it tripped me up when I tried to copy-paste from older examples and got a type error.

Lesson: Pin to a specific SDK version when learning, and read the SDK source for the canonical API rather than relying on third-party tutorials.

Building the framework

The server is built in three layers: a transport layer, the MCP itself, and the underlying tools.

I separated the MCP server from the transport layer in my code early on, mostly because it felt like the natural way to structure things. At the time, I did it mostly to keep components small and easy to consume since I was learning. It turned out to be genuinely useful later when I realized certain clients have transport limitations. More on that later.

Here's the basic structure I ended up going with:

src/
  server.js            # Entry point — HTTP Streaming transport
  stdio.js             # Entry point — stdio transport (Claude Desktop)
  mcp.js               # MCP server + tool/resource registration
  data/
    greetings.js       # Shared data (language → greeting mapping)
  tools/
    helloWorld.js      # No-input tool
    helloName.js       # Tool with a required string input
    greetName.js       # Tool with error handling and MCP logging
    listLanguages.js   # Tool that exposes the languages list to the model
  resources/
    languages.js       # Static resource at languages://list

mcp.js is the heart of the server. It creates the McpServer instance and registers tools and resources. Critically, it knows nothing about how it's being transported — no HTTP code, no stdio code:

// src/mcp.js
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import * as helloWorld from "./tools/helloWorld.js";

export const server = new McpServer({
  name: "hello-mcp",
  version: "1.0.0",
});

server.registerTool(helloWorld.name, helloWorld.config, helloWorld.handler);

Each tool lives in its own file and exports three things: name, config, and handler (or a factory function if the handler needs server access — more on that later). The tool file knows nothing about HTTP, stdio, or even the server object.

This makes adding new tools or resources trivially easy.

The first tool

Tools are the primary way MCP servers expose functionality to an AI model. Each tool has a name the model uses to invoke it, a description that tells the model what the tool does and when to use it, an optional input schema that defines what arguments it accepts, and a handler that runs when the model calls it and returns structured content back. The model reads tool descriptions at runtime and decides autonomously which tools to call and with what arguments.

My first commit was deliberately minimal: one tool, one transport, no data layer, no error handling. I wanted to get something working first before layering in too much complexity.

Here's the complete initial tool:

// src/tools/helloWorld.js
export const name = "hello_world";

export const config = {
  description: "Returns a Hello, World! greeting",
};

export async function handler() {
  return {
    content: [{ type: "text", text: "Hello, World!" }],
  };
}

That's it. No inputs, no schema, no error cases. The response shape, ({ content: [{ type: "text", text: "..." }] }), is the MCP standard for text output.

The HTTP transport in server.js was equally minimal: a Node.js http.createServer that routes POST /mcp to a StreamableHTTPServerTransport instance and ignores everything else. The key detail is running in stateless mode (sessionIdGenerator: undefined), which means each request gets a fresh transport instance rather than trying to maintain session state:

// src/server.js
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import http from "node:http";
import { server } from "./mcp.js";

const httpServer = http.createServer(async (req, res) => {
  if (req.method === "POST" && req.url === "/mcp") {
    const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
    res.on("close", () => transport.close());
    await server.connect(transport);
    await transport.handleRequest(req, res);
    return;
  }
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end("hello-mcp is running\n");
});

const PORT = process.env.PORT ?? 3000;
httpServer.listen(PORT, () => {
  console.log(`MCP endpoint → http://localhost:${PORT}/mcp`);
});

I could verify the tool was working with a raw curl command:

curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc": "2.0", "id": 1, "method": "tools/call",
       "params": {"name": "hello_world", "arguments": {}}}'

Note the Accept header — it's required. The transport rejects requests that don't signal they can handle either JSON or SSE. This tripped me up with my first curl test.

Testing with Claude Desktop

Once I had a working tool, I wanted to see it inside Claude. Claude Desktop supports MCP servers via the stdio transport, where Claude spawns the server as a subprocess and communicates over stdin/stdout.

Adding stdio support was literally five lines, because the server was already transport-agnostic:

// src/stdio.js
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { server } from "./mcp.js";

const transport = new StdioServerTransport();
await server.connect(transport);

Then I added the server to Claude Desktop's config:

{
  "mcpServers": {
    "hello-mcp": {
      "command": "node",
      "args": ["/absolute/path/to/hello-mcp/src/stdio.js"]
    }
  }
}

A few things I learned the hard way:

Use an absolute path. Claude Desktop spawns the process from a different working directory, so relative paths fail silently.
Quit and fully relaunch Claude Desktop after editing the config. There's no hot-reload.
Verify the connection at Claude menu → Settings → Developer. The server should be labeled as "running" (this use to be a green dot but has evolved with the introduction of Connectors)

Once my server was running, I could just type "say hello to the world" in Claude and watch it invoke hello_world automatically. The model sees the tool description and decides when to call it — I didn't direct it explicitly.

Expanding tools and resources

With the scaffolding in place, I started added progressively more sophisticated tools to learn more.

Adding inputs with Zod

hello_name was the next step — a tool that takes a required name string:

// src/tools/helloName.js
import { z } from "zod";

export const name = "hello_name";

export const config = {
  description: "Returns a personalized Hello greeting",
  inputSchema: {
    name: z.string().describe("The name to greet"),
  },
};

export async function handler({ name }) {
  return {
    content: [{ type: "text", text: `Hello, ${name}!` }],
  };
}

Zod validation runs at the transport layer before the handler is ever called. Pass an invalid input (wrong type, missing required field) and the SDK returns a -32602 Invalid params JSON-RPC error without touching handler code. This is genuinely useful — the inputs are guaranteed to conform to the schema by the time the handler runs.

Now Claude could greet me by name!

Resources, error handling, and MCP logging

The next tool, greet_name, is where the project got interesting. Unlike the previous two tools, it takes multiple inputs: a person's name and a language. Then, it uses the language to look up a greeting from a shared data file and return something like "Bonjour, Chuck!" It's the first tool that has real validation concerns (what if the language isn't supported?), real observability concerns (what is the model actually passing in?), and a dependency on shared server state. It took four distinct iterations to arrive at the final version, and each one taught something new.

Part 1: Zod enum for validation

The first version was straightforward. It took a name string and a language input constrained to a Zod enum built directly from the keys of the greetings data file:

// src/tools/greetName.js (first version)
import { z } from "zod";
import { greetings } from "../data/greetings.js";

export const config = {
  description: "Returns a personalized greeting in the specified language",
  inputSchema: {
    name: z.string().describe("The name to greet"),
    language: z.enum(Object.keys(greetings)).describe("The language to greet in"),
  },
};

export async function handler({ name, language }) {
  const greeting = greetings[language];
  return {
    content: [{ type: "text", text: `${greeting}, ${name}!` }],
  };
}

This felt clean. The valid language values are derived directly from the data — add a language to greetings.js and the enum updates automatically. Zod validation runs at the transport layer before the handler is called, so if the model passes "klingon", the SDK returns a -32602 Invalid params error and the handler never runs. No manual validation needed.

The problem is that -32602 is a protocol-level JSON-RPC error. The model can't see the error message — it just knows the call failed. There's no way for Claude to tell the user "I tried 'klingon' but it's not a supported language." It just hits a wall.

Part 2: Free-form string input and `isError`

To experiment with error handling and logging, I switched the language input from a Zod enum to a plain z.string(). This intentionally removed the automatic validation — any string gets through to the handler — so I could handle bad input in the handler and respond in a way the model could actually use:

inputSchema: {
  name: z.string().describe("The name to greet"),
  language: z.string().describe("The language to greet in (e.g. 'french', 'japanese')"),
},

Now, when the handler received an unsupported language, instead of letting the SDK throw a protocol error, I returned isError: true:

if (!greeting) {
  return {
    isError: true,
    content: [{ type: "text", text: `Unsupported language: "${language}". Check the languages resource for supported options.` }],
  };
}

The distinction matters:

return { isError: true, content: [...] } — the error text comes back to the model as readable tool output. The model can see it, reason about it, and try something different.
throw new Error(...) — produces a protocol-level JSON-RPC error. The model can't read the message at all; it just knows the tool failed.

For recoverable errors where the model should be able to react, isError: true is almost always the right choice.

Part 3: Logging with the factory pattern

With error handling in place, I wanted to add MCP protocol logging — emitting info, warning, and debug messages visible in the MCP Inspector's notifications panel. The SDK method for this is server.sendLoggingMessage(), but that requires a reference to the server object inside the tool handler.

The naive approach — importing server from mcp.js inside greetName.js — creates a circular dependency. mcp.js imports greetName.js; greetName.js imports mcp.js. JavaScript ES modules handle circular imports inconsistently — I got undefined instead of an explicit error, which made it slow to diagnose.

The solution was a factory function. Instead of exporting a handler directly, the tool exports createHandler(server), which closes over the server and returns the actual handler:

// src/tools/greetName.js (final version)
export function createHandler(server) {
  return async function handler({ name, language }) {
    await server.sendLoggingMessage({
      level: "info",
      message: `greet_name called with name="${name}", language="${language}"`,
    });

    const greeting = greetings[language];

    if (!greeting) {
      await server.sendLoggingMessage({
        level: "warning",
        message: `Unsupported language requested: "${language}"`,
      });
      return {
        isError: true,
        content: [{ type: "text", text: `Unsupported language: "${language}". Check the languages resource for supported options.` }],
      };
    }

    await server.sendLoggingMessage({
      level: "debug",
      message: `Greeting resolved: "${greeting}"`,
    });

    return {
      content: [{ type: "text", text: `${greeting}, ${name}!` }],
    };
  };
}

In mcp.js, registration becomes:

server.registerTool(greetName.name, greetName.config, greetName.createHandler(server));

The tool file never imports server. mcp.js calls the factory at registration time and passes itself in. The dependency flows one way. No circularity.

Part 4: Resources vs. tools in Claude Desktop

Without the enum, I needed a way for the model to discover the list of valid languages. I built a languages://list resource — a read-only MCP resource backed by the same greetings.js data file:

// src/resources/languages.js
export async function reader() {
  return {
    contents: [{ uri, text: JSON.stringify(Object.keys(greetings), null, 2) }],
  };
}

This felt architecturally correct. Resources are the MCP primitive for exposing read-only data. The model could fetch the list, see what's supported, and retry greet_name with a valid language.

Except it didn't work that way in Claude Desktop. Resources are fetched by the client — meaning the user or the host application — not by the model. Claude Desktop doesn't surface resources to the model at all. The model had no idea languages://list existed.

The fix was adding a list_languages tool that returns the same data:

// src/tools/listLanguages.js
export async function handler() {
  return {
    content: [{ type: "text", text: Object.keys(greetings).join(", ") }],
  };
}

The resource still exists — the MCP Inspector can fetch it, and any client that exposes resources to users can use it. But for Claude Desktop, the tool is what makes the language list accessible to the model. When greet_name returns an error, the model can now call list_languages on its own, see the supported options, and retry with a valid value.

What's next

This project was explicitly a learning exercise, but there are natural directions to take it:

Prompt templates — the third MCP primitive I haven't touched. Prompts let you define reusable prompt templates that the user (not the model) can insert into the conversation.
Stateful sessions — the HTTP transport supports session tracking via sessionIdGenerator. Stateful sessions would let you maintain per-connection state, which opens up tools that span multiple requests.
Real data sources — everything here is hardcoded. Connecting greet_name to a real translation API, or the languages resource to a database, would make it a genuinely useful server.
Deployment — the HTTP transport is already deployable as a standard Node.js service. Wrapping server.js in a container and putting it behind a reverse proxy gets you a hosted MCP endpoint.

The takeaway

Building hello-mcp gave me a much better mental model of MCP than reading the spec did. A few things I'd tell someone starting out:

Separate your server from your transport from day one. The cost is negligible; the flexibility is real.
Use isError: true for recoverable errors. The model can reason about tool errors; it can't reason about JSON-RPC exceptions.
Resources are for clients, not models. If you need the model to see data, make it a tool.
Check the SDK version. MCPs are evolving fast; older examples may lead you astray.

If you want to see the full working server — all the tools, both transports, the resource, and the factory pattern — the complete source is on GitHub at github.com/chuckmeyer/hello-mcp. Clone it, connect it to Claude Desktop, and try breaking greet_name with an unsupported language. It's a good way to see how all the pieces fit together.

Setting up your MacBook for mobile Flutter development

Chuck Meyer — Tue, 20 Dec 2022 19:53:14 +0000

This month I'm trying to level up on my mobile development skills by learning Flutter with and end goal of building a mobile search application. The first step was setting up a functional local dev environment on my laptop. I realized that there would be a few steps, but I didn't anticipate needing SIX different languages to get up and running!

In this post, I'll walk you through setting up your MacBook for cross-platform Flutter development on iPhone and Android devices.

Assumptions

You will need a terminal configured just the way a like it and the brew package manager installed. If you don't have it already, you should install brew first.

Install Flutter

The easiest way to install flutter is using brew

brew install --cask flutter

Once brew has installed flutter and all of its dependencies, you can use flutter itself to track what's left to do:

flutter doctor

This is also a good time to install command completion for flutter. Here's the command to that for zsh:

flutter bash-completion >> ~/.zshrc

Depending on what you already had installed, you probably have a lot left to do, so let's get to it!

The iOS build path

For iOS development, you need a full version of Xcode including the iOS SDK, not just the command line tools. It's easiest to install this from the App Store. Once it's finished installing, drop back to the command line and run the following command to accept the License agreement and install any additional components.

sudo xcodebuild -runFirstLaunch

You'll also want cocoapods for dependency management on the iOS side. Install it using brew.

brew install cocoapods
pod setup

That should be everything you need for iOS. Let's test to see if it works.

Testing the iOS build path

It's time to launch an iPhone simulator and create your first Flutter project.

open -a Simulator
flutter create my_first_app
cd my_first_app
flutter run

This should launch an iPhone emulator, create the default click-counting Flutter app, and load it onto the emulated iPhone.

The Android build path

On the Android side, you'll want to install Android Studio and the Android SDK. This guide walks you through the steps, but here's an overview.

First, download and install Android Studio for MacOS.
Launch Android Studio and create your first project.
Select Tools -> SDK Manager -> Android SDK -> SDK Tools and install the Android SDK Command-Line Tools and the latest Android Emulator

Switch back to the command line to accept all necessary licenses for Android using the following command.

flutter doctor --android-licenses

You'll need a Java runtime environment if you didn't already have one installed. The easiest is to just install the latest JRE form Oracle.
That should do it for the Android side. Time to test.

Testing the Android build path

To test the Android side, install an emulator and set it up as a target for flutter. First, choose an image.

~/Library/Android/sdk/tools/bin/sdkmanager --list | grep system-images

Select a recent system image to install and create an Android Virtual Device. Then you can launch the emulator and load the click-counting Flutter app.

~/Library/Android/sdk/tools/bin/sdkmanager --install "system-images;android-33;google_apis;arm64-v8a"
~/Library/Android/sdk/tools/bin/avdmanager create avd -n "pixel_5_api33" -k "system-images;android-33;google_apis;arm64-v8a" -b "arm64-v8a" -d "pixel"

flutter emulators –-launch pixel_5_api33
flutter run

You are now ready to begin cross-platform development of your mobile app!

Next time, we'll add search to our mobile applications using the Algolia Flutter Helper.

Customize Algolia React components with Tailwind classes

Chuck Meyer — Tue, 19 Jul 2022 19:46:45 +0000

While I was at Algolia's Paris office last week, Dhaya Benmessaoud from our Front-end Experience team showed me a nifty trick for styling Algolia's React widgets in your UI. Out-of-the-box, Algolia provides a couple of pre-built themes for search experiences (Algolia and Satellite) and the ability to create custom themes. Recently, the front-end experience team has added a third way to style your UI by injecting custom CSS classes into your Algolia React components.

This is excellent news for people who use class-based CSS frameworks like Bootstrap and Tailwind! In my case, I was working with the Algolia Ecommerce UI Template, which relies on Tailwind for styling. I wanted to add a <TrendingFacets> widget from the Algolia Recommend UI library to my homepage, but I wanted to style it using Tailwind classes to match the rest of my front-end.

Here's how it looks before styling:

I can definitely do better! To accomplish this, I need to use the classNames attribute for my component. It's available for all of Algolia's React widgets (including Recommend) and allows you to override styling on component-specific elements. Some of our other front-end APIs like Vanilla JavaScript (cssClasses) and Vue (class-names) have had this functionality for years, and now it's available in React thanks to the recent refresh that added React hooks.

The documentation lists the elements I can override for each Algolia widget. For instance, here are the elements for a <SearchBox> widget:

root: The root element of the widget.
form: The form element.
input: The input element.
submit: The submit button.
reset: The reset button.
loadingIndicator: The loading indicator element.
submitIcon: The submit icon.
resetIcon: The reset icon.
loadingIcon: The loading icon.

For my <TrendingFacets> widget, I want the list in a horizontal line to conserve space, so I add a flex class to its list element. I'll also add a new facetItem class to give each item a clean capsule shape with some simple hover styling. Here's how my component looks after styling.

And here's the code:

<TrendingFacets
  classNames={{ list: 'flex', item: 'facetItem' }}
  recommendClient={recommendClient}
  indexName={indexName}
  maxRecommendations={3}
  itemComponent={({ item }) => (
    <a href={item.facetValue}>{item.facetValue}</a>
  )}
  facetName={facetName}
/>

Adding classNames to customize the style of Algolia widgets makes so much sense, especially for people like me who are addicted to Tailwind CSS for styling front-ends. You can read more about adding custom CSS classes to widgets in the Algolia documentation. If you're new to Algolia, you can try it out by signing up for a free tier account.

I'd love to see other examples of well-styled search experiences in the comments!

Feature Spotlight: Trends Models in Recommend

Chuck Meyer — Thu, 07 Jul 2022 03:37:03 +0000

Recommendations thrive on data – the more you know, the better the recommendations you can make. Algolia’s Recommend product puts your data to work using machine-learning to suggest products or content that will interest your customers. Today, we’re putting a spotlight on Recommend’s new Trends models. You’ll learn about how they work and how they expand the ways that you can use recommendations.

At launch, Recommend offered two initial machine-learning models: Related Products and Frequently Bought Together. Both are collaborative-filtering models, meaning you train them on the products your users click on and purchase as they interact with your website (events data). These models are great for product-centric recommendations. Given a specific product from your catalog, you can use the models to suggest other products that your customers either found similar or also purchased. You can place these recommendations on product detail pages and checkout flows to help your customers discover other products they might be interested in. Separate to what we'll be discussing in this article, these initial models have just been updated and you can now get started using them right away without events data - learn more here.

Trends models are similarly powered by collaborative-filtering, but are different in that they aren’t restricted to recommendations based on a single product. Instead, they look for product trends across the entire catalog, or within a particular facet/category of your catalog.

Diving into Trends

To use the Recommend models, you’ll need to have your products stored in an Algolia index. Then, you can track trends for either items or facet values across your index. Remember that a facet is an attribute, like “color”, that you have configured in your index for filtering. The possible values for this attribute across your index are called facet values – like “red” or “purple”.

Depending on the type of trend, you will train one of two new models:

Trending items - The most popular items either for a specific facet value or across the entire catalog.
Trending facet values - The most popular values for a specific facet (e.g. “sweaters” as a value for “category”).

Both models are trained by collaborative-filtering, meaning they learn trends from events data – specifically conversion events captured from your users. A conversion event could be purchasing an item, adding it to a shopping cart, or marking it as a favorite.

The trending items model looks at both the total number of conversion events for each item over the last few days, and the change in the number of conversion events over time to learn “trendiness” for each record in the index. It then assigns a score to each item in the catalog, either globally or within a particular facet value.

For trending facet values, this model does the same thing for a facet attribute – scoring the total number of conversions and change in conversions over a number of days for each facet value. You can collect trend information on up to three facets per model.

In order to use trends, you’ll need to train the model with at least 500 conversion events spread out over at least three days. Obviously, the more information you send, the better the recommendations the model can provide.

Where to use Trends

Trending items complement the other product-centric models by allowing you to recommend popular items or top sellers within a particular category on your home page before your customers have selected a single product.

Trending facets are great for adding popular categories or product attributes to your homepage that are relevant right now – whether it’s garden supplies in the spring or coats and hats in the fall.

Both models, once trained, can provide up to 30 recommendations, either globally or within a specified facet.

Training your Trends model

Before you can use any of the Recommend models, you’ll need to sign-up for an Algolia account and load your product catalog into an index. You can use an existing Search index or set one up just for Recommend.

Once your index is populated with product records, you’ll need to start sending user event information to Algolia. You can use the event integrations built into Algolia’s InstantSearch front-end libraries, the Algolia Insights API, or supported integrations with major ecommerce platforms and analytics back ends to collect this data. You can even upload your events as a CSV file with the appropriate record format.

Remember, because the Trends models look at changes over time, you’ll need to send conversion events that span multiple days.

The minimum event requirements are:

500 conversions in the last 30 days
Events across a minimum of 3 days (so not 500 conversions in 1 day)
Events for a minimum of 10 items in your index

You can track your events totals across your application in the Data Sources section of the Dashboard. This section also gives you access to debugging tools for troubleshooting your events.

To start training your model, choose the Trends model from the Recommend Dashboard. Select your product index and Recommend will let you know if you have enough of the required conversion events to start training. If you see an error about retrieving events, you may need to disable your ad-blocking software.

Next, you can select any facets that you want to take into account when training your model. For instance, you could train the model for Trending facet values on the facet category_page_id. You are now ready to click Train Model to start the training process. Training typically takes a few hours to complete.

Add trends to your frontend using the Recommend UI

Once your model is trained, you are ready to start adding Trend recommendations to your application. The easiest way to do this is with the Recommend front end UI libraries for vanilla JavaScript or React.

Let's say that you want to add trending categories to the Algolia Ecommerce UI Template using your newly trained Trending facet values model. First, you’ll need to add the recommend and recommend-react libraries to your project using npm (or yarn):

npm install --save @algolia/recommend-react @algolia/recommend

Once the libraries are installed, you’ll need to write a new FacetList component to retrieve and display facet recommendations from your trained model. Your component needs to initialize a Recommend client using the App ID and API key from the app that contains your trained model.

const recommendClient = recommend(ALGOLIA\_APP\_ID, ALGOLIA\_SEARCH\_ONLY\_API\_KEY)

Next, add the TrendingFacets widget from the Recommend React library. Since you’re working in the Ecommerce UI, you’ll use the abstracted Container component as a wrapper and handle titles the same way as other components in this library. That means you’ll want to suppress the default header by including headerComponent={() => null}. You can avoid overwhelming your visitors by reducing the list of 30 recommendations to just the top 3 using maxRecommendations={3}.

Here’s the complete FacetList component:

import algoliasearch from 'algoliasearch';
import recommend from '@algolia/recommend'
import { TrendingFacets } from '@algolia/recommend-react'
import classNames from 'classnames'
import { Container } from '@/components/container/container'

const recommendClient = recommend(ALGOLIA\_APP\_ID, ALGOLIA\_SEARCH\_ONLY\_API\_KEY)

export type FacetListProps = {
  title?: string
  indexName: string
  facetName: string
  className?: string
  \[index: string\]: any
}

export function FacetList({
  indexName,
  facetName,
  title,
  className,
}: FacetListProps) {
  return (
    <section className={classNames('py-4 laptop:py-16', className)}>
      <Container>
        {title && (
          <h2 className="text-sm font-semibold tracking-\[2px\] uppercase mb-3 laptop:mb-6 laptop:ml-3 laptop:heading-3">
            {title}
          </h2>
        )}
        <TrendingFacets
          recommendClient={recommendClient}
          indexName={indexName}
          maxRecommendations={3}
          itemComponent={({ item }) => <a href={item.facetValue}>{item.facetValue}</a>}
          headerComponent={() => null}
          facetName={facetName}
        />
      </Container>
    </section>
  )
}

Finally, add the finished component after the Banner widget on your index.tsx page:

      <FacetList
        title="Trending Categories"
        indexName="prod\_ECOM"
        facetName="category\_page\_id"
      />

After reloading, you should now see the top trending categories, just below the banner on the home page:

Conclusion

Trends models are a great complement to the existing, (and newly updated), Product models in Recommend. You can combine both types of models to help your customers discover new items during their entire journey on your site – facet value trends on the homepage lead them to trending items on the category page, related products on a product detail page, and finally to items frequently bought together during checkout. At each stage, customers are guided to items that they may have missed through a traditional search.

You can start using Trending items and Trending facet values right now from the Algolia Recommend dashboard. Or, you can read more about the other features that Recommend has to offer.

Feature Spotlight: Optional Filters

Chuck Meyer — Mon, 18 Apr 2022 16:40:29 +0000

While answering Algolia forum posts last week, I did a deep dive on Optional Filters for Algolia Search. Similar to filters and facet filters, optional filters are applied at query-time, allowing you to use all sorts of contextual information to improve results. Unlike the other filters, optional filters don't remove records from the result set. Instead, they allow you to say, "If records match this filter, move them up or down the ranking," without changing the number of records returned.

Some interesting use cases:

Move posts that mention a particular user to the top of the result set
Up-rank products available at a customer's local store
Down-rank products that are out-of-stock
Pin a specific record to the top of the listing based on an external recommendations engine

You can use filters and facet filters to reduce the number of records in the result set at query-time, then optional filters to manipulate the rankings for the remaining records. You can even apply filter scoring to control the order of the records further.

Here's an example that applies facet filters for product_type and price_range to an index from a Shopify store. The code selects the objectID of two records to promote, then injects them as optional filters into the query. If either of those products is part of the result set that matches the other criteria in the query, those products are pushed to the top of the ranking. The code uses filter scoring to ensure the featuredProduct will always appear above the alternateProduct.

import algoliasearch from 'algoliasearch';

const featuredProduct = '41469303161004';
const alternateProduct = '41469346644140';

const client = algoliasearch('H2M6B61JEG', 'b1bdfc3258823bb4468815a664dce649');

// Standard replica
const index = client.initIndex('shopify_algolia_products_price_asc_standard');

// with params
index.search(query, {
    facetFilters: [[
        "product_type:HardGood",
        "price_range:75:100"
    ]],
    optionalFilters: [[
        `objectID:${featuredProduct}<score=500>`,
        `objectID:${alternateProduct}<score=200>`
    ]],
    hitsPerPage: 50,
}).then(({ hits }) => {
    console.log(hits.map(item => `- ${item.title} | ${item.product_type} | ${item.objectID} | ${item.price_range}`).join('\n'));
});

Notice that this code uses a standard replica of the Shopify index sorted by price. Optional filters don't play well with Virtual Replica indices since both re-rank records at query-time, leading to unpredictable results. If you plan to use optional filters, you should use a standard replica that applies ranking at index-time.

You can also use negative optional filters to push records down the ranking. For example, if you wanted to push posts written by the current user lower in the rankings but not remove them completely:

index.search('', {
    filters: `date_timestamp > ${Math.floor(d.setDate(d.getDate() - 7) / 1000)}`,
    optionalFilters: [
      `author:-${user.name}`
    ],
    hitsPerPage: 50,
}).then(({ hits }) => {
    console.log(hits};
});

Optional filters are a powerful tool to add to your ranking tool belt, but remember that any query-time calculations will impact search performance. For instance, you shouldn’t use filter scoring on searches that may return more than 100,000 results. Always try to move ranking criteria to index configuration when possible. Use optional filters only when you need to further tune your results at query-time using more real-time context.

Let me know if you find a great (or not so great) use case for optional filters in your search UI!

Add autocomplete search to your Strapi blog

Chuck Meyer — Tue, 05 Apr 2022 17:26:20 +0000

Strapi is an open-source, headless CMS that builds API abstractions to retrieve your content regardless of where it's stored. It's a great tool for building content-driven applications like blogs and other media sites.

In this post, you're going to add interactive search to a Strapi blog with a Next.js front end using Algolia's Autocomplete.js library and the community-built Search plugin for Strapi.

Prerequisites

Strapi and Algolia Autcomplete.js are both build using Javascript, so you'll want node v.12 installed.

You'll build on the basic blog application from this guide using Strapi and Next.js. You should familiarize yourself with the steps in that post before building your search experience on top of it.

You'll also need an Algolia account for search. You can use your existing Algolia account or sign up for a free account.

Building the back end

Start by creating a directory to hold your project's front and back ends:

mkdir blog-strapi-algolia && cd blog-strapi-algolia

Strapi has a set of pre-baked templates you can use to get a CMS up and running quickly. These all include Strapi itself with pre-defined content types and sample data. If you don't have a Strapi blog already, you can use the blog template to quickly set one up.

npx create-strapi-app backend  --quickstart --template @strapi/template-blog@1.0.0 blog

After the script finishes installing, add an admin user at http://localhost:1337 so you can log in to the Strapi dashboard. This script sets up most of back end for us, including a few demo blog posts. You can read more about everything that was setup in the quick start.

Next you need to index your demo content. Fortunately, the Strapi community has you covered with a Search plugin and Algolia indexing provider built by community member Mattias van den Belt. You can read more about Mattie's plugin in the documentation, but getting up and running only requires a couple of pieces of configuration.

Go ahead and stop your Strapi server so you can install the plugin using npm (or yarn).

cd backend && npm install @mattie-bundle/strapi-plugin-search @mattie-bundle/strapi-provider-search-algoliai --save

You'll need to add an Algolia API key and App ID to your Strapi environment. You can manage your keys by navigating the Algolia Dashboard under Settings > Team and Access > API Keys, or go directly to https://algolia.com/account/api-keys. Since Strapi is modifying your Algolia index, you'll need to provide either the admin API key (for demos) or create a key with appropriate access for your production project.

# .env
// ...
ALGOLIA_PROVIDER_APPLICATION_ID=XXXXXXXXXX
ALGOLIA_PROVIDER_ADMIN_API_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

With your credentials in place, the last step is to configure the plugin. Create or modify the ./config/plugins.js file in your backend directory. You want to tell the plugin to index the article and category content types for your blog.

'use strict';

module.exports = ({ env }) => ({
  // ...
  search: {
    enabled: true,
    config: {
      provider: 'algolia',
      providerOptions: {
        apiKey: env('ALGOLIA_PROVIDER_ADMIN_API_KEY'),
        applicationId: env('ALGOLIA_PROVIDER_APPLICATION_ID'),
      },
      contentTypes: [
        { name: 'api::article.article' },
        { name: 'api::category.category' },
      ],
    },
  },
});

Restart your Strapi server to pick up these environment variables and the new plugin (npm run develop). The Search plugin triggers when new content is Published, so you'll need to either Unpublish and Publish the demo articles, or create a new one. Load the Strapi admin panel (http://localhost:1337/admin) and navigate to Content Manager > COLLECTION TYPES > Article and either click on an existing article to Unpublish or click on Create new Entry. Click Publish on your article to index this entry into your Algolia application. You can do the same for the category content type if you'd like to index those as well.

Building the front end

Now that you've built your back end and populated your index, it's time to build the front end for you users.

Strapi has a great blog post walking you through building a Next.js powered front end. You'll build on top of those steps here. You can either walk through their quick start yourself, or you can just clone this repo if you want to jump directly to adding search.

git clone --single-branch --branch no-search-version git@github.com:chuckmeyer/blog-strapi-frontend.git frontend

Don't forget to run cd frontend && npm install if you cloned the front end from the repo.

This is enough to get the basic blog site up and running. You can test it out by running npm run dev in the frontend directory.

The only thing missing is search. You'll be using the Algolia Autocomplete.js library to add an autocomplete search experience to your blog's navigation bar. When a user types into the field, the autocomplete "completes" their thought by providing full terms or results. The Autocomplete library is source agnostic, so you'll also need the Algolia InstantSearch library to connect to your index on the back end.

npm install @algolia/autocomplete-js algoliasearch @algolia/autocomplete-theme-classic --save

To use the autocomplete library in a React project, you first need to create an Autocomplete component to wrap the library. You can find the boilerplate for this in the autocomplete documentation.

./frontend/components/autocomplete.js

import { autocomplete } from '@algolia/autocomplete-js';
import React, { createElement, Fragment, useEffect, useRef } from 'react';
import { render } from 'react-dom';

export function Autocomplete(props) {
  const containerRef = useRef(null);

  useEffect(() => {
    if (!containerRef.current) {
      return undefined;
    }

    const search = autocomplete({
      container: containerRef.current,
      renderer: { createElement, Fragment },
      render({ children }, root) {
        render(children, root);
      },
      ...props,
    });

    return () => {
      search.destroy();
    };    
  }, [props]);

  return <div ref={containerRef} />;
}

Just like in the back end, you'll need your Algolia credentials to connect to the API. Since the front end only needs to read from the index, you can use your search key for the application. Create a ./frontend/.env.local file to store your credentials.

NEXT_PUBLIC_ALGOLIA_APP_ID=XXXXXXXXXX
NEXT_PUBLIC_ALGOLIA_SEARCH_API_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Now you can initialize your connection to Algolia and add your new Autocomplete component by updating the code in ./frontend/components/nav.js.

import React from "react";
import Link from "next/link";

import { getAlgoliaResults } from '@algolia/autocomplete-js';
import algoliasearch from 'algoliasearch';
import { Autocomplete } from './autocomplete';
import SearchItem from './searchItem';
import "@algolia/autocomplete-theme-classic";

const searchClient = algoliasearch(
  process.env.NEXT_PUBLIC_ALGOLIA_APP_ID,
  process.env.NEXT_PUBLIC_ALGOLIA_SEARCH_API_KEY,
);

const Nav = ({ categories }) => {
  return (
    <div>
      <nav className="uk-navbar-container" data-uk-navbar>
        <div className="uk-navbar-left">
          <ul className="uk-navbar-nav">
            <li>
              <Link href="/">
                <a>Strapi Blog</a>
              </Link>
            </li>
          </ul>
        </div>
        <div className="uk-navbar-center">
          <Autocomplete
            openOnFocus={false}
            detachedMediaQuery=''
            placeholder="Search for articles"
            getSources={({ query }) => [
              {
                sourceId: "articles",
                getItemUrl( {item} ) { return `/article/${item.slug}`},
                getItems() {
                  return getAlgoliaResults({
                    searchClient,
                    queries: [
                      {
                        indexName: "development_api::article.article",
                        query,
                      }
                    ]
                  })
                },
                templates: {
                  item({ item, components}) {
                    return <SearchItem hit={item} components={components} />;
                  }
                }
              },
            ]}
          />
        </div>
        <div className="uk-navbar-right">
          <ul className="uk-navbar-nav">
            {categories.map((category) => {
              return (
                <li key={category.id}>
                  <Link href={`/category/${category.attributes.slug}`}>
                    <a className="uk-link-reset">{category.attributes.name}</a>
                  </Link>
                </li>
              );
            })}
          </ul>
        </div>
      </nav>
    </div>
  );
};

export default Nav;

As you can see, you're passing a few parameters to the Autocomplete component:

openOnFocus={false} - tells your search not to populate results until a user starts typing
detachedMediaQuery=''- opens search in a detached modal, providing more room for your results
placeholder="Search for articles" - the text that appears in the searchbox before a search
getSources={({ query }) => - where you define your data sources for your autocomplete experience

Remember that Autocomplete is source agnostic. You define sources based on APIs, libraries, or static content within your application. Here, you're binding a source called articles to your Algolia index using the getAlgoliaResults function from the autocomplete-js library.

              {
                sourceId: "articles",
                getItemUrl( {item} ) { return `/article/${item.slug}`},
                getItems() {
                  return getAlgoliaResults({
                    searchClient,
                    queries: [
                      {
                        indexName: "development_api::article.article",
                        query,
                      }
                    ]
                  })
                },
                templates: {
                  item({ item, components}) {
                    return <SearchItem hit={item} components={components} />;
                  }
                }
              },

The development_api::article.article is the index generated by the Strapi Search plugin above for your article content type. When you move to production, the plugin will create a separate production_api::article.article index in the same application.

The getItemUrl() section sets up keyboard navigation, while getItems() handles retrieving articles from your index using the query term(s) from the searchbox.

Notice the code above references a SearchItem component. This is the template you'll use to tell Autocomplete how to render your search results. Add a new component called ./frontend/components/searchItem.js with the following code.

import React from "react";

function SearchItem({ hit, components }) {
  return (
    <a className="aa-ItemLink" href={`/article/${hit.slug}`}>
      <div className="aa-ItemContent">
        <div className="ItemCategory">{hit.category.name}</div>
        <div className="aa-ItemContentBody">
          <div className="aa-ItemContentTitle">
            <components.Highlight hit={hit} attribute="title" />
          </div>
          <div className="aa-ItemContentDescription">
            <components.Highlight hit={hit} attribute="description" />
          </div>

        </div>
      </div>
    </a>
  );
};

export default SearchItem;

With this code, you're displaying the category associated with the article, the title, and the description. Use the components.Highlight component to emphasize the part of the attribute that matched the user's query.

And with that, you're done! Start your front end server with npm run dev. You should now see the autocomplete searchbox at the top of the page. Clicking on it opens the modal search interface where you can start typing your search term.

You can see a hosted version of this front end on codesandbox, although it may take some time for the back end container to start. The before and after versions of the front end code are both available on Github as well.

If you build something cool using this blog, share it with us on Twitter (@algollia).

Build a store locator that includes online sellers

Chuck Meyer — Tue, 22 Mar 2022 14:35:39 +0000

The problem

Let's say you've been tasked to build an application to help consumers find agencies providing a specific service. Some of these agencies are local brick-and-mortar storefronts and others are online-only agencies that service the same local area. This problem was initially posed by Alejo Arias in the Algolia Discourse forum:

I have a series of providers in my index:

some are national providers (they have a national: true attribute)

some are state-wide providers (they have a state attribute with the list of states they service, e.g. [“NY”, “FL”])

some are local (they have specific lat/lng in their _geoloc attribute)

I want in my results anything that matches local providers by location close to my users, but also provide (in the same results) state and national providers. Adding a aroundLatLng filter automatically removes other results, no matter what facets or filters I try.

How can I achieve this?
Basically I want to have something like: aroundLatLng: x,y OR state: NY OR national: true

So how do you combine results from a geographic search for brick-and-mortar stores with other results from boolean or text-based queries? And how do you build an interface to display them in a unified way?

Geographic data and Algolia Search

As Alejo mentions, you can use Algolia for geographic searches by adding a special _geoloc attribute on your records. You put one or more sets of latitude/longitude tuples into this attribute to indicate geographic locations linked to the record.

Then you use the Algolia client libraries to query against these geocoded records -- filtering either within a radius around a fixed point (aroundLatLong) or the area within a shape (insideBoundingBox or insidePolygon). The documentation goes into more detail about the differences between these methods. You can also read through these posts that walk you through building a pure-geographic store locator.

However, you cannot extract geographic and non-geographic results from the same query. If you are searching for proximity, records lacking _geoloc attributes will not show up in the result set.

So how do you perform this search when not all records have geographic coordinates?

A single index solution

You could do the whole thing via geographic search. By adding _geoloc data to the state and national records, you could search for everything using a geographic query. For instance, placing the statewide agencies at coordinates at the center of each state. This was the initial solution I added to the forum post, but there are several problems with this solution:

Alejo specifically mentions that some providers span multiple states
Placing providers at the center of the state will cause inaccurate results for consumers who live near state borders
National providers would need records in every state

A multi-index solution

As an alternative you can build a multi-index solution with one index for the brick-and-mortar storefronts that include geographic data, and another for the state and national providers. You can then search the two data sources independently and blend the result sets. This approach requires two Algolia queries per search, but it will allow us to guarantee results from both types of providers.

Preparing your indices

First, you'll need an agency data set. You can build one from scratch using a couple of sources. You can start with anonymized address data from this repo containing about 3000 addresses across the United State. Then, run these addresses through a small script to add fictional agency names and randomly flag some of the agencies as "preferred".

def transform_records(addresses):
  address_records = []
  for address in addresses:
    record = {}
    record_geocode = {}
    # One in ten chance agency is preferred 
    record['preferred'] = 10 == random.randint(1,10)

    record['objectID'] = random_name.generate_name().title()
    if record['preferred']:
      record['name'] = f"{record['objectID']} Agency (Preferred)"
    else:
      record['name'] = f"{record['objectID']} Agency"
    record['address'] = address.get('address1')
    record['city'] = address.get('city')
    record['state'] = address.get('state')
    record['zip'] = address.get('postalCode')
    record_geocode['lat'] = address['coordinates']['lat']
    record_geocode['lng'] = address['coordinates']['lng']
    record['_geoloc'] = record_geocode
    address_records.append(record)
  return address_records

You can use another script to generate statewide and multi-state agencies for the second index. Both data sets reside in this repo. You can create indices from these data sets under your existing Algolia account or sign up for a free account and set up a new agency_finder application.

Building the front end

Now that you've populated your indices, it's time to build the front end. Algolia's geoSearch component in the InstantSearch library includes a helper component to initialize the Google Maps API, render a Map, and tie that map to geolocation queries in your Algolia index. It's the same component I used previously to build a COVID-19 case visualizer. However, for this project, you want the user to type in an address and resolve the geolocation information for them using the Google Places API. This proves challenging using the out-of-the-box components in InstantSearch, so you'll build your own interface from scratch.

This blog post gives us a solid model for building an address autocomplete form in React. You'll use this as the foundation for your AgencyFinderForm component to render the address autocomplete input field as well as read-only fields to display the resulting address. The latitude/longitude are stored in state, but not shown on the form

You can modernize the code from the blog by using the Google Wrapper around your React components to initialize the google object and add the Places API.

   renderForm = (status) => {
    switch (status) {
      case Status.SUCCESS:
        return <AgencyFinderForm handleCallback={this.handleCallback} />;
      default:
        return <h3>{status} ...</h3>;
      };
  }

  render() {
    return (
      <div>
        <h1>Find an Agency</h1>
        <p className='instructions'>🔍 Search for your address to find the closest agencies.</p>
        <div className='left-panel'>
          <Wrapper apiKey={process.env.REACT_APP_GOOGLE_API_KEY} render={this.renderForm} libraries={["places"]} />
        </div>
        <div className='right-panel'>
          <AgencyFinderResults hits={this.state.results} />
        </div>
      </div>
    )
  }
}

Next you add a clear button to the basic form.

  handleClear() {
    this.setState(this.initialState);
    var input = document.getElementById('autocomplete');
    input.value = '';
    google.maps.event.removeListener(this.autocompleteListener);
    this.initAutocomplete();
  }

Finally, you'll clean up processing the address_components from the Places API with following code:

  handlePlaceSelect() {
    const addressObject = this.autocomplete.getPlace();
    const address = addressObject.address_components.reduce((seed, { short_name, types }) => {
      types.forEach(t => {
        seed[t] = short_name;
      });
      return seed;
    }, {});
    [this setState](this.setState)({
      streetAddress: `${address.street_number} ${address.route}`,
      city: address.locality ? address.locality : address.sublocality_level_1,
      state: address.administrative_area_level_1,
      zipCode: address.postal_code,
      geoCode: addressObject.geometry.location.lat() + ', ' + addressObject.geometry.location.lng(),
    });
  }

Querying for results

After the user has selected a location and you have the latitude, longitude, and address information stored in the component state, you're ready to query the indices. You use the multipleQueries method from the Javascript API client to batch together the two queries and combine the results. This will still count as two queries against your Algolia limit, but it reduces the number of round trips to the API.

handleSubmit(event) {
    const queries = [{
      indexName: statesIndex,
      query: this.state.state,
      params: {
        hitsPerPage: 10
      }
    }, {
      indexName: geoIndex,
      query: '',
      params: {
        aroundLatLng: this.state.geoCode,
        facetFilters: [ this.state.preferred ? 'preferred:true' : '' ],
        hitsPerPage: 10,
      }
    }];

    this.searchClient.multipleQueries(queries).then(({ results }) => {
      let allHits = [];
      results.map((result) => {
        return allHits.push(...result.hits);
      });
      this.props.handleCallback(allHits);
    });
  }

First, you initialize the two queries. Notice how the multipleQueries method allows us to mix geographic and string-based queries, and even layer in an
optional facetFilter for your "Preferred" agencies. You then pass the array of queries to the client. The response includes the individual results from each
query, but you can just smash the hits from the two result sets into a single array and pass them to the AgencyFinderResults component.

Putting it all together

You now have a solid proof-of-concept React component for layering geographic and non-geographic results into a single result set. At this point you could improve the example by adding a Google Map to display the geographic results. You could also pivot back to a single index, using multipleQueries ability to query the same index multiple times with different parameters.

The complete example is available in this Github repo or you can try out a live demo.

Meet Searchy, the Battlesnake powered by Algolia Search

Chuck Meyer — Thu, 09 Dec 2021 16:58:17 +0000

What I did

Since I started working at Algolia, I see search everywhere. Naturally, when trying my hand at building a Battlesnake, my first thought was "can I build a snake powered by search?" So, I played mad scientist and built a Battlesnake that uses an Algolia Search index to hunt for food on the board. Her name is Searchy.

The API latency is perfectly fine and she's actually ranked on a couple of leader boards. Here's how I did it.

What is Battlesnake?

If you're not familiar with Battlesnake, it's a competitive programming game. Battlesnake builders write code against the pre-defined API and deploy it to an endpoint. The Battlesnake game servers use that endpoint to control the snakes in real time as they attempt to find food, avoid other Battlesnakes, and stay alive as long as possible.

Just like any other microservice, competitors can use whatever language and tech stack they want behind the API, as long it can respond with "up", "down", "left", or "right" within the service level agreement (SLA) response time of the API (typically 500ms).

The most obvious technology to use here is machine learning. Train an algorithm on a pile of games, let it learn the best moves, and set it loose to compete against other snakes. But I started thinking about old school chess programs. Back before the advent of machine learning, the way you built an engine to play chess (or really any turn-based game) was by using tree traversal. Basically, map out all of the possible board representations and then find the best one based on the current board.

I thought perhaps I could do the same for Battlesnake -- generate a collection of boards centered around my snake's head and then traverse them to find the best move based on the current board state received via the API.

What's search got to do with this? 🐍🔍

For a chess engine, you always start from the same initial position and games proceed proceed from there with openings, middle games, and end games.

For Battlesnake, your snake can start anywhere on the board (which can be of a variable size) and there's really no relation from one board to the next. So I thought it might be better to treat my boards more like radar, with my snake's head at the center and a representation of the surrounding squares to determine where to move next.

Rather than traversing a tree, I could put all of these boards into an Algolia index, then use the search API to quickly find the current board and identify the best next move for Searchy.

Building the boards

Why did tree traversal fall out of favor in the first place? Well, things can quickly get out of hand depending on how far out you want to search. There's about 36 moves per position in one move of a game of chess. There's 400 positions possible after each player's first move, 200,000 after two moves, and nearly 120 million after just three.

The same holds true with Battlesnake. Every square at any time could be empty, contain part of a snake, a wall, or a piece of food. That means if my board snapshot was a three by three grid, there could be 4^9 different combinations (262,144). A five by five grid take us to 4^25, or 1.1 quadrillion combinations. Obviously, this isn't tenable.

So I aimed a bit lower. What if I just represented various combinations of food? Now my boards were base-2 (food or empty) instead of base-4. This reduced the number of combinations significantly! A 3x3 board was now only 512 combinations and a 5x5 grid a reasonable (relatively speaking) 33.5 million. Half of that, actually, if I assume the snake's head is always the center square.

You can find my approach in this github repo. The board generators are written in Python and live in the utilities directory. Running utilities/make_food_plays.py generates all the possible positions for food in a 5x5 matrix (about 16.7 million of them). It then weights the possible moves on each board based on food proximity and how much food is in each quadrant.

    for loc, value in enumerate(board):
        if value == 'O':
            x_diff = loc % board_size
            y_diff = loc // board_size
            x_weight = head - abs(x_diff - head)
            y_weight = head - abs(y_diff - head)

            # left
            if x_diff < head:
                preferred["left"] += 1 + x_weight + y_weight
            # right
            if x_diff > head:
                preferred["right"] += 1 + x_weight + y_weight
            # down
            if y_diff < head:
                preferred["down"] += 1 + x_weight + y_weight
            # up
            if y_diff > head:
                preferred["up"] += 1 + x_weight + y_weight

    best_move_score = max(preferred, key=preferred.get)

Finally, it creates JSON records of all the boards and uses the Algolia Python client to import the records into an Algolia index.

def update_index(plays: str, index: str = ''):
    # Create the index
    print("Updating index {}".format(index))
    client = SearchClient.create(os.getenv('APP_ID'), os.getenv('API_KEY'))
    index = client.init_index(index)
    index.clear_objects()
    index.save_objects(plays)

Once the boards are loaded into an index, I don't have to run this utility again. Searchy makes all game time decisions against the index.

Building my endpoint

Searchy is built using the Python Starter Snake as a foundation. At game time, I do some quick collision evaluations in server_logic.py, then build a string representing a 5x5 field around her head. I use this string to query the Algolia index in find_boards.py to get the best moves from the list of possible boards. All the "smarts" are in the board generator, so I can work to constantly improve Searchy's vision without putting more drag on these real time queries.

So, why is this a bad idea?

Even at a more reasonable 16.7 million records, using Algolia this way is still suboptimal. This is because I'm treating Algolia more like a database than a search index, bypassing most of the features that make it so powerful. Algolia is designed from the ground up for lightning-fast type-as-you-go, predictive, interactive search. Every aspect of the search engine design leans into this, from prefix matching to how we scale our indices.

Maintaining a large index designed for incredibly fast, as-you-type search is costly. And it's mostly wasted when I'm simply retrieving a complete record (the board) every time.

But why is it still kind of an awesome idea?

So at the end of the day, I'm basically towing a trailer with a sports car. You can do it, but it's not the best tool for the job or the best use of your money.

And yet... it works pretty beautifully! Searchy has a consistent latency of about 250ms, well below the required 500ms of the API, and even without much logic around avoiding other snakes, she has maintained a 25% win rate for months. By offloading board decisions to Algolia, I've reduced the amount of real-time code I need to maintain and moved decision making to the asynchronous board generation process.

There's nothing more satisfying than an exercise in stunt coding that creates something surprisingly viable!

What's next?

I have lots of ideas on where to take Searchy next. I could improve her vision by doing a coarse grain search by averaging food in each quadrant of the board. I'd also like to create a second index for collision detection so everything is pulled via queries, but I'm trying to thoughtful about my number of records/queries.

Obviously the whole thing is a little silly, but I can but feel there are some interesting things around faceting the index to pick strategies, or using geosearch instead of text search that could really make this approach shine.

For now, I'm mostly impressed I can query the result from 16.7 million record Algolia index via API in < 250ms

Building a COVID-19 geosearch index using CSV files, MongoDB, or GraphQL

Chuck Meyer — Wed, 29 Sep 2021 14:23:19 +0000

My kids recently went back to school, which means COVID-19 is again fresh in my mind. I thought it might be interesting to build a COVID-19 geosearch site to explore case counts using a map interface. The first step is selecting a data source and building an index. Creating a hosted index from your well-structured data is crucial to how Algolia returns fast and accurate search results. Creating an index can also be the first challenge for us as developers trying to get search up and running.

I want to build the index for my site using John Hopkins University's aggregated COVID-19 data set. It turns out there are several different ways we can consume this data set. This offers us an opportunity to explore several patterns for ingesting data from different types of back ends, including flat files, databases, and APIs. As developers, we typically don't choose where we get our data. Applications come with pre-existing data sources and defined interfaces. We may even need to interact with multiple data sources to build the type of search needed for our application.

By the way, Algolia continues to offer free Pro plans for not-for-profit COVID-19 related applications if you're looking to build (or have built) something similar yourself.

Getting started

At Algolia, we talk about data ingestion as a three-step indexing process:

Fetching data from our data source
Transforming the extracted data
Sending our records to an index

In the rest of this blog, we'll walk through some strategies to ingest data from each of the available data formats that JHU offers. To follow along, you'll want to create an index under your existing Algolia account or sign up for a free account and set up an application.

You'll find all of the ingest scripts we discuss below in the scripts directory of the COVID-19 geosearch demo repo. Feel free to clone it and test the finished demo. You'll need to create an .env file from the example.env and add your Algolia app information and API key before you run the scripts.

Fetching data from flat files

John Hopkins conveniently publishes their global and US data to a GitHub repo that is updated at least daily. The data itself is stored in CSV format. These files contain the geocode coordinates we need for our mapping front end.

For instance, here's the record for my home county here in Ohio:

39049,Franklin,Ohio,US,2021-08-31 04:21:46,39.96995815,-83.01115755,139178,1531,,,"Franklin, Ohio, US",10569.763874248532,1.0863785943180675

Data scientists find it appealing to use flat files in a repository for storing data because of the emphasis on version control and tracking changes over time. If better information becomes available, they can update the historical records while also capturing the fact that the record has changed. A high-order database may struggle tracking that change. We'll write a quick script to ingest the raw CSV data directly into our index. We can do this using the Python pandas library.

#!python3
import pandas

DATA_FILE = '../COVID-19/csse_covid_19_data/csse_covid_19_daily_reports/08-30-2021.csv'

def main():
  df = pandas.read_csv(DATA_FILE)
  print(df)

if __name__ == "__main__":
    main()

They've named each file with a datestamp, which means we'll eventually need a way to find the filename with the latest data. For now, we're just pinning the ingest to a particular day. The file itself has a lot of data, though. We'll want to trim it down to just the information we need for our search. Since we can't do that during the ingest step, we'll save that for the transformation step and move on to the next data source.

Fetching data from a database

The devs over at MongoDB have imported the JHU data set into a managed MongoDB document store. Consuming from a database instead of the raw files has a couple of advantages. First, they take care of ingesting the CSV files from the Github repo and ensure they update the data hourly. Living downstream of the document store means we don't have to do the work of sorting through the flat files and finding the latest data. Additionally, MongoDB gives us a managed endpoint and a known interface, reducing friction for our developers since we no longer have to deal with the bespoke data structure of the flat files.

We can connect to their document store directly using pymongo and use its metadata to retrieve the latest records.

#!python3
from pymongo import MongoClient

MDB_URL = "mongodb+srv://readonly:readonly@covid-19.hip2i.mongodb.net/covid19"

def main():
  client = MongoClient(MDB_URL)
  db = client.get_database("covid19")
  stats = db.get_collection("global_and_us")
  metadata = db.get_collection("metadata")

  # Get the last date loaded:
  meta = metadata.find_one()
  last_date = meta["last_date"]

  results = stats.find(
    {
      "date":last_date,
    }
    print(results)

if __name__ == "__main__":
    main()

A crucial part of building our search index is trimming the data down to only what we need to search the data. Since we're using a database, we don't need to ingest the whole document, like with the flat files. Let's scope our query down to just the locality info, geocode coordinates, and confirmed case count. We can also skip any records missing positional data:

  results = stats.find(
    {
      "date":last_date,
      "loc":{"$exists": True, "$ne": [] }
    }, {
      "combined_name": 1, 
      "county": 1,
      "state": 1,
      "country": 1,
      "confirmed": 1,
      "loc": 1
    }

This will make our job easier when we transform the data records later.

Fetching data from REST APIs

MongoDB also provides a RESTful API to retrieve the same data without having to connect to the document store. APIs have the advantage of needing little more than a secure HTTP connection to consume. The challenge comes from complex data requests that require intimate knowledge of the API design, as we'll see below.

First, let's build our REST request:

#!python3
import json
import requests

METADATA_URL = 'https://webhooks.mongodb-stitch.com/api/client/v2.0/app/covid-19-qppza/service/REST-API/incoming_webhook/metadata'
REST_URL = 'https://webhooks.mongodb-stitch.com/api/client/v2.0/app/covid-19-qppza/service/REST-API/incoming_webhook/global_and_us'

def main():
  meta = requests.get(METADATA_URL)
  last_date = meta.json()['last_date']
  query = {
    'min_date': last_date,
    'max_date': last_date,
    'hide_fields': '_id, fips, country_code, country_iso2, country_iso3, population, deaths, confirmed_daily, deaths_daily, recovered, recovered_daily'
  }
  response = requests.get(REST_URL, params=query)
  print(response.json())

if __name__ == "__main__":
    main()

Again, we use the metadata to make sure we're grabbing only the latest data. Notice that the REST API exposes a hide_fields parameter we can use as a negative filter to get just the fields we need. It’s not as straightforward as just listing the fields we want, but there might have been reasons for designing the API like that. With APIs, we must work with the interface we’re given. Fortunately, as we’ll see in the next section, this is a problem developers have been thinking about.

Fetching data from GraphQL APIs

The final interface we explore is an authenticated GraphQL API. GraphQL provides the same HTTPS-accessible interface as the REST API, but adds a normalized query language that removes the need for deep familiarity with individual APIs. Once again, we use the metadata to find the date of the latest data and retrieve only the fields we need. However, because this API is authenticated, we must first hit an authentication endpoint and grab a short-lived access token:

#!python3
import json
import requests

GRAPHQL_AUTH = "https://realm.mongodb.com/api/client/v2.0/app/covid-19-qppza/auth/providers/anon-user/login"
GRAPHQL_URL  = "https://realm.mongodb.com/api/client/v2.0/app/covid-19-qppza/graphql"

def main():
  response = requests.get(GRAPHQL_AUTH)
  access_token =  response.json()['access_token']

  headers = {}
  headers["Accept"] = "application/json"
  headers["Content-Type"] = "application/json"
  headers["Authorization"] = "Bearer {}".format(access_token)

  metadata = requests.post(GRAPHQL_URL, headers=headers, json={'query': 'query { metadatum{ last_date }}'})
  if metadata.status_code != 200:
    raise Exception(f"Query failed to run with a {response.status_code}.")
  last_date = metadata.json()['data']['metadatum']['last_date']

  query = '''query {
    global_and_us(query: { date: "''' + last_date + '''" }, limit:5000)
    { confirmed county state country combined_name loc { type coordinates }}
}'''

  response = requests.post(GRAPHQL_URL, headers=headers, json={'query': query})
  if response.status_code != 200:
    raise Exception(f"Query failed to run with a {response.status_code}.")
  print(response.json())

if __name__ == "__main__":
    main()

This interface doesn't bring much new to the table. The one thing it has over the REST API is that it's standardized. GraphQL really shines when we query across multiple, disparate back ends or thinly slice our data for mobile or low-bandwidth use cases. It may be interesting to bring in additional data after a search, but we can do that with the other interfaces with less overhead.

Choosing our data source

There are pros and cons to each of these ingest methods. Consuming the flat files directly gets us closest to the data and includes some global municipality data that's not in the downstream sources. However, consuming these files means additional code to figure out which file has the latest data. We'll also need to do our own data normalization.

Consuming the files via MongoDB provides a simple interface and builds on top of a managed data ingestion layer to the flat files, but at the cost of some fidelity in the global data. For this use case, the REST and GraphQL APIs don't provide much beyond what we get from consuming the upstream sources. All three (MongoDB and the two API methods) provide query interfaces to filter records and retrieve only the attributes we need for our index.

As we think about keeping the data in sync over time, we may find the MongoDB interface appealing because we can use the metadata to ensure we're always grabbing the most recent case counts. As much as I love the additional data we get by consuming the raw CSV files, we'd have to build a way to monitor the repo to ensure we're always getting the most recent data.

Transforming our data

After selecting our data source, our next task is shaping the data for our index. Algolia indices must be in JSON format with a unique objectID per record. It makes sense to map these IDs to an existing ID in our data source. The Algolia API can create these IDs for us, but we don't recommend this. Beyond these requirements, the goal here is to trim our records down to the simplest form that still provides the right balance between performant search and useful results.

We are creating a geographic representation of our COVID-19 data, so at a bare minimum, we will need the geocode coordinates and the confirmed cases count for each record we want to display. To make the data easier to consume, we should include locality information like county or province to display on the map, and states and countries to improve the search relevance.

Here's our transform code for the CSV flat-file ingestion, again using pandas:

  covid_records = []
  for index, row in df.iterrows():
    # Skip locations w/o coordinates
    if pandas.isna(row['Lat']):
      print('Skipping {}: No geocode'.format(row['Combined_Key']))
    else:
      covid_record = {}
      covid_geocode = {}
      print(row['Combined_Key'])
      covid_record['`objectId`'] = row['Combined_Key']
      # Let's not use the combined key for US counties, instead let's use county and state  
      if pandas.isna(row['Admin2']):
        covid_record['location'] = row['Combined_Key']
      else:
        covid_record['location'] = row['Admin2'] + ', ' + row['Province_State']
      covid_record['country'] = row['Country_Region']
      covid_record['confirmed_cases'] = int(row['Confirmed'])
      covid_geocode['lat'] = row['Lat']
      covid_geocode['lng'] = row['Long_']
      covid_record['_geoloc'] = covid_geocode
      covid_records.append(covid_record)

The ingest code remains fairly consistent across all the ingest patterns. That makes sense since they all inherit the shape of the CSV files that are the root source. Here's the same code for our MongoDB source:

  covid_records = []
  for row in response.json():
    # Unassigned and Unknown records are alread scrubbed in this DB
    # Skip 'US' and 'Canada' since they have incomplete data
    # and locations w/o coordinates
    if row['combined_name'] != 'US' and row['combined_name'] != 'Canada' and 'loc' in row:
      covid_record = {}
      covid_geocode = {}
      print(row['combined_name'])
      covid_record['`objectId`'] = row['combined_name']
      # Let's not use the combined key for US counties, instead let's use county and state  
      if 'county' in row:
        covid_record['location'] = row['county'] + ', ' + row['state']
      else:
        covid_record['location'] = row['combined_name']
      covid_record['country'] = row['country']
      covid_record['confirmed_cases'] = row['confirmed']
      covid_geocode['lat'] = row['loc']['coordinates'][1]
      covid_geocode['lng'] = row['loc']['coordinates'][0]
      covid_record['_geoloc'] = covid_geocode
      covid_records.append(covid_record)
    else:
      print('Skipping {}: No geocode'.format(row['combined_name']))

In both cases, we are left with a normalized Python dictionary with the attributes we need for search and discovery.

Building our index

The last step is to send our normalized data to the Algolia Search API. At this point, the code is boilerplate using the Python SDK:

  client = SearchClient.create(os.getenv('APP_ID'), os.getenv('API_KEY'))
  index = client.init_index(os.getenv('ALGOLIA_INDEX_NAME'))
  index.clear_objects()
  index.save_objects(covid_records)

This code clears out any existing records and rebuilds the index using the latest data. By using the Python client to interact with the Algolia API, we don't have to worry about things like record batching and API retries, reducing the amount of code needed here. It also ensures zero downtime.

Most of the index defaults work just fine for this use case. The only changes I'd like to make are to limit our searchable attributes to just country and location, and rank our results in descending order by the number of cases. High case counts tend to map to large population centers, which makes the data more useful when we zoom out on the map.

Here's the snippet from my index configuration:

{
...
  "searchableAttributes": ["unordered(country)", "unordered(location)"],
  "ranking": ["typo", "geo", "words", "filters", "proximity", "attribute", "exact", "custom"],
  "customRanking": ["desc(confirmed_cases)"],
...
}

Next steps

After the initial data ingest, we also need to decide how to keep our index up to date as the underlying data changes. There are a number of patterns we can follow here depending on how we initiate the update and modify the index.

Rebuilding our index

Since our COVID-19 data set has a fixed number of records, clearing and rebuilding the index every few hours or a few times a day isn't particularly heavy. We can do this at fixed intervals using a scheduled serverless function or embedding our script in our build process. If we wanted even closer to real-time updates, we could set up a GitHub action on the COVID-19 repo to trigger a rebuild of our index whenever we merge a new PR.

Atomic rebuilds for production data

For a larger production index, we'll want to avoid the downtime as an index rebuilds or the possibility of a failed update. For this reason, we'll use the replace all objects method to perform an atomic reindex. Rather than rebuilding the index in place, this method creates a new index and only cuts over after all records are saved, reducing downtime and ensuring the action is, in fact, atomic.

Incremental updates

Sometimes it makes sense to perform incremental updates to individual records or even individual fields of data rather than rebuilding the entire index. For instance, if we were tracking confirmed cases over time, we would need to take into account occasional updates to historical data. It's not necessary to rebuild the entire index for a small data change. It makes more sense to monitor for changes using webhook subscriptions or by monitoring the files directly. Then we can incrementally add or update records in batches as data changes. In this pattern, the unique objectId becomes critical to reference the existing records during updates.

Building a front end

Now that we have our index, we can focus on building our front end. The geosearch widget from the Algolia React Instantsearch library lets us build a front end fairly trivially using Google Maps. You can take a sneak peek n the repo, but we'll save implementing that for another day.

DEV Community: Chuck Meyer

The Agent Factory: Building Consistent Agents at Scale

The Three-Legged Stool

When One Stool Isn't Enough

The Factory Pattern

One Template, Three Legs

Registering What Was Built

Managing the Fleet

Codifying the Factory

The Pattern in Action

Conclusion

Building a Javascript "Hello,World" MCP server in 2026

A moving target: how the MCP SDK has evolved

Building the framework

The first tool

Testing with Claude Desktop

Expanding tools and resources

Adding inputs with Zod

Resources, error handling, and MCP logging

Part 1: Zod enum for validation

Part 2: Free-form string input and isError

Part 3: Logging with the factory pattern

Part 4: Resources vs. tools in Claude Desktop

What's next

The takeaway

Setting up your MacBook for mobile Flutter development

Assumptions

Install Flutter

The iOS build path

Testing the iOS build path

The Android build path

Testing the Android build path

Customize Algolia React components with Tailwind classes

Feature Spotlight: Trends Models in Recommend

Diving into Trends

Where to use Trends

Training your Trends model

Add trends to your frontend using the Recommend UI

Conclusion

Feature Spotlight: Optional Filters

Add autocomplete search to your Strapi blog

Prerequisites

Building the back end

Building the front end

Build a store locator that includes online sellers

The problem

Geographic data and Algolia Search

A single index solution

A multi-index solution

Preparing your indices

Building the front end

Querying for results

Putting it all together

Meet Searchy, the Battlesnake powered by Algolia Search

What I did

What is Battlesnake?

What's search got to do with this? 🐍🔍

Building the boards

Building my endpoint

So, why is this a bad idea?

But why is it still kind of an awesome idea?

What's next?

Building a COVID-19 geosearch index using CSV files, MongoDB, or GraphQL

Getting started

Fetching data from flat files

Fetching data from a database

Fetching data from REST APIs

Fetching data from GraphQL APIs

Choosing our data source

Transforming our data

Building our index

Next steps

Rebuilding our index

Atomic rebuilds for production data

Incremental updates

Building a front end

Part 2: Free-form string input and `isError`