Splice

Splice: Turn your OpenAPI spec into a live mock server and production-ready SDKs in seconds.

Comment

Inspiration

In every hackathon and agile team, there's a classic bottleneck: the Frontend vs. Backend standoff. Frontend developers are blocked waiting for API endpoints, while backend developers are rushing to build them. We realized that the OpenAPI specification (Swagger) is the perfect contract, but the tooling around it is often clunky, expensive, or hard to set up.

We wanted to build a Frankenstein, stitch together three seemingly incompatible developer tools into one seamless workflow. The insight: don't build from scratch, integrate brilliantly.

What it does

Splice is a Frankenstein tool that instantly stitches together API design, testing, and client generation:

  1. Instant Mock Server: Upload an OpenAPI JSON/YAML file, and Splice spins up a live, accessible HTTP server (powered by Prism) that responds according to your schema examples.
  2. One-Click SDK Generation: It analyzes your spec and generates a fully typed TypeScript/Axios SDK that you can download and drop into your frontend project.
  3. API Explorer: A beautiful, real-time interface to test your endpoints and see your mock server in action.

The magic is that these three tools (API docs, mock server, SDK generator) normally live in separate applications. Splice combines them into one unified workflow: Upload → Explore → Mock → Generate → Download.

How we built it

We built Splice using Next.js for a modern, server-side rendered React application, and leveraged Kiro as our AI IDE to rapidly scaffold and integrate the three disparate components.

The Architecture:

  • Component 1 - Schema Explorer: Integrated @stoplight/json-schema-viewer to display beautiful OpenAPI visualizations
  • Component 2 - Mock Server: Integrated @stoplight/prism-cli programmatically to spawn mock server processes on demand
  • Component 3 - SDK Generator: Utilized @openapitools/openapi-generator-cli (which requires a Java runtime) to handle the complex logic of SDK creation

The Tech Stack:

  • Frontend: Next.js 16, Tailwind CSS v4, HeroUI for a sleek, dark-mode-first aesthetic
  • State Management: Custom file-system-based persistence layer to track uploaded specs and generated SDKs across server restarts
  • Integration: Kiro helped scaffold the integration layer that connects all three components seamlessly

The real innovation wasn't building these tools; it was orchestrating them into one cohesive product.

Challenges we ran into

The Frankenstein Problem: Integrating Three Separate Tools

The biggest challenge wasn't building individual features. It was making three enterprise tools play nicely together in a single application.

Deployment & Multi-Runtime Environments

  • The Problem: Running heavy CLI tools like Prism and OpenAPI Generator (which needs Java) inside a standard Node.js serverless environment (like Vercel) proved impossible due to size limits and runtime restrictions.
  • The Solution: We pivoted to Railway using Nixpacks. We crafted a custom nixpacks.toml configuration to layer nodejs_20, pnpm, and openjdk11 into a single container image.

Dependency Hell

  • Faced obscure errors like ERR_PNPM_NO_GLOBAL_BIN_DIR when trying to install CLI tools globally
  • Solution: Architected them as root workspace dependencies and configured pnpm.onlyBuiltDependencies to ensure their binaries were correctly linked and available in the system PATH at runtime

Circular Referencing & Schema Resolution

  • Handling complex OpenAPI specs with circular $ref dependencies was tricky
  • Used @apidevtools/swagger-parser to dereference schemas correctly so we could display the actual schema structure in the UI instead of just $ref paths
  • This was critical for seamlessly passing specs between the explorer, mock server, and SDK generator

Process Lifecycle Management

  • Keeping the mock server alive and responsive while managing the SDK generator process was complex
  • Implemented robust process management to ensure the Prism server stayed running in the background until explicitly stopped, preventing zombie processes
  • The three components needed to coordinate: explorer triggers mock server, mock server needs to stay alive while SDK generator runs

Empty SDKs

  • Initially, generated SDKs only contained a README because the generator was silently failing
  • Had to debug the Java process execution and ensure the output directory was correctly captured and zipped
  • The integration point between Prism and the SDK generator needed careful orchestration

Context Across Components

  • Each tool (Prism, OpenAPI Generator, Stoplight Elements) has different configuration requirements
  • Solution: Created a unified configuration layer that translates between the three tools, so users only interact with one interface

Accomplishments we're proud of

  • Successfully containerizing a multi-runtime environment (Node + Java) to enable enterprise-grade code generation in a web app
  • Seamlessly integrating three independent tools into one workflow—the true "Frankenstein" achievement
  • The "Magic" moment when you click "Start Mock Server" and get a working URL that actually responds to curl requests, all from the same app where you explored the API and generated the SDK
  • A clean, intuitive UI that hides the immense complexity of orchestrating three separate systems working in concert

What we learned

  • Integration > Innovation: Building something new is hard. Making three existing tools work beautifully together is harder but more valuable.
  • DevOps is part of Dev: You can't just build an app; you have to design for where it lives. Understanding Docker and Nixpacks was crucial, and Kiro's guidance was invaluable here.
  • Process Management: Managing child processes (spawning mock servers) in a web application requires careful handling of PIDs, ports, and cleanup. But when done right, it enables powerful workflows.
  • Context is Everything: When integrating multiple tools, maintaining consistent context across components (same spec, same configuration, same user intent) is the difference between a toolkit and a product.
  • AI-Assisted Integration: Kiro excelled at architecting how three separate tools would communicate. The AI agent understood dependencies, suggested data flow patterns, and caught integration issues before they became runtime problems.

What's next for Splice

  • Cloud Sync: Persisting specs to a database (PostgreSQL) instead of ephemeral storage, so teams can collaborate
  • More Languages: Adding support for Python, Go, and Swift SDK generation (the framework for adding new generators is already in place)
  • Two-Way Sync: Editing the spec directly in the UI and having it update the mock server in real-time
  • Advanced Mocking: Custom mock response rules, request validation, and scenario-based responses
  • More Frankenstein Integrations: Potentially integrate with API documentation tools, contract testing frameworks, or API versioning systems

Built With

  • axios
  • docker
  • framer-motion
  • heroui
  • next.js-16
  • nixpacks
  • openapi-generator
  • prism
  • railway
  • react-19
  • sonner
  • tailwind-css
  • typescript
  • vitest
Share this project:

Updates