DEV Community: functors

Part 2: Hands-on tc Framework: Building a Full-Stack Async API with Pages

Robert J. Berger — Fri, 17 Apr 2026 22:03:11 +0000

Introduction: The Practical Graph

This post will show a practical, hands-on example that implements a serverless topology using the tc (Topology Composer) framework. It supports synchronous entry points with asynchronous real-time updates. You will construct a REST API (API Gateway Routes) backed by a Lambda producer.

This Lambda producer emits an event to a an EventBridge Bus, which the framework routes to an AppSync Channel for Websocket broadcast via a secondary notifier function.

Finally will show how to include a Web GUI by incorporating S3/CloudFront Pages for the frontend.

By defining the system as a directed graph of logical connections rather than a list of static resources, tc derives all IAM policies, event rules, and infrastructure glue automatically, enforcing “least privilege” algorithmically.

Prerequisites & Environment Setup

Before we start, make sure you have the following in place:

An AWS Account.
tc CLI installed (the Rust-powered engine behind this magic).
Docker (specifically for buildx support).

Set up local dev environment

A Note on Environment: This guide assumes you are working in a proper *nix environment (macOS or Linux). Only tested on macOS.

Create a working directory and cd into it

mkdir -p tc-rest-demo
cd tc-rest-demo

To set the context for this tutorial, copy and paste the following into your terminal:

export SANDBOX=$USER-dev
export NAMESPACE=rest-demo

tc supports many conventions based on filenames and directory hierarchies.

A topology.yml is always at the top of the working directory of the project

Defining the Topology (`topology.yml`)

The core of your Functor is the topology.yml. This defines the graph: the logical connections where relationships are primary and infrastructure glue is derived algorithmically. There are currently 8 "atoms" that can be elements of a topology.

Entity	Cloud Mapping (AWS)	The So What? (Benefit)
Functions	Lambda / ECS	Pure business logic; side-effect free compute.
States	Step Functions	The managers handling flow control and error recovery.
Events	EventBridge	The nerves of the system; decoupled signals.
Routes	API Gateway	Synchronous HTTP entry points.
Mutations	AppSync (GraphQL)	Modern data modification for frontends.
Queues	SQS	Buffering and load leveling between components.
Channels	AppSync Events	Real-time, two-way communication via Websockets.
Pages	S3 & CloudFront	Static frontend assets (HTML/JS/CSS).

You can compose these in the topology.yml file. In general tc supports convention over configuration with sensible automatic defaults for many things. But these can also be overriden in the topology.yml or function.json files.

States (Orchestration)

Abstraction: Represents the flow control, error handling, and decision-making logic of a system. In the "Cloud Functor" model, States coordinate tasks and delegate work to Functions or other subsystems, ensuring that business logic remains completely decoupled from the execution flow.

Automation: Maps directly to AWS Step Functions. tc automates the state machine definition and the complex IAM roles required for the state machine to transition between states and invoke other resources.

Functions (Business Logic / Compute)

Abstraction: Represent pure business logic and act as side-effect-free compute units. They are the core computational workers of your topology where the actual application code lives and executes.

Automation: Maps to Lambdas or ECS Containers. tc helps with the whole lifecycle of creating, maintaining and deploying Lambdas. There is support for a variety of languages, and packaging as it supports both zip and container image builds. We only use image builds for very large lambda images.

Events (Asynchronous Messaging)

Abstraction: Represents the "nerves" of the system—decoupled signals broadcast to interested subscribers without direct point-to-point dependencies.

Automation: Maps to Amazon EventBridge. tc automates the creation of buses (or use of existing ones) and the definition of Rules that filter and route specific messages to targets (like queues or functions).

Routes (REST API Entry Points)

Abstraction: Represents synchronous HTTP entry points into the topology.

Automation: Maps to Amazon API Gateway (REST APIs). tc automates the creation of the API resources, methods (GET, POST, etc.), and the integration permissions required to invoke the backend logic.

Mutations (GraphQL Operations)

Abstraction: Represents data modification operations, typically used in modern frontend-backend interactions.

