An Opinionated Guide to Component APIs

Jun 20, 2022
John Gozde

John Gozde is the tech lead for the Imply Polaris UI.

When you think of APIs, what comes to mind? REST? RPC protocols and wire formats? Syscalls?

If you’re a frontend engineer, there are domain-specific APIs you interact with every day, but maybe you don’t think of them as such. I’m talking about Components.

Every major UI framework has the concept of a component. They help us encapsulate reusable functionality and set boundaries around what is displayed and how it behaves. It’s useful to think of each component as an API unto itself, albeit one that is a subset of a larger framework-specific component API.

The framework’s API is essentially fixed and beyond our control, but what we can control is exposed to other users/developers who consume the components we build. Things like naming conventions, prop types, and broader patterns for groups of related components are entirely user-level concerns that have downstream impacts.

What follows is a set of guidelines for building React components at the level of a component library or a design system. They are non-exhaustive and represent my personal tastes, but they have been largely extracted from Imply’s internal Canopus design system.

Feel free to use this however you like – fork it, copy it verbatim, or negate every single rule. The details of the guidelines are less important than simply having guidelines at all.

Caveat: It’s more important to be internally consistent than to strictly adhere to this or any other style guide. That is, if the project you’re contributing to has an established set of guidelines that contradict these, it’s better to follow what is already in place, at least for the short term. It’s fine to change the conventions a project uses over time, but it should be done deliberately and as a team.

Use ‘onSubjectVerb’ naming convention for event props

Also known as “callback props”, these are functions that are invoked based on some asynchronous trigger event, such as a user interaction, a network response, or a change in state. Notably, this excludes functions that are invoked during the render phase.

DO assign names to event props like on[Subject]Verb, where Subject is optional and Verb is usually present tense.Examples: onChange, onCancel, onTableScroll, onAvatarClick, onOpenChange, onEntryModeToggle
🤔MAYBE break the above rule for grammatical reasons.Example: onFilesSelected – uses past-tense verb “selected” because onFilesSelect is slightly more awkward to read and say.
DON’T reverse subject/verb or use prefixes like handle, set or other verbs, even if consumers would typically pass a state setter as a value.Bad examples: setEntryMode, handleAvatarClick, changeOpen, onScrollTable

The reasoning behind this guideline is based on 1) consistency with DOM events and 2) avoiding leaky abstractions.

The setSomeThing naming convention is a particularly common mistake I see being made, usually during refactoring. E.g., some state foo that was being kept in a child component was lifted up to a parent component, so the engineer added props to the child called foo and setFoo and moved the useState into the parent.

// ⛔️ Incorrect

function Parent(props: ParentProps) {
  const [foo, setFoo] = useState(”);
  return <Child foo={foo} setFoo={setFoo} />
}

interface ChildProps {
  foo: string;
  setFoo: React.Dispatch<React.SetStateAction<string>>;
}

function Child(props: ChildProps) {
  return (    <input      value={props.foo}      onChange={e => props.setFoo(e.target.value)}    />  )
}

But now we have an abstraction leak. The child should no longer be aware of where foo is stored or how it is updated. Maybe it lives in component state, maybe it lives in a Redux store, or maybe it’s something entirely different – it shouldn’t matter to the child component. All it needs to know is the current value of foo and what function to invoke when it thinks foo should change: onFooChange.

// ✅ Correct

function Parent(props: ParentProps) {
  const [foo, setFoo] = useState(”);
  return <Child foo={foo} onFooChange={setFoo} />
}

interface ChildProps {
  foo: string;
  onFooChange: (foo: string) => void;
}

function Child(props: ChildProps) {
  return (    <input      value={props.foo}      onChange={e => props.onFooChange(e.target.value)}    />  )
}

Include original DOM event as the last parameter

DO consider passing the originating DOM event as the last parameter when adding logic on top of a DOM event.Example: onVisibleToggle(visible: boolean, e: React.MouseEvent<HTMLElement>)

This ensures that users have the option to use preventDefault() or stopPropagation() if necessary. If a synthetic event might be triggered by multiple kinds of DOM events, you can type the event object using a type union or React.SyntheticEvent<HTMLElement>.

Avoid “is” prefix for boolean props

Boolean flags or toggles are props that accept true or false and where ={true} can be omitted when using JSX. They might be used for setting different behavior modes or for controlling some kind of binary state.

As far as naming is concerned, there are exactly two options, both of which are equally valid: “prefix with is” and “don’t prefix with is”. But since this is an opinionated guide, I can only choose one:

DO use adjectives for naming boolean props that describe a component’s state.Examples: open, visible, readOnly, compact, disabled, selected, checked, required
DON’T prefix boolean props with is or has.Bad examples: isOpen, isReadOnly, isLoading, hasMultiple, wasVisible
🤔MAYBE use present participles of adverbs when describing transient state.Examples: loading, savingBut these might also be better encapsulated in a multi-value toggle prop, e.g. state=”loading” or state=”saving”.

Please, put down your pitchforks. While that is the convention I prefer, my advice at the top, “internal consistency above all else,” still applies. It’s better for all toggles to use the same convention within a component or within a library than it is to always use this particular convention.

