Platform
Architecture
A web app, an authenticated API, and a split between work that answers in the page and work that belongs on a GPU. Nothing exotic — the interesting decisions are about where the boundaries sit.
Inline
CPU engines
Queued
GPU workers
Per-project
versioned cache
3
export formats
01
The shape of the system
The product is a Next.js web application talking to an authenticated API. Behind that API sit the engines, and the one structural decision that shapes everything else is how they are split. Work that finishes in seconds on a CPU runs inline and returns inside the request, so the page simply has an answer. Work that needs accelerated hardware goes onto a queue and is picked up by a GPU worker, so the page gets a job identifier and the browser stays responsive.
That split is not an implementation detail hidden from users. It is the pricing model, the interaction model and the cost model all at once. Inline engines are free and immediate. Queued engines consume credits and tell you where you are in line. A user who understands that one distinction can predict both the speed and the bill of any action in the product.
02
The layers
Next.js application
Server-rendered pages with interactive panels where they earn their keep — the Escher pathway map, the genome browser, the Mol* structure viewer. Heavy viewers load on demand rather than on every page.
One authenticated surface
The interface is a client of the same API that external integrations use. There is no private back door, which means any workflow the product supports is a workflow you can automate.
CPU engines
Flux analysis on COBRApy, codon adaptation through DNA Chisel, primer design via Primer3, annotation and assembly on Biopython. Seconds, not minutes, and free however often you run them.
GPU workers
Variant scanning with Meta ESM-2, structure prediction and docking run as jobs on dedicated workers. Standard, Performance and Max classes trade cost against turnaround on a per-job basis.
Cached and versioned per project
Results are written against the project that requested them and stamped with the engine build that produced them. Repeating an identical run returns the cached result instead of charging you twice.
A queryable reference layer
1,000 constructs across 65 organisms, 70 series and 6 tiers from Pepper through Tier 5, spanning 100 SHU to 16,000,000 SHU. Available in the interface, and over the API as structured data.
03
What comes out
- Sequence
- GenBank — annotated, feature-complete
- Sequence
- FASTA — plain, for anything downstream
- Assembly
- SBOL — parts, junctions, provenance
- Tables
- CSV — shortlists, scores, batch results
- Structures
- Standard coordinate files for Mol*
- Manifest
- Engine versions and run identifiers
- Access
- Interface download or public API
Export formats are a portability guarantee, not a feature list. GenBank and FASTA go anywhere a sequence needs to go. SBOL carries the assembly structure with it, so a collaborator receives a design rather than a pile of strings. Every package ships with a manifest naming the engine versions involved, which is what makes a result something a reviewer can check instead of accept.
The public API exposes the same engines, the same catalog and the same export paths the interface uses. Jobs submitted through it behave identically: inline work answers immediately, queued work returns an identifier. Enterprise workspaces add scoped API keys, webhook callbacks, reserved GPU capacity and SSO.
04
Why it is built this way
Three properties fall out of the design. Iteration is cheap, because the stages people repeat most are the ones that run inline and free. Results are reproducible, because nothing is stored without the version of the thing that computed it. And the product is composable, because the interface has no capability the API lacks.
The engine layer is built on open-source scientific tooling that the field already reviews and trusts — COBRApy and Escher, Meta ESM-2, Primer3, DNA Chisel, Biopython, Mol*. The platform contributes the parts that are tedious to build and easy to get wrong: orchestration, caching, versioning, access control and a coherent interface over the whole set.
Ready to run it
Try this in the Splice Platform.
CPU engines are free to run. GPU engines run on prepaid credits.
Related