--- url: 'https://altinity.com/webinarspage/live-coding-with-moosestack-lets-ship-real-time-dashboards-and-ai-chat-powered-by-clickhouse' title: 'Live-coding with MooseStack: Let’s ship real-time dashboards and AI chat powered by ClickHouse®' author: name: Cristina Munteanu url: 'https://altinity.com/author/cmunteanu/' date: '2026-02-10T10:16:00-08:00' modified: '2026-06-09T18:23:11-07:00' type: post summary: 'Josh Lee (Altinity) and Chris Crane (Fiveonefour) demonstrate MooseStack, an open-source TypeScript/Python developer framework that bundles ClickHouse®, Kafka/RedPanda, Temporal, and Redis into a single real-time analytics backend. Watch a live-coding session where they build a Bluesky firehose dashboard with MCP-powered...' categories: - Webinars tags: - AI-clickhouse image: 'https://altinity.com/wp-content/uploads/2026/01/Live-coding-with-MooseStack-webinar.png' published: true --- # Live-coding with MooseStack: Let’s ship real-time dashboards and AI chat powered by ClickHouse® **Recorded**: February 10 @ 08:00 am PST **Presenters**: Joshua Lee & Chris Crane In this live-coding webinar, Josh Lee (Open Source Advocate, Altinity) and Chris  Crane (Co-founder and Head of Product, Fiveonefour) walk through MooseStack, Fiveonefour’s open-source developer framework for embedding real-time analytical infrastructure into applications. The session uses MooseSky, a Bluesky firehose analytics dashboard built by Josh using Claude Code, as the live demo application. MooseSky ingests every post on the Bluesky social network via a WebSocket firehose, buffers them through a RedPanda/Kafka stream, writes them to ClickHouse, runs a word-frequency transformation workflow, pre-aggregates word trends into a SummingMergeTree materialized view at 10-second granularity, and exposes everything through a REST API and a custom MCP server that powers in-dashboard AI chat. Chris explains the architectural problem MooseStack solves: adding OLAP capabilities to a transactional application normally requires assembling, operating, and maintaining a streaming buffer, a validation layer, ClickHouse itself, workflow orchestration, and custom APIs. MooseStack bundles all of this together as code, using TypeScript interfaces for schemas that propagate automatically to Kafka topics, ClickHouse tables, ingest APIs, and streaming functions. This gives both human developers and AI coding agents a single code-defined surface to work against, eliminating the need for manual DDL management and giving type-safe autocomplete across the entire pipeline. The live-coding portion demonstrates two changes: Claude strips a Redis cache from the trends API endpoint (live-reloading in under a minute), and then adds a word-category column to the ClickHouse schema (including a Kafka topic update, transformation logic changes, a materialized view update, and an API update) in roughly nine minutes of total agent time. The session closes with a look at Fiveonefour’s Boreal Cloud hosting platform and its Vercel-style preview branch deployments for ClickHouse -backed applications. **Here are the slides:** [Live-coding with MooseStack Let’s ship real-time dashboards and AI chat powered by ClickHouse®](https://altinity.com/wp-content/uploads/2026/02/Live-coding-with-MooseStack-Lets-ship-real-time-dashboards-and-AI-chat-powered-by-ClickHouse®.pdf)[Download](https://altinity.com/wp-content/uploads/2026/02/Live-coding-with-MooseStack-Lets-ship-real-time-dashboards-and-AI-chat-powered-by-ClickHouse®.pdf) ## **Key Moments (Timestamps)** Key moments generated with AI assistance. - 00:04 – Welcome, speaker introductions: Josh Lee (Altinity) and Chris  Crane (Fiveonefour/MooseStack) - 00:59 – Altinity overview: cloud, enterprise support, Kubernetes Operator, Project Antalya - 01:25 – Fiveonefour overview: MooseStack and Boreal Cloud integrate natively with Altinity - 02:08 – Demo overview: MooseSky, a Bluesky firehose dashboard with MCP AI chat - 03:23 – Live demo: the dashboard, word trend graphs, and asking the data questions via MCP - 05:47 – Why adding OLAP to an existing application is harder than it looks - 08:10 – MooseStack’s modules: schemas as code, streaming, APIs, workflows, MCP - 11:03 – The local dev experience: moose dev hot-swaps ClickHouse, Kafka, and APIs - 12:29 – Code walkthrough: the Temporal workflow ingesting the Bluesky WebSocket firehose - 14:00 – Claude Code built this: how schema-as-code makes AI-assisted development reliable - 16:59 – Models: TypeScript interfaces for BlueskyPost and WordOccurrence - 17:34 – Pipelines: ingest APIs, Kafka topics, and ClickHouse tables from a single definition - 19:27 – The architecture diagram: firehose → workflow → RedPanda → ClickHouse → materialized view → API + MCP - 20:57 – Trends API: raw SQL over typed TypeScript objects, end-to-end type safety - 24:16 – Anecdote: the Black Friday schema break at Nike that inspired MooseStack - 26:57 – Live coding #1: removing the Redis cache with Claude (under 1 minute) - 30:09 – MCP servers: the Moose dev server MCP and the ClickHouse MCP for debugging - 35:27 – Live coding #2: adding a word category/NSFW column to the schema (9 minutes) - 43:20 – Schema migration discussion: development vs. production behavior - 44:36 – Live demo: querying the AI chat for top swear words - 46:43 – Live coding #3: regenerating the architecture diagram using the Moose infra map MCP - 53:17 – Boreal Cloud: CI/CD, preview branches, and seeding staging with production data - 55:34 – Q&A: Vue.js compatibility, NATS support plans --- ## **Webinar Transcript** ### **[00:04] – Welcome and Speaker Introductions** **Josh:** Hello everybody and welcome to live coding with MooseStack. This is going to be a live coding session with MooseStack from Fiveonefour. I am Josh Lee. I am an open source advocate at Altinity. I’m joined by Chris. **Chris:** Hey folks. Chris  Crane, co-founder and head of product at Fiveonefour. We’re the creators of the MooseStack open-source dev framework. We create dev tools and cloud infrastructure that help developers incorporate real-time analytical infrastructure into your applications and your AI agents. Excited to be here. Thanks for having me, Josh. **Josh:** I’m really excited to have you on here. I’ve been having a lot of fun playing around with MooseStack and Boreal Cloud. I’m just excited to show it all off to everybody. --- ### **[00:59] – About Altinity and Fiveonefour** **Josh:** Altinity is the place to run open source ClickHouse better. We offer both a managed cloud as well as enterprise support, and [Bring Your Own Cloud and Bring Your Own Kubernetes](https://altinity.com/managed-clickhouse/bring-your-own-cloud/) offerings. Our lawyers did want me to point out that we’re not affiliated with ClickHouse, Inc. We’re just humble open-source contributors and big fans of the project. **Chris:** Fiveonefour’s commercial hosting platform integrates natively with Altinity so you can bring your own ClickHouse cluster from Altinity. We help you package up real-time analytical infrastructure that’s often necessary to power these kinds of workloads in a user-facing or internal application. Josh is going to be showing off our open-source tool stack today. --- ### **[02:08] – Demo Overview: MooseSky** **Josh:** We’re going to be taking a look at MooseStack. The demo application I spun up is called MooseSky. This is inspired by a project we did last year that ingested the Bluesky firehose, which has all of the posts going to Bluesky in real time. I decided to recreate it using MooseStack, and it was so much easier. We’re going to talk about some of the tools I had available that allowed me to make this more of a robust, production-like toy. It still is kind of a toy application, but it has all the things that most toys would not have, like Kafka buffers, heartbeats, and observability. --- ### **[03:23] – Live Demo: The Dashboard and MCP AI Chat** **Josh:** MooseSky has two main components: a backend ingestion pipeline and API, and a React frontend that creates a dashboard interface with a chat interface. Part of MooseStack is the ability to run long-running workflows, which we’ll talk about in more detail. We have a workflow running here that’s ingesting the Bluesky firehose and writing all of the posts to ClickHouse as well as to a Kafka stream, where they can then be processed and also written to other ClickHouse tables. That gives us this dashboard where we can look at any time frame within the last 24 hours. We can look at specific words. ClickHouse’s columnar storage and OLAP features give us 10-second granularity for the last 24 hours. All of these posts that include the word “because” or “love.” Valentine’s Day is coming up, so that’s a nice one. This is in GMT, so I’m guessing this dip is when the majority of Bluesky users were sleeping. We can also talk to the data. I’ve already got an MCP API set up as part of the MooseStack backend. But I can ask something like: what are the most popular words in the last three hours? It’s hooked up to the API and one of the things it can do is run a ClickHouse query. It went ahead and did that. We can see the query that it ran and it gets us the top 10 words over the last three hours. --- ### **[05:47] – The Problem: Why Adding OLAP to an Application Is Hard** **Chris:** One thing I love about that demo is how snappy the dashboard is and how quick the LLM responses are. That shows you the power of having ClickHouse power these queries. If you’re looking to bring real-time dashboards and AI chat into your application, this architecture probably looks pretty familiar. It’s a common pattern for what it looks like to integrate this kind of functionality into an existing application that typically starts out powered by a transactional backend like Postgres. Adding OLAP capabilities to your backend is usually not as simple as spinning up a ClickHouse database and pointing your transactional queries at it. There’s a whole bunch more that goes into it. You’re probably going to want some kind of data pipelining component, whether that’s change data capture or ETL. You’ll want ingest APIs that validate data on the way in. You probably want some kind of streaming buffer sitting in front of ClickHouse to optimize and batch writes, or stream data to other destinations. And then you’re going to need to build APIs, MCPs, or whatever programmatic interfaces you want on top of ClickHouse, and integrate those all the way through to your front end. This adds a fair bit of complexity. What we’ve tried to do with MooseStack is give you a bunch of that tooling out of the box, wrapped up as Lego blocks that you can assemble into whatever architecture you want, all as code in TypeScript or Python, in languages that integrate naturally into your application. --- ### **[08:10] – MooseStack’s Modules** **Chris:** When you’re using the MooseStack framework, you’ve got different modules within Moose that correspond to the different parts of the backend you want to build. Josh is going to show how he used almost all of these modules in the demo. One of the core things you get with MooseStack is what I call ClickHouse as code. Instead of only interacting with the underlying database via DDLs and SQL commands and managing it all manually, you’re going to get schemas as TypeScript interfaces or Python classes, migration management capabilities, and lineage and tracing. We’ve taken OLAP and made it developer friendly, giving you ORM-inspired functionality you may be used to from your Postgres world, but for ClickHouse. There’s also this integrated stack that’s application-ready. It’s not just ClickHouse, but Kafka or RedPanda for streaming, Temporal for workflow orchestration, Redis for caching. You get all of this orchestrated together out of the box, with best practices baked into the abstractions. --- ### **[11:03] – The Local Dev Experience: ****moose dev** **Chris:** What this all adds up to is a really AI-native and local developer experience. Josh is going to be running the whole MooseStack locally on his laptop. You get all of this automatically running with a single command: moose dev. That means as a developer or even as an AI agent writing code, your changes are automatically hot-swapped into the underlying infrastructure. You get an instant feedback loop, full context for AI, logs, and errors. All of that can feed back to help the AI iterate and build just like you would as a human developer. --- ### **[12:29] – Code Walkthrough: The Bluesky Firehose Workflow** **Josh:** Let’s look at the code. I’m going to start with the workflow because that’s what kicks everything off. This workflow is defined as a MooseStack workflow object, which can be triggered by an API call and then tracked inside Temporal. It kicks off a task that connects to the WebSocket of the Bluesky firehose and starts streaming the data directly to the Kafka topic. I ended up switching from an HTTP ingestion API to direct Kafka streaming because the HTTP approach was a little slow for catching up with historical data on the Bluesky firehose. Another cool point: all of the code for this was essentially written by Claude Code. I didn’t one-shot it, but over the course of a few hours, which was very fast in my opinion, I was able to guide Claude to build this up piece by piece. All corrections were made by telling Claude to fix its own mistakes. That’s pretty powerful. --- ### **[14:00] – Why Schema-as-Code Makes AI-Assisted Development Reliable** **Josh:** I think that’s probably my second favorite thing about this whole stack. Because it’s so opinionated about the tools you’re using, I didn’t have to spend four hours writing Dockerfiles and Docker Compose files and then giving Claude context on how to work with all that. It’s just opinionated. You get the same tools every time. So then you’re just writing business logic. And because everything, including your schemas, is code, you and the LLM have the same data to reason about the shape of the system without having to run commands to investigate it. You can just look at the code to see what everything is. **Chris:** That’s a big part of our core philosophy: not fully abstracting away the underlying SQL, especially with ClickHouse. A lot of the power comes from the nuance of the SQL there. We want to give you full control of your underlying infrastructure, full visibility, full transparency, but also give you the ergonomics and tooling to help you move faster and less dangerously. --- ### **[16:59] – Models: TypeScript Interfaces for BlueskyPost and WordOccurrence** **Josh:** We have a model for our BlueskyPost. This is for the raw post data that’s actually coming off the firehose. It just gets persisted as is. We also have a WordOccurrence model, which counts the occurrences of individual words as we analyze these posts. This is happening inside one of those workflows. --- ### **[17:34] – Pipelines: One Definition, Four Artifacts** **Josh:** Then we have a post pipeline. This automatically takes that schema and sets up both an ingestion API you can hit, the Kafka stream, and the ClickHouse tables that go along with all of that. It automatically sets up the persistence to the ClickHouse table from the Kafka stream. Really convenient. We have another one for WordOccurrence. We’re not setting up an API for that one because it’s internal, but we are streaming it and persisting it. What this does is give you a TypeScript hook to interact with that underlying infrastructure. In the workflow, we’re calling blueSkyPostPipeline.stream(), which references the underlying RedPanda stream that’s part of that pipeline, and with a simple send() function we can drop events in that match the schema defined with the TypeScript interface. --- ### **[19:27] – The Architecture** **Josh:** Here’s the architecture. We have the workflow ingesting the WebSocket, going to a RedPanda topic, getting persisted immediately to ClickHouse, going through another transforming workflow, another RedPanda topic, another ClickHouse persistence, and finally a [materialized view](https://altinity.com/blog/clickhouse-materialized-views-illuminated-part-1). Materialized views in ClickHouse are a way to create projections of data that you know you want to query based on certain dimensions, pre-laying out that data. The word trends materialized view uses a SummingMergeTree engine to sum up all instances of unique words over 10-second intervals. Because we’re writing word occurrences every second, there will be multiple entries per word per 10-second interval. --- ### **[20:57] – Trends API: Raw SQL Over Typed TypeScript Objects** **Josh:** Here is the trends API endpoint. You can see the query for this endpoint. We’re selecting the top trends using type-hinting from the schema objects we have defined, writing the whole query, and returning the JSON. Pretty straightforward API endpoint code, similar to Express. One of the things I love about this: you’ve got the raw SQL, so you can see what’s actually happening under the hood. But instead of referencing hard-coded SQL column names, we’re referencing the TypeScript objects from the TypeScript interface. That gives you autocomplete ergonomics as a developer, but it also gives you compliance, governance, and software development lifecycle benefits. In the real world, it’s not just one developer working on this codebase. You might have a front-end team, an API team, another team working on the database and schemas. What you get now is: if someone changes the underlying schema of the database by modifying the TypeScript interface in the models file, in real time they’re going to see that this is breaking the downstream code because that interface is used by this query downstream. You get that for free because it’s just TypeScript. Your linter, your compiler, your real-time IDE checking will flag this out of the box. **Chris:** Build-time errors are so much better than runtime errors. And because you’re running the exact same thing locally on your laptop as you would run in production, the local feedback loop is instant. --- ### **[24:16] – Anecdote: The Black Friday Schema Break at Nike** **Chris:** Before starting Fiveonefour, my co-founders and I worked at Nike running global data engineering. One of the inspirations for this product from the very start was: the day before Black Friday, one of our data engineers pushed a change to the streaming data pipeline that was capturing all of the real-time data coming from the Nike website. It turned out they changed the schema, and it broke the recommendation engine downstream from that. The Nike recommendation engine was down for some very bad number of hours over Black Friday. It ended up being a many-million dollar impacting event. That’s the kind of thing we want to prevent by bringing TypeScript, by bringing development best practices, by bringing infrastructure as code and the software development lifecycle to the world of analytical infrastructure and classic data engineering workloads. If we had had something like this in place, I’d like to believe that would have been caught. --- ### **[26:57] – Live Coding #1: Removing the Redis Cache** **Josh:** All right, let’s do some live coding. One suggestion was to strip out the Redis cache that had somehow crept into the API endpoint and show the real-time data feed refreshing in the front end. Claude was kind of sneaky and snuck that cache in there. I didn’t notice, and there was this big delay in the data and I could not figure out why. There was a Redis cache in there. Clever use of Redis. Watch your AI assistants, folks. Let’s build a Claude session to remove it. [Claude removes the cache from the API endpoint. The Moose dev server hot-reloads.] That was awesome. Claude removed all the cache in about a minute. --- ### **[30:09] – MCP Servers: The Moose Dev Server MCP and the ClickHouse MCP** **Josh:** In addition to the custom MCP that we’ve built into this application and exposed through specific API endpoint tools, there’s the MCP server that’s built into Moose. That’s what Claude referenced when it built the Mermaid architecture chart. And there’s also the ClickHouse MCP, which is really useful for inspecting the [ClickHouse system tables](https://kb.altinity.com/altinity-kb-setup-and-maintenance/altinity-kb-monitoring/) to diagnose weirdness. Looking at those system tables is sort of the first place I would look to debug ClickHouse weirdness. **Chris:** The Moose dev server MCP gives you, as a developer or your copilot, tools that are helpful when you’re developing locally with MooseStack. There are tools for querying ClickHouse, tools for pulling data from RedPanda, tools for interacting with Temporal, and a getInfraMap tool that pulls the underlying map of the infrastructure from the Moose server. Under the hood, Moose is constantly keeping this metadata map of your infrastructure, all the different pieces, and how they’re tied together. That infrastructure map is what all the different capabilities of the framework are built on. **Josh:** You can also create custom MCPs for your application. If all you’ve got is an internal BI tool and you want to ask natural language questions, the built-in ClickHouse MCP might be sufficient. But when you want to start exposing that capability to other teams across your organization, or to end users, you start to want custom MCPs: building a custom interface embedded in your application, putting in authorization and authentication, adding semantic context with prompt engineering, adding definitions of what different words mean within your organization. When everything is code, it becomes a typical developer exercise to do these things in an mcp.ts file. --- ### **[35:27] – Live Coding #2: Adding a Word Category Column** **Josh:** Let’s implement the plan we made to tag words with categories, starting with NSFW, to add a new column to the ClickHouse schema. This will show how Moose automatically handles that migration. The question is where to implement this logic. We could do it in the front end, filtering data returned from the API. That puts more logic than we want in the front end and doesn’t take advantage of the database. We could implement it as a materialized view in ClickHouse, filtering out words. Or we could push it upstream in the streaming function, implementing it as TypeScript logic between the RedPanda streams to process events as they come in, similarly to how we’re already filtering stop words. With the upstream streaming filter, we also have the option of keeping the raw data. We could still have the raw data write to a raw data table in ClickHouse and have a processed data table where words are categorized. Instead of swear words, you could imagine filtering sensitive information, PII, or financial data. You could drop that data, mask it, encrypt it, or even make calls to an LLM within the streaming function to do probabilistic sentiment analysis. The plan I created in advance will first update the underlying models by adding a category column to the TypeScript interface, then Moose will propagate that change down into the underlying ClickHouse database and keep the whole data pipeline in sync. Then it’ll add the word list and the categorization logic in the transformation, update the materialized view, and update the API endpoint. [Claude runs through the plan, making changes to models, pipelines, transformation logic, materialized view, and API. The Moose dev server hot-reloads.] That took about nine minutes. That’s incredibly fast for a change that touches the schema, Kafka, a transformation function, a materialized view, and an API endpoint. --- ### **[43:20] – Schema Migrations: Development vs. Production** **Josh:** For a development environment, that was a great experience: it applied fresh logic to fresh data without me having to run commands. In production, you probably don’t want that to happen automatically. Moose has tools to output its migration plan as JSON that you can edit before it actually runs in production. Or how I’d probably handle it for something running against a constant stream is to have both schema versions running in parallel and versioned, with a programmatic cutover in the code rather than it happening automatically when a new version is deployed. --- ### **[44:36] – Querying the AI Chat for Top Swear Words** **Josh:** Let’s ask the chat: what are the top swear words? [The Claude MCP session queries ClickHouse and returns results.] All right, well, we updated the schema and added a category column. Claude returned a query and results. That was amazing. --- ### **[46:43] – Live Coding #3: Regenerating the Architecture Diagram** **Josh:** Let me show the Moose dev server MCP in action by regenerating the architecture diagram as a Mermaid chart. I’ll add the MCP to this session first. [Josh adds the Moose dev server MCP via the CLI command claude mcp add –transport http moose http://localhost:4000/mcp.] **Chris:** The getInfraMap tool on the Moose dev server MCP is one of the core differentiators of the Moose framework. Under the hood, it’s constantly maintaining a metadata map of your infrastructure, all the different pieces and how they’re tied together. All the different capabilities of the framework are built on top of that. [Claude calls the MCP, retrieves the infrastructure map, and generates a Mermaid diagram that is committed to the repo’s readme. GitHub renders it automatically.] So here we have our architecture: starting with the Bluesky Jetstream, the Temporal-powered workflow pulling the data and posting it to the ingest stream in Kafka, then two transformations reading off that, two tables in ClickHouse, one for raw data and one for processed data, the materialized view on top of that, and then the API and the MCP pulling from the materialized view. Pretty cool. --- ### **[53:17] – Boreal Cloud: CI/CD and Preview Branches** **Chris:** Boreal is the hosting platform from Fiveonefour, where we give you a bunch of CI/CD and path-to-production capabilities out of the box that blend elegantly with what you’ve been seeing from Josh in the demo locally. If you’re using our hosting platform, when you push new code up to GitHub, Boreal will automatically pull the latest code and update your cloud or production infrastructure based on that. It’ll track changes to main and keep production up to date using Moose migrations to do those migrations safely, with oversight but without manually running DDLs against your production database. One of my favorite features: if you’re using branches in GitHub, every time you push a new branch, Fiveonefour is automatically going to spin up a temporary staging environment or preview branch for you based on that branch. You can run it locally to test it, and also push it through CI/CD to test against a real cloud environment. You can seed both local or the preview branch with production data with a single command. It starts to give you this Vercel-like workflow, but native to ClickHouse and real-time analytics. If that sounds interesting, please check it out at 514.com. --- ### **[55:34] – Q&A** **Chris:** There was a question around using Vue.js. Yes, MooseStack will work with Vue or whatever TypeScript or JavaScript application framework you prefer. There are essentially two broad ways you can use Moose with an application framework. You can have them run separately in separate runtimes and import your Moose-defined objects into your Vue, Express, or Next.js codebase and reference those objects from your APIs or components. Or you can embed the entire application component into the Moose runtime and have its lifecycle managed by moose dev so that when you run it, it spins up the entire application stack for you. Both are viable and we have examples of both in our templates. There was also a question around using NATS instead of Kafka or RedPanda for the streaming. We don’t have plans yet, but we’re very much guided by our community road map. If there’s functionality you want to see in Moose, hop into the Slack community and let us know. **Josh:** Awesome. Thanks Chris. This has been a really awesome stack. I’m definitely going to be playing around with it a lot more. We have an office hours coming up and a webinar. Be sure to check those out at altinity.com/events. Check out the demo code. If you have feedback, Chris would love to hear it in the MooseStack Slack. I’m always happy to hear from you in the Altinity Slack and get your ClickHouse questions answered. See you all next time. **Chris:** Thanks everybody. --- ## **FAQ Section** **Q: What is MooseStack and what problem does it solve for developers?** MooseStack is an open-source developer framework from Fiveonefour that bundles the infrastructure needed to add real-time OLAP capabilities to an existing application: ClickHouse for analytics storage, Kafka or RedPanda for stream buffering, Temporal for workflow orchestration, and Redis for caching. Rather than assembling and wiring all of these together yourself, MooseStack provides TypeScript and Python abstractions that let you define schemas, pipelines, transformations, APIs, and MCP servers as code. Changes to those code definitions automatically propagate to the underlying infrastructure including ClickHouse schema migrations, Kafka topic updates, and API regeneration, with a hot-reload dev server for instant local feedback. Altinity.Cloud integrates natively with Fiveonefour so you can bring your own ClickHouse cluster from Altinity; see the [Altinity.Cloud BYOC documentation](https://docs.altinity.com/altinitycloud/quickstartguide/running-in-your-cloud-byoc/) for setup details. **Q: How does schema-as-code in MooseStack prevent the kind of production breakage it was designed to prevent?** In MooseStack, your ClickHouse table schema, your Kafka topic schema, your ingest API validation, and your downstream transformation logic all reference the same TypeScript interface or Python class. If you change the interface, your TypeScript compiler, linter, and LSP immediately flag every place in the codebase that is now type-incompatible, at edit time, before anything runs. This catches the class of schema mismatch bugs that, in traditional data engineering setups, only surface at runtime when data lands in the wrong format, often causing silent corruption or downstream failures. **Q: What ClickHouse features make this kind of real-time word-trend dashboard possible?** Three ClickHouse features are central to the MooseSky demo. First, ClickHouse’s columnar storage and compression allow very fast aggregation queries over hundreds of millions of rows. Second, the SummingMergeTree engine allows pre-aggregated counts to be stored and merged efficiently without needing to re-aggregate from raw data on every query. Third, [ClickHouse materialized views](https://altinity.com/blog/clickhouse-materialized-views-illuminated-part-1) act as insertion-triggered transforms that automatically maintain the pre-aggregated word trend table as new raw posts arrive from the Bluesky firehose, giving the dashboard its 10-second granularity with sub-second query response times. **Q: How does the MCP-powered AI chat in the demo work?** The MooseSky demo exposes a custom MCP server as part of the MooseStack backend. This MCP server provides the AI agent (Claude) with tools to query the ClickHouse database using the application’s own schema, inspect table definitions, and run analytical queries. The MooseStack dev server also exposes its own MCP with infrastructure-level tools: querying ClickHouse, reading RedPanda topics, interacting with Temporal, and retrieving a live metadata map of the entire application infrastructure. The ClickHouse system tables, accessible via the [ClickHouse system table monitoring tools](https://kb.altinity.com/altinity-kb-setup-and-maintenance/altinity-kb-monitoring/), are also available for debugging. **Q: How does MooseStack handle ClickHouse schema migrations in production vs. development?** In development, the moose dev hot-reload server automatically propagates schema changes to the underlying ClickHouse instance and Kafka topics when you save code, resetting to fresh data for new schemas. In production via Boreal Cloud, migrations are applied using Moose’s migration tooling, which outputs a migration plan as JSON that can be reviewed and edited before execution. Teams can also run dual schema versions in parallel with a programmatic cutover in code, rather than having migrations fire automatically on deploy, which is especially important for pipelines that are continuously ingesting live data. **Q: Can I use MooseStack with my existing front-end framework?** Yes. MooseStack works with any TypeScript or JavaScript front-end or backend API framework, including Vue, React, Next.js, Express, and others. You can either import Moose-defined TypeScript objects into your existing framework’s codebase and reference them from your APIs or components directly, or embed your entire application component into the Moose runtime so that Moose dev manages the lifecycle of your full application stack locally. --- © Altinity, Inc. All rights reserved. Altinity, Altinity.Cloud, and Altinity Stable are registered trademarks of Altinity, Inc. ClickHouse is a registered trademark of ClickHouse, Inc.; Altinity is not affiliated with or associated with ClickHouse, Inc. Kubernetes, MySQL, and PostgreSQL are trademarks and property of their respective owners.