DOCSEARCHbyAlgolia
Submit Docs

Skip Framework

repository·main·Indexed 23 days ago

https://github.com/skiplabs/skip

A framework for building reactive backend services with automatic dependency tracking and updates. It features a native runtime powered by the Skiplang toolchain and SKDB, a reactive SQL database. The ecosystem includes tools for Docker image builds, NPM package releases, and native runtime binary distribution, alongside examples for automated cache invalidation, real-time chat rooms, and reactive blogging services.

Tokens
51.3K
Snippets
86
Records
247
Agent score
79%

What's inside Skip

  1. Overview of the Skip Ecosystem

    main

    The Skip ecosystem consists of three primary components:

    1. Skip Framework: An open-source framework for building reactive backend services. It provides TypeScript interfaces and abstractions that allow you to write reactive services using standard tools while leveraging a custom native backend for efficient, automatic dependency tracking.
    2. Skiplang Toolchain: The implementation of the Skip Framework's native runtime. It includes the compiler, runtime, and tools like skargo and sktest.
    3. SKDB: A reactive SQL database built on top of Skip. The TypeScript client is available via the skdb NPM package.

  2. Overview of the Skip framework

    main
    Skip is an open-source framework for building and running reactive services and systems. It allows developers to define reactive services that expose resources—data and computation outputs. These resources can be queried via HTTP by standard clients or subscribed to by reactive clients for real-time updates. Skip services are written declaratively, defining a reactive computation graph that the framework manages, ensuring efficient updates and automatic dependency tracking without manual change propagation.

  3. Overview of Reactive Blogger Frontend architecture

    main

    The Reactive Blogger Frontend is a Vue.js 3 application built with TypeScript and the Composition API. It is designed to demonstrate real-time reactive patterns.

    Core Components

    • App.vue: The main application layout and navigation.
    • Feed.vue: Displays the real-time blog post feed using EventSource.
    • Login.vue: Handles user authentication forms.
    • Submit.vue: Provides the interface for creating and editing blog posts.

    Logic and State

    • Composables: Uses useAuth.ts for managing authentication state and JWT handling.
    • Real-time Updates: Leverages Server-Sent Events (SSE) to push updates to the client.

  5. SKStore System Guarantees

    main

    SKStore provides several core guarantees for building reactive systems:

    • Transactional: Updates are atomic; either the whole transaction succeeds or nothing changes.
    • Concurrent: Multiple readers and writers can interact simultaneously without blocking, except during the commit phase.
    • Garbage Collected: Automatic GC where collection time is a function of the update size, not the total heap size (preventing long pauses on large collections).
    • Storage Agnostic: Works both in-memory and on-disk.
    • Time Travel & Observation: Supports quick retrieval of diffs for eager directories between the present and any point in the past, and allows observing changes on any directory with easy recovery from connection drops.

  7. What is an Event-Hidden Architecture?

    main

    An Event-Hidden Architecture is a design pattern where the underlying distributed system is event-driven, but the complexity of events, queues, and asynchronous state management is abstracted away from the developer.

    Instead of manually managing event schemas, queues, and race conditions, developers use reactive frameworks like Skip to write logic as simple, declarative functions (e.g., map functions). This approach provides several benefits:

    • Declarative Experience: Logic is written without explicit references to infrastructure or events.
    • Synchronous Feel: While the system works asynchronously to support high concurrency, the developer experience feels effectively synchronous.
    • State Management: State changes and correctness are handled by the platform, allowing developers to focus on "init time" state logic.
    • Transparency & Replayability: Because events are managed in lower layers that understand their semantics, the system enables better visibility and the ability to "time travel" through application computation.

    This model is intended to replace traditional "event-driven" architectures that force developers to manage the complexities of distributed systems directly.

  8. Integrate Skip services with existing web backends

    main

    Skip reactive services can be integrated into existing web backends (Python, Node.js, etc.) by communicating with the control port over HTTP. This allows your backend to manage stream creation, deletion, and data operations.

    • Python: Use libraries like requests to communicate with the service.
    • JavaScript/TypeScript: Use Express or other frameworks. For a more streamlined experience, use the SkipServiceBroker class to handle HTTP requests programmatically.

  9. How Skipper verifies side effects via contracts

    main

    Skipper does not verify that a side effect (like sending an email or an HTTP call) actually occurred in the real world. Instead, it verifies that the description of the effect matches a fixed, typed contract.

    This approach allows for deterministic, closed-loop verification without needing access to live third-party services or sandboxes. The verification process relies on three pillars:

    1. Effects as Typed Values: All I/O is declared upfront as a typed external. The reactive core is strictly prohibited from performing I/O; it only constructs the description of the effect. Execution is deferred to a separate subprocess at the edge.
    2. Typed Doubles (Stubs): During the verification loop, external calls are replaced by typed mock records (stubs). These stubs return predefined values or errors based on the input parameters, ensuring the verification pass is deterministic and reproducible.
    3. Contract-Based Verification: The unit of verification is the contract (e.g., an OpenAPI spec). The agent codes against this frozen spec, and the loop type-checks and validates every call site against it. This allows you to verify code for proprietary or remote services as long as you have their type definitions.

  10. Requirements for Skip Mapper functions

    main

    To ensure reliable behavior in the Skip reactive computation runtime, all mapper functions must adhere to two core invariants:

    1. Side-effect-free: Mappers must not mutate external state or perform out-of-band operations. If a mapper mutates external data, that mutation may occur repeatedly as inputs change, leading to bugs if the mutation is not idempotent. Additionally, dependencies on mutable state outside the Skip heap can cause stale results.
    2. Deterministic: A mapper must always produce the same output for the same input. Non-determinism can cause unexpected behavior as changes propagate through the computation graph, potentially increasing re-evaluation costs and breaking the runtime's guarantee of from-scratch consistency (the guarantee that reactive outputs are identical to a full re-execution from scratch).

  11. Edit and structure the documentation website

    main

    The documentation website is built with Docusaurus.

    • Markdown Content: Files located under www/docs can be edited directly. Changes are typically picked up automatically while the site is running.
    • Navigation/Sidebars: When you change the file structure under www/docs, you must update the www/sidebars.ts file to reflect the new organization.
    • Configuration: The docusaurus.config.ts file relies on specific relative paths to source entry points and tsconfig files. Ensure these paths remain valid if you move files.

  12. How Skip fits into Event-Hidden Architectures

    main

    In the context of modern distributed applications, Skip serves as a reactive framework for incremental computation. It is designed to handle the "backend reads" portion of an application.

    Key capabilities include:

    • Distributed Reads: Implementing reads from multiple sources and managing latencies to disparate clients and views.
    • Data Blending: Developers can blend data from multiple REST and/or streaming sources.
    • Simplified Logic: Logic is written as simple map functions, free from references to infrastructure or events.
    • Automated Correctness: Performance and correctness concerns, such as cache invalidations, are outsourced to the Skip framework.