Automation: Maps to AWS AppSync (GraphQL). tc automates the schema definition and resolver mapping, allowing developers to define a "Mutation" that triggers a function or updates a data source.

Queues (Buffering)

Abstraction: Represents load leveling and asynchronous buffering between components.

Automation: Maps to Amazon SQS. tc automates the queue creation and the "glue" permissions allowing specific functions to produce to or consume from the queue.

Channels (Real-Time/Sockets)

Abstraction: Represents real-time communication pathways, allowing the server to push updates to clients (e.g., for chat apps or progress trackers).

Automation: Maps to AWS AppSync Events (Websockets). tc automates the connection logic, allowing a topology to push messages to a "Channel" that connected frontend clients are subscribed to.

Pages (Static Content)

Abstraction: Represents the frontend assets or static UI components of the application.

Automation: Maps to Amazon S3 (storage) and CloudFront (CDN). tc manages the deployment of HTML/JS/CSS assets associated with the topology.

Details: In most serverless frameworks, the frontend is a second-class citizen; just some files you manually shove into a bucket. In tc, the Pages entity brings the UI into the graph.

Pages manages your static assets (HTML/JS/CSS) via S3 and CloudFront. To understand where this fits, look at our "Bones and Muscles" model. While you might use Terraform to build the "Bones": the heavy, static infrastructure like VPCs or RDS instances that provide rigidity Pages is part of the "Muscles." These are the high-velocity components that provide the actual motion of your application.

Unlike Terraform, which relies on a brittle local state file, tc is stateless. It queries the "universe" (AWS) directly via the resolver to find those bones and attach the muscles. The Pages entity automates the "magic spells" of the cloud: provisioning the S3 bucket, setting up the CloudFront CDN, and handling invalidations. You define the path, and the system ensures the UI is wired to the same logical topology as your API.

The "Graph-First" Automation

The true power of tc lies not just in creating these resources, but in automating the relationships between them.

If a developer defines a topology where a Route triggers a Function, which puts a message on a Queue, tc automatically compiles the necessary:

API Gateway Integration.

IAM Policies (e.g., sqs:SendMessage scoped strictly to that queue).

Event Source Mappings (connecting the Queue to a worker Function).This allows developers to define the system as a clean graph (Topology) while the tool handles the "spaghetti" of infrastructure configuration.

The "Pages" Entity: Frontend as a First-Class Citizen

name: rest-demo
pages:
  frontend: ./frontend  # Path to your static assets

routes:
  /request:
    method: POST
    function: processor # REST entry point maped to a Lambda function with the label processor

functions:
  processor: # Definition of the Lambda function that handles the REST request
    handler: handler.py # Specifies the entry point
    event: ProcessedEvent # Emits an EventBridge event signal when done

events:
  ProcessedEvent: # Definition of the EventBridge Event
    channel: Updates # Routes the event to a Websocket channel

channels:
  Updates: # Definition of the AppSync Event Channel
    function: default # Appsync Events for real-time delivery

In this graph, the composer sees that a route calls a function, which emits an event, which triggers a channel update. You aren't writing IAM policies or configuring EventBridge rules; you are describing how the data flows.

The Build Process: Bundling Logic

Once your topology is defined, you run tc build. This command packages your business logic into deployable artifacts using the builder .

If the Lambda function is relatively simple, like in our example here, there are little to no library dependencies, at least none that have CPYTHON or other transitive dependencies that require compiling/linking. In this simple case, tc build will just bundle up using Docker buildx all the Python (or other interpreted language) code in a standard ZIP file as for normal AWS Lambda images.

Because tc uses Docker buildx for multi-architecture support (linux/amd64), your builds are consistent whether you’re on your laptop or running in a CI/CD pipeline. No more "it worked on my machine" excuses.

Implementing the Async Response & Progress Tracking

By integrating Pages with Channels, we stop making the user stare at a loading spinner. Instead of a black-box backend that leaves the UI hanging, we make the application feel alive.

Initiating the Request: The Pages frontend sends a POST request to the /request route.

Async Processing: The processor function acknowledges the request immediately.

Tracking Progress: As the function works, it emits events. These "nerves" of the system travel through the graph to the AppSync Channel.

