GO
Go
Reference runtimeGo · goroutines and the standard library
net/httpgRPC-GoIBM SaramaTemporal SDKOpenTelemetry
Go project guideBuild typed service graphs on a visual canvas or in a Python architecture DSL. Generate Go, C++, Python, Rust and TypeScript projects with HTTP, gRPC, Kafka and OpenTelemetry. Implement business logic in explicit extension points.
Code generation from architecture produces native projects without flattening every language into the same implementation. Model HTTP and gRPC APIs, event-driven architecture, and Kafka stream processing once; each ServiceLib runtime preserves the graph contract using the ecosystem its developers expect.
Go · goroutines and the standard library
C++20 · choose userver or Boost.Asio
Python 3.12+ · asyncio execution
Rust 1.97+ · async tasks and ownership
Node.js 24 LTS · strict ESM TypeScript
Every generated project exposes the same Make interface while delegating to the native tools of its target language.
make buildmake testmake lintNative compilers, formatters, type checks, and language-specific quality gates.
make docker-up-devmake debug-<service_name>Source-mounted Docker Compose services with a debugger port for each generated service.
make kubernetes-upmake kubernetes-testBuild images, install infrastructure and Helm releases, then verify rollouts and metrics.
make merge-checkmake merge-validatePreview generated changes and preserve user-owned code through explicit merge hooks.
One behavioral contract. The runtimes share stream semantics, lifecycle and graceful shutdown rules, configuration, OpenTelemetry tracing, and Prometheus-compatible metrics.
Use the typed Python architecture DSL as architecture as code: factories, enums, and object references replace fragile string keys. Validate the model, produce canonical YAML, reconstruct Python from existing YAML, or call the generation API and download the generated project as a ZIP.
typed Python→validate()→canonical YAML→generated servicesUse Codex as an AI service designer without asking it to guess symbolic references in a large YAML file. The Service Architect Codex MCP server gives the agent a typed Python authoring API, graph-aware rules, deterministic validation, and code generation for services, streams, connectors, endpoints, pools, and types.
Local inspection and validation need no cloud credentials. An API key is used only when Codex requests generated runtime code.
Process inventory reservations in parallel, using the Inventory Workers pool with priority 10.
priority_task_pool_call()architecture.yamlproject.zip Shape your system through architecture.
Implement business logic in ordinary code.
In a large project, understanding the architecture means piecing together source code, documents and team knowledge. Diagrams help explain the design, but do not by themselves carry architectural changes into the implementation.
Service Architect makes architecture a working part of development. Describe meaningful business stages, their contracts and interactions. The generator turns that composition into code; you implement each stage in your chosen language.
The graph does not need to reproduce your program line by line. A node can represent a simple operation or a complete business stage. You choose what to expose, review and change through architecture, and what to keep inside a function. Less context to understand, clearer changes to review, and freedom to implement.
Building distributed systems means dealing with complexity that compounds at every layer.
Start with an example, inspect the native code and verify the result. Each guide connects an architectural choice to a concrete development workflow.
Model an HTTP endpoint, connect typed processing and implement the generated business contracts.
Visual microservice tutorial →Follow the order example across service boundaries, parallel item work and event delivery.
Explore the integration example →Review a new archive, preserve application-owned files and verify changed interfaces.
Safe code regeneration →Find a sampled request and connect runtime behavior to the graph and its dashboards.
OpenTelemetry walkthrough →Docker Compose · Generated Helm charts · Pools and parallel execution
Separate repeatable infrastructure work from the application behavior your team needs to implement, review and operate.
A new service needs HTTP handlers, middleware, configuration, metrics and tests before its business behavior can be verified.
Generate the common infrastructure, implement the business functions and validate them using the project build and test workflow.
Maintaining architectural wiring separately in diagrams and code can create drift.
The graph defines the architecture you choose to model. Generated wiring makes that composition executable; business functions remain ordinary code.
When something breaks in production, engineers spend hours reading logs trying to reconstruct what happened.
Recorded traces connect failures to modeled stages. Available detail depends on instrumentation, sampling and data-capture settings.
Understanding the context for an AI-assisted change can require tracing dependencies across many files.
The graph supplies architectural context and contracts. The team chooses the scope; it does not restrict what user-written business code may do.
Ship backend services without a dedicated platform team. Move as fast as a large engineering org from day one.
Standardize how services are built across teams. Eliminate the inconsistency that comes with ten engineers making ten different infrastructure choices.
Reduce the cost of maintaining distributed systems. Get visibility into every service without a dedicated observability team.
The code generation and AI-integration market is growing fast. This is a developer tool with a clear ROI story and zero runtime lock-in.
Use the graph to change the composition of your service, not just illustrate it. Generated wiring implements modeled connections and contracts; developers choose the level of detail and implement business behavior in code.
Model meaningful business stages, contracts and interactions. Choose which details belong in the graph and which stay inside functions.
Generate native service wiring and contracts from the model, then implement business behavior in ordinary code.
Relate recorded traces and metrics to modeled nodes. Visibility depends on instrumentation, collection and sampling; function internals remain code.
Transport, concurrency, deadlines, errors, telemetry, and lifecycle are derived from the topology.
Instead of asking AI to generate an entire application — constrain it to one function at a time. The framework handles everything else.
AI receives a small typed contract, not permission to redesign the application.
OrderItemOrderItemResultOrderItemResultNo HTTP handler. No gRPC setup. No tracing boilerplate. No lifecycle code.
Give an agent the relevant stages and contracts, then agree on the scope of the change.
Explicit inputs and outputs make intent easier to discuss and review. Tests and implementation review still matter.
Generated wiring supplies the modeled infrastructure. Agents can work on architecture or business code within a scope chosen by the team.
Review architectural changes as graph changes, then inspect affected business implementations.
Generated telemetry uses the identities of modeled nodes and links, so recorded traces can be explored in architectural context. Trace coverage and captured values depend on instrumentation, sampling and runtime settings; the graph does not automatically expose every action inside a business function.
The trace runs through the exact nodes you designed. No separate trace UI to learn.
Parallel fanout, timeout paths, error streams — all visible as separate branches in the trace, matching graph structure exactly.
See the actual data — inputs, outputs, errors — at each node for any request. No log parsing required.
Instrumentation for modeled stages is generated. Configure telemetry collection and sampling, and instrument function internals when you need additional detail.
Service Architect generates typed contracts, infrastructure and explicit business-code extension points. Implement and test your application logic in the generated project before deploying it.
Typed stream wiring, service lifecycle, configuration models, serialization, pools, and call semantics.
service.generatedconfig.generatedserdes/HTTP routes, OpenAPI models, protobuf modules, gRPC clients and servers, and connector adapters.
openapi/proto/transport/OpenTelemetry instrumentation, Prometheus metrics, health endpoints, and runtime-specific Grafana dashboards.
telemetrymetricsgrafana/Native build tooling, Docker images, Compose environments, Kubernetes and Helm deployment, CI, and safe merge scripts.
MakefileDockerfilehelm/The same non-trivial order system is generated for every supported runtime. Inspect the actual projects, then follow one request through the shared architecture.
Accept a typed order with two items over HTTP.
Fan out item work and call Inventory over gRPC.
Race the result branch against a soft deadline.
Merge both outcomes into one confirmed response.
| Traditional Development | Service Architect |
|---|---|
| Wiring described and implemented separately | Modeled wiring generates the composition |
| Manual service wiring | Generated automatically |
| Observability added later — or never | Built in from day one |
| Architectural intent buried in code diffs | Review architecture and implementation separately |
| Debugging means reading logs | Graph context + recorded traces |
| Hidden runtime behavior | Telemetry for modeled execution boundaries |
Service Architect and Temporal solve different parts of the same distributed-system problem. Service Architect models the complete service topology and generates its runtime wiring. Temporal provides durable workflow execution. Define a Temporal workflow or Activity endpoint, configure an optional Temporal schedule, and Service Architect generates the connection, worker, client, lifecycle, and target-language Temporal SDK integration.
Temporal integration supports Go, Python and TypeScript. Read Cron vs Temporal, Workflow endpoints, Activities and Schedules.
| Aspect | Service Architect | Temporal |
|---|---|---|
| Responsibility | Designs and validates the modeled service topology | Executes Workflows and Activities durably |
| Source model | Visual graph, typed Python DSL, and canonical YAML | Workflow and Activity code plus persisted Event History |
| System boundaries | HTTP, gRPC, Kafka, Cron, streams, errors, and Temporal connections | Workflow, Activity, Task Queue, Schedule, Signal, and Update execution |
| Generated runtime | Native service projects and lifecycle wiring; Temporal adapters for Go, Python, and TypeScript | SDK workers connected to Temporal Service or Temporal Cloud |
| Observability | OpenTelemetry traces, metrics, and dashboards mapped to the architecture graph | Event History, Temporal Web UI, SDK metrics, and tracing |
| Best fit | Executable service architecture, request pipelines, event processing, and integration design | Retries, durable timers, sagas, compensation, and long-running execution |
Use Service Architect on its own for service pipelines that do not require durable execution. Add a Temporal workflow, Activity, or Temporal schedule where work must survive restarts, retry reliably, wait for long periods, or coordinate compensation. The modeled integration stays visible in the graph while Temporal owns durable execution.
Own your application code and choose where to deploy it. Generated projects use Go, C++, Python, Rust or TypeScript with the corresponding ServiceLib runtime; the architecture model and runtime remain explicit project dependencies.
Read, audit, and contribute to the framework.
You own the application code. Generated services use the selected ServiceLib runtime, without a hosted Designer dependency.
Native projects you can build and deploy on your own infrastructure.
Works with any compatible tracing and metrics backend.
A small runtime library coordinates the graph execution. Generated services use the selected language and ServiceLib runtime. You own the application code and choose where to deploy it.
The cross-language conformance project compares observable service behavior, traces, metrics and lifecycle scenarios. Its suites document which runtimes and cases each check covers.
Read the conformance tests → · Read the benchmark and its limits →
Architecture becomes executable.
Observability becomes the primary interface.
AI focuses on business logic.
Developers focus on system design.
Shape systems through executable architecture. Choose meaningful business stages, implement them in ordinary code, and review changes with architectural context.