CRUD + Services

Service Demos

Yichus is aimed at CRUD and service code where business logic stays readable, effects stay explicit, and the analysis layer can still prove what your program really does.

The demos on this page are the current service offering direction: tiny hello-world routing, explicit CRUD workflows, Dynamo-style transport transforms, handler registries, and scheduler-style background logic. They are written as real Bosatsu programs, not framework mockups.

Explicit IO Typed CRUD flows Trust analysis Bosatsu-first authoring

What Yichus is offering here

Today the service story is a set of concrete Bosatsu demos that show how Yichus wants CRUD and service authoring to feel: small, explicit, analyzable, and ready for deeper tooling.

Hello world routing

Start with tiny route dispatch and request selection logic in plain Bosatsu.

Open `api-gateway.bosatsu`

CRUD workflows

Read, update, and create records with explicit IO steps instead of hidden framework magic.

Open `inventory.bosatsu`

Open `inventory-service.bosatsu`

Transport transforms

Decode wire data, map it into domain types, and keep every dependency visible to the Explorer.

Open `dynamo-transform.bosatsu`

Handler registries

Add new entities or routes by registering new handlers, not by scattering dispatch logic across the codebase.

See `make_handler` and `find_handler`

Pipeline demos

Model multi-stage service logic with named intermediate values and explicit data movement.

Open `data-pipeline.bosatsu`

Background orchestration

Queueing, retries, and scheduling can live in the same analyzable Bosatsu world.

Open `job-scheduler.bosatsu`

Hello world service

The smallest service demo is intentionally boring: route selection should be obvious, auditable, and easy to extend.

A tiny route table in Bosatsu

package Demo/Service/ApiGateway

def route: String -> String =
  path ->
    if path == "/health" then "health-handler"
    else if path == "/metrics" then "metrics-handler"
    else "not-found"

Why this matters

The point is not that routing is hard. The point is that Yichus wants even the smallest service surface to stay in ordinary Bosatsu, where the same analysis stack can inspect control flow, routing logic, and downstream dependencies.

When this grows into request parsing, auth checks, and domain handlers, you are still working in a language with total functions and explicit effects rather than a pile of hidden callbacks.

CRUD hello world

The inventory demo is the smallest real CRUD-style flow on this page: read a record, update it, then create a related record.

Explicit read/write/create flow

package Demo/Service/Inventory

def purchase(db: Db, item_id: String, quantity: Int) -> IO[Order]:
  flat_map(
    db_read(inventory_table(db), item_id),
    item ->
      flat_map(
        db_write(inventory_table(db), item_id, item),
        _ -> db_create(orders_table(db), Order("pending", item_id, quantity))
      )
  )

What this demonstrates

  • The domain flow is visible in one place: read inventory, update inventory, create order.
  • IO is explicit, so batching, retries, lotteries, or async follow-up work have somewhere principled to live.
  • The Explorer can reason about whether the order output genuinely depends on the inventory read and the purchase inputs.

This is the seed for the larger CRUD vision: let authors write business rules plainly, then let the platform layer own scheduling, optimization, and verification.

What makes Yichus special

Plenty of tools can generate handlers. The distinctive Yichus angle is that the service code stays analyzable all the way down.

Effects are values

Reads, writes, and follow-up work live in IO. They are composed intentionally instead of being hidden behind framework lifecycle hooks.

Trust verification

Yichus can inspect the compiled Bosatsu program and check whether a parser, handler, or CRUD transform really depends on its inputs instead of returning a fabricated answer.

Business logic stays local

Handler selection, transforms, and domain rules can be expressed as normal functions and registries rather than framework-specific annotations spread across files.

Transport and domain stay separate

The demos lean on explicit transport types and explicit mapping into plain application models. That keeps wire-format compromises from leaking into business code.

Composable platform features

Filtering, permissions, batching, and scheduling can be layered on top of the same service logic because the control flow and side effects are structurally visible.

Real source, not fake demos

These pages point at actual Bosatsu files in the repo. The code samples are the same style of code Yichus wants authors to write, inspect, and eventually deploy.

Dynamo Transform

The Dynamo Transform demo is the flagship service example today. It shows how Yichus can represent real service plumbing without giving up readability: parse wire data, choose the right handler, apply filters, and emit plain models.

What it does

Takes raw DynamoDB JSON (as DynamoValue enums), parses them into typed transport models (User[String], Post[String]), applies workspace and date-range filters, converts numeric strings into plain application models (UserPlain, PostPlain), and routes items through a handler registry based on entity type tags.

The nested author pattern is particularly useful for CRUD systems: a Post contains a User author, and the parser plus mapper stack keeps that shape intact instead of flattening everything into ad hoc maps.

Why it matters

This is the page to read if you want to see the service-platform thesis in one file: transport parsing, handler lookup, filter application, and output construction all live inside analyzable Bosatsu code.

It is also the kind of code where static analysis pays off most. The Explorer can check whether a parser really reads the incoming record, whether a filter really inspects the configured fields, and whether a transform is real rather than hardcoded.