Real-Time Feedback: The frontend listens to the Websocket Channel. The UI updates in real-time as the backend moves through stages, providing a seamless, responsive experience.

Algorithmic IAM Policies & Roles

One of the biggest headaches in AWS is writing "brittle bones" IAM policies. Usually, developers get lazy and use wildcards (Resource: *), creating a "Confused Deputy" problem where services are tricked into acting maliciously.

tc kills this problem through Algorithmic Authorization. The composer uses tested templates to automatically infer the intent of your graph:

It sees the Route points to a Function and generates the lambda:InvokeFunction permission.
It sees the Function emits to an Event, so it generates events:PutEvents.
It adds aws:SourceArn condition keys to trust policies automatically.

The compiler generates mathematically correct policies scoped to exact ARNs. You literally cannot forget a security condition because you don't write the JSON: the system derives it from the relationship.

Deployment: Moving into the Cloud

To move your Functor into the cloud, we use tc create and tc update. Let’s cut to the chase: tc does not manage a local state file. Instead, the resolver uses the AWS SDK to query the "universe" to find the ARNs of your "Bones" (VPC, etc.) and wires your "Muscles" to them.

Run the following command to deploy:

tc create --sandbox $SANDBOX --profile $AWS_PROFILE

If you change the code or the topology graph, run tc update. The resolver will detect what changed in the cloud and apply only the necessary updates to the "muscle" layer, making the iteration cycle nearly instantaneous.

Wrap Up: The Cloud is Your Computer

In just a few steps, we have deployed a full-stack, event-driven application with a secured REST API and an async, Websocket-enabled frontend. By using a single graph definition, we’ve eliminated the manual "spaghetti" of infrastructure glue.

We’ve seen how Functions (Pure Logic), Events (Nerves), and Pages (UI) work together. Turns out, once you stop fighting low-level primitives and start thinking in graphs, building complex systems becomes way too easy. You are no longer an infrastructure manager; you are a cloud programmer.

Stay tuned for Part 3, where we will cover States the "Managers" (Step Functions) that handle flow control and error recovery in truly massive fractal architectures.

tc Documentation: https://tc-functors.org/
tc Github: https://github.com/tc-functors/tc

Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud

Robert J. Berger — Fri, 17 Apr 2026 18:39:06 +0000

This is the first part of a multipart series introducing tc Cloud Functors

The Monolith in the Desert Problem

Sometimes I feel like the Forrest Gump of computing, having worked on or been around everything from the introduction of mini and microcomputers to starting an ISDN ISP in 1993, pioneering international server farms, and building early e-commerce sites through the earliest days of the cloud, working with AWS in 2008. (and so much more!)* Since then I've specialized in serverless infrastructure and systems.

About three years ago, I joined a startup called Informed, whose product is a very sophisticated Intelligent Document Processing pipeline for lenders. Informed had the classic situation of a startup that has found its market with a working product, but the implementation is a mirror of the random walk they took to discover their market/product fit. They were processing about 8% of all US car loans, dealing with heavy bank regulations, and had the terrifying constraint of infinite PII. Yet, the tech stack was a typical startup tangle: a massive Ruby on Rails app sitting at the center of the universe, talking to just about every AWS service imaginable through Elastic Beanstalk, and using a single Postgres database as a message bus. I don't say this with disdain. It was a working system that had lots of quality engineering and had been very successful in delivering services to some of the top banks and generating profits.

Most startups have this random wandering in the desert until they find their product/market fit, and their software tends to follow the same route. Unfortunately, it was also a nightmare of tech debt where adding a single feature felt like moving a mountain.

We knew we had to move to a modular, event-driven architecture, but we weren't just talking about a couple of functions. We were looking at a future that now consists of 107 topologies and 340 Lambdas across Python, Ruby, and Node. Managing that kind of complexity for a small team of developers is the real hurdle. Traditional tools like CloudFormation which, frankly, I find to be a collection of frustrating magic spells. Using CloudFormation felt like trying to build a high-performance engine out of low-level, brittle bones. Even Terraform, while it sucks less, didn't have the right impedance match for the high-velocity muscle of a distributed serverless system.

