Search-first Web Applications

Lots of software projects struggle when they try to implement search-related features. I was reminded of this by @trek's reaction to this Algolia marketing tweet:

Development teams often delay building search due to lack of confidence in getting it right & fear that it will take longer than expected.

— Algolia (@algolia) May 11, 2017

Stop reading my diary please. https://t.co/cnWlInPm83

— Trek Glowacki (@trek) May 11, 2017

I have heard nothing but good things about Algolia's product, and if you're one of those teams that has been putting off the "Add Search" item on your TODO list, outsourcing it to them is probably not a bad idea.

But instead of treating search as something you can tack on later, what if you make search the foundational primitive for your whole application? That is the approach we're taking in Cardstack.

In a trivial sense, every screen of your application is already driven by "search". An SQL query, a GraphQL query, a JSONAPI GET: these are all specialized forms of search. But when the requirements change and you need to tune any of them for relevance, personalization, fuzzy matches, relatedness, or additional heterogeneous types, you're left painstakingly hand-coding new behaviors. These searches are brittle because the data access patterns and the resulting UI patterns are all hard-coded directly into the application.

In contrast, a search-first application:

1. Handles every data fetch via a search engine: a system that is good at both structured and fuzzy queries, optimized for low-latency. (Examples include Elasticsearch and Algolia.)

2. Allows the search results to drive the resulting UI. Every piece of content returned by the search is expected to have a corresponding UI component that is appropriate for displaying in the current context.

This results in fluid applications that are better at uniting disparate pieces of data into holistic experiences. And it leads us toward the big-picture vision of an open card ecosystem — once the whole experience is driven by search and families of UI components with standardized external APIs, there's no reason all the components need to come from one vendor/application/author. The user can remix micro-applications together into more than the sum of their parts.