DEV Community: David Herbert💻🚀

Figma to React: How Kombai Finally Solved My Frontend Workflow

David Herbert💻🚀 — Fri, 28 Nov 2025 15:11:06 +0000

As a frontend developer, much of my job is converting Figma designs into React code—a process that’s both meticulous and repetitive. Every pixel, color, font weight, spacing, and padding has to match the designer’s intent exactly. It can be satisfying when it comes together, but it’s also a huge time sink.

Naturally, to save time and speed up my workflow, I’ve tried out various tools that promise to automate the conversion from Figma to React. But most of them ended up creating more cleanup work than they saved. Then I tried Kombai — and the difference was immediately clear.

Unlike most generic code generators I’ve tried, Kombai is the only frontend-specific AI agent I can genuinely vouch for that actually understands frontend development and produces code I’d write myself, not code I need to rewrite.

Why Figma to React tools didn’t work for me

Let’s be honest, Figma-to-React tools have existed for years, but most can’t handle real-world frontend needs or the realities of production code. After trying most of the popular solutions available, some of the problems I consistently faced with these tools:

Hardcoded <div>s everywhere

This was the most frustrating issue I ran into. When a Figma design is given to these tools, they translate what’s visible literally. If your design shows 10 customer orders, you get code that hardcodes those 10 orders directly into the markup as <div>s.

What I’d typically get:

<div className=”orders-table”>
  <div className=”order-row”>
    <div className=”customer-name”>Gabriel Esu</div>
    <div className=”order-id”>#12345</div>
    <div className=”price”>$2,499.99</div>
    <div className=”status”>Paid</div>
  </div>
  <div className=”order-row”>
    <div className=”customer-name”>Jane Smith</div>
    <div className=”order-id”>#12346</div>
    <div className=”price”>$29.99</div>
    <div className=”status”>Pending</div>
  </div>
  {/* Every single row hardcoded like this... */}
</div>

Everything’s just baked into the component, including details that should typically come from an API, like payment info.

This is fine for static mockups, but impractical for real production apps that need dynamic data. It also makes it impossible to reuse the component with different data. I’d end up spending hours refactoring everything to separate data from presentation—might as well code it from scratch.

Bad component structure

These tools organize components by Figma layer grouping, not logical boundaries or reusability. They just follow whatever layer grouping exists in Figma and generate component structures that don’t always translate well into logical component hierarchies.

For example, a dashboard grouped in Figma as “Header,” “Main Content,” and “Sidebar” becomes one giant monolithic component mirroring those groups—impossible to reuse or maintain.

export default function Dashboard() {
  return (
    <div className=”dashboard”>
      {/* Everything dumped in one component */}
      <div className=”header-section”>
        <div className=”logo”>...</div>
        <div className=”search-bar”>
          <input type=”text” placeholder=”Search...” />
          <button>Search</button>
        </div>        

    <div className=”user-menu”>
          <img src=”avatar.png” />
          <div className=”dropdown”>
            <div>Profile</div>
            <div>Settings</div>
            <div>Logout</div>
          </div>
        </div>
      </div>

      <div className=”main-content”>
        <div className=”stats-cards”>
          <div className=”card”>...</div>
          <div className=”card”>...</div>
          <div className=”card”>...</div>
        </div>
        <div className=”orders-table”>
          {/* 50+ lines of table markup */}
        </div>
        <div className=”pagination”>...</div>
      </div>

      <div className=”sidebar”>
        {/* Navigation, filters, etc. */}
      </div>
    </div>
  );
}

It’s a nightmare: a 300-line component you can’t reuse or test in isolation. Any change means digging through hundreds of lines of code.

What’s worse is that it didn’t even extract the most obvious reusable pieces. The stats cards are clearly the same component repeated three times with different data, but instead of creating a <StatsCard /> component, the tool just copied and pasted the markup three times.

The result: code that ignores React’s modularity is hard to maintain and impossible to reuse. A proper component tree separates reusable units, not just frame layers.

Didn’t follow tech stack-specific best practices

Most Figma-to-React generators are stack-agnostic: they ignore TypeScript types, prop definitions, naming patterns, and linting rules. They don’t know your preferred libraries, folder structure, coding conventions, or how your team handles props and state—so the code always feels generic and disconnected.

