Examples Gallery
Explore complete, copy-pasteable Spayscript templates for architectures, machine learning pipelines, and flowcharts.
1. Multi-Tier Web Application
This template defines a classic system architecture consisting of a Load Balancer distributing traffic to Web Servers, which connect to a relational Database and a Redis Cache. It uses a mix of explicit coordinates, nested stack containers, and custom fill colors.
12345678910111213141516171819202122// Top level load balancer"Load Balancer" [icon: server, color: blue] // Stack of horizontal web serversstack "Web Tier" [direction: h] { "Web Server 01" [process, color: blue] "Web Server 02" [process, color: blue]} // Databases at the bottom"Primary DB" [db, color: green]"Redis Cache" [db, color: orange] // Connections"Load Balancer" -> "Web Server 01": arrow"Load Balancer" -> "Web Server 02": arrow "Web Server 01" -> "Primary DB": arrow [label: "Write"]"Web Server 02" -> "Primary DB": arrow [label: "Write"] "Web Server 01" -> "Redis Cache": arrow [label: "Read"]"Web Server 02" -> "Redis Cache": arrow [label: "Read"]2. Machine Learning Pipeline
This example showcases a machine learning pipeline where data flows through different layers (convolution, pooling, and dense layers) to make predictions. It makes heavy use of the 3D-styled `ml` layers and a vertical `stack` container to align the pipeline.
1234567891011// Vertical pipeline stackstack "Pipeline" [direction: v] { "Input Images" [process, color: slate] "Conv2D (32 filters)" [ml: conv2d, color: purple] "MaxPool2D" [ml: maxpool, color: orange] "Fully Connected" [ml: dense, color: blue] "Class Probabilities" [process, color: green]} // Chain connections"Input Images" -> "Conv2D (32 filters)" -> "MaxPool2D" -> "Fully Connected" -> "Class Probabilities"3. User Authentication Flow
A classic decision flowchart mapping a login attempt. It uses a rhombus-shaped decision node, orthogonal step routing, and custom label offsets to create a clean, easy-to-read diagram.
123456789101112// Nodes"User enters credentials" [process, color: blue]"Credentials Valid?" [dec, color: orange]"Redirect to Dashboard" [process, color: green]"Show Error Message" [process, color: red] // Connections"User enters credentials" -> "Credentials Valid?" "Credentials Valid?" -> "Redirect to Dashboard": arrow [label: "Yes"] "Credentials Valid?" -> "Show Error Message": arrow [label: "No"]4. Microservices & Event-Driven Architecture
This example demonstrates an event-driven microservices architecture using a `grid` container to group services, a `stack` container for infrastructure, and explicit databases.
123456789101112131415161718192021222324252627282930// Clients at the top"Web Browser Client" [icon: browser, color: blue] // Gateway and brokerstack "Infrastructure" [direction: v] { "API Gateway" [icon: api, color: purple] "Kafka Event Broker" [icon: queue, color: pink]} // Microservicesgrid "Microservices Pool" [color: green] { "Inventory Service" [icon: server, color: green] "Order Service" [icon: server, color: green] "Payment Service" [icon: server, color: green] "Shipping Service" [icon: server, color: green]} // Databases"Orders DB" [db, color: orange]"Inventory DB" [db, color: orange] // Connections"Web Browser Client" -> "API Gateway": arrow [label: "HTTPS Request"]"API Gateway" -> "Kafka Event Broker": arrow "Kafka Event Broker" -> "Order Service": arrow [label: "Events"]"Kafka Event Broker" -> "Inventory Service": arrow [label: "Events"] "Order Service" -> "Orders DB": arrow"Inventory Service" -> "Inventory DB": arrow5. Data Processing & Feature Engineering
This example illustrates a feature engineering and data loading pipeline. It highlights key features such as `code` nodes representing source transformation script, `icon` shapes representing systems, annotations via `callout`, and various layout shapes like `parallelogram` and `hexagon`.
1234567891011121314151617181920212223242526272829303132// Data input shape (parallelogram)"Raw CSV Files" [data, color: blue] // Processing shape (hexagon)"Data Cleaning" [process, color: purple] // Code execution block (python code)code "Transform Script" "lang=python" {import pandas as pd def clean_data(df): df = df.dropna() df['normalized'] = df['value'] / df['value'].max() return df} // Database output"Clean Data Store" [db, color: green] // Icon node"Nginx" [icon: server, color: blue] // Callout warning/notecallout "Data Warning" "Data schema is validated before writing to the database." [color: orange] // Connections"Raw CSV Files" -> "Data Cleaning": arrow [label: "Ingest"]"Data Cleaning" -> "Clean Data Store": arrow [label: "Write"] "Nginx" -> "Raw CSV Files": dashedarrow [label: "Web Upload"]"Data Cleaning" -> "Transform Script": line [routing: step]"Transform Script" -> "Clean Data Store": arrow6. Mathematical Model Optimization
This template showcases optimization processes using `equation` blocks containing LaTeX formulas, `icon` shapes representing computational units, and different shape variants such as `cloud`, `trapezoid`, `triangle`, and `star`.
12345678910111213141516171819202122232425// Data collection from cloud (cloud shape)"Cloud Storage API" [icon: cloud, color: blue] // Preprocessing / filtering (trapezoid)"Pre-filtering" [process, color: orange] // Cost function / Optimization (equation node)equation "Loss Formula" "J(\\theta) = \\frac{1}{2m} \\sum_{i=1}^{m} (h_\\theta(x^{(i)}) - y^{(i)})^2" [color: red] // Optimizer model (triangle shape)"SGD Optimizer" [dec, color: pink] // CPU processor / execution (icon node)"CPU" [icon: cpu, color: purple] // Best model output (star shape)"Optimal Model" [icon: star, color: yellow] // Connections"Cloud Storage API" -> "Pre-filtering": arrow [label: "Data Stream"]"Pre-filtering" -> "Loss Formula": arrow "Loss Formula" -> "SGD Optimizer": arrow"SGD Optimizer" -> "CPU": line [routing: step, label: "Compute"]"CPU" -> "Optimal Model": arrow [label: "Converged"]7. AWS Cloud Infrastructure
This example models an AWS VPC with public and private subnets, exposing an Application Load Balancer in the public tier, ECS Tasks in the application tier, and primary/replica database servers in the isolated data tier. It demonstrates nested containers, stacks, database variants, and styled connections.
1234567891011121314151617181920212223242526"AWS VPC (10.0.0.0/16)" [color: blue] { "Public Subnet (10.0.1.0/24)" [color: green] { "App Load Balancer" [icon: network, color: green] } "Private App Subnet (10.0.2.0/24)" [color: orange] { stack "App Cluster" [direction: v] { "ECS Task 01" [process, color: orange] "ECS Task 02" [process, color: orange] } } "Private Data Subnet (10.0.3.0/24)" [color: red] { "RDS Primary" [db, color: red] "RDS Replica" [db, color: red, dash: dashed] }} "User Traffic" [icon: globe, color: blue] "User Traffic" -> "App Load Balancer": arrow [label: "HTTPS"]"App Load Balancer" -> "ECS Task 01": arrow"App Load Balancer" -> "ECS Task 02": arrow"ECS Task 01" -> "RDS Primary": arrow [label: "Query"]"ECS Task 02" -> "RDS Primary": arrow [label: "Query"]"RDS Primary" -> "RDS Replica": dashedarrow [label: "Replicate"]8. CI/CD Deployment Pipeline
This template details a CI/CD build pipeline where code committed by a developer triggers GitHub Actions testing, code linting, containerization (Docker Hub), and cloud deployment. It utilizes callouts, clouds, cylinders, and flexible connector lines.
12345678910111213141516171819202122232425"Developer" [icon: user, color: purple] "GitHub Repository" [icon: git-pull-request, color: slate] "GitHub Actions Runner" [color: blue] { stack "Pipeline" [direction: v] { "Linting & Tests" [process, color: blue] "Docker Build & Push" [process, color: blue] "Vercel Deploy Trigger" [process, color: blue] }} "Container Registry" [icon: database, color: blue]"Production App" [icon: cloud, color: green] callout "Deploy Check" "Deploy only runs if tests pass" [color: yellow] "Developer" -> "GitHub Repository": arrow [label: "git push"]"GitHub Repository" -> "Linting & Tests": arrow [label: "webhook"]"Linting & Tests" -> "Docker Build & Push": arrow"Docker Build & Push" -> "Vercel Deploy Trigger": arrow"Docker Build & Push" -> "Container Registry": arrow [label: "Push Image", routing: straight]"Vercel Deploy Trigger" -> "Production App": arrow [label: "Deploy Webhook", routing: straight]"Container Registry" -> "Production App": dashedarrow [label: "Pull Image"]"Vercel Deploy Trigger" -> "Deploy Check": line9. Serverless REST API Backend
A serverless application backend routing web client requests through an API Gateway to a pool of Indigo Lambda functions that perform DynamoDB operations and schedule async events on an SQS buffer.
12345678910111213141516171819202122"Web Client" [icon: chrome, color: blue] "API Gateway" [icon: network, color: purple] "AWS Lambda Stack" [color: blue] { stack "Lambdas" [direction: v] { "GetUser Lambda" [process, color: blue] "UpdateUser Lambda" [process, color: blue] "NotifyUser Lambda" [process, color: blue] }} "DynamoDB Users" [db, color: green]"SQS Notification Queue" [icon: queue, color: orange] "Web Client" -> "API Gateway": arrow [label: "/users/*"]"API Gateway" -> "GetUser Lambda": arrow"API Gateway" -> "UpdateUser Lambda": arrow"GetUser Lambda" -> "DynamoDB Users": arrow [label: "Read"]"UpdateUser Lambda" -> "DynamoDB Users": arrow [label: "Write"]"UpdateUser Lambda" -> "NotifyUser Lambda": dashedarrow [label: "Invoke Async"]"NotifyUser Lambda" -> "SQS Notification Queue": arrow [label: "Send Msg"]