We knew we wanted to move to a more unified and serverless style of infrastructure. The use case matched serverless perfectly, as its API driven, machine-to-machine work primarily. It's very bursty and follows the normal sine wave pattern of the US business hours. We also found that the existing tooling did not lend itself to building such complex serverless systems.

Before we had tc our developers were spending 80% of their time manually wiring infrastructure and only 20% writing logic; we had already lost. We needed to stop managing resources and start programming the cloud as a single computer. This frustration with manual wiring led us to a breakthrough: moving away from resource lists and toward a graph-first mental model.

Amazingly, company management approved the rewrite, and we actually were successful with first customers on it after 6 months and fully switched to the new system in 9 months. It was during this time that tc was developed based on our real needs and experiences. We continue to add new features as we discover the needs.

The Mental Shift: From Resources to Graphs

The Aha! Moment happens when you realize most tools ask the wrong question. They focus on the implementation (the how) rather than the intent (the what). I scoured the InterTubes for something better, but everything else was still resource-centric.

Question Asked	Primary Focus	Outcome
Resource-First (Terraform/CloudFormation)	What resources do you need?	A static list of primitives (buckets, roles) that must be manually wired.
Function-First (Serverless Framework)	What functions do you have?	A collection of compute units that still require manual infrastructure glue.
Graph-First (tc)	What is the graph of your system?	A logical topology where relationships are primary and infrastructure is derived algorithmically.

Think of it like the React analogy. Before React, we manually manipulated the DOM (the infrastructure). With React, we focus on component state and relationships; the DOM manipulation is just a side effect handled by the framework. In the tc model, you describe how components connect, and the system handles the IAM roles, event rules, and subscriptions as derivative artifacts. It’s an inversion of control where the graph is the truth. To make this graph-based thinking concrete, we created a single unit of encapsulation: the Cloud Functor.

What is a Cloud Functor?

We borrowed the term functor from OCaml’s parameterized modules. In our world, a Cloud Functor is a first-class, composable unit of infrastructure. To understand it, just look at your file system as a similar model of hierarchy and other characteristics.

Namespaced: Just like a directory, every functor has a unique identifier to keep things organized and domain-specific.

Sandboxed: You can deploy isolated versions (dev, staging, feature-branch) in the same deployment account without collision.

Versioned: We use Git tags and deployment manifests to freeze implementations, making rollbacks as simple as pointing to a previous tag.

Isomorphic: The definition is abstract; the same YAML renders consistently whether it's on your laptop or in production.

The File System Analogy shows how you work through Sub-Tree Autonomy. You can cd into a deeply nested folder, say, src/loan-app/extraction/ssn-id and run tc create or tc update in that directory. The tool treats that subfolder as the root of the universe, ignoring the rest of the 340-Lambda monolith. This zooming allows for infinite nesting in a fractal pattern; a top-level orchestrator delegates to sub-orchestrators, and every level looks the same. Every one of these functors is built from the same set of atomic building blocks.

Breaking away from the file system analogy, the top feature of Cloud Functors is their Composability.

The 8 Atoms of the Cloud Universe

We identified eight core entities that are sufficient to build any sophisticated serverless topology.

Entity	Cloud Mapping (AWS)	The So What? (Benefit)
Functions	Lambda / ECS	Pure business logic; side-effect free compute.
States	Step Functions	The managers handling flow control and error recovery.
Events	EventBridge	The nerves of the system; decoupled signals.
Routes	API Gateway	Synchronous HTTP entry points.
Mutations	AppSync (GraphQL)	Modern data modification for frontends.
Queues	SQS	Buffering and load leveling between components.
Channels	AppSync Events	Real-time, two-way communication via WebSockets.
Pages	S3 & CloudFront	Static frontend assets (HTML/JS/CSS).

By defining these logical connections, the spaghetti of infrastructure glue is derived algorithmically. This isn't just a convenience; it’s the secret to killing some of the most common security headaches in the cloud.

Composability - The Real Superpower of tc

Let's cut to the chase about the real superpower of tc: graph-based composability. Turns out, when you stop thinking in terms of disjointed infrastructure resources and start treating your cloud primitives: functions, events, queues, and routes as fundamental atoms, you can build some truly elegant, self-documenting systems.