// What you get from most tools
function Button(props: any) {
  return <button style={{ background: ‘#0066FF’ }}>{props.text}</button>;
}

// What you actually need
interface ButtonProps {
  variant: ‘primary’ | ‘secondary’ | ‘danger’;
  size?: ‘sm’ | ‘md’ | ‘lg’;
  disabled?: boolean;
  onClick?: () => void;
  children: React.ReactNode;
}

function Button({ 
  variant, 
  size = ‘md’, 
  disabled = false, 
  onClick, 
  children 
}: ButtonProps) {
  return (
    <button 
      className={`btn btn-${variant} btn-${size}`}
      disabled={disabled}
      onClick={onClick}
    >
      {children}
    </button>
  );
}

Proper TypeScript types and clear prop interfaces matter in real projects. Generic tools skip these entirely.

Limited styling options

Most Figma-to-React code tools supported only a handful of styling options. Typically just CSS Modules and maybe Material-UI. That’s it. Want Tailwind, Styled Components, or Emotion? You’re out of luck. Even when a styling option is “supported,” the implementation is inconsistent. No shared theme, no design tokens, no variants—components are styled differently all over.

The worst part was that my team already had established styling conventions. We used Tailwind with a custom theme configuration, specific utility patterns, and component variants. These tools ignored all of that, producing generic styles that don’t match our codebase.

I’d spend hours replacing inline styles, fixing spacing, and restructuring components—work that should have been done automatically.

No reuse of existing repo components

These tools had zero awareness of my existing codebase. When they generated code for a new design, they’d create brand-new components from scratch. Meanwhile, my existing reusable components were sitting right there in the repo, unused.

This happened with everything: we had a <Button /> component with variants, size options, and loading states; a custom <Modal /> component with our company’s specific styling and focus management. But these tools didn’t reuse any of the existing components; they generated new ones with none of these functionalities.

They weren’t aware of our design system either. We had design tokens for colors, spacing, typography, and shadows. Every component in our repo used these tokens. But the generated code would contain hard-coded values, resulting in massive inconsistencies.

Bad Code Fidelity

Almost every tool had code fidelity issues. The generated layout looked fine in the preview, but the underlying HTML structure made no semantic sense. You’d find nested containers wrapped around single elements for no reason, or siblings that should be grouped placed in different parent divs. The hierarchy often didn’t match the visual structure at all.

This matters because a poorly structured DOM makes everything harder. Styling becomes a pain, and layouts break at different screen sizes. The biggest culprit was absolute positioning. Most tools default to positioning elements absolutely because it’s the easiest way to match pixel-perfect coordinates from Figma. They grab the x and y values from the design file and translate them directly into CSS.

.container {
  position: relative;
  width: 1440px;
  height: 900px;
}

.sidebar {
  position: absolute;
  left: 0;
  top: 0;
  width: 250px;
  height: 100%;
}

.header {
  position: absolute;
  left: 250px;
  top: 0;
  width: 1190px;
  height: 80px;
}

.main-content {
  position: absolute;
  left: 250px;
  top: 80px;
  width: 1190px;
  height: 820px;
}

This might match the design at 1440px, but when you resize the window, everything overlaps or breaks because they’re locked to fixed positions. Modern CSS layouting techniques like flexbox and grid exist specifically to solve this problem, yet most tools ignore them completely.

Typography inconsistencies were another constant headache. A design might specify Inter with a weight of 600 and a size of 16px, but the tool would pick a completely different font family, weight, and size because it couldn’t access the exact one from Figma.

Colors were no different. The generated code would often be close enough that you might not notice immediately, but wrong on closer inspection. Images also presented their own set of problems; they often used the wrong images, placeholders, or were rendered at the wrong dimensions.

Even when fidelity was good, code quality would be so poor that you risk breaking fidelity trying to fix it.

No interactivity

Most tools treat Figma designs like screenshots, translating the visuals to static code with no interactivity. A search bar would just be a div with an icon and some placeholder text. No input field. No onChange handler. Nothing is actually functional.

// What gets generated
function SearchBar() {
  return (
    <div className=”search”>
      <img src=”search-icon.svg” alt=”search” />
      <div className=”placeholder-text”>Search by product #, name, date...</div>
    </div>
  );
}

They don’t understand that a magnifying glass icon next to text is universally recognized as a search field, and can’t infer the role of UI elements from their visual appearance. They just reproduce rectangles, not functionality.

Dropdowns are worse—the tools would see a button labeled “More Actions,” but the generated code would do nothing—no menu, no options, just a static button that looks interactive but isn’t. I’d end up rebuilding every interactive element myself, making the generated code just a wireframe that requires the same amount of work as coding it from scratch.

Friction in saving code

Most Figma-to-React tools didn’t work inside my IDE. They ran as Figma plugins or in separate browser windows, which meant a tedious workflow just to get generated code into my project

First, I’d generate the code, download a zip or copy to clipboard, navigate to the correct directory, create the file, paste, and save. Then I’d fix import issues manually, move any referenced images or icons to the right assets folder, and update all paths. A complex component could take 10-15 minutes to integrate.

The constant context switching was the worst part. I’d be in my IDE, need a component from a design, switch to the browser, generate code, download it, switch back, navigate the file tree, paste, fix imports, move assets, fix paths, and test. Every new component meant repeating the entire cycle.

General-purpose agents help, but

General-purpose AI agents like Claude and ChatGPT feel like they should solve these problems. They’re smarter, more flexible, and reason about code in ways Figma-to-code tools can’t. They do work better most of the time, but they still lack understanding of my codebase, so the outcome wasn’t as good as I expected.

Bad Code Fidelity

General-purpose AI agents avoid the worst offenses. They don’t spam absolute positioning or generate nonsensical div structures like generic Figma-to-React tools. But they still produce code that breaks on resize, with colors slightly off and fonts that don’t match.

The issue shifts from “terrible structure” to “slightly wrong decisions.” An agent would use flexbox correctly but ignore responsiveness, or hallucinate aspects of the design entirely. It’d add proper semantic HTML but miss the exact border radius or shadow. Colors are close but not pixel-perfect. The layout works for specific viewport sizes.

It’s less obviously broken, which makes it harder to catch. Everything looks good until you compare side-by-side with the design and notice the heading is 18px instead of 20px, the gap is 16px instead of 24px, and the card shadow is entirely different.

No interactivity

Same problem. Agents treated Figma files like static screenshots. They could describe what they saw, but couldn’t infer that a magnifying glass icon meant a search input should actually search, or that a down arrow meant a dropdown should expand.

When you look at a design, you intuitively understand the behavior. A hamburger icon opens a menu. A card with a hover state responds to mouse movement. But AI agents only see pixels and layers, so I still had to add all the interactivity myself or prompt separately outside the scope of the design.

Limited use of existing repo components

This is where AI agents should shine compared to Figma-to-code tools, and they do, but only barely. They have search tools and can find existing components in your codebase. But their understanding is shallow.

They’d find my <Button /> component and see that it exists with props like variant and size. But they don’t understand when to use it or that every button in the app should use this component.

// My existing Button component
<Button variant=”primary” icon={<SaveIcon />}>
  Save Changes
</Button>

// What the AI agent generates in the same file
<button className=”icon-btn”>
  <TrashIcon />
  Delete
</button>

This happens because agents don’t have the same intuition that a human developer builds over time through working in a codebase. A developer who’s worked in a codebase for a few weeks knows “we always use the Button component” or “we have a Card wrapper for everything.” They’ve internalized the patterns.

AI agents search cold each time, trying to piece together what exists without understanding the intent behind your architecture. They treat each generation as an independent task and never build that cumulative understanding of “how we do things here.”

Asset handling

This is where things get messy, especially with Figma integrations. When using something like the Figma MCP server, the agent can access images from Figma files, but the implementation is problematic. It generates code with image sources pointing to localhost URLs.

<img src=”http://localhost:3000/figma-image-xyz.png” alt=”hero” />

This works while developing locally with the MCP server running. But the moment I stop the server, push the code, or deploy to production, all images break. I’m left with broken references that need manual replacement.

Even when images load locally, they often render at the wrong dimensions. The Figma design might show a 16:9 hero image, but the agent generates a fixed width and height, squashing it to 4:3. There’s also no consideration for asset organization. In a real project, icons go in an icons folder, images in public/images, or maybe through a CDN. The agent just dumps URLs inline wherever needed.

Kombai solved the pain points

Kombai was one of the last agents I tried, but it turned out to be the best. Unlike general-purpose AI models, Kombai is purpose-built for front-end engineers, and it felt like the first tool that understood what front-end development actually is.

I first used Kombai while building an e-commerce application, then again for a job-application tracker. Despite the projects being completely different, my experience remained consistent.

Proper data structures, not hardcoded markup

The first thing I noticed was that Kombai didn’t hardcode data into JSX. When I gave it a design with an orders table, it generated proper data structures and mapped over them.

interface Order {
  id: string;
  customerName: string;
  price: number;
  status: ‘Paid’ | ‘Pending’ | ‘Cancelled’;
}

function OrdersTable({ orders }: { orders: Order[] }) {
  return (
    <div className=”orders-table”>
      {orders.map((order) => (
        <div key={order.id} className=”order-row”>
          <div className=”customer-name”>{order.customerName}</div>
          <div className=”order-id”>#{order.id}</div>
          <div className=”price”>${order.price.toFixed(2)}</div>
          <div className=”status”>{order.status}</div>
        </div>
      ))}
    </div>
  );
}

The component was immediately reusable. I could pass any array of orders, and it would render them. No refactoring needed. The TypeScript interface was already defined, the data was properly typed, and the component expected props instead of having everything baked in.

This extended to everything: product cards accepted product data, user profiles took user objects, stats dashboards mapped over metrics arrays. Every component was built from the start to handle dynamic data.

Component structure that makes sense

Kombai didn’t just mirror the Figma layer structure. It actually thought about how components should be organized in React.

For the job application portal, I gave it a waitlist Figma design to implement, instead of one massive component, Kombai broke it into logical, reusable pieces:

Each component had a single responsibility and could be imported and used anywhere. The structure matched how I’d actually architect it myself, even down to how it implemented the route and separated the route content from regular component elements.

It also did the same in my e-commerce project:

import { createRouter, createRoute, createRootRoute, Outlet } from ‘@tanstack/react-router’;
import { Box, Group } from ‘@mantine/core’;
import Sidebar from ‘./components/Sidebar/Sidebar’;
import Header from ‘./components/Header/Header’;
import OrdersPage from ‘./pages/OrdersPage’;
import OrderDetailsPage from ‘./pages/OrderDetailsPage’;
import { mockRootProps } from ‘./data/ordersMockData’;

const rootRoute = createRootRoute({
  component: () => (
    <Group gap={0} align=”flex-start” wrap=”nowrap”>
      <Sidebar teamMembers={mockRootProps.teamMembers} />
      <Box style={{ marginLeft: ‘256px’, width: ‘calc(100% - 256px)’ }}>
        <Header 
          currentTime={mockRootProps.currentTime} 
          userAvatar={mockRootProps.currentUser.avatar} 
        />
        <Outlet />
      </Box>
    </Group>
  ),
});

This is exactly how I would structure it myself. Clean, modular, and easy to understand.

Proper mock data separation

Kombai created a dedicated file, mockData.ts, that stores all the mock data for the project based on the design’s raw data. It includes details such as mock user profiles, analytics data, payment info, application lists, and stats summaries.

import type { Application, Stats, UserProfile } from “../types”;

export const mockUser: UserProfile = {
  name: “Snow”,
  avatar: “/avatar-snow.svg”,
  hasNotifications: true,
};

export const mockStats: Stats = {
  totalApplications: 72,
  totalApplicationsChange: 2.7,
  totalInterviews: 7,
  totalInterviewsChange: -2.7,
  responseRate: 28,
  responseRateChange: 2.7,
};

export const mockApplications: Application[] = [
  {
    id: “1”,
    jobTitle: “Product Designer”,
    companyName: “Moniepoint MFB”,
    companyLogo: “/company-stripe.jpg”,
    location: “Remote”,
    status: “interviewing”,
    lastUpdated: new Date(”2025-07-26T09:14:00”),
    createdAt: new Date(”2025-07-25”),
  },
  {
    id: “2”,
    jobTitle: “Senior UX Designer”,
    companyName: “Moniepoint MFB”,
    companyLogo: “/company-stripe.jpg”,
    location: “Remote”,
    status: “not_moving_forward”,
    lastUpdated: new Date(”2025-07-26T09:14:00”),
    createdAt: new Date(”2025-07-25”),
  },
//  ...more mock applications
];

This meant I could later connect the same UI to a real API by simply replacing the mock file. No UI logic needed to change. This is exactly how production-ready code should be structured.

Tech stack integrity, and follows React best practices

Kombai was able to scan my codebase and understand my tech stack, with the added flexibility to edit it or set it up myself.

It generated proper TypeScript interfaces, followed React conventions, and produced code that looked like it belonged in my project.

interface ButtonProps {
  variant: ‘primary’ | ‘secondary’ | ‘danger’;
  size?: ‘sm’ | ‘md’ | ‘lg’;
  disabled?: boolean;
  loading?: boolean;
  onClick?: () => void;
  children: React.ReactNode;
}

function Button({ 
  variant, 
  size = ‘md’, 
  disabled = false,
  loading = false,
  onClick, 
  children 
}: ButtonProps) {
  return (
    <button 
      className={`btn btn-${variant} btn-${size}`}
      disabled={disabled || loading}
      onClick={onClick}
    >
      {loading ? <Spinner /> : children}
    </button>
  );
}

Proper TypeScript types. Sensible prop defaults. Even handling for loading states. This wasn’t generic code that needed cleanup; it was production-ready.

Styling flexibility

Kombai, let me choose how I want the styles generated. I could use Tailwind, CSS Modules, Styled Components, or even vanilla CSS. More importantly, it respected my existing styling conventions.

When I selected Tailwind as my styling option, Kombai generated code using my project’s existing utility classes and design tokens:

function Card({ title, description }: CardProps) {
  return (
    <div className=”rounded-lg border bg-(--bg-dark) border-gray-200 bg-white p-6 shadow-sm”>
      <h3 className=”text-lg text-(--text-primary) font-semibold “>{title}</h3>
      <p className=”mt-2 text-sm text-gray-600”>{description}</p>
    </div>
  );
}

The colors used are our existing Tailwind theme, and even the spacing values (p-6, mt-2) matched our design system. The component looked consistent with the rest of the codebase without any manual adjustments, which is more than I can say for most of the other Figma-to-React tools I’ve tried in the past.

Actually uses existing components

This was the game-changer. Kombai understood my codebase and reused existing components instead of recreating them. When I asked it to build a new page or component, it searched my repo, found my <Button /> component, and used it consistently throughout:

function QuickSettings() {
  return (
    <div className=”settings-page”>
      <div className=”settings-header”>
        <h1>Account Settings</h1>
        <Button variant=”primary” icon={<SaveIcon />}>
          Save Changes
        </Button>
      </div>

      <div className=”settings-actions”>
        <Button variant=”secondary”>Cancel</Button>
        <Button variant=”danger” icon={<TrashIcon />}>
          Delete Account
        </Button>
      </div>
    </div>
  );
}

Every button used my existing <Button /> component. It recognized that my component handled icons through a prop, so it used that instead of creating inline button elements. It understood the variant system and picked appropriate variants for different actions.

The same happened with other components. It found my <Modal />, <Input />, and <Select /> components and used them properly. It felt like working with another developer who knew the codebase, not a tool that was seeing my project for the first time.

Interactivity built-in

Kombai didn’t treat designs as static screenshots. It inferred behavior from visual cues and added proper interactivity. That search bar I mentioned earlier? Here’s what Kombai generated for a page that had that, along with a date range picker filter:

The search bar wasn’t just a div with placeholder text. It was a fully functional search component with debouncing, loading states, and proper result handling. Kombai recognized the visual pattern of a search interface and implemented the behavior that pattern implies.

The <DateRangePicker/> worked the same way, with a fully functional date range picker, click-outside behavior, proper positioning, and keyboard navigation support. The kind of polish that usually requires multiple iterations to get right.

Code fidelity that actually matches

The generated code matched the design pixel-perfectly. But unlike other tools, it did so using proper CSS techniques.

function DashboardLayout() {
  return (
    <div className=”flex min-h-screen”>
      <Sidebar className=”w-64 border-r border-gray-200” />

      <div className=”flex flex-1 flex-col”>
        <Header className=”h-16 border-b border-gray-200” />

        <main className=”flex-1 overflow-y-auto p-6”>
          <div className=”mx-auto max-w-7xl”>
            {children}
          </div>
        </main>
      </div>
    </div>
  );
}

Flexbox for layout instead of absolute positioning. Proper responsive patterns. The layout worked across all screen sizes. Font weights, sizes, colors, spacing—everything matched the Figma design exactly as I wanted. There were a few instances I had to make a minor tweak or ask it to fix something, but fortunately, it does have the ability to track and autofix issues on its own.

Seamless workflow integration

Kombai worked directly in my IDE through its VS Code extension. No context switching, no downloading zip files, no manually fixing import paths.

I’d select a Figma frame, run the Kombai command in VS Code, and the component appeared in my project with all imports already configured. If the component used icons or images, they were automatically saved to the correct directories with the correct paths.

// All imports worked immediately
import { Button } from ‘@/components/ui/Button’;
import { Modal } from ‘@/components/ui/Modal’;
import { SearchIcon } from ‘@/components/icons’;
import { useOrders } from ‘@/hooks/useOrders’;

The component was also created in the right location, following my project’s folder structure. It respected my import aliases. It even used my existing custom hooks when appropriate. There was no friction between generating code and actually using it.

After finishing the project, I asked Kombai to review the page’s performance and suggest improvements.

It identified key performance issues and recommended changes that significantly improved speed and responsiveness. The loading time improved by 60%, the bundle size dropped by 52%, and overall interactivity and rendering performance improved by roughly 70–80%. It also suggested additional ways to continue improving the performance of my web app.

How was Kombai able to perform better?

It wasn’t by accident that Kombai worked better than Figma-to-React tools or general-purpose agents. Kombai has implemented domain-level optimizations to fit into React developers’ workflows and generate the best React code from Figma designs.

Human-tested RAG

Most AI agents rely on model-generated documentation extracts that miss common pitfalls. Kombai is powered by human-tested RAG, not the usual mix of scraped docs and guesswork most agents rely on. That means its generated code is based on real-world frontend patterns and version-specific best practices that developers have actually validated.

It supports 30+ frontend libraries with a focus on the React ecosystem, including React 18 and 19, JavaScript and TypeScript, and common React stacks. You can combine React with Next.js and Tailwind, TanStack Router with MUI, or any other combination.

What impressed me most was the flexibility. If you’re using a library Kombai doesn’t officially support, you can write custom rules for it, and the agent will follow your guidelines.

Best Figma interpretation

Kombai doesn’t just read Figma files; it understands them the way a frontend developer would. Real-world Figma files are messy. Designers leave invisible elements, use incorrect grouping, have overlapping nodes, or add unintended fills and shadows. Most tools translate everything literally, including the mistakes.

Kombai handles this gracefully. It recognizes invisible layers and excludes them, understands when grouping is just for designer organization rather than component structure, and filters out accidental styling properties. This interpretation engine is the next evolution of the Figma-to-code model that became Product Hunt’s top developer tool of 2023, built and refined based on how real teams design and ship products.

Understands codebase like a human

Kombai takes a human-like approach to understanding codebases. It identifies key parameters for writing quality code in a given repository, then extracts necessary information like code files and configurations.

In a codebase with a custom component library, Kombai understands each reusable component’s function, UI appearance, and required props, much like a developer onboarding to a new project. Its search and indexing tools are optimized for codebases, enabling it to find and reuse relevant code faster and more accurately than general-purpose agents.

Browser tool for preview, debugging, and performance improvements

Kombai includes a browser tool that lets you preview the generated code, debug issues, and identify performance problems. You can see how your components render, check network requests, and spot layout issues before even opening your IDE.

This is useful for various use cases. UI fixes, network errors, component refactoring, and performance improvements. You get a full development environment right inside Kombai.

Conclusion

For years, I tried to make Figma-to-React tools work. I wanted automation to handle the repetitive parts of frontend development so I could focus on interesting problems. But every tool created more work than it saved.

Kombai was different. It didn’t just convert designs to code; it understood what I was building and how I wanted to build it. It generated components I could actually use, worked with my existing codebase, and handled tedious parts while respecting my architecture decisions.

The result is a tool that actually speeds up my workflow. I’m not spending hours refactoring generated code or manually adding interactivity. I’m building features faster, with fewer bugs, and with code that fits seamlessly into my project. That’s what I wanted from Figma-to-code automation all along.

Enthusiast: The Open-Source Toolkit for Building RAG-Powered AI Agents for E-Commerce Workflows

David Herbert💻🚀 — Wed, 29 Oct 2025 14:02:22 +0000

When people talk about AI in e-commerce, the conversation often starts and ends with chatbots. Even then, these chatbots are usually built on shaky foundations: they deliver answers that feel generic, break whenever a prompt is worded differently, or fail outright if the underlying data isn’t structured correctly.

The cracks only widen when your catalog involves complex product descriptions or categorizations, and a simple change to your catalog can often break these chatbots and internal training decks. Yet most retail problems go far beyond answering a few customer questions.

Modern e-commerce teams juggle many moving parts: growing product catalogs, marketing campaigns, customer inquiries, and product knowledge scattered across tools, spreadsheets, PDFs, and support docs. The promise of AI in e-commerce isn’t just about automating responses; it’s about making your entire product data pipeline smarter with a RAG‑based agentic AI solution that speaks your product language. That’s where Enthusiast comes in.

What is Enthusiast?

Enthusiast is an open-source, production-ready agentic AI framework with pre-built agents and workflows designed to solve everyday challenges in e-commerce — built by UpsideLab. It leverages the power of retrieval-augmented generation (RAG) and large language models (LLMs) to create a self-hosted unified knowledge platform that supercharges your e-commerce operations and speaks your product’s language to both customers and team members.

In simpler words, it connects to the systems your e-commerce business already uses, such as product databases, documentation repositories, and customer communication platforms, then turns this scattered data into a unified, searchable interface. Teams can then build and customize AI agents to not only automate tasks such as customer support, product search, marketing content creation, and internal knowledge management, but also empower developers, marketers, and support teams with an AI “teammate” that can search, reason, and respond instantly and factually.

Unlike many SaaS products, Enthusiast is self-hostable and open-source. You can deploy it on your own servers or in the cloud and choose between proprietary models, such as OpenAI, or self-hosted models through Mistral or Ollama. The framework is built on familiar technologies: Python, Django, PostgreSQL, and React, allowing teams to easily extend it. And because it is open‑source, you have complete control over model prompts, agent workflows, and data, with no vendor lock‑in or hidden usage costs.

Why a RAG‑based AI Agent Matters in E-Commerce?

Traditional chatbots often sound generic because they draw from a limited set of prompts and employ fuzzy keyword matching. In contrast, Enthusiast utilizes a Retrieval-Augmented Generation (RAG) engine at its core, which builds a vectorized index of your content to perform contextual search and extract information relevant to a query.

When a user asks a question, the agent retrieves relevant documents from your product catalog or knowledge base and feeds them into a language model, grounding the response in factual data rather than generic model knowledge. Enthusiast also includes layered evaluation and optional LLM‑based validation to reduce hallucinations and surface data inconsistencies.

Simply put, using RAG, Enthusiast splits the problem into two steps: first, it fetches relevant facts from your own data sources to retrieve the proper context in real-time, and then crafts a response using the language model based on that context to generate accurate, human-like answers or recommendations. This approach addresses common pain points, such as inconsistent support answers, time-consuming content workflows, and sales teams lacking quick access to product data.

How Enthusiast Tackles Real E-Commerce Problems

Enthusiast isn’t a monolithic AI product; the framework ships with plug-and-play agents tailored for common e-commerce workflows.

Customer Support

The customer‑support agent connects directly to your product catalog and documentation to answer shopper enquiries. It retrieves precise answers from both structured and unstructured documentation, reducing ticket queues and improving first‑contact resolution. It also features an API layer that enables integration with helpdesk or CRM tools, allowing you and your team to deploy AI-powered support on the channels already in use.

Marketing Content

Marketing teams can use Enthusiast’s content‑generation agent to produce ads, newsletters, blog posts, and product descriptions. The agent is grounded in your product data and existing assets, mimicking your brand’s tone and style. And because Enthusiast runs locally or on your own servers, sensitive product data never leaves your infrastructure. The framework also supports multiple languages, making it easy to tailor campaigns for different regions.

Internal Knowledge Management and Search

Teams often lose time digging through scattered docs and half-remembered links. Enthusiast brings that information together into a single, searchable hub where people can ask questions in plain language and get accurate answers. Enthusiast achieves this by ingesting existing data and integrating with your knowledge sources, such as manuals, PDFs, markdown files, Confluence, Notion, etc., and transforming them into a centralized, searchable knowledge-sharing portal.

This allows teams to query complex, cross-functional information and get accurate answers to product-related questions in natural language. Responses are also evaluated through layered feedback combining user input, automated scoring, and optional LLM validation to ensure accuracy. And because it is self-hosted, sensitive data remains behind your firewall.

Product Recommendations

Keyword searches and rigid filters often miss the subtleties of what shoppers are really looking for. Enthusiast approaches your catalog more like a teammate, able to field open-ended questions and still land on the right products. Ask, “What’s a good waterproof jacket for spring hiking?” and it pulls the best matches straight from your catalog. You decide how the prompts are framed and how the workflow connects to your taxonomy, brand voice, or recommendation style.

Content Verification

Before product descriptions or reviews go live, you want to have confidence that they align with your catalog data and house policies. Enthusiast can double-check that content for accuracy and consistency, saving your team from tedious manual reviews. Enthusiast’s content validation agent helps teams compare descriptions, reviews, and marketing copy against your product catalog and docs, flagging inconsistencies or areas that need improvement. The validation prompts and rules are fully customizable and can even be run automatically or on demand.

Conclusion - Is Enthusiast right for you?

Enthusiast shows that AI in e-commerce doesn’t have to end with generic chatbots or an expensive SaaS subscription black box. Whether your team is exploring practical and flexible AI-powered solutions to optimize internal operations, improve customer experiences, or is frustrated by the limitations of closed SaaS solutions, Enthusiast is the right toolkit to innovate your e-commerce stack.

Out of the box, it offers ready-made agents for common e-commerce problems, while still allowing you to shape the prompts, retrieval logic, and deployment environment to fit your specific needs. The payoff is practical: an accurate knowledge base assistant for team members, fewer repetitive support requests, a consistent brand voice across content, and a shopping experience that feels intuitive for customers.

And the best part? Enthusiast is open source and built on a standard web stack, which keeps you free from vendor lock-in and API limits. You can start with OpenAI for simplicity, then grow into hosting your own Llama or Mistral model as your needs evolve. Ready to see what an open, flexible e-commerce agentic AI framework can do for your team? Try Enthusiast.

How Recast AI Improves Your Daily Reading Lifestyle and Boosts Productivity

David Herbert💻🚀 — Fri, 20 Oct 2023 08:57:35 +0000

As developers and tech enthusiasts, allocating time for self-improvement and keeping up with our myriad of interesting reads is often a wishful aspiration. Whether it's news articles, productivity hacks, blog posts on learning a skill, or keeping up with your favorite newsletters, finding the time to sit down and read through lengthy articles can be challenging, especially when juggling a busy schedule in a constantly moving world.

Wouldn't it be cool if you could listen to these articles like podcasts? So I recently came across an app called "Recast AI," which is supposed to summarize articles into podcasts, offering a modern solution to traditional reading and transforming your reading routine into an engaging auditory experience, saving you time.

What Exactly is Recast?

LetsRecast.ai, or simply Recast, is an AI-powered app designed to take the articles you're keen on reading and brew them into short, lively podcast-style audio summaries, morphing a potentially time-consuming read into a brief, engaging listen. This is particularly handy for those bustling days when sitting down with a lengthy article is a far-off dream.

Whether jogging in the park, driving to work, or tidying up at home, Recast ensures your thirst for knowledge remains quenched. It's like having a personal narrator who succinctly unfolds the essence of all your "want-to-read" articles to you, allowing you to soak in the knowledge without anchoring yourself to a text. This way, your reading list becomes a playlist, bridging the textual world with the auditory, making consuming your articles online more flexible and enjoyable.

Recast is an ingenious way to enrich your reading experience and boost productivity, as it saves you time and helps you adapt to your bustling lifestyle. It's not just about saving time; it's about redefining how you interact with your reading list, turning the solitary act of reading into an interactive auditory session.

What Does Recast Sound Like?

Unlike typical robotic text-to-speech voices, Recast employs a conversational tone, making it easier to grasp the key points of articles in a more meaningful and enjoyable way. There's just something about the chatty nature of these podcasts that makes them more appealing than traditional audio summaries.

Think of a podcast series featuring two charming and smart hosts who read any topic you like and then discuss it in rich, beautiful voices. That's precisely how Recast sounds, and the voices are brought to life by Recast's powerful AI.

Why use Recast?

Recast promises to improve your life based on the following key benefits:

Saves you reading time: Recast acts as your personal news summarizer, delivering the crux of articles in a nutshell. Imagine the time you'd save when, instead of sifting through lengthy paragraphs, you get the core message delivered to your ears. This is especially beneficial in a world where time is of the essence, and staying updated is crucial.
Reduces screen time: In today's digital age, screen time has become synonymous with eye strain. Recast offers a refreshing break from the constant screen time by summarizing articles into podcasts. Now, mundane tasks like doing the dishes, commuting, or exercising become opportunities to catch up on the latest news or articles, all without having to stare at a screen.
Gain Deeper Insight: Recast's conversational tone is a game-changer. It's not just a robotic summary but an engaging narrative that explains the content to you in a way that enhances comprehension and retention of key information. This subtle shift from mere summarization to explanation is like having a knowledgeable friend explaining articles to you in a simple, digestible manner.
Discover interesting reads: The platform isn't just a solitary experience but a community where you can see what others have recast, helping you discover intriguing stories or important news you might have missed. It's a modern way to expand your horizons and stay informed about diverse topics.
Clear off your reading backlog: If you have multiple tabs open with articles you plan to read "someday," Recast is your go-to solution. It helps declutter your life by converting those open tabs and backlogs rotting in your inboxes and read-later newsletters into delightful podcast summaries. Now, your reading list becomes a listening list, making it more manageable and less daunting to get through.
Available across platforms: Recast is available as an iOS app, a feature-packed web app, and a Chrome extension for submitting articles.

How to Recast (How Does it Work)?

Recasting is straightforward. You can recast things yourself or explore the countless great recasts made by others. Create a free Recast account at letsrecast.ai and download the app or install the Chrome browser add-on extension.

Select any article you're curious about on the web (but have yet to read due to time constraints), or open a new tab and browse an interesting article. Click on the recast Chrome extension. Click on "recast it", and it'll do its little recasting magic, and in minutes, your Recast will be ready! Your unique recast conversation will pop up in both your app and inbox. It's truly hassle-free.

The experience is even more convenient in the mobile app, where you can use the in-browser feature in the Recast app to surf the web for an article or share any article you're reading in other apps directly to the Recast app using your phone's in-app sharing capability.

Summary

In conclusion, Recast seems to be a modern-day boon for those seeking to balance a busy life with the thirst for knowledge. It essentially molds itself around your lifestyle, ensuring that your quest for knowledge doesn't fall by the wayside amidst daily chores and responsibilities.

Recast is especially great for those who prefer auditory learning or those with hectic schedules, allowing you to absorb crucial content without investing much time. By leveraging the power of AI technology, Recast transforms your traditional reading habit into a more convenient, engaging, and effective podcast learning experience.

How to Implement and use Feature Flags in a Svelte Application

David Herbert💻🚀 — Tue, 10 Jan 2023 17:49:10 +0000

When deploying code, one of the best ways to ensure it's high quality, meets user or business requirements, and works as it should is by feature flagging it. Feature flags are a great way to control the release of new code or features in your software, as feature flags make it possible to test new code on specific users or a group of users before releasing them to everyone.

Feature flagging allows you and your team to easily experiment with new features or make changes to existing ones without deploying a new software version. Furthermore, feature flags make it possible for you and your team to seamlessly execute trunk-based development by facilitating continuous deployments and ensuring code integration reliability.

This guide will cover how we can use feature flags to introduce new features in a Svelte application.

What is Svelte?

Svelte is a JavaScript compiler and a frontend development tool similar to popular JavaScript frameworks like React, Angular, Vue, etc., for building small pieces or whole interfaces of single-page web applications. However, unlike these traditional frameworks, Svelte offers a refreshing outlook on building user interfaces by taking on a different and somewhat innovative approach to creating fast, slick, and reactive user interfaces.

In contrast to traditional frameworks, Svelte is a unique framework that compiles all its work when you build your application rather than doing it in the browser. As a result, it doesn't rely on a virtual DOM to update the DOM. Instead, it compiles your components into highly efficient JavaScript code that can surgically update the actual DOM whenever the application's state changes. Svelte converts your code into optimized JavaScript at build time instead of interpreting it at runtime. In other words, you won't pay the performance cost associated with traditional JavaScript framework abstractions, as no extra scripts or libraries are shipped to production.

What makes Svelte even more awesome is that you can also use it to compile your favorite framework, as it has support for most of the popular frontend frameworks, making it ideal for JavaScript developers looking to get lighter builds from their favorite frameworks.

The Advantages/Disadvantages of Svelte?

When it comes to using Svelte, there are both benefits and drawbacks. On the plus side, Svelte is known for being fast and lightweight, allowing developers to quickly build fast web applications that are both lightweight and responsive. Additionally, the code compiled by Svelte is typically highly optimized and easy to read, making it easier to debug and work with compared to the layered abstractions in traditional frameworks. In addition, Svelte applications are typically smaller than those built with other frameworks in file size, further enhancing performance.

However, one disadvantage to using Svelte is that it is a very new technology. As a result, there is less community support and fewer resources accessible compared to popular frameworks like Vue and React. Furthermore, because it is so lightweight, it may not be the ideal choice for more complicated projects as it might not be as flexible compared to other production-tested frameworks.

Prerequisites

Before we begin, these are technologies you should be familiar with and have installed on your local machine to be able to follow along this guide:

HTML& CSS knowledge
JavaScript knowledge
Basic Svelte knowledge
Have Node.js v8+ installed

About Our Sample Svelte Application

For our sample application, we will create a simple feature in a sample Svelte application that displays a random fact about cats each time a user visits or reloads the page. However, we will wrap this feature with a feature flag, so users can only see it when the feature flag is toggled on. Otherwise, we render a display message informing users of its unavailability when toggled off.

If you want to follow along, you can find the source code on GitHub. To keep things straightforward, we will use ConfigCat's feature flag management service to control our feature from a remote dashboard. So, let’s get right to it.

Creating a Sample Svelte Application

Let's start by quickly scaffolding a Svelte app using the create vite command.

npm create vite@latest myapp -- --template svelte

This prompts us to choose our Svelte development environment or choose between the JavaScript and the various supported frontend frameworks we wish to work with. Afterwards, we run the install command to install all our dependency packages.

npm install

With that, we can start our dev environment.

npm run dev

We now have a working Svelte demo app.

Creating Our Random Cat Fact Feature

To keep things simple and straightforward, we’ll make use of a free Cat Fact API that returns an object containing a random fact about cats each time a call is made to it. We’ll simply render the returned fact in our markup.

<script>
  import { onMount } from "svelte";
  // Fact object
  let data = {};

  // Fetch data once the component mounts
  onMount(async () => {
    const res = await fetch(`https://catfact.ninja/fact`);
    data = await res.json();
  });
</script>

<main>
  <h1>Random Fact About Cats</h1>
  <!-- Show fact -->
  <p>{data?.fact}</p>
</main>

<style>
  h1 {
    font-size: 1.5rem;
  }
</style>

With that, our app is ready to be feature flagged.

Creating a Feature Flag using ConfigCat

As stated earlier, we will use Configcat's feature flagging service to toggle our feature on/off. So, sign into the ConfigCat Dashboard and create a new feature flag. Don't have an account? Quickly sign up for a free account.

To create the new feature flag on ConfigCat:

Log into the dashboard and navigate to the appropriate config.
You can add a feature flag by clicking the 'Add feature flag' option and entering the necessary information.

For our Svelte app to be able to connect to our feature flag, we will need to copy the ConfigCat SDK Key.

How to Connect our Svelte Application to ConfigCat?

Now that we have created the feature flag, it’s time to integrate it with our Svelte application. Fortunately, ConfigCat provides a number of open-source client SDKs to facilitate seamless integration with their feature flagging services. For this guide, we’ll use the JavaScript SDK package.

Installing the JavaScript client SDK is as simple as running the following command.

npm i configcat-js

We can now import it into our app and initialize it using the provided SDK key associated with our ConfigCat Dashboard.

<script>
  import * as configcat from "configcat-js";
  import { onMount } from "svelte";
  // Fact object
  export let data;
  export let featureFlag;

  // Fetch data once the component mounts
  onMount(async () => {
    const res = await fetch(`https://catfact.ninja/fact`);
    data = await res.json();

    // Connect to ConfigCat client
    const configCatClient = configcat.createClient(
      "fK7ZCApWbkaDu14njPKZQw/s9XWupU5K0KRp_9PvkU02g"
    );

    // Get feature flags value
    featureFlag = await configCatClient.getValueAsync("randomfactflag", false);
  });
</script>

<main>
  <h1>Random Fact About Cats</h1>

  <!-- Show fact only if flag is toggled on -->
  {#if featureFlag}
    <p>{data?.fact}</p>
  {/if}

  <!-- Show message if flag is toggled off -->
  {#if !featureFlag}
    <p>Ops! This feature is currently unavailable</p>
  {/if}
</main>

<style>
  h1 {
    font-size: 1.5rem;
  }
</style>

Now, when we toggle on the feature flag?

The feature is made available to our users.

However, when the feature flag is toggled off?

The feature is no longer available to users.

Source Code: Github

Conclusion

As you have seen, integrating feature flags into your Svelte app using ConfigCat is pretty straightforward. With feature flags, you can clear up any questions when introducing changes to your application without affecting users' experience.

Getting started with ConfigCat is easy thanks to its intuitive dashboard, easy-to-use SDKs, and well-organized docs. Visit this page to see other supported SDKs. Follow ConfigCat on Twitter, Facebook, LinkedIn, and GitHub to learn more about feature flagging and its associated benefits.

Short-lived or Long-lived Flags? Explaining Feature Flag lifespans

David Herbert💻🚀 — Tue, 12 Jul 2022 21:52:32 +0000

Feature flags (aka. feature toggles) are becoming increasingly relevant in software development as they provide the ability to toggle features on or off in production, perform a gradual rollout of features and enable A/B testing experiments.

However, an often overlooked part of this feature flagging technique is that it introduces complexity and has inherent risks when said complexity isn't properly managed. As you're using more and more feature flags within your organization, it's important to understand that some of these flags are meant to last only for a short period and should, therefore, be removed from your codebase.

Feature Flags Life Cycle (Longevity)

Feature flag longevity, as the name suggests, has to do with the lifecycle of a feature flag and how long it should remain in the codebase. Since feature flags split your code paths into two or more paths, having too many feature flags for a long time can create additional complexity in your system and an overabundance of them can easily lead to cognitive overload.

In addition, as with everything, when left unmanaged, feature flags can result in technical debt due to the presence of stale flags that no longer serve a purpose in your codebase. Having these stale flags can be a recipe for disaster as they can accidentally be toggled on. Thus, it is recommended that feature flags are kept as short-lived as possible and their number as low as only needed.

For these reasons, it is, therefore, necessary to evaluate the purpose of a feature flag to determine its lifespan depending on its use case.

Short-Term vs Long-Term Feature Flags

The first step when considering a new feature flag or keeping your flags organized is to identify whether a flag is going to be a short-term or permanent feature flag.

Short-Term Feature Flags

A short-term or temporary flag has a limited lifespan and is often used for release management such as dark launching a new feature, performing experiments, canary rollouts, and tests. When you label a flag as short-term, you can then keep track of it for removal in the future. Once the flag has served its purpose, the application configuration and code are immediately cleaned up, and the flag removed since it no longer has a use.

Long-Term Feature Flags

A permanent or long-term flag, on the other hand, provides certain control for an extended period, even after a feature is released. The flag might exist for as long as the feature does and is often used for things such as paywalls or entitlements, customizations, load shedding, or accessibility.
Flags that are long-lived easily become part of your regular software operations, so you create them intending to keep them around indefinitely.

Different Types of Feature Flags and their Various Life Span

There are different types of Feature Flags, and they are categorized according to their life span and use case:

Release toggles

Release Toggles are usually short-term flags used to slowly expose new features to users and also make it possible to keep certain functionalities hidden from some or all users while iterating on them. These types of Feature Flags make it possible for teams to continuously integrate new features into production without having to worry about the associated risks of continuous deployment.

Ops toggles

Ops or Operations toggles usually serve as “circuit breakers” to protect the system when integrating it with new features or functionalities to accommodate for potential issues. Ops flags are also short-term flags that are often used to determine the impact of a new microservice or infrastructure component on a system by monitoring it for possible unexpected errors such as CPU spikes or memory leaks. The ops flag can then be used to disable the new component for further troubleshooting if things don't go as planned.

Experiment toggles

Experiment toggles are short-term feature flags that are used for performing tests and experiments in a bid to collect data from real live users in production, such as carrying out A/B testing to decide between two or more implementation ideas.

Permission toggle

Permission toggles are usually flags that are used to customize the product experience of your users. This is done by limiting certain features to only a subset of users based on user entitlement or privileges such as subscription level or authentication status. We may, for instance, have a set of "premium" features that are available only to subscribers or paying customers. Unlike other toggles, permission toggles are usually long-term.

Dangers of Technical Debt and the Importance of Retiring Flags

Technical debt is a debt a company will have to pay later in the future for choosing a simpler, faster, but less reliable option today. And like all forms of debt, technical debt accumulates interest if not handled properly. This compromise can lead to a substantial amount of work and potential costs in the future.

As the popular saying states, "With great power comes great responsibility". One argument against using feature flags is that they contribute to technical debt. This is an understandable argument since you can quickly end up with several unused feature flags if you don't pay attention to your flags and conduct regular cleanups or reviews. In the absence of a removal plan, they will become obsolete and add technical debt and complexity. Having these stale flags in your application can adversely affect its reliability and increase development costs down the line.

Eventually, this technical debt accumulates and stays in your application for years and nobody is sure what a flag does. These flags can become tangles of conditional logic in your code which becomes challenging to manage in the future as your team will end up having to waste actual development time dealing with potential issues that might arise from stale flags.

It is therefore necessary to retire unused flags to avoid the technical debt associated with stale flags. Adopting a third-party feature flag management system such as ConfigCat can be sensible since the platform has built-in solutions such as tracking of stale flags and scheduled reports on your flags usage. This makes it easy to eliminate the technical debt associated with having stale flags in your source code.

Summary

Feature flagging is a very useful technique to have in your deployment toolbox for continuous integration and feature delivery in our application. Feature flags allow companies to ship more frequently, minimize risk, increase productivity, and even target users and perform A/B tests to determine which features are more popular with these users.

However, like so many techniques in software development, it also requires proper management and organization to avoid falling into technical debt as a result of misuse or mismanagement.

Having too many stale or long-lived flags adds complexity that accumulates into technical debt. Hence, the lifecycle of feature flags should be understood and properly managed by teams for the best results. Cleaning up stale flags and keeping the number of feature flags modest and as short-lived as possible becomes key in maintaining a sane and healthy codebase.

Be sure to check out ConfigCat's Feature Management service to discover how you can mitigate the frustrations of managing all your feature flags and you can also follow ConfigCat for more on LinkedIn, Twitter and Facebook.

Eliminating Traditional Feature Release Anxieties

David Herbert💻🚀 — Tue, 21 Jun 2022 10:14:16 +0000

As developers, we spend countless hours building new features and having them pass through rigorous QA tests. However, despite experience and all preparations made, there's always that dreaded feeling you get in the pit of your stomach when you know it's time for deployment. What if something goes wrong in production and your feature doesn't function as expected?

As software engineers, we are constantly faced with a variety of challenges. These challenges range from developing innovative features based on constantly changing requirements, to deploying these features to production and releasing them to users with the hopes that they work as intended.

Anyone that has been actively involved in software development is familiar with the stress and anxiety that is caused by deployment and feature release. There's always the constant worry over whether things will go smoothly as planned when these changes are pushed to users.

That’s why the most important investment a team can make in a company is helping engineers overcome this constant fear of failure associated with feature releases.

The Anxiety and Pain of Traditional Big Bang Feature Releases

In the past, deployments were done using what's known as a big-bang approach, where all features are released in one go. This results in a single major release with lots of changes and feature releases bundled into it, which is problematic in at least two ways:

Bundling up lots of changes and new features into one big bang release makes the release more complicated. The complexity of such a release opens up a lot of possibilities for release failure since things could go wrong in a lot of ways. As a result, most engineers and everyone involved in the process in such organizations or companies don't like release day due to the risks and anxiety that come along with it.
Secondly, another problem with this big bang release approach is that most organizations are typically structured to have a fixed release schedule that is infrequent, such as one in every 3 months or thereabouts. This makes delivering changes, fixes, and new feature updates to customers slower, which results in users of the service not being able to access new features or improvements quickly enough. This could negatively impact the user experience of the service.

Overall, traditional big bang feature releases are much slower and riskier because there is a lot more at stake with each deployment if things don't go as planned, which causes greater anxiety and fear of failure for anyone involved in the process.

Separating Code Deployment from Feature Releases with Feature Flags

Releasing feature updates comes with many risks, so it would be prudent to try to minimize these risks by separating deployments from feature releases. This approach allows for a safer and more flexible release strategy, as it is typically safer to make these release changes incrementally.

This incremental strategy means that the risks associated with traditional deployments and feature releases are minimal and better managed. Also, priority features can get delivered as soon as they become available for user consumption.

However, the question you might have if you are new to the world of modern DevOps is what is the difference between deployment and feature release as these terms are often used interchangeably.

Deployment typically involves moving software changes from one controlled environment to another, usually from a development environment to a live or production environment. The fact that these changes are in the user's environment does not necessarily mean they are available to the user.
Feature releases describe the rollout of features and updates to users. In other words, a release gives users access to these new changes and features by making them available to the users.

One of the most effective and easiest ways to separate your deployments from your feature releases is by using feature flags.

Feature flags determine whether a piece of code or functionality wrapped within it is active or not. Like conditional if/then statements, you can put your updates and features behind a feature flag that hides them after deployment until it’s ready to be released. This means you can continually ship value while avoiding unnecessary risks and anxieties.

The Benefits of Using Feature Flags

Whenever you are releasing new features and updating your product, it is easier to have a continuous delivery pipeline which allows you to push these updates incrementally as quickly as possible while also safeguarding your customers in the event that any unexpected issue arises. You should be able to roll these updates back out of production as quickly as possible to avoid negatively impacting users.

With feature flags, it is possible to create a continuous delivery pipeline that allows for both feature addition and risk reduction. Feature flags allow deployments of features to be decoupled from their releases. As a result, you can easily roll out new features without releasing them immediately to the public and easily roll back these features if the need arises.

Fortunately, there are several feature flag management services such as ConfigCat that offer feature flags as a service. A good feature flag configuration management service comes equipped with key feature flag functionalities and tools to help you and your team leverage the power of feature flags such as:

User Segmentation: Feature flags can be used to segment your users into subgroups and to test and release features to them based on attributes assigned to different user segments such as location, geography, gender, etc.

A/B Testing: By using Feature Flags, you or your Product/Marketing teams can test alternative ideas on your users before proceeding to final implementation based on the feedback from these tests. By doing this you are able to offer the most satisfying customer experience by pushing only the most performant ideas to your users.

Progressive Delivery: Feature flags enable you to implement your feature releases gradually to help minimize the negative effects of continuous product iteration. The advantage of releasing in smaller chunks regularly is that it's much easier to observe the effect of each change, and if anything goes wrong, quickly roll back the changes.

Kill Switch for Easy Rollback: In the event that your feature release doesn't work correctly in production, the change can be rolled back immediately from production via a kill switch option.

Intuitive UI Dashboard: Remotely manage all of your feature flags from an intuitive dashboard without having to redeploy code when changes need to be made to the flags' configuration.

SDK Integration: Simple SDK for easy integrations with various apps and platforms.

Summary

In today's rapidly changing world, if you don't improve, you get worse. The success of a development team ultimately depends on how frequent and successful their releases are. However, traditional deployment comes with a lot of release anxiety from the fact that release day is made into a major event.

Feature flags play a prominent role in making releases as uneventful as possible by providing key functionalities that give you fine-tune control over the exposure of your feature releases. By using feature flags, you can decouple your feature releases from deployment to create a continuous delivery pipeline that enables you to continuously ship value without risking unnecessary exposure.

For more information on feature flags and how they help ease deployment-related anxiety, follow ConfigCat on Facebook, Twitter and LinkedIn.

Decoupling Feature Releases from Deployment Using Feature Flags

David Herbert💻🚀 — Fri, 17 Jun 2022 16:08:41 +0000

In a traditional software development workflow, whenever there are updates or feature releases to be made, they are typically tied to a single major deployment to production. As a result, the frequency of feature delivery is slower and a lot riskier because there’s a lot more at stake with each deployment if things don't go as planned.

That is to say that releases should not be tied to deployments but rather, decoupled from them. Due to this reason, in a continuous delivery environment, it is considered best practice to decouple feature releases from deployments as it allows for more incremental releases.

Hence, understanding the concept of decoupling releases from deployment and how feature flags can make that possible is a key for any team.

The Difference Between Deployment and Feature Release

We must have a clear understanding of the difference between deployment and feature release before proceeding further because these terms are often used interchangeably but are not the same.

Deployment: When we refer to "deployment" we mean the action of pushing code from a development environment to the production environment or a certain part of our infrastructure. This deployed code could contain one or more updates, features or functionalities.

Release: When we refer to "release" we mean the actual act of enabling or exposing a change, feature, or functionality to our end-users.

The difference between both is that when a feature is deployed, it does not necessarily mean the end-user now has access to it. No! It simply means the feature has been pushed to the end-users environment (i.e. production environment), whereas, releasing the feature is the action of exposing or turning it on, so it is available and accessible to the end-user.

The Concept of Decoupling Feature Release from Deployment

The typical development workflow involves collaborating in teams on any given product or feature where each team member works on a different feature branch. However, when collaborating in parallel it’s often not feasible to wait until every developer has completed their work before making a deployment.

Sometimes certain features may be ready before others are, or may need testing on users in a live environment so as to gain immediate feedback to aid iteration and modification.

Ideally, you want to be able to push these features when they are ready for release or live testing into production and expose some users to them. At its core, the reason for decoupling releases from deployment is to be able to deliver new features to users faster while mitigating some deployment risks and without compromising on software quality.

Decoupling releases from deployment gives you control over when and how a release is made even after deploying to production. Should something go wrong with a release, you only need to "un-release" these changes rather than having to do a full rollback to the previous version or having to hastily build a potentially buggy patch.

Imagine for a second, that you are the owner or manager of a retail store where thousands of customers shop daily. When your supplier or manufacturer supplies you with a new range of products, and you move them from the warehouse to the store (i.e. deployment).

You don't just throw everything on the shelves so that people can buy them (i.e. release). You may choose to put only a few on store shelves to test them out and to see how customers interact with them. That is the same as decoupling your releases from deployment to perform a selective release.

Using Feature Flags to Decouple Releases from Deployments

Feature flags (also called feature toggles) play a key role in continuous delivery, specifically in the concept of decoupling feature releases from deployment as they make it possible to deploy code behind conditional flags, and then only toggling them on/off to expose or hide said code from users as the need arises.

Feature flags provide several interesting features that facilitate decoupling and testing in production, such as being able to target a specific subset of users or user groups, or a percentage (portion) of your traffic, as well as providing accompanying kill switches for easy rollbacks.

By feature flagging, you can safely push code to production without immediately exposing it to users, experiment with A/B tests, release by user segmentation, reduce the risk associated with deployment by making incremental updates and be able to turn a resource or feature on/off at will.

Luckily you don’t need to worry about building or managing your own feature flags as there are companies such as ConfigCat that offer feature flags as a service, making it easy to integrate a feature flag management system into your releases.

Feature Release with Phased Rollout

When you release an update or a feature to production, phased rollout enables you to implement your release in stages via user segmentation. Phase rollout lets you break your releases into stages by targeting only a subset or percentage of users at a time. This lets you gradually ramp up the number of users exposed to your release until the release is made available to all of your users.

You can start by releasing it to the first 1% or 5%, then ramp it up to 10%, 20%, 50%, 75%, and finally 100%. This strategy lets you control the blast radius (limit the scope of potential issues) of a release and makes it possible to test and gain immediate feedback early on from your users. For example, if a release performs poorly or is buggy, it's better if only 5% of users experience this rather than your entire user base.

Furthermore, staged rollouts are also useful for experimenting with new features, such as doing A/B testing. Instead of pushing out releases to all users simultaneously, you can use controlled, measurable feedback to determine what's working in a phased rollout release.

Feature Release with Dark Launch

As the name implies, a dark launch is usually not publicized, but rather rolled out stealthily by first releasing to a subset of users before a full release to see how they perform. Usually, users are unaware they are testing out the new feature or functionality; rarely will the new feature be announced or highlighted until it’s ready for full release.

As a result, development teams can get early feedback from users, test bugs, and even stress test infrastructure performance. This allows for faster, iterative releases, and ensures that application performance is not affected, and the release is well received by users.

This release method was popularized by major tech companies such as Facebook and Google to test upcoming features by pushing them out to a subset of users before an all-out release.

Benefits of Decoupling Feature Release from Deployment

Decoupling releases from deployments using feature flags has several key benefits:

Get Code to Production faster - Decoupling your feature releases from your deployment makes it possible to release more frequently.
Risk Mitigation - Easily control the blast radius of your releases.
User Targeting - Through user segmentation, the visibility of features can be targeted to certain users.
A/B Testing - Easily run A/B tests of features to see which performs better.
Percentage Rollouts - Release features incrementally to your users to gain feedback early on that can be used to improve it further.
Trunk Release - You can release parts of the code and push them into production even if some features are not yet ready for deployment by keeping them toggled off.
Kill Switch - Quickly roll back a feature when it is performing poorly or is buggy.
Avoid Branching and Merging - Rather than having to keep maintaining separate feature branches for a new feature, you can avoid potential merge conflicts using feature flags to conditionally enable features when they're ready.

Conclusion

The idea behind decoupling releases from deployment with feature flags is to maintain a fast, continuous integration feedback loop. This makes it possible to rapidly deliver updates to production and test new features without impacting your infrastructure or disrupting your user experience.

Decoupling your releases from your deployments gives you greater control over your feature releases. As a result, you can push code anywhere and at any time without exposing your users to deployment risks.

To learn more about using feature flags to decouple releases you can follow ConfigCat on Twitter, Facebook and LinkedIn.

Feature Flag Rollbacks for Product Managers

David Herbert💻🚀 — Mon, 09 May 2022 19:58:31 +0000

Product managers are responsible for deciding what products to develop that align with the company's goals and also satisfy the needs of the customers. To be a successful product manager, you have to start by defining what a winning product looks like and iterate over it until it's right. To do so, you have to understand that at its core, a product is broken down into its features and quality of user experience.

However, when developing these features, even after thoroughly testing them in your development environment for potential bugs and issues that may negatively impact user experience, it may not always be sufficient to ensure a successful release to users.

What is a Feature Rollback?

When it comes to feature delivery, things don't always go according to plan. A feature may work perfectly fine when tested in development, but may not function as expected or may receive poor user acceptance when it hits production or gets released to users.

A feature rollback is a way to quickly undo a feature rollout (release) by reverting the code changes back to the previous state without the feature's release – In other words, it is the action of “un-releasing” or “rolling back” the feature from production back to development and undoing access to it, so users are no longer exposed to it.

Why is Feature Rollback Important to Product Managers?

Nowadays, software development is about speed and efficiency when it comes to feature releases, UI improvements, and bug fixes. It is ultimately a product manager's responsibility to manage a product throughout its lifecycle from the stages of developing, testing, deploying, to finally rolling out features to users.

Feature rollback is critical whenever these changes are pushed into production or a feature is released to users because unexpected behaviors can still occur, which could negatively impact users and even lead to service disruption.

When issues are detected during a feature release or the feature is not well received, a rollback workflow is needed to immediately safeguard your users and their experience by quickly rolling back the feature while you iterate or figure out the root cause of the problem.

A feature rollback is therefore essential to product managers in preparation for situations where things don't go as planned because it helps ensure a swift response to detected issues and quick resolution without having to worry about its disruption to production operations which could lead to unexpected costs.

Use Case Scenarios for Feature Rollback Strategy

There are several case scenarios where having a rollback strategy in your development workflow and release cycle can be the right solution:

The Feature Performs Poorly After its Release

Despite the fact that we might like to believe our users are like us, they are not. We might speculate that we understand our users and what they want as customers. However, every decision to develop a feature is at best, a guess and without actual real-world feedback, a likely shot in the dark at what these users want.

Suppose you develop a new feature based on this assumption, and then, after it is released, you discover that it’s performing poorly because users do not like it. Where do you go from there?

You may want to perform a feature rollback so as to "un-release" this feature from its live environment back to its development environment and gather as much real-world user feedback as you can from this release.

You can then iterate with the newly acquired data to make improvements to the feature or come up with a better initiative, so user expectations are better met.

A Feature Bug sneaks its way onto Production

Imagine you developed a new messaging feature and before releasing it to users, it passes through several rigorous QA and internal testing processes. This testing helps uncover bugs and potential problems in the newly developed feature that are later resolved before it is deployed to production.

However, after releasing this messaging feature to users, a strange bug is encountered that prevents users from sending messages. In such unexpected situations where a feature behaves differently in production as a result of bugs or other technical issues. In order to fix it, you will likely have to roll back the feature.

A rollback option gives you a near-real-time response to major problems such as these that occur during a feature release.

Developing a Rollback Option Using Feature Flags

A feature flag is a simple way to toggle on or off certain functionality for some or all of your users. This toggling can be done without the active participation of your development team via a user interface provided by companies that offer feature flags as a service. Thus, giving not just developers, but also non-technical members of a product control access to run tests, and experiments or incrementally roll out a feature to users.

Feature flags control who sees and has access to a feature and can be used to break your feature release into incremental rollouts through user segmentation. This is done by first exposing the feature to only a few of your users, such as your internal users or beta testers in production. After gathering feedback from these initial users, you can then gradually roll it out to the rest of your users until every user has access.

Most importantly, feature flags come with kill switches to facilitate a quick rollback of a feature at any time if things don't go as planned. This empowers you as a product manager and your development team with the flexibility to adapt to unexpected changes as the need arises.

Using Feature Flags to Perform A/B Tests and Experiments

A product manager is constantly tasked with adding value to products and delivering new customer experiences by bringing their best ideas to life. This is done by conducting user experiments and market research to gain insight into what product ideas would perform as planned or even better before making a final decision on what to move forward with.

Feature flags include powerful custom targeting functionalities that give you, your engineers and marketing teams control access to perform real-world experiments to better understand your users. In addition, testing more features with more people early in its development cycle helps you decrease certain risks while also gaining business insights before making final rollout decisions.

With feature flags, you can build quality into your product delivery by running live A/B tests on users to experiment with your ideas in order to find out which idea performs better with users. This ensures that your ideas match both customer expectations and your company's objective.

Conclusion

The deployment process is inherently risky, and there can be many unforeseen pitfalls. However, you still have to add new features to your products to keep your customers happy. Having a feature flag rollback option in a development workflow allows you to test new features in a real-world environment earlier on in their development circle while avoiding the most common risks of deployment and reducing risks of failure, which allows you to better serve users.

By making it easier for product managers to choose which ideas and features to release or roll back; to whom and when; feature flags help bridge the gap between continuous innovation and frequent deployments to production. Product managers are able to set their companies apart from competitors by orchestrating unique user experiences that drive long-term success with this level of control provided by feature flags.

Most importantly, you don’t have to burden your engineers with the task of building homemade feature flags as there are companies such as ConfigCat that conveniently offer feature flags as a service – making configuring and managing your flags a dashboard away.

To learn more about becoming a better product manager using feature flags, you can follow ConfigCat on LinkedIn, Twitter and Facebook

Implementing Feature Flags in a Next.js Application

David Herbert💻🚀 — Thu, 28 Apr 2022 13:14:49 +0000

Our job as developers often involves releasing new features regularly. However, how can we ensure that these features work properly in production before safely releasing them to all users? It's easy, by feature flagging!

What is Feature Flagging?

Many companies struggle to roll out new features and functionalities in an incremental way. Feature flagging is a mechanism used to control access to certain features with simple switches called feature flags, feature toggles or feature switches.

Through feature flagging, anyone can safely test code in production, perform canary releases, conduct A/B testing, and many other unique uses. You can deliver different content and functionalities to targeted users through user segmentation based on a feature flag’s value and its associated config rules.

What Exactly are Feature Flags?

Feature flags are conceptually based on being able to encapsulate sections of your code into conditional statements that can be switched on and off depending on your needs.

Similarly to an if/else statement, these flags return true/false boolean values based on the state of the feature flags (whether they are toggled on or off) and are implemented directly inside your source code to check these external conditions before executing the code.

Feature Flag Use Case in a Next.js Application

Consider this scenario: Suppose we implemented a new feature in a Next.js application that allowed us to generate random user profiles with every page load or reload, and we wanted to roll this out to our user base.

As you may have guessed already, wrapping this feature in a feature flag would give us the perfect control needed to plan a feature release to our users either through incremental roll-out via user segmentation or performing an all-out release.

We will examine how we can accomplish this by creating a Next.js application that incorporates the aforementioned feature with a feature flag in a step by step process.

Requirements:

Basic knowledge of Next.js.
You’ve local installation of Node and NPM.

Step 1: Create a New Feature Flag Using a Feature Flagging Service

Rather than going through the hassle of building and managing an actual feature flag from scratch, I’ll be using ConfigCat – a company that offers feature flags as a service – to create and remotely manage our feature flag from its dashboard.

So quickly jump to ConfigCat and create a free account, then:

Navigate to your dashboard.
Click the ‘Add feature flag’ option and provide the required details about the flag.
Copy the ConfigCat SDK Key (this will be needed to enable us to connect our Next.js app to our feature flag).

Step 2: Configure and Set Targeting Rules for the Feature Flag

As a feature flag management service, ConfigCat provides multiple ways to target your users with feature flags to achieve a controlled feature release. This can be done by targeting a certain percentage of your traffic allocation or through user segmentation where you can specify the target audience for your feature release based on a list of predefined (or custom) shared attributes such as location, gender, age, etc.

To keep things simple, I'll be using the default settings – which is to target all users.

Step 3: Creating the Base Version of the Next.js App

Now that we have our feature flag ready, It’s time for us to create our Next.js application. We’ll start by running create-next-app in the command line to quickly bootstrap a Next.js application for us.

    npx create-next-app

Afterwards, we run the following command to launch our dev environment and have our starter template demo page ready:

    npm run dev

Step 4: Create Random User Generator Feature in Next.js Application

There are two ways that Next.js pre-renders web pages: Static Generation and Server-side Rendering. In Static Generation, the pages are generated at build time while in Server-side rendering, the page is generated on the server on each request before being sent to the client.

We will be taking the Server-side rendering route because we will be using a third party Random User API to get new random user data on each user request (whenever the page is loaded/reloaded).

Let’s get to it.

I’ll start by emptying the root index.js file responsible for the home page of our demo application and then creating an export getServerSideProps function that would be responsible for making requests on the server before the page is generated.

    // This runs on the server on each request
    export async function getServerSideProps() {
      // Fetch random user data from external API
      const res = await fetch("https://randomuser.me/api/");
      const data = await res.json();

      // Return data to page via props
      return { props: { data: data.results } };
    }

This random user API returns an array containing an object of randomly generated user details:

After making the request on the server, the next step is to make use of the data in our component’s template and render the required user details.

    // Page Component
    export default function Home({ data }) {
      // Extract the required user details
      const firstName = data[0].name.first;
      const lastName = data[0].name.last;
      const image = data[0].picture.large;
      const gender = data[0].gender;
      const location = data[0].location.country;

      // Generated page Template
      return (
        <div className='card'>
          <img src={image} class={gender} />
          <h2>{`${firstName} ${lastName}`}</h2>
          <p><span>Gender: </span> {gender}</p>
          <p><span>Location: </span>{location}</p>
        </div>
      );
    }

With that, we have a Next.js app that generates random user details on each page load/reload:

That’s pretty much it, we now have a fully working random user generator feature in our Next.js application.

Step 5: Connecting the Next.js Application to ConfigCat and Integrating the Feature Flag

Now that we have our feature ready, it’s time to connect our Next.js application to our feature flagging service provider, before proceeding to integrate the random user generator feature with our feature flag.

Since we intend to use ConfigCat, I will start by installing their JavaScript (SSR) SDK via NPM - this is required to connect our application to ConfigCat:

    npm i configcat-js-ssr

Afterwards, I’ll import the installed package into our root index.js component and refactor our getServerSideProps function by initializing the package using the SDK key copied from the dashboard (i.e. connect our application to ConfigCat using the SDK key):

    import * as configcat from "configcat-js-ssr";

    // This runs on the server on each request
    export async function getServerSideProps() {
      // Initialize ConfigCatClient with your SDK Key:
      const configCatClient = configcat.createClient(
        "fK7ZCApWbkaDu14njPKZQw/vBw-jxALN0eiWNilfwboGA");

      // Check the state of the feature flag
      const randomUserFlag = await configCatClient.getValueAsync(
        "randomuserflag", false);

      // Fetch random user data from external API
      const res = await fetch("https://randomuser.me/api/");
      const data = await res.json();

      // Return flag's state and dat to page via props
      return { props: { randomUserFlag, data: data.results } };
    }

The next step is to refactor the template to only render the random profile card if the feature flag is toggled on, and to otherwise render a different message:

    // Page Component
    export default function Home({ data, randomUserFlag }) {
      // Extract the required user details
      const firstName = data[0].name.first;
      const lastName = data[0].name.last;
      const image = data[0].picture.large;
      const gender = data[0].gender;
      const location = data[0].location.country;

      // Page Template
      return (
        <>
          {randomUserFlag && (
            <div className='card'>
              <img src={image} class={gender} />
              <h2>{`${firstName} ${lastName}`}</h2>
              <p><span>Gender: </span> {gender}</p>
              <p><span>Location: </span>{location}</p>
            </div>
          )}
          {!randomUserFlag && <p>Feature has been toggled off</p>}
        </>
      );
    }

With that final touch, our feature flag now has control over our random profile card. If we toggle on the feature flag:

Our users would have access to the random profile card generator:

But when the feature flag is toggled off:

Our users have no access to the feature:

Final thoughts

We have seen how feature flagging takes a simple concept - choosing between different code paths at runtime - to help teams introduce features in a controlled manner while in production.

Through feature flagging, you can ship code more frequently, test in production, perform canary deployment and master feature releases to deliver high-quality software while also reducing some of the risks that come with continuous deployment.

You may find the following links helpful if you'd like to explore further:

More information about ConfigCat can be found on its Facebook, Twitter and LinkedIn pages.

Using Feature Flags in a Remix Application

David Herbert💻🚀 — Tue, 05 Apr 2022 06:36:52 +0000

Remix, the React-based full-stack framework for building server-rendered applications, has been generating a lot of buzz lately, especially since it was open-sourced. Remix is a dedicated Server-Side Rendering (SSR) framework for building web applications that are rendered on the server.

Feature Flag Basics

Fundamentally, a feature flag is nothing more than a simple variable that can be remotely set to true or false. It is mostly used as feature switches to toggle on/off a section of a piece of code, usually a functionality or feature that is wrapped in a conditional if statement that uses the feature flag's value for its logic.

Here's a generic code snippet that demonstrates how a feature flag works in its simplest form:

const theFeatureFlag = true

if (theFeatureFlag === true ) {
     // execute the code here i.e enable this functionality
          }

Rather than doing a risky all-out deployment or launch, feature flags allow you to slowly roll out features through user segmentation and easily decouple code from deployment, which can be extremely helpful in a production environment when used in continuous integration and continuous delivery cycle. They also have a lot of other use cases, outside of just these.

Building a Hacker News Trending Feed with Remix

To demonstrate how we can use feature flags in a Remix application, we will start by building a simple Remix app that pulls trending news stories from the popular Hacker News website using the unofficial Hacker News Search API on Algolia.

The idea is to create a news feed that displays the top 20 trending news and then proceed to wrap this feed functionality in a feature flag that is hosted on ConfigCat. Whenever the flag is toggled on, the user visiting the site is shown the top 20 trending news. When the flag is toggled off the user is unable to see this trending news feed.

Let’s get started!

Prerequisites

Basic knowledge of React and Remix.
Local installation of Node.js and NPM.
A ConfigCat account which will be used to create the feature flag. Register now – It’s free.

Initializing our Remix App for our Feature Flag

Here is the source code to the sample Remix app on GitHub if you want to follow along. We’ll start by quickly spinning up a working Remix demo app using the create remix command.

npx create-remix@latest

This would present us with an interactive welcome screen prompting us to select where and what should be included in our demo app. In the end, we’d be prompted to run npm install to install all of our dependencies.

Now that we have a working demo Remix app, let’s proceed to build our Hacker News feed for our feature flag. We’ll start by creating a loader function in our Remix root component that runs on the server - this allows us to make API calls on the server before the app is rendered.

import styleURL from "~/styles/global.css";
import { useLoaderData } from "remix";

// Runs on the server - for api calls
export const loader = async () => {
  // fetch stories from HN
  const stories = await fetch(
    "https://hn.algolia.com/api/v1/search?tags=front_page"
  );
  const newsFeed = await stories.json();

  // return stories to App component
  return [newsFeed.hits];
};

We have successfully created a fetch request that pulls in the desired stories from Hacker News and returns it as an array of news stories. Next, we’ll proceed to create our actual HTML template where we will loop through this returned array and render the news as ordered list items.

export default function App() {
  // get access to the stories in the loader function created above
  const [newsFeed] = useLoaderData();

  return (
    <html lang='en'>
      <head>
        <meta charSet='UTF-8' />
        <meta http-equiv='X-UA-Compatible' content='IE=edge' />
        <meta name='viewport' content='width=device-width, initial-scale=1.0' />
        <link rel='stylesheet' href={styleURL} />
        <title>Demo Feature Flag</title>
      </head>

      <body>
        <div>
          <h1>Trending Hacker News Feed</h1>

          <ol>
            {newsFeed.map((story) => (
              <li key={story.id}>
                <a href={story.url}>{story.title}</a>
              </li>
            ))}
          </ol>

        </div>
      </body>
    </html>
  );
}

With that we should now have a working Hacker News Feed that renders the top 20 trending news stories as shown below.

Setting up a Feature Flag on ConfigCat's Dashboard

To create a new feature flag, sign in to your ConfigCat dashboard. In the upper-left corner of your dashboard you can create a new config file or use the default ‘main’ config.
After which, select the ‘Add Feature Flag’ option that allows you create new feature switches and give your flag a name and key value that would be used to access the flag in your application code.

Lastly, copy the SDK key as it would be needed to connect your application to the dashboard.

There are also targeting options to configure how to serve the feature flag through user segmentation, but to keep things simple we will only be using the default settings - which is to target all.

Initializing the Feature Flag Service SDK in Our Remix App

Feature flag management solutions rely on SDKs. The SDK is installed into your application code where it communicates with the feature flag management service to determine what state the feature flags are in and checks the configuration rules for how they are to be served, i.e what users to target. Additionally, some companies' SDKs like that of ConfigCat are generally open source and safe, but this is not the same for all companies.

To use the ConfigCat Feature Flagging service, we have to install the ConfigCat SSR Package in our application via NPM.

npm i configcat-js-ssr

We will now import the package into our root App component and then initialize it in our loader function with the SDK key that we copied earlier. This would connect our Remix application to our ConfigCat dashboard.

So, let’s refactor our initial loader function to include just that.

import styleURL from "~/styles/global.css";
import { useLoaderData } from "remix";
import * as configCat from "configcat-js-ssr";

// Runs on the server - for api calls
export const loader = async () => {

  // Connect to your ConfigCat's dashboard
  const configCatClient = configCat.createClient(
    "fK7ZCApWbkaDu14njPKZQw/vBw-jxALN0eiWNilfwboGA"
  );

  // Check and store status of feature flag
  const newsFeedFlag = await configCatClient.getValueAsync(
    "newsfeedfeatureflag",
    false
  );

  // Fetch stories from Hacker News
  const stories = await fetch(
    "https://hn.algolia.com/api/v1/search?tags=front_page"
  );
  const newsFeed = await stories.json();

  // return stories and status of the feature flag to App component
  return [newsFeed.hits, newsFeedFlag];
};

Controlling the News Feed Functionality with a Feature Flag

Now that we have access to the status of the feature flag in our ConfigCat dashboard, let’s refactor our initial HTML template using a ternary operator to condition whether the news feed is visible or not, depending on the state of the feature flag.

export default function App() {
   // Get access to the stories and state of feature flag in the loader function created above
  const [newsFeed, newsFeedFlag] = useLoaderData();

  return (
    <html lang='en'>
      <head>
        <meta charset='UTF-8' />
        <meta http-equiv='X-UA-Compatible' content='IE=edge' />
        <meta name='viewport' content='width=device-width, initial-scale=1.0' />
        <link rel='stylesheet' href={styleURL} />
        <title>Demo Feature Flag</title>
      </head>

      <body>
        <div>
          <h1>Trending Hacker News Feed</h1>

          {newsFeedFlag ? (
            <ol>
              {newsFeed.map((story) => (
                <li key={story.id}>
                  <a href={story.url}>{story.title}</a>
                </li>
              ))}
            </ol>

          ) : (
            <h2>Ops! News Feed unavailable</h2>
          )}
        </div>
      </body>
    </html>
  );
}

We can now control our news feed feature from our ConfigCat dashboard using feature toggles. When the feature flag is toggled off, the news feed would be disabled and the user won’t have access to it as shown below.

But when the feature is toggled back on, the user is given access to the news feed.

The Remix sample app on GitHub

Key Takeaways

As seen in the Remix application built above, feature flags make it rather easy to remotely control or release features in your application. With feature flags developers, testers, and IT personnel can basically turn on or off certain functionality and perform targeted releases through user segmentation without affecting the existing application infrastructure.

However, it is not your team's core competency to build a feature flagging system as it may distract them from their main development process. The need for a feature flag management service is therefore essential as feature flags help you take control of your future releases.

For more, you can follow ConfigCat on Facebook, Twitter and LinkedIn.

How to do Canary Release / Progressive Delivery with ConfigCat

David Herbert💻🚀 — Wed, 16 Feb 2022 10:42:51 +0000

In this post, we’ll look at how we can easily implement a canary release of a feature in 7 steps using ConfigCat’s feature flagging service through its provided dashboard.

This step-by-step guide will showcase how we can release a new feature incrementally, by first exposing it to low-risk user groups (e.g. team members and possibly friends), and then gradually releasing it to a larger audience - using ConfigCat, a feature flag service to implement everything.

So let’s get right to it. The assumption is that we have logged into our ConfigCat’s dashboard and successfully implemented an instance of a feature flag named “Facebook Sharing Enabled” in our application.

Step 1 - Unreleased State

We’ll take it from the start, where we have our feature flag set up and initially toggled off for all users.

Step 2 - Releasing Only to Team Members

Following that, we need to release the feature to only team members. This allows you to get immediate feedback from your team.

Step 3 - Releasing to Team Members and Friends

Afterwards, we proceed to include friends or people in your circle that you have a good relationship with in the feature’s release by having it available to only team members and these people. This allows you to get feedback from real users who will be cooperative with you.

Step 4 - Releasing to 1% of Users - But No Sensitive Users

If more feedback is needed, the next step would be to have it released to random people, say 1% of users - making sure to exclude the most risky users (i.e those with high expectations and a lot of money). In the screenshot, we’ve targeted those users from the United States as our sensitive users.

Step 5 - Releasing to 5% of Users - But No Sensitive Users

Now, we proceed to release it to even more random people - say 5% of users, but still excluding any sensitive users. Now we have our feature available to team members, friends, and 5% of our user base - excluding sensitive users.

Step 6 - Releasing to Everyone Except Sensitive Users

The next step is to have the feature available to everyone except our sensitive users. At this point, enough confidence has been gained from the received feedback to test it on everyone. The next step is to have the feature available to everyone except our sensitive users.

Step 7 - Releasing to Everyone

If all errors have been fixed, UI-glitches corrected, and all the test users are happy with the feature then it’s finally safe to release it to our entire user base - including the sensitive users.

Conclusion

As we have seen, implementing a canary feature release is no rocket science, especially when using ConfigCat as it provides a feature management service, with an easy to use dashboard that makes it convenient and intuitive to do just that. Even a non-technical team member can handle canary releases with ConfigCat’s 10 minutes trainable feature flag and configuration management service.

How To Use Feature Flags in Vue.JS

David Herbert💻🚀 — Sun, 30 Jan 2022 13:44:57 +0000

Feature flags have made it easier than ever to continuously test and integrate new features in our applications with confidence, even while in a production environment without having to worry about deployment risks like downtimes or bugs that could greatly impact the experience of the entire user base.

What are Feature Flags?

Feature Flags are conditional statements like an if/else block of code that provides the ability to switch certain functionalities or features on/off in an application. They return a boolean value that you or anyone else from your team is able to remotely set from the ConfigCat dashboard without deploying code. This feature flagging technique allows logic to be provided only to certain groups or subsets of users at a time by building conditional feature branches into deployed code. During runtime, the code is executed if the flag is toggled on, but is skipped if the flag is off.

Why use feature flags?

Features flags can be applied to a wide variety of use-cases, ranging from the simplest to the most advanced scenarios in the modern software development workflow. But to list a few that reflect their usefulness:

Facilitates Beta testing & A/B testing.
Easily rollback a feature using kill switch.
Decouple new features from deployment without deploying new code.
Allows non-technical people to manage feature releases.
Facilitate subscription/membership-based access to features.
Safely push to production more often with a shorter release cycle.
Mitigates typical deployment risks like bugs and downtimes.
Useful for special use case scenarios - like enabling/disabling maintenance mode.

As you can see, there are a lot of benefits associated with feature flags and why you’d want to use them in your application.

How To Use Feature Flags in VueJS

Now that we know what feature flags are, and why we’d want to use them. Let’s jump right to how we can use these feature flags in a VueJS application. For this, we’ll be using ConfigCat’s feature flagging service.

ConfigCat allows you to manage features in your application without needing to redeploy code. These features can be rolled-out in batches to certain percentages of users and provide the ability to target specific user groups based on user profile attributes such as geo-location or other custom attributes. All of this is also provided on a web-based interface where feature flags can be toggled on/off which is very convenient for non-technical people as there is no need to edit config files. Everything in the ConfigCat dashboard can also be accessed programmatically through the public management API

Sample Application

To keep things simple and straightforward, we will be creating a calculateAge Feature in a simple VueJS Application that allows users to calculate their age. This sample app would have a form that receives a users birth year and returns the calculated age. However, this feature would only be made available to users when we toggle the feature on from our ConfigCat dashboard. So let’s get to work.

Prerequisite

Basic understanding of VueJS.
NodeJS and NPM installed.
Code Editor

Creating a VueJS Application

Let’s jump right into our code editor and start by first installing the VueJS CLI - which provides some Vue commands which makes it easy to quickly scaffold a demo app in VueJS.

npm install -g vue@cli

Next, we’ll create a new VueJS application from the command line using the Vue create command.

vue create my-project

This quickly spins up a “my-project” directory with a VueJs demo app environment setup. After choosing the default setup, it’ll install the necessary dependencies for our application. With that out of the way, we are going to install a configcat-jspackage that would enable us to be able to use ConfigCat in our VueJS application - while we are at it, we would also install a “dotenv” package because we would be needing it to store our ConfigCat SDK key in a .env file (environment variables file).

npm install configcat-js dotenv

Finally, we launch our app in the browser by running:

npm run serve

Creating a Feature Flag

That’s it, everything is up and running in the browser. To create a feature flag, let's head over to ConfigCat - if you don’t already have an account, quickly sign up for one. We’ll be using a free account for this demo. Next, log in to your account to get access to the dashboard as shown below.

Once on the dashboard, click on “add feature flag” and provide a name for the feature flag you want to be created and toggle on the values for the environment you want to use this feature flag in (for this demo, we’ll toggle on the test mode).

After saving it, we can go back to our dashboard and toggle on this feature flag, or even customize it to target specific users based on predefined or custom attributes.

To get the SDK key, you can click the view SDK key at the top right of your dashboard or scroll to the bottom of the dashboard where you’re shown how to connect your application to ConfigCat.

Copy the code as it would be needed to get access to this account - go ahead and store this in your “.env” file in the VueJS application.

Creating a Feature and Connecting it to ConfigCat

Now let’s jump back to our VueJS application and create a simple VueJS template consisting of a form that lets users calculate their age in the root App.vue directory.

<template>
    <div id="app">
        <button class='btn' @click='getUserAgeFeatureStatus'>
            Calculate Age
        </button>

        <p v-if='!userAgeFeature && !loading' class='text'>Sorry, This feature has been disabled by the Admin</p>
        <p v-else-if="error">{error}</p>

        <div v-else-if='userAgeFeature'>
            <p class='text'>Calculate your age below by providing your year of birth</p>
            <input
                type='number'
                v-model='birthYear'
            />
            <button class='btn btn-calculate' @click='calcAge'>
                Calculate
            </button>

            <p v-if='age'>You are {{ age }} years old</p>
        </div>
    </div>
</template>

In this sample example, we have designed a template with just a button indicating the feature. If the feature has been turned off, it should display a message to the user showing the feature is not accessible but if the feature is available for the user, there should be an input field and button for the user to calculate age.

Next, we would need to import ConfigCat where we need to use it like in the below snippet.

Then create a configcat.client() object and pass it the SDK key we got from our dashboard.

Also, we are going to add some states to the data property to be able to keep track of their values. We would have the userAgeFeature which would help us to know the state of the feature, the error to keep track of any error that occurs, the birthYear and age to keep track of the birthYear and age of the user respectively.

Lastly, we would then create the getUserAgeFeatureStatus method to check for the state of the feature in ConfigCat.

Source file

To reiterate what we just did, firstly, an instance of the client is created with the client SDK detail which is being stored in a variable.

try {
                let configCatClient = configCat.createClient(
                    process.env.VUE_APP_CONFIGCAT_SDK
                );

The SDK key has been stored in the .env file in the base directory for security purposes. To avoid errors, please make sure you use the same name as your .env file after process.env.

Then, we await the response from getting the status of a particular feature.

const res = await configCatClient.getValueAsync(
                    "isMyFirstFeatureEnabled",
                    false
                );
                this.userAgeFeature = res

The first argument is the feature flag’s name on the ConfigCat dashboard while the second argument is the default value. The response returned is a boolean, either true or false. This response is then saved in the userAgeFeature state.

Lastly, we check if there was an error - which is handled by the error state that receives the error message.

} catch (err) {
                this.error = err.message
            }
  }

The getUserAgeFeatureStatus is then bound to the HTML by an on click event as shown below:

<button class='btn' @click='getUserAgeFeatureStatus'>
            Calculate Age
 </button>

Based on the state of the feature in the dashboard, if the Calculate Age Button is clicked, it checks the status of the feature on the client ConfigCat’s dashboard. If it is false i.e turned off, a message is displayed to notify the user that the feature is currently disabled.

But if it is true i.e turned on, the user is able to use the calculateAge feature to calculate their age.

Source Code

Conclusion

If you aren't using feature flags, you're probably missing out on the perfect tool for mastering your development cycles and feature releases. As you have seen, it’s quite easy to implement feature flags in your VueJS application using ConfigCat’s feature flagging service.

In just 10 minutes of training, even team members who are not technically inclined can learn and use ConfigCat's feature flag solution to gain control over feature releases. You can learn more on their How it Works page.

If you found this article interesting, you can also checkout how to implement ConfigCats's feature flag in React.