Prefer ‘false’ as a default value

This guideline is related to the principle of least astonishment. A boolean prop with the default value of true is redundant when specified as a flag, but the reader would only know this by inspecting the source of the component or reading the documentation on the props interface, if present.

DO prefer a default value of false for optional boolean props

Therefore, it’s preferable to invert the logic such that the default value is false and specifying the flag toggles it to true.

// ⛔️ Incorrect

interface SomeComponentProps {
  enabled?: boolean; // default=true
}

<SomeComponent />; // unclear -> do I need to set ‘enabled’?
<SomeComponent enabled />; // redundant
<SomeComponent enabled={false} />; // verbose
// ✅ Correct

interface SomeComponentProps {
  disabled?: boolean; // default=false
}

<SomeComponent />;
<SomeComponent disabled />;

Prefer composition over toggle props, use consistent naming otherwise

🤔MAYBE use a verbSubject pattern for naming boolean props that describe a component’s behavior.Examples: allowDragging, hideSourceColumnField
DON’T add excessive boolean props for toggling between different behavior modes.
DO prefer component composition over excessive use of toggle props.

This pattern is especially common. A new requirement is introduced that requires a slight change in behavior for a specific scenario, so the engineer adds a boolean prop to toggle between the old behavior and the new behavior. And then another requirement is introduced that requires another toggle… and then another…

After N toggle props are added, our component is handling 2N additional behavior modes, which makes it harder to predict what exactly will get rendered and how it will behave for the different combinations that exist.

Past a certain (very subjective) complexity threshold, it’s usually better to refactor this component and use composition to toggle different behavior modes rather than props. But won’t this shift the complexity to where the component is being used? Yes it will – but that complexity exists because the different usage sites have different requirements from each other, so our boolean prop was misleading us.

Prefer string-based unions for multi-value toggles

This one is fairly straightforward. Props that toggle between one of many states or behaviors should be typed as string unions, avoiding enums, objects, or other values that necessitate imports. The reason behind this rule is more for convenience and DX than anything else.

DO prefer string-based type unions for multi-value toggles.
DON’T use enums, const objects, or other values that require imports.
// ✅ Better
interface SomeComponentProps {
  state?: ‘loading’ | ‘saving’ | ‘idle’;
}
<SomeComponent state=”loading” />

// ⛔️ Worse
enum SomeComponentState {
  Loading,
  Saving,
  Idle
}

interface SomeComponentProps {
  state?: SomeComponentState;
}
<SomeComponent state={SomeComponentState.Loading} />

The approach using string unions is terser, more readable, and offers the same level of type safety as the approach using enums. It also avoids extra import statements and supports refactor/rename operations with recent versions of the TS language server.

Prefer value types for props

Picking the appropriate name for a prop is half the battle; the other half is choosing its type. React runs on JavaScript and both have quirks that influence which types are more or less appropriate for props.

For instance, many optimizations in React depend on referential equality comparisons for state and props in order to avoid doing unnecessary work. This works well for value types, like strings, numbers, and booleans, but it completely falls apart for arrays, objects, dates, and all class instances.

[] === [] // => false
[1] === [1] // => false
{} === {} // => false
{a:1} === {a:1} // => false
new Date(2020,0,1) === new Date(2020,0,1) // => false

This one language property is the achilles heel of optimization in React, which was seemingly designed for a more civilized language than what is available to us now. Records and tuples may alleviate some of this pain in a future ES runtime, but for now we need to address these issues at the component API level.

DO prefer value types for props.
🤔MAYBE inline object properties into individual props.

There are a plethora of valid reasons why we might choose an object or an array for a prop’s type. Maybe we’re rendering a list of items; maybe there’s an external dependency that accepts configuration as an object; maybe there are some props that should always be set together.

In some cases we can avoid a reference type but in others we can’t. It really depends on the situation.

Case 1 – arrays

Consider a component that renders a list of items, and the items themselves are fairly expensive to render. Using an array for the items prop is really the only choice we have (as of this writing). There are 3rd party libraries for constructing immutable lists, but due to limitations in JS as language (lack of operator overloads), it’s impossible to make referential equality, a === b, to behave like value equality.

If either the component or the items prop are memoized in some way (e.g., PureComponent, memo, useMemo, etc.), then this memoization is very easy to break for consumer components. All they need to do is specify a value like items={[1, 2, 3]} and the memoization is broken. We can even break it ourselves by setting a default value like items = [] because empty arrays are referentially unequal.

In this scenario, we have two options, neither of which are ideal. Option 1 is to clearly document that items is memoized for performance reasons so consumers should take care to do the same. Option 2 is to write a custom equality function for PureComponent (shouldComponentUpdate) or memo (areEqual) that uses shallow comparison for items. But option 2 is not available for useMemo, unfortunately.

Case 2 – non-finite objects

Another scenario similar to the above would be for object props that have a large number of properties or where the properties may have arbitrary keys. Like with arrays, our only options are to document or somehow use shallow equality internally.