Source and tests

If you want a single file that best captures the current CRUD/service direction, start with dynamo-transform.bosatsu.

The four-layer pattern

The Dynamo Transform demo establishes a service shape Yichus can grow around. Each layer has one job, which keeps the program readable and gives analysis clear boundaries to inspect.

Wire layer: DynamoValue (DynString, DynNumber, DynMap, ...)
↓ parse_User / parse_Post
Transport layer: User[String], Post[String]
↓ map_User / map_Post (with to_int)
Application layer: UserPlain, PostPlain
↓ process_item + find_handler
Handler layer: EntityHandler dispatch + FilterConfig

Parameterized transport types

User[num] and Post[num] are parameterized by their numeric type. When parsed from DynamoDB, numbers come as strings: User[String]. The map_User function converts them generically: pass in string_to_Int and you get User[Int]. This pattern means you write the mapping logic once and reuse it across all numeric conversions.

Single-pass collectors

Instead of calling lookup(entries, "field") for each field (which scans the list each time), the parsers use a single-pass collector that walks the entry list once and accumulates all fields simultaneously. This is a performance optimization that also makes the parsing logic more explicit -- each field match is visible in one place.

Handler registry

EntityHandler wraps a name, a parser, field accessors, and a serializer into a single existential type. find_handler looks up the right handler by entity type tag ("_et"). This pattern scales cleanly: adding a new entity type means adding a new handler to the list, not modifying existing dispatch logic.

Composable filters

FilterConfig combines workspace ID filtering with date-range filtering (both created and modified). Each filter dimension is independently optional. The pipeline applies all filters after parsing, so an item that passes the workspace filter but fails the date filter is still rejected. Empty filter lists mean "accept all."

Deep nesting: FeedSnapshot

Real CRUD backends rarely stop at one level of nesting. The demo includes a FeedSnapshot type that nests FeedEntry → Post → User, and still keeps the conversion story mechanical. 

struct FeedEntry[num](
  post: Post[num],
  featured_author: User[num],
  ranking_score: num
)

struct FeedSnapshot[num](
  workspace_id: String,
  generated_at: String,
  entries: List[FeedEntry[num]],
  total_score: num
)

# Converting the entire tree from String to Int requires
# exactly one function call:
mapped = map_FeedSnapshot(snapshot, safe_int)

The map_FeedSnapshot function automatically applies the conversion to every numeric field at every nesting level: the snapshot's total_score, each entry's ranking_score, each post's view_count and word_count, and each author's age and score. This is the payoff of the parameterized transport type pattern: deep nesting becomes mechanical rather than error-prone.

What the tests cover

The test file includes 10 assertions organized into test suites. Each one exercises a specific layer of the pipeline.

Wire → Transport

  • DynNumber values unwrap to strings
  • Nested DynMap authors parse correctly
  • All seven User fields are extracted
  • All eight Post fields are extracted

Transport → Application

  • map_Post applies conversion recursively
  • Nested author fields convert to Int
  • parse_UserPlain composes parse + convert
  • parse_PostPlain handles nested conversion

Pipeline & Filters

  • Unknown entity types are dropped
  • Workspace filter keeps matching items
  • Date-range filter rejects out-of-range items
  • Deep FeedSnapshot mapping converts all levels

Using this demo with the Explorer

Point the Explorer at the Dynamo Transform source and you get a full trust analysis of every binding. The Explorer will show you which parsers actually read from the DynamoValue input, which filters actually inspect the relevant fields, and whether any "transformation" is secretly a hardcoded constant.

What to look for

  • Do the parse_* functions depend on their entries input?
  • Does process_item actually call find_handler?
  • Do the map_* functions apply the conversion function to every numeric field?
  • Are any filter predicates hardcoded to always return True?

Expected trust profile

Every binding in this demo should be trustworthy. The parsers genuinely read from wire input. The mappers genuinely apply conversions. The filters genuinely check conditions. If any binding shows up as suspicious, it means something is wrong.

This is the baseline: a program where everything is real. Compare it with the Explorer trust verification page where some bindings are deliberately fabricated.

Related demos

The service page is not just one deep example. It is a small library of Bosatsu service patterns that can eventually turn into a broader CRUD platform.

Inventory

Minimal CRUD workflow with inventory state and order creation.

API gateway routing

Request dispatching with path-based handler selection and response construction.

Dynamo transform

Wire decoding, handler registries, transport mapping, and composable filtering.

Data pipeline

Multi-stage data processing with explicit intermediate types and provenance tracking.

Background job scheduler

Job scheduling with priority queues, retry logic, and execution state tracking.

Try it

Use this page when validating roadmap work around CRUD flows, handler registries, and service-platform ergonomics. Point the Explorer at the source to verify that parsing, routing, filtering, and transformation logic genuinely depends on the incoming data.

Start with CRUD hello world · Read the hello world route · Read the full Dynamo source · Read the tests · Learn about trust verification