Servicers

For each of your data types you need to implement its methods. You do that by implementing server-side (backend) servicers based on the data types and methods you defined (using Pydantic in Python or Zod in TypeScript).

note

UI methods have no backend servicer code — the React App.tsx component is the implementation. You only implement reader, writer, transaction, and workflow methods in the servicer.

For Python, you'll be creating subclasses of the code-generated Servicer class where you can implement each of the methods you defined. For TypeScript you can either create subclasses or you can create an object literal.

For example, for a data type called Account:

Python

from bank.v1.bank_rbt import Account

class AccountServicer(Account.Servicer):
    # ...

TypeScript

Object literal

import { Account } from "../../api/bank/v1/account_rbt.js";

const accountServicer = Account.servicer({
  // ...
});

Class

import { Account } from "../../api/bank/v1/account_rbt.js";

class AccountServicer extends Account.Servicer {
  // ...
}

Each method gets passed:

• context: a subclass of Context specific to the method kind (e.g., ReaderContext)
• request: the type defined in your API file

To read and write the state of your data type from within one of your methods:

• Python: self.state
• TypeScript w/ classes: this.state
• TypeScript w/ object literals: state argument passed into your method

important

When creating a subclass of Servicer, there is a 1-1 mapping between an instance of your subclass and an instance of your data type that was either implicitly or explicitly created.

When using object literals in TypeScript, a single servicer may handle many different instances of your data types differentiated by different state arguments.

For more details on how to implement your methods see:

• reader
• writer
• transaction
• workflow