Case 3 – finite objects

But consider a different scenario where we are building a component that has a default size, but that size can be changed by the consumer. Say we expose this via a size prop, typed as an object taking width and height properties:

interface MyProps {
  foo: string;
  bar?: number;
  size?: { width: number; height: number }
}

This type is deliberately forcing consumers to choose between not specifying any size or specifying both dimensions simultaneously. But again, this component is expensive to render, so we are memoizing the whole thing or maybe just the size prop. This has a similar issue as the array case above because if a consumer provides size={{ width: 20, height: 20 }}, that memoization will be broken.

Unlike the array case, however, there is a 3rd option available, which is to inline the size properties directly onto the props interface:

interface MyProps {
  foo: string;
  bar?: number;
  width?: number;
  height?: number;
}

Semantically speaking, this is not identical to the original props because now it’s possible to specify width without specifying height and vice versa. If we wanted to be really pedantic, we could use separate props interfaces and function overloads to enforce that both are set or not set:

interface MyProps {
  foo: string;
  bar?: number;
}
interface MyPropsWithSize extends MyProps {
  width: number;
  height: number;
}

function MyComponent(props: MyProps): JSX.Element ;
function MyComponent(props: MyPropsWithSize): JSX.Element;
function MyComponent(props: MyProps | MyPropsWithSize) {
  // return …
}

But this is a little bit overkill and would escalate in complexity very quickly if we wanted to do the same for other prop combinations. A more practical solution would be to simply tolerate omission of either width or height and pick an appropriate default.

interface MyProps {
  foo: string;
  bar?: number;
  width?: number;
  height?: number;
}

function MyComponent(props) {
  const { width = 20, height = 20 } = props;
  // OR
  const { width = props.height ?? 20, height = props.width ?? 20 } = props;
}

Use ‘children’ prop for composition

The key to building composable components in React is the children prop. It receives special treatment in JSX – anything between a component’s opening and closing tags is passed to it as the children prop. The component can then decide where in its tree these children should be rendered.

DO accept children for composition and content whenever possible.

When building component libraries, we might be inclined to avoid supporting composition in some components, often for legitimate reasons. Take, for example, a Button component. Suppose we always want a Button to have associated text for accessibility reasons (Buttons that are rendered using only an icon would move their text property to a tooltip and an aria-label). But since the text might be rendered on the screen or it might be added to an HTML attribute, we only want to allow strings. We could build our Button props like this:

interface ButtonProps {
  children: string;
  iconOnly?: boolean;
  icon?: string;
}

This would work exactly as we want – we can toggle between icon-only and icon-with-text rendering while maintaining good accessibility. But then what if someone wants to decorate their button text?

<Button icon=”danger”>
  <strong>Cancel!</strong>
</Button>

This would no longer compile because the children type is incorrect (JSX.Element is not assignable to string). The DOM would happily allow a <strong> inside a <button>, but we have prevented it because if we set iconOnly, the aria label would become [Object object].

So to avoid confusion, we might use an interface like this:

interface ButtonProps {
  children?: never; // disallow children
  iconOnly?: boolean;
  icon?: string;
  text: string;
}

Now our Button doesn’t support composition at all, but users would be less likely to pass arbitrary JSX to a prop called text. This might be an acceptable compromise, but the consequence is that our Button API is no longer composable.

Maybe there’s another compromise we can make?

interface ButtonProps {
  children?: JSX.Element;
  iconOnly?: boolean;
  icon?: string;
  text: string;
}

function Button(props: ButtonProps) {
  const content = props.children ?? props.text;
  return (
    <button {…}>{content}</button>
  )
}

In this version, we allow children to be set if needed, but still require a plain text prop for accessibility. When rendering the content, we look at children first, falling back to text. This preserves composability while enforcing accessibility, at the cost of a bit of extra complexity within our component and maybe some redundancy for consumers that specify both children and text.

Prefer component clusters over “slot” props

Certain kinds of reusable UI elements are difficult to represent with a single component, especially if some degree of freedom is necessary for users. Take, for example, a Dialog component. A naive implementation might be straightforward, but as more UX patterns emerge, we might ask for more customization. Can we disable the header? Can we put arbitrary content in the header? Can we put buttons on both sides of the footer? Etc.

Though we could support extra customization by piling on props, a more natural API might be to create a “clustered” API for our component, where a component cluster is a group of components that are designed to work together and are namespaced under a single root component.

DO prefer value types for props.
⚠️AVOID using element props to define component customization “slots”.

Here is a concrete usage example of a Dialog component that offers customization via clustering:

// ✅ Better
<Dialog open={open} onOpenChange={onOpenChange}>
  <Dialog.Header omitCloseButton>
    My fancy dialog <PopoverButton icon=”INFO”>Details go here…</PopoverButton>
  </Dialog.Header>
  <Dialog.Body>
    Content goes here
  </Dialog.Body>
  <Dialog.Footer css={{ display: ‘flex’ }}>
    <Dialog.Close>Close</Dialog.Close>
    <Dialog.Action css={{ marginLeft: ‘auto’ }} onClick={…}>Cancel</Dialog.Action>
    <Dialog.Action onClick={…}>Confirm</Dialog.Action>
  </Dialog.Footer>
