# TEA Party TApp Intro

## The goal of TEA Party

We built the TEA Party TApp to show:

* What a typical [web3](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/045_advanced_tapps/t-rust/obsidian/_gitbook-dev-docs/010_core_docs/070_What_makes_a_Web3_application.md) looks like (we call them **TApps**).
* The building blocks of a typical TApp.
* How to use Tea Party as a boilerplate to build your own TApps.

The TEA Party TApp is a useful social media application. Users can post messages to a public board as well as send private messages with notifications. See [the TEA Party user guide](https://teaproject.medium.com/tea-party-tapp-epoch-9-users-guide-2bd8ddd87daa) for more information.

## Basic workflow

In this section, we'll learn the basic workflow between all three tiers: how a user action get processed from the front-end to the state machine layer and back to the user.

{% @mermaid/diagram content="sequenceDiagram
participant A as Front end
participant B as Back end
participant C as IPFS/OrbitDB
participant D as State machine receiver
participant E as State machine conveyor
participant F as State machine actor
participant G as State
participant H as GlueSQL
A->>A: click the Tea party URL received from shared link or wallet
rect rgb(222,222,222)
A->>+B: reqeust to launch the Tea Party via the url link
B->>+C: get the CID and request IPFS
C->>-B: resposne the html/css/js front end code
B->>-A: send back the html/css/js front end code
A->>A: render on the browser. show the UI to the end user.
end
rect rgb(222,222,222)
A->>+B: query the NoSQL data (such as messages list without querying SQL database)
B->>+C: query OrbitDB
C->>-B: response data (such as message body)
B->>-A: send message body
A->>A: render in browser, showing to the end user
end
rect rgb(222,222,222)
A->>+B: query SQL database (such as my starred message list)
B->>+D: sending query txn
D->>+F: dispatch query txn
F->>+H: actor query GlueSQL
H->>-F: response query result (such as my starred message IDs)
F->>-D: response ids
D->>-B: response ids
B->>+C: query the messages body based on message IDs from GlueSQL
C->>-B: response message bodies that I starred
B->>-A: response message bodies that I starred
A->>A: render on browser.
end
rect rgb(222,222,222)
A->>+B: post a new message
B->>B: generate a command txn to pay for the fee
B->>D: send the command txn and followup to at least two state machine replicas
D->>E: the command txn waiting on all the conveyors
E->>E: waiting in conveyor
E->>+F: after the grace period, the command txn dispatch to state machine actor for execution
F->>+G: actor execute command and call state update
G->>G: update state inside state machine
G->>-F: command txn committed and state changed
F->>-E: response back
E->>D: response back
D->>B: response back to hosting CML
B->>B: confirm the payment went through, now generate post message txn to OrbitDB
B->>+C: insert new message to OrbitDB
C->>-B: inserted
B->>-A: confirmed posting message completed
A->>A: render the UI and notify end user.
end" %}

## The magical Proof of Time state machine

In this section, we'll explain how the distributed state machine works, including how it handles consensus among different replicas. Keep reading about the [magic of the state machine](https://dev.teaproject.org/basic-concepts/080_magic_of_state_machine).

## Understanding the WebAssembly Runtime

You can learn more about how the WebAssembly code runs inside the [mini-runtime](https://dev.teaproject.org/z_glossary/mini-runtime) by reading about the [magic\_of\_wasm](https://dev.teaproject.org/z_glossary/magic_of_wasm).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://dev.teaproject.org/045_advanced_tapps/020_teaparty.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.