One simply defines the logical connections between these namespaced and sandboxed entities in a clean YAML graph, and the tc composer works its magic spells to infer all the complex IAM permissions and infrastructure glue for you. Because these relationships are elevated to explicit, first-class citizens rather than being scattered as obscure implementation details, the topology definition itself becomes a highly readable architecture diagram where no low-level infrastructure configuration leaks into your business logic.

This means we can seamlessly compose these atomic entities into higher-order Cloud Functors, and then recursively compose those into massive enterprise systems, allowing my team to understand an entire topology of 30+ interconnected microservices at a glance without ever wading through the spaghetti code of traditional IaC.

Algorithmic Security: Killing the Confused Deputy

In the trenches, I see developers just getting it working by stripping away SourceArn or ExternalId conditions because IAM is hard. This creates the confused deputy problem, where a service is tricked into acting on behalf of a malicious party.

The tc composer solves this using Algorithmic Security:

Tested Templates: The composer uses pre-validated, secure policy templates for every connection. It automatically adds SourceArn condition keys to trust policies. You literally cannot forget them because you don't write them.

Least Privilege by Default: Since the graph knows Function A only talks to Queue B, the compiler generates a policy scoped strictly to those ARNs. No wildcards (*) allowed.

Because you define the topology (logic) and not the policy (implementation), the compiler always regenerates the algorithmically secure version. While tc handles the muscle, we still need a skeleton to hold everything up.
You still need someone with an understanding of IAM roles/policies to create the templates, but the enforcement is done by the tooling.

The Bones and Muscles Hybrid Architecture

We don't try to replace Terraform (at least not yet!). Instead, we use a hybrid model that respects different infrastructure velocities:

The Bones (Terraform): This is your skeleton—heavy, static stuff like VPCs, RDS, and the Event Bus. You want your bones to be rigid and reliable. We will run Terraform to set up and maintain these static elements. We do not run Terraform regularly and don't really use it for drift management. Not only that, but we expect to eventually have tc be able to create and manage all AWS elements (and maybe other clouds someday).

The Muscles (tc): These are the high-velocity parts: Lambdas, Step Functions, and the Rules/Subscriptions on that bus. They attach to the bones and provide the actual motion. tc manages this fully

The Tendons (The Resolver): This is the magic. The tc resolver queries the universe (AWS) to find the ARNs of the bones as well as the state of the deployed functors and all the previously deployed services. tc talks directly to AWS via the AWS SDKs. The resolver then uses that data to supply ARNs or other info needed to wire things up.

The Developer Workflow: `Zooming` into Action

The workflow is designed for speed. Because the tc builder uses Docker buildx for multi-architecture support (Linux/amd64), your builds are consistent regardless of your local machine or build by CI/CD in the Cloud.

tc build    # Package logic and ML models (Docker multi-arch)
tc publish  # Push assets like Layers and EFS models to S3
tc create   # Provision the isolated, namespaced sandbox
tc invoke   # Test logic directly in the cloud via a REPL

The three pillars of this workflow are:

Sandboxing: Collision-free environments (e.g., dev-your-name). Alice’s messages never end up in Bob’s queue.

Contextual Execution: Zoom into a sub-folder and iterate in seconds, ignoring the rest of the system.

Isomorphic Rendering: The same YAML is used for your local dev sandbox and production. No more it worked on my machine.

Wrap Up: The Cloud is the Computer

At the end of the day, the goal is to stop being infrastructure managers and start being cloud programmers. When we moved to this graph-first model at Informed, our implementation speed just zoomed. Being spoiled by Ruby and other high-level languages, I couldn't go back to manual wiring. We are now integrating LLMs/Agents with tc both for dev and targets, so things should go even faster.

Turns out, once you stop fighting with low-level primitives and start thinking in graphs, building complex systems becomes far too easy. It’s truly a superpower. Stop thinking in resource lists. Start thinking in graphs. The cloud is your computer; it's time to start programming it properly.

tc Cloud Functors is an open source project that can be found at https://github.com/tc-functors with documentation at https://tc-functors.org/.