</Dialog>

Every component that might be part of a Dialog is namespaced under the name Dialog, which itself might be a component (we could also alias it as Dialog.Root). These components are designed to work together seamlessly, both visually and functionally, and we indicate that to consumers by grouping them under the same namespace.

Many of the sub-components in this cluster might be considered “slots” – well-defined placeholders where we accept arbitrary content. In this case, Header, Body, and Footer are slots. Some, like Body, might be required while the rest are optional.

The actual implementation of these components might vary depending on the functional complexity. Sometimes it’s a simple matter of stitching things together with CSS, but other times it might require an implicit React Context to tie things together. That’s beyond the scope of this style guide – the important thing is to avoid exposing those kinds of implementation details to consumers.

Note that the above could be designed using props instead of component clusters, which might look something like this:

// ⛔️ Worse
<Dialog
  open={open}
  onOpenChange={onOpenChange}
  omitCloseButton
  header={
    <>
      My fancy dialog <PopoverButton icon=”INFO”>Details go here…</PopoverButton>
    </>
  }
  footer={
    <>
      <Dialog.Close>Close</Dialog.Close>
      <Dialog.Action css={{ marginLeft: ‘auto’ }} onClick={…}>Cancel</Dialog.Action>
      <Dialog.Action onClick={…}>Confirm</Dialog.Action>
    </>
  }
  footerCss={{ display: ‘flex’ }}
>
  Content goes here
</Dialog>

There is nothing technically wrong with this approach, but for a low-level component, the API surface area is too large for the amount of customization that might be desired. An API like this might be suitable as a wrapper for Dialog after a few primary archetypes have emerged, but those would commonly live at the application level.

Avoid “render” props

This is an older component API pattern that was popular in the era of class components. Rather than using composition, components would offer customization in the form of props, which would often directly override an internal render method of the same name. E.g., renderHeader, renderFooter, renderGridBody, etc.

Render props should generally not be used for new component APIs, favoring clusters and slots (described above).

⚠️AVOID render props if at all possible, favoring composition via slots.
DO use props named render* for providing alternative rendering logic when necessary.
DON’T use children as a render function.

The “Don’t use children” rule is especially important with this pattern because a) it was fairly common at one point and b) it defies expectations of most UI component APIs. children should be broadly supported (as argued above) and should only accept renderable elements. APIs that expect children to be specified as functions or objects or anything not directly renderable should be avoided.

Other blogs you might find interesting

No records found...
Mar 21, 2024

How GameAnalytics Provides Flexible Data Exploration with Imply

Learn how GameAnalytics, the leading analytics provider for the gaming industry, provides insights on over 100,000 games, 1.75 billion players, and 24 billion monthly sessions.

Learn More
Mar 04, 2024

Smart Devices, Intelligent Insights: How Rivian and Thing-it use Apache Druid for IoT Analytics

Learn how engineers and architects from electric vehicle manufacturer Rivian and smart asset management platform Thing-it use Apache Druid for their IoT analytics environments.

Learn More
Feb 21, 2024

What’s new in Imply Polaris – January 2024

At Imply, we're excited to share the latest enhancements in Imply Polaris, our real-time analytics Database-as-a-Service (DBaaS) powered by Apache Druid®. Our commitment to refining your experience with Polaris...

Learn More
Feb 21, 2024

Introducing Apache Druid 29.0

Apache Druid® is an open-source distributed database designed for real-time analytics at scale. We are excited to announce the release of Apache Druid 29.0. This release contains over 350 commits & 67 contributors.

Learn More
Feb 14, 2024

Apache Druid vs. ClickHouse

If your project needs a real-time analytics database that provides subsecond performance at scale you should consider both Apache Druid and ClickHouse. Find out how to make an informed choice.

Learn More
Jan 23, 2024

Enhancing Data Security with Role-Based Access Control in Druid and Imply

Managing user access to relevant data is a crucial aspect of any data platform. In a typical Role Based Access Control (RBAC) setup, users are assigned roles that determine their access to relevant data. We...

Learn More
Jan 16, 2024

Comparing Data Formats for Analytics: Parquet, Iceberg, and Druid Segments

In this blog, I will give you a detailed overview of each choice. We will cover key features, benefits, defining characteristics, and provide a table comparing the file formats. Dive in and explore the characteristics...

Learn More
Jan 12, 2024

Scheduling batch ingestion with Apache Airflow

This guide is your map to navigating the confluence of Airflow and Druid for smooth batch ingestion. We'll get you started by showing you how to setup Airflow and the Druid Provider and use it to ingest some...

Learn More
Dec 29, 2023

A Buyer’s Guide to OLAP Tools

How do OLAP databases work—and which one is right for you? Read this blog post to learn more about which OLAP solutions are best for different use cases.

Learn More
Dec 26, 2023

What is IoT Analytics?

