Skip to main content

Dynamically scaling your Skip services

· 4 min read
Senior Engineer

Skip makes it fast and easy to build reactive services which efficiently update their outputs in response to input changes, powering real-time features and saving resources by avoiding unnecessary recomputations.

The technical foundation that makes this possible is Skip's hyper-efficient reactive computation graph, which is written in the Skip programming language, runs natively, and takes great pains to efficiently represent and manipulate the data underlying your reactive system.

However, that still requires memory, compute, and other resources -- so what do you do when traffic spikes or grows beyond the capacity of even a powerful single machine? Scale out and distribute your reactive service across more machines, of course!

React + Vite in front of a Skip Service - the template

· 2 min read
Software Engineer

Hello skippers. Today, we are introducing a new template to our collection: React + Vite. While our previous blog posts focused on building skip services, this new template represents our first step into the frontend, bringing together the best of both worlds: front and back.

npx create-skip-service my-skip-chat --template with_react_vite

What's Inside the Template?

Our React + Vite template for Skip Services comes with everything you need to get started on building a modern web application: an easy to manipulate end-to-end data flow from the user interface to the backend, and vice-versa (reactive programming enthusiasts, I have your attention now).

Getting Started

To create a new project with our React + Vite template, simply run:

npx create-skip-service my-skip-chat --template with_react_vite --verbose

cd my-skip-chat # enter the project directory
./setup.sh # and set up the project

Setting up the project will end up with:

✅ Setup complete!

To run the application:
1. Start the reactive service:
cd reactive_service && pnpm start

2. In a new terminal, start the frontend:
cd frontend && pnpm dev

The frontend will be available at http://localhost:5173

This could hardly ever be simpler :-p

If you open the project directory

In both subprojects, frontend and reactive_service, we've hardcoded some values, and taken shortcuts here and there in order to be straight to the point: making reactive programming easy to get, easy to grasp, easy to adopt, easy to embrace. easy to marry... ok, one step too far.

One or two cool things you will want to try:

  • plugging into a DB from the backend, we can give you some help : Building a Real-time Blog with Skip and PostgreSQL
  • having several conversations on screen, one per tab
  • integrating your user-management system
  • integrating an AI agent to discuss into the chat

We have a Discord server, why don't you swing by and say hi, ask a question or two?

What's Next?

For the next Skip article, what should I tackle first? You tell me!

  • Scaling your Skip service horizontally?
  • Having an AI agent interacting in the chat ?
  • Managing authorization and privacy per user?
  • What else would be most useful to you now?

A CLI to streamline the creation of Skip services

· 3 min read
Software Engineer

Hello Skippers. Today, we are excited to announce the release of create-skip-service: A CLI Tool for Skip Service Development. It aims to simplify the development workflow by providing a convenient way to bootstrap new Skip services.

npx create-skip-service <project-name> <options>

Reactive Social Network Service with Skip

· 10 min read
Software Engineer

Reactive programming often sounds complex—but it doesn't have to be. What if you could actually see how data responds to change, in real time, right from your terminal?

In this tutorial, we walk through building a small proof-of-concept social network backend using Skip and TypeScript. It tracks users, groups, and their friendships—with automatic updates to "active friends" using Skip’s reactive computation graph.

You’ll learn how to:

  • Set up a reactive Skip service
  • Define users and groups as live-updating resources
  • Connect it all to a REST API using Express
  • Observe real-time updates as the data evolves

"The simpler, the merrier" — this project keeps things minimal, focused, and easy to explore.

From Alice adding a new friend to live data reactions, this guide makes reactive systems tangible.

Event-Hidden Architectures

· 6 min read
SkipLabs Advisor

Event-Hidden Architectures

How did we get here?

One of the most powerful and consistent trends in software for the past decade has been the move from single stack to cloud native applications. Cloud native applications are inherently distributed and have become popular as developers are drawn to the convenience of containers and platform-as-a-service infrastructure.

The API-ification of important subsystems means today hardly anyone would consider implementing their own payments, shipping, SMS, chat, billing or shopping cart functionality. Instead they’ll lean on Stripe, Twilio, Shopify, Shippo, etc; accelerating time-to-value and further distributing the functions of the application.

In the last few years developers have moved quickly to incorporate more and diverse AI features into their applications, but AI models and application logic compute requirements are quite different from one another and therefore seldom run in the same stack, further distributing the application.

New built-in resources for Skip services

· 5 min read
Senior Engineer

The Skip framework is a system for building and running incremental backend services, simplifying the challenges of engineering complex reactive systems.

While Skip reactive services compose naturally with each other, they must also coexist with other backend systems with non-reactive semantics and APIs.

This blog post describes some recent enhancements we've made to the Skip framework to make it easy to bridge the reactive/non-reactive interface for popular systems like PostgreSQL and Kafka, and shows how you can build similar integrations with other systems and APIs.

SkipLabs Funding

· 3 min read
SkipLabs Founder & CEO

The News

We’re pleased to announce that SkipLabs has raised $8 million to bring incremental computing to applications everywhere. We intend to use the entirety of this funding to enhance the open source Skip project and grow the developer community.

This financing also means we get to work with Lenny Pruss at Amplify Partners who have invested in some of today’s most prominent developer platforms such as dbt Labs, Prisma and Temporal to name a few and Alex Mackenzie at Tapestry VC. Check out Amplify’s blog post that shares their view on SkipLabs and the future of reactive systems and Tapestry’s blog post on why they chose to invest.

We are also humbled to earn the support of individual investors like Adam Gross, Spencer Kimball, Yann LeCun, Tom Occhino, Olivier Pomel and Nicolas Vasilache.

Why Skip?

· 7 min read
SkipLabs Founder & CEO

Skip After Meta

Facebook allowed us to open source both Hack and Skiplang so we could share both with the larger engineering community. I eventually decided to leave Facebook (now Meta) to build on the work of Hack and Skiplang and develop technologies that would address the same challenges we had at Facebook but for engineers generally. To do this, SkipLabs needed to incorporate two new technologies to make the work we did at Facebook usable in a normal engineering context.

Skip's Origins

· 5 min read
SkipLabs Founder & CEO

Coping with success

I joined a much-smaller-than-today’s Facebook in 2011 to work on what would eventually become the developer tools team. At the time I joined, the engineering team was in the hundreds and the tools we had for development were, well, not great. PHP was the backbone of almost everything, with millions of lines of code. JavaScript was secondary, and only a few critical services ran on other languages. The company was scaling rapidly, and our development practices weren’t keeping up.

As the codebase grew, so did the difficulty of maintaining and improving it. Facebook became much more feature rich and simple enhancements became complicated and error prone. Often new features needed to operate conditionally on how other preexisting features were already operating. Essentially with each new layer of features teams added, state management became a greater concern.