Because it deals with fast-moving, real-time data, IoT analytics is uniquely challenging. Learn how to overcome these challenges and how to extract (and act on) valuable insights from IoT data.

Learn More
Dec 19, 2023

OLTP and OLAP Databases: How They Differ and Where to Use Them

Learn about the differences between analytical and transactional databases—their strengths and weaknesses, what they’re used for, and which option to choose for your own use case.

Learn More
Dec 15, 2023

Query from deep storage: Introducing a new performance tier in Apache Druid

Now, Druid offers a simpler, cost-effective solution with its new feature, Query from Deep Storage. This feature enables you to query Druid’s deep storage layer directly without having to preload all of your...

Learn More
Dec 15, 2023

How KakaoBank Uses Imply for Financial Analysis

As a mobile-first digital platform, KakaoBank accumulates a substantial amount of data. Therefore, analysts need a solution that can effectively analyze and pre-process large quantities of data, visualize the...

Learn More
Dec 14, 2023

Joins, Multi-Stage Queries, and More: Relive the Excitement of Druid Summit 2023

Druid Summit kicked off its fourth year as a global gathering of minds passionate about real-time analytics and the power of Apache Druid. This year’s event revealed a common theme: the growing significance...

Learn More
Dec 13, 2023

An Introduction to Online Analytical Processing (OLAP)

Online analytical processing (OLAP) analyzes data at scale—and provides actionable insights to organizations. Learn about how OLAP works, what a data cube is, and which OLAP product to use.

Learn More
Dec 12, 2023

Real-Time Data: What it is, Why it Matters, and More

Real-time data travels directly from the source to end users, so that it can be processed and acted on instantly. Learn all about the challenges, benefits, and best practices for real-time data.

Learn More
Dec 08, 2023

Druid vs Pinot: Choosing the best database for Real-Time Analytics

Do you want fast analytics, with subsecond queries, high concurrency, and combination of streams and batch data? If so, you want real-time analytics, and you probably want to consider the two Apache Software...

Learn More
Dec 07, 2023

What’s new in Imply Polaris – October and November 2023

At Imply, our commitment to continually improving your experience with Imply Polaris—our real-time analytics Database-as-a-Service (DBaaS) powered by Apache Druid®—is evident in recent developments. Over...

Learn More
Nov 15, 2023

Introducing Apache Druid 28.0.0

Apache Druid 28.0, an open-source database for real-time analytics, introduces Async queries, UNION ALL support, SQL WINDOW functions, enhanced ingestion features, including multi-Kafka topic support, and...

Learn More
Oct 18, 2023

Migrating Data From S3 To Apache Druid

This blog covers the rationale, advantages, and step-by-step process for data transfer from AWS s3 to Apache Druid for faster real-time analytics and querying.

Learn More
Oct 12, 2023

What’s new in Imply Polaris, our real-time analytics DBaaS  – September 2023

Every week, we add new features and capabilities to Imply Polaris. Throughout September, we've focused on enhancing your experience as you explore trials, navigate data integration, oversee data management,...

Learn More
Sep 27, 2023

Introducing incremental encoding for Apache Druid dictionary encoded columns

In this blog post we deep dive on a recent engineering effort: incremental encoding of STRING columns. In preliminary testing, it has shown to be quite promising at significantly reducing the size of segment...

Learn More
Sep 21, 2023

Migrate Analytics Data from MongoDB to Apache Druid

This blog presents a concise guide on migrating data from MongoDB to Druid. It includes Python scripts to extract data from MongoDB, save it as CSV, and then ingest it into Druid. It also touches on maintaining...

Learn More
Sep 21, 2023

How Druid Facilitates Real-Time Analytics for Mass Transit

Mass transit plays a key role in reimagining life in a warmer, more densely populated world. Learn how Apache Druid helps power data and analytics for mass transit.

Learn More
Sep 19, 2023

Migrate Analytics Data from Snowflake to Apache Druid

This blog outlines the steps needed to migrate data from Snowflake to Apache Druid, a platform designed for high-performance analytical queries. The article covers the migration process, including Python scripts...

Learn More
Sep 15, 2023

Apache Kafka, Flink, and Druid: Open Source Essentials for Real-Time Data Applications

Apache Kafka, Flink, and Druid, when used together, create a real-time data architecture that eliminates all these wait states. In this blog post, we’ll explore how the combination of these tools enables...

Learn More
Sep 11, 2023

Visualizing Data in Apache Druid with the Plotly Python Library

In today's data-driven world, making sense of vast datasets can be a daunting task. Visualizing this data can transform complicated patterns into actionable insights. This blog delves into the utilization of...

Learn More
Sep 05, 2023

Bringing Real-Time Data to Solar Power with Apache Druid

In a rapidly warming world, solar power is critical for decarbonization. Learn how Apache Druid empowers a solar equipment manufacturer to provide real-time data to users, from utility plant operators to homeowners

Learn More
Sep 05, 2023

When to Build (Versus Buy) an Observability Application

Observability is the key to software reliability. Here’s how to decide whether to build or buy your own solution—and why Apache Druid is a popular database for real-time observability

Learn More
Aug 29, 2023

How Innowatts Simplifies Utility Management with Apache Druid

Data is a key driver of progress and innovation in all aspects of our society and economy. By bringing digital data to physical hardware, the Internet of Things (IoT) bridges the gap between the online and...

Learn More
Aug 14, 2023

Three Ways to Use Apache Druid for Machine Learning Workflows

An excellent addition to any machine learning environment, Apache Druid® can facilitate analytics, streamline monitoring, and add real-time data to operations and training

Learn More
Aug 11, 2023

Introducing Apache Druid 27.0.0

Apache Druid® is an open-source distributed database designed for real-time analytics at scale. Apache Druid 27.0 contains over 350 commits & 46 contributors. This release's focus is on stability and scaling...

Learn More
Aug 10, 2023

Unleashing Real-Time Analytics in APJ: Introducing Imply Polaris on AWS AP-South-1

Imply, the company founded by the original creators of Apache Druid, has exciting news for developers in India seeking to build real-time analytics applications. Introducing Imply Polaris, a powerful database-as-a-Service...

Learn More
Aug 03, 2023

Embedding Visualizations using React and Express

In this guide, we will walk you through creating a very simple web app that shows a different embedded chart for each user selected from a drop-down. While this example is simple it highlights the possibilities...

Learn More
Jul 25, 2023

Apache Druid: Making 1000+ QPS for Analytics Look Easy

This 2-part blog post explores key technical considerations to support high QPS for analytics and the strengths of Apache Druid

Learn More
Jul 25, 2023

Things to Consider When Scaling Analytics for High QPS

This 2-part blog post explores key technical considerations to support high QPS for analytics and the strengths of Apache Druid

Learn More
Jul 20, 2023

Automate Streaming Data Ingestion with Kafka and Druid

In this blog post, we explore the integration of Kafka and Druid for data stream management and analysis, emphasizing automatic topic detection and ingestion. We delve into the creation of 'Ingestion Spec',...

Learn More
Jul 12, 2023

Schema Auto-Discovery with Apache Druid

This guide explores configuring Apache Druid to receive Kafka streaming messages. To demonstrate Druid's game-changing automatic schema discovery. Using a real-world scenario where data changes are handled...

Learn More
Jul 11, 2023

What’s new in Imply Polaris – Q2 2023

Imply Polaris, our ever-evolving Database-as-a-Service, recently focused on global expansion, enhanced security, and improved data handling and visualization. This fully managed cloud service, based on Apache...

Learn More
Jun 06, 2023

Introducing hands-on developer tutorials for Apache Druid

The objective of this blog is to introduce the new set of interactive tutorials focused on the Druid API fundamentals. These tutorials are available as Jupyter Notebooks and can be downloaded as a Docker container.

Learn More
Jun 01, 2023

Introducing Schema Auto-Discovery in Apache Druid

In this blog article I’ll unpack schema auto-discovery, a new feature now available in Druid 26.0, that enables Druid to automatically discover data fields and data types and update tables to match changing...

Learn More
May 30, 2023

Exploring Unnest in Druid

Druid now has a new function, Unnest. Unnest explodes an array into individual elements. This blog contains design methodology and examples for this new Unnest function both from native and SQL binding perspectives.

Learn More
May 28, 2023

What’s new in Imply Polaris – Our Real-Time Analytics DBaaS

Every week we add new features and capabilities to Imply Polaris. This month, we’ve expanded security capabilities, added new query functionality, and made it easier to monitor your service with your preferred...

Learn More
May 24, 2023

Introducing Apache Druid 26.0

Apache Druid® 26.0, an open-source distributed database for real-time analytics, has seen significant improvements with 411 new commits, a 40% increase from version 25.0. The expanded contributor base of 60...

Learn More
May 22, 2023

ACID and Apache Druid

ACID and Druid, an interesting dive into some of the Druid capabilities in the light of ACID compliance

Learn More
May 21, 2023

How to Build a Sentiment Analysis Application with ChatGPT and Druid

Leveraging ChatGPT for sentiment analysis, when combined with Apache Druid, offers results from large data volumes. This integration is easily achievable, revealing valuable insights and trends for businesses...

Learn More
May 21, 2023

Snowflake and Apache Druid

In this blog, we will compare Snowflake and Druid. It is important to note that reporting data warehouses and real-time analytics databases are different domains. Choosing the right tool for your specific requirements...

Learn More
May 20, 2023

Learn how to achieve sub-second responses with Apache Druid

Learn how to achieve sub-second responses with Apache Druid. This article is an in-depth look at how Druid resolves queries and describes data modeling techniques that improve performance.

Learn More
May 19, 2023

Apache Druid – Recovering Dropped Segments

Apache Druid uses load rules to manage the ageing of segments from one historical tier to another and finally to purge old segments from the cluster. In this article, we’ll show what happens when you make...

Learn More
May 18, 2023

Real-Time Analytics: Building Blocks and Architecture

This blog identifies the key technical considerations for real-time analytics. It answers what is the right data architecture and why. It spotlights the technologies used at Confluent, Reddit, Target and 1000s...

Learn More
May 17, 2023

Transactions Come and Go, but Events are Forever

For decades, analytics has focused on Transactions. While Transactions are still important, the future of analytics is understanding Events.

Learn More
May 16, 2023

What’s new in Imply Polaris – Our Real-Time Analytics DBaaS

This blog explains some of the new features, functionality and connectivity added to Imply Polaris over the last two months. We've expanded ingestion capabilities, simplified operations and increased reliability...

Learn More
May 15, 2023

Elasticsearch and Druid

This blog will help you understand what Elasticsearch and Druid do well and will help you decide whether you need one or both to reach your goals

Learn More
May 14, 2023

Wow, that was easy – Up and running with Apache Druid

The objective of this blog is to provide a step-by-step guide on setting up Druid locally, including the use of SQL ingestion for importing data and executing analytical queries.

Learn More
May 13, 2023

Top 7 Questions about Kafka and Druid

Read on to learn more about common questions and answers about using Kafka with Druid.

Learn More
May 12, 2023

Tales at Scale Podcast Kicks off with the Apache Druid Origin Story

Tales at Scale cracks open the world of analytics projects and shares stories from developers and engineers who are building analytics applications or working within the real-time data space. One of the key...

Learn More
May 11, 2023

Real-time Analytics Database uses partitioning and pruning to achieve its legendary performance

Apache Druid uses partitioning (splitting data) and pruning (selecting subset of data) to achieve its legendary performance. Learn how to use the CLUSTERED BY clause during ingestion for performance and high...

Learn More
May 10, 2023

Easily embed analytics into your own apps with Imply’s DBaaS

This blog explains how developers can leverage Imply Polaris to embed robust visualization options directly into their own applications without them having to build a UI. This is super important because consuming...

Learn More
May 09, 2023

Building an Event Analytics Pipeline with Confluent Cloud and Imply’s real time DBaaS, Polaris

Learn how to set up a pipeline that generates a simulated clickstream event stream and sends it to Confluent Cloud, processes the raw clickstream data using managed ksqlDB in Confluent Cloud, delivers the processed...

Learn More
May 08, 2023

Real time DBaaS comes to Europe

We are excited to announce the availability of Imply Polaris in Europe, specifically in AWS eu-central-1 region based in Frankfurt. Since its launch in March 2022, Imply Polaris, the fully managed Database-as-a-Service...

Learn More
May 07, 2023

Stream big, think bigger—Analyze streaming data at scale in 2023

Imply is predicting the next "big thing" in 2023 will be analyzing streaming data in real time (and Druid is built for just that!)

Learn More
May 07, 2023

Should You Build or Buy Security Analytics for SecOps?

When should you build—or buy—a security analytics platform for your environment? Here are some common considerations—and how Apache Druid is the ideal foundation for any in-house security solution.

Learn More
May 05, 2023

Introducing Apache Druid 25.0

Apache Druid 25.0 contains over 293 updates from over 56 contributors.

Learn More
May 03, 2023

Druid and SQL syntax

This is a technical blog, which summarises the process of extending the Druid's SQL grammar for ingestion and delves into the nitty gritty of Calcite.

Learn More
May 02, 2023

Native support for semi-structured data in Apache Druid

Describes a new feature- ingest complex data as is into Druid- massive improvement in developer productivity

Learn More
May 01, 2023

Real-Time Analytics with Imply Polaris: From Setup to Visualization

Imply Polaris offers reduced operational overhead and elastic scaling for efficient real-time analytics that helps you unlock your data's potential.

Learn More
May 01, 2023

Datanami Award

Apache Druid won Datanami's 2022 Readers’ and Editors’ Choice Awards for Reader's Choice "Best Data and AI Product or Technology: Analytics Database".

Learn More
Apr 30, 2023

Alerting and Security Features in Polaris

Describes new features - alerts and some security features- and how Imply customers can leverage it

Learn More
Apr 29, 2023

Ingestion from Amazon Kinesis and S3 into Imply Polaris

Imply Polaris now supports data ingestion from Amazon Kinesis and Amazon S3

Learn More
Apr 27, 2023

Getting the Most Out of your Data

Ingesting data from one table to another is easy and fast in Imply Polaris!

Learn More
Apr 26, 2023

Combating financial fraud and money laundering at scale with Apache Druid

Learn how Apache Druid enables financial services firms and FinTech companies to get immediate insights from petabytes-plus data volumes for anti-fraud and anti-money laundering compliance.

Learn More
Apr 26, 2023

What’s new in Imply – December 2022

This is a what's new to Imply in Dec 2022. We’ve added two new features to Imply Polaris to make it easier for your end users to take advantage of real-time insights.

Learn More
Apr 25, 2023

What’s New in Imply Polaris – November 2022

This blog provides an overview for the new features, functionality, and connectivity to Imply Polaris for November 2022.

Learn More
Apr 24, 2023

Imply Pivot delivers the final mile for modern analytics applications

This blog is focused on how Imply Pivot delivers the final mile for building an anlaytics app. It showcases two customer examples - Twitch and ironsource.

Learn More
Apr 23, 2023

Why Analytics Need More than a Data Warehouse

For decades, analytics has been defined by the standard reporting and BI workflow, supported by the data warehouse. Now, 1000s of companies are realizing an expansion of analytics beyond reporting, which requires...

Learn More
Apr 21, 2023

Why Open Source Matters for Databases

Apache Druid is at the heart of Imply. We’re an open source business, and that’s why we’re committed to making Druid the best open source database for modern analytics applications

Learn More
Apr 20, 2023

Ingestion from Confluent Cloud and Kafka in Polaris

How to ingest data into Imply Polaris from Confluent Cloud and from Apache Kafka

Learn More
Apr 18, 2023

What Makes a Database Built for Streaming Data?

For an analytics app to handle real-time, streaming sources, it must be built for streaming data. Druid has 3 essential features for stream data.

Learn More
Oct 12, 2022

SQL-based Transformations and JSON Columns in Imply Polaris

You can easily do data transformations and manage JSON data with Imply Polaris, both using SQL.

Learn More
Oct 06, 2022

Approximate Distinct Counts in Imply Polaris

When it comes to modern data analytics applications, speed is of the utmost importance. In this blog we discuss two approximation algorithms which can be used to greatly enhance speed with only a slight reduction...

Learn More
Sep 20, 2022

The next chapter for Imply Polaris: celebrating 250+ accounts, continued innovation

Today we announced the next iteration of Imply Polaris, the fully managed Database-as-a-Service that helps you build modern analytics applications faster, cheaper, and with less effort. Since its launch in...

Learn More
Sep 20, 2022

Introducing Imply’s Total Value Guarantee for Apache Druid

Apache Druid 24.0 contains 450 updates and new features, major performance enhancements, bug fixes, and major documentation improvements

Learn More
Sep 16, 2022

Introducing Apache Druid 24.0

Apache Druid 24.0 contains 450 updates and new features, major performance enhancements, bug fixes, and major documentation improvements

Learn More
Aug 16, 2022

Using Imply Pivot with Druid to Deduplicate Timeseries Data

Imply Pivot offers multi step aggregations, which is valuable for timeseries data where measures are not evenly distributed in time.

Learn More
Jul 21, 2022

A Look Under the Surface at Polaris Security

We have taken a security-first approach in building the easiest real-time database for modern analytics applications.

Learn More
Jul 14, 2022

Upserts and Data Deduplication with Druid

A look at what can be done with Druid for upserts and data deduplication.

Learn More
Jul 01, 2022

What Developers Can Build with Apache Druid

We obviously talk a lot about #ApacheDruid on here. But what are folks actually building with Druid? What is a modern analytics application, exactly? Let's find out

Learn More
Jun 29, 2022

When Streaming Analytics… Isn’t

Nearly all databases are designed for batch processing, which leaves three options for stream analytics.

Learn More
Jun 29, 2022

Apache Druid vs. Snowflake

Elasticity is important, but beware the database that can only save you money when your application is not in use. The best solution will have excellent price-performance under all conditions.

Learn More
Jun 22, 2022

Druid 0.23 – Features And Capabilities For Advanced Scenarios

Many of Druid’s improvements focus on building a solid foundation, including making the system more stable, easier to use, faster to scale, and better integrated with the rest of the data ecosystem. But for...

Learn More
Jun 22, 2022

Introducing Apache Druid 0.23

Apache Druid 0.23.0 contains over 450 updates, including new features, major performance enhancements, bug fixes, and major documentation improvements.

Learn More
Jun 10, 2022

Druid Architecture & Concepts

In a world full of databases, learn how Apache Druid makes real-time analytics apps a reality in this Whitepaper from Imply

Learn More
May 25, 2022

3 decisions that shaped the Polaris UI

Imply Polaris is a fully managed database-as-a-service for building realtime analytics applications. John is the tech lead for the Polaris UI, known internally as the Unified App. It began with a profound question:...

Learn More
May 19, 2022

How Imply Polaris takes a security-first approach

A primer for developers on security tools and controls available in Imply Polaris

Learn More
May 17, 2022

Imply Raises $100MM in Series D funding

There is a new category within data analytics emerging which is not centered in the world of reports and dashboards (the purview of data analysts and data scientists), but instead centered in the world of applications...

Learn More
May 11, 2022

Imply Named “Cool Database Vendor” by CRN

There can’t be one database good at everything. When it comes to real-time analytics, you need a database built for it.

Learn More
May 11, 2022

Living the Stream

We are in the early stages of a stream revolution, as developers build modern transactional and analytic applications that use real-time data continuously delivered.

Learn More
May 02, 2022

Migrating Data from ClickHouse to Imply Polaris

In this blog, we’ll review the simple steps to export data from ClickHouse in a format that is easy to ingest into Polaris.

Learn More
Apr 06, 2022

Java Keytool, TLS, and Zookeeper Security

Lean the basics of Public Key Infrastructure (PKI) as it relates to Druid and Zookeeper security.

Learn More

Let us help with your analytics apps

Request a Demo