At <QuickConvex /> we like [Rust](https://www.rust-lang.org/). After all, we’ve [used Rust in production for almost ten years](https://blog.convex.dev/a-tale-of-three-codebases/), and the Convex backend is even built in Rust! So when we began to [add support for new languages](https://github.com/get-convex/convex-py) beyond JavaScript/TypeScript, Rust was near the top of the list.

We’re very pleased to announce our Rust client is now up on [GitHub](https://github.com/get-convex/convex-rs) and [crates.io](https://crates.io/crates/convex)! This means you can write Rust programs that read, write, and subscribe to records in your Convex deployments, just as with our [original JavaScript/TypeScript library.](https://github.com/get-convex/convex-js)

So what might you do with this new Rust crate?

# Haskell helps Convex onto the nice list

I know, I know—this article is about using *Rust* with Convex. So why is [the Haskell programming language](https://www.haskell.org/) getting involved? Well, Convex’s overall architectural principles are heavily influenced by ideas from Haskell. In particular, Convex’s decision to represent transactions as side-effect-free code is an idea that Haskell advanced beautifully with its [Software Transactional Memory](https://wiki.haskell.org/Software_transactional_memory) (STM) implementation and library.

In 2007, in the book [Beautiful Code](https://www.oreilly.com/library/view/beautiful-code/9780596510046/), Haskell creator Simon Peyton-Jones contributed a wonderful chapter called “Beautiful Concurrency.” Inside, [he introduced STM](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/beautiful.pdf) as a way to model concurrent systems that desire atomic changes to shared state without using pessimistic locking.

The chapter contained a Haskell program demonstrating STM in practice, implementing a contrived scenario Simon dubbed “The Santa Claus problem.” The full chapter provides a great amount of detail on this problem, but here’s a summary:

1. At the North Pole, nine reindeer (Simon generously included Rudolph), ten elves, and Santa all need to work together following some rules
1. If all nine reindeer are ready to work, Santa gathers them up and delivers presents with them
1. Otherwise, if at least three elves are ready to work, Santa goes into his study to build presents with exactly three of the elves
1. If neither group is ready, Santa waits. He doesn't work alone!
1. After a shift working with Santa, each elf and reindeer goes alone on vacation for a while, unavailable to work until they return

In *Beautiful Code*, Simon implemented each of these characters as an actor in a separate Haskell thread, using STM to coordinate their shared state. I decided to recreate my own solution in a multi-process, multi-host distributed system, using the Convex backend to coordinate state. Read on to see how!

# Making a flight plan

It will help to understand our scenario's rules if we make some algorithmic pseudocode. First, let’s write down the logic for the elves and reindeer. They both have the same routine, so this routine will be for a generic “worker.”

```
register new ("elf" | "reindeer") as state "ready"
loop {
  wait until Santa says our state is "working"
  wait (aka "work") until Santa says our state is "vacationing"
  sleep for a random amount of time -- on vacation
  set our own state to "ready"
}
```

Now, let’s write down Santa’s logic:

```
loop {
  do {
    poll everyone with state as "ready"
  } until all 9 reindeer or at least 3 elves are "ready"

  if 9 reindeer are "ready" {
    the work group = all nine reindeer
  } else {
    the work group = any three elves who are "ready"
  }

  atomically set every member of the work group to "working"
  sleep a random amount of time -- the group is working
  atomically set every member of the work group to "vacationing" 
}
```

# Polar architecture

Based on our pseudocode exploration above, we can model the shared state of this problem as a table of records where each record represents an individual worker. We have exactly two requirements for these records:

1. We need to distinguish between “reindeer” and “elf” workers, since Santa’s selection behavior is different for each (namely, preferring reindeer, and working with the whole set vs. a subset)
1. We need to track the current state of each of these workers as either “ready”, “working”, or “vacationing”. This is effectively how Santa and the workers will communicate with each other.

Time to get coding! First, let’s lock down the Convex schema in `convex/schema.ts`:

```tsx
import { defineSchema, defineTable } from "convex/schema";
import { v } from "convex/values";

export default defineSchema({
	workers: defineTable({
    workerType: v.union(v.literal("reindeer"), v.literal("elves")),
    state: v.union(
      v.literal("ready"),
      v.literal("working"),
      v.literal("vacationing")
    ),
  }),
});
```

<CodeCaption>The `workers` table contains the two fields to fulfill the two requirements above. We’ll use a union of literals from Convex’s value library to represent both the worker type and the worker state’s valid set of values.</CodeCaption>

Now, in a file called `convex/worker.ts` let’s implement the Convex query and mutation functions that will soon service our worker actor:

```tsx
import { Doc, Id } from "./_generated/dataModel";
import {
  DatabaseReader,
  DatabaseWriter,
  mutation,
  query,
} from "./_generated/server";

// Initial call. Create a new worker with an initially ready-to-work state.
export const insertReadyWorker = mutation(
  async (
    { db }: { db: DatabaseWriter },
    { workerType }: { workerType: "reindeer" | "elves" }
  ) => {
    const newId = await db.insert("workers", { workerType, state: "ready" });
    return newId;
  }
);

// Check if Santa has told us it's time to work.
export const isTimeToWork = query(
  async ({ db }: { db: DatabaseReader }, { id }: { id: Id<"workers"> }) => {
    return (await db.get(id))!.state == "working";
  }
);

// Check if Santa has told us our work is done.
export const isTimeToVacation = query(
  async ({ db }: { db: DatabaseReader }, { id }: { id: Id<"workers"> }) => {
    return (await db.get(id))!.state == "vacationing";
  }
);

// After we're done vacationing, mark ourselves ready to work again.
export const markBackFromVacation = mutation(
  async ({ db }: { db: DatabaseWriter }, { id }: { id: Id<"workers"> }) => {
    await db.patch(id, {
      state: "ready",
    });
  }
);
```

Each of these functions provides the server-side capabilities for the Rust app’s worker routine, which we’ll get to momentarily. Notice these functions are only about maintaining *one actor’s state.* There is no collective querying or mutation–the worker only cares about their own tasks.

Santa, meanwhile, is the one who decides what the group does, so his module of Convex functions (`convex/santa.ts`) will contain queries and mutations that span *all* worker records.

According to our pseudocode, he’ll need some kind of query to check if there is a group ready to work:

```tsx
export const newGroupReady = query(async ({ db }): Promise<"reindeer" | "elves" | null> => {
  // Quick invariant check. No one should be working if we don't expect it.
  const workersBusy = await anyoneWorking({ db });
  if (workersBusy) {
    throw "Busy workers before Santa said to go?";
  }
  // No one working. Do we have another workgroup?

	// Helper function that queries workerType = reindeer + "ready"
  const reindeer = await waitingReindeer({ db });
  if (reindeer.length == 9) {
    return "reindeer";
  }
	// Helper function that queries workerType = elves + "ready"
  const elves = await waitingElves({ db });
  if (elves.length >= 3) {
    return "elves";
  }
  return null;
});
```

<CodeCaption>If we have nine reindeer or at least three elves, this query function returns the appropriate worker type that Santa should engage in work. Santa can subscribe to this until the result is non-null.</CodeCaption>

Once a group is ready, Santa needs a mutation to schedule that group to work and one more to finish that work and put them on vacation:

```tsx
// Grab the appropriate group and mark them working. The given `work`
// was returned as ready from the `newGroupReady` query.
export const dispatchGroup = mutation(
  async ({ db }, { work }: { work: "reindeer" | "elves" }) => {
    if (await anyoneWorking({ db })) {
      throw "should never try to kick off a workgroup when work is already happening";
    }
    if (work == "reindeer") {
      const reindeer = await waitingReindeer({ db });
      assert(reindeer.length === 9);
      for (const r of reindeer) {
        await db.patch(r._id, { state: "working" });
      }
    } else if (work == "elves") {
      // Then, kick off elves to work.
      const elves = await waitingElves({ db });
      assert(elves.length >= 3);
      const wakeElves = elves.slice(0, 3);
      for (const e of wakeElves) {
        await db.patch(e._id, { state: "working" });
      }
    } else {
      throw "Uh, what kind of job is this?";
    }
  }
);

// Release the current workgroup. Put them on vacation.
export const releaseGroup = mutation(async ({ db }) => {
  const workers = await currentWorkers({ db });
  for (const w of workers) {
    await db.patch(w._id, {
      state: "vacationing",
    });
  }
});
```

And that’s basically everything we need. Time to build the actor routines that use these Convex functions in a Rust app!

# Rusty Routines

Rust apps communicate with Convex using a client from the Convex crate. Creating a new Rust client is easy:

```rust
let mut convex = ConvexClient::new(&cli.deployment_url).await.unwrap();
```

<CodeCaption>Note that we’ll make liberal use of unwrap() for concision in this example project, but your Real Production™ apps should handle the errors!</CodeCaption>

Invoking mutations is a client method that takes a name and arguments just like JavaScript/TypeScript. It returns a future since the Convex client is 100% async.

![](https://cdn.sanity.io/images/ts10onj4/production/413713b6f91de3dbcc107c5ead20619fd292f573-2026x320.png)

Subscriptions are exposed as a [`futures::Stream`](https://docs.rs/futures/latest/futures/stream/trait.Stream.html), yielding new values whenever Convex pushes them over the wire when dependent backend data changes.

![](https://cdn.sanity.io/images/ts10onj4/production/58df3a708029670c707b1fcc4ec7ff9fc3dcf411-2032x522.png)

In Rust, arguments to all Convex functions are provided as a [`BTreeMap`](https://doc.rust-lang.org/std/collections/struct.BTreeMap.html), where each value is a [Convex-specific `Value` type](https://docs.rs/convex/0.1.2/convex/enum.Value.html) that represents all the types you can pass to Convex functions.

And that’s all we need to know about the Convex crate API. With those basic ingredients covered, let’s now walk through the Rust function for Santa's implementation line by line. We’ll use these few Convex client methods to invoke the Convex functions in `santa.ts` to create our actor.

First, the preamble…

```rust
async fn santa(deployment_url: String, max_work_ms: Arc<AtomicU64>) {
    let mut convex = ConvexClient::new(&deployment_url).await.unwrap();
    let mut rng = rand::rngs::StdRng::from_entropy();
    loop {
```
<CodeCaption>Create the Convex client and initialize a random number generator for creating random sleep timings for the work duration. Then enter the main loop body of the routine.</CodeCaption>


Our pseudocode outlined the beginning of Santa's algorithm as:

``` 
  do {
    poll everyone with state as "ready"
  } until all 9 reindeer or at least 3 elves are "ready"
  if 9 reindeer are "ready" {
    the work group = all nine reindeer
  } else {
    the work group = any three elves who are "ready"
  }
``` 

You may recall this logic is already in our deployment’s query function `newGroupReady`. This will return null if no group is ready, or a group name if so. All that remains is to write this bit of Rust, which blocks on a subscription until a group type is returned:

```rust
    // Wait for a new group of workers to be ready!
    let mut sub = convex
        .subscribe("santa:newGroupReady", maplit::btreemap! {})
        .await
        .unwrap();
    let mut job = String::new();
    while let Some(result) = sub.next().await {
        if let FunctionResult::Value(Value::String(given_job)) = result {
            job = given_job;
            break;
        }
    }
    drop(sub);
```
<CodeCaption>Consume values from the subscription stream (ignoring nulls) until we get a string value indicating a particular type of worker group is ready.</CodeCaption>


And to recap the rest of our Santa algorithm pseudocode:

```
  atomically set every member of the work group to "working"
  sleep a random amount of time -- working
  atomically set every member of the work group to "vacationing"
```

Right. So, atomically ([which we get for free in Convex mutations](https://stack.convex.dev/dont-drop-acid)) set everyone in the workgroup to state “working”:

```rust
    // Kick off work.
    convex
        .mutation(
            "santa:dispatchGroup",
             maplit::btreemap! {
                 "work".to_owned() => Value::String(job),
             },
        )
        .await
        .unwrap();
```
<CodeCaption>Call the `dispatchGroup` mutation, passing along the job type we were just told is ready to go.</CodeCaption>


Our Santa routine will now sleep for a random duration to simulate the time it takes to finish the work.

```rust
    // Let the group "work" with Santa.
    tokio::time::sleep(
        Duration::from_millis(
            rng.gen_range(0..max_work_ms.load(Ordering::Relaxed)),
        )
    )
```

Then, we need to call a mutation to atomically release the current workers so they stop working and go on vacation:

```rust
    // Release them from their duties.
    convex
        .mutation("santa:releaseGroup", maplit::btreemap! {})
        .await
        .unwrap();
   } // go back to the top of the loop and wait for the next group!
}
```

We’ll skip a detailed examination of the worker routine’s Rust code. In brief, it uses the Convex functions from `workers.ts` in a loop similar to Santa:

1. It uses subscriptions to wait until Santa puts them to work and then again until he releases them
1. It calls a mutation to re-mark itself as ready to work after a random delay for “vacation”

# The Arctic in Action

Let’s see this simulation run!

The running Rust program on the left side of this video contains all 20 actors in separate threads with separate Convex connections–19 worker threads (nine reindeer, ten elves) and one Santa thread. Their only shared state is in the Convex deployment they access over the network.

On the right, we can see the Convex dashboard update as the collective state machine cycles:

<QuickVid src="https://static.convex.dev/stack/get-rusty-with-santa/santa-sim-dash.webm" />

And since Convex is [great at web stuff](https://stack.convex.dev/reactive-backend), I built a tiny bonus React app. The app provides a nifty visual depiction of the North Pole state and additionally lets you adjust two Convex-backed values that parameterize how long the Rust program sleeps during vacation and work periods:

<QuickVid src="https://static.convex.dev/stack/get-rusty-with-santa/santa-sim-ui.webm" caption="Can you guess how these speed variables work? React mutates, and Rust subscribes…" />

Want to run it yourself, or go deeper into the code? The whole codebase is up [on GitHub](https://github.com/jamwt/rusty-reindeer).

# Ho! Ho! Workflow!

*Some* may argue this Santa situation is pretty silly. What’s the point?

Well, what we’ve really created is a distributed workflow system where different programs depend on each other’s state to advance a collective process. And because of the Convex foundation, this workflow utilizes ACID semantics to [guarantee appropriate coordinated behavior](https://a16z.com/2023/04/14/the-modern-transactional-stack/). 

This scenario represents one common pattern where we’re excited to see folks use Rust [(and Python!)](https://pypi.org/project/convex/) with Convex. After all, there are numerous background, batch, command line, data-intensive programs out there quietly intermingling with and enhancing the UI-centric web and mobile apps we interact with and love.

And now with Convex, you can use a single, powerful, consistent set of abstractions to build these hybrid systems with ease.

If you've been itching to write Convex programs in Rust, your time has come. We take the new Convex Rust crate for a spin by writing a distributed system simulation of Santa and his team working together at the North Pole. Yes, really.

Convex gets Rusty with Santa

Convex provides automatic type safety all the way from your database schema to your React app. How does it work? Hint: we use some wild TypeScript.

End-to-end TypeScript with Convex

In this post, we’ll walk through putting together a full-stack chat app, and add some features. 

We’ll use React and Vite, though any React framework works. We’ll use <QuickConvex /> as the backend, where our server-side functions will run, and where we’ll store our app’s data. 

To see this in action, the code is [here](https://github.com/ianmacartney/convex-chat-gpt), and a running version is [here](https://convex-chat-gpt-f6rq.vercel.app/) (for now). You can clone it and run it yourself with a few configurations in the README, but read on to see a step by step guide on building your own. Also, the published version uses the "authed" branch in the repo, in case you want to see how simple it is to add auth.

To run this yourself, you’ll need to make an [OpenAI account](https://platform.openai.com/signup) and [get an API key](https://platform.openai.com/account/api-keys).

If you’re familiar with Convex, you can skip ahead to step 2.

<BuildWithConvex />

# 0. Bootstrap a Vite React app

If you don’t already have an app, we can make one:

```bash
npm create vite@latest
```

I picked `convex-chatgpt` as the project name, `React` as the framework, and `Javascript` as the variant.

At this point, if we run:

```bash
npm install
npm run dev
```

we have a locally running webapp.

Let’s change `src/App.jsx` to list messages and have a form to submit messages:

<details>
<summary>App.jsx</summary>
    
    ```tsx
    import {useState} from "react";
    import "./App.css";
    
    function App() {
      const messages = [
        {author: "user", body: "Hello, world"},
      ];
      const sendMessage = body =>
        console.log("Trying to send: " + body);
      const [newMessageText, setNewMessageText] =
        useState("");
    
      return (
        <div className="App">
          {messages.map((message, i) => (
            <p key={i}>
              <span>{message.author}: </span>
              <span style={{ whiteSpace: "pre-wrap" }}>
                {message.body ?? "..."}
              </span>
            </p>
          ))}
          <form onSubmit={(e) => {
            e.preventDefault();
            setNewMessageText("");
            sendMessage(newMessageText);
          }}>
            <input
              value={newMessageText}
              onChange={e => setNewMessageText(e.target.value)}
              placeholder="Write a message…"
            />
            <input type="submit" value="Send" disabled={!newMessageText} />
          </form>
        </div>
      );
    }
    
    export default App;
    ```
</details>    

At this point, we have an app that shows a static list of messages and logs to the console when trying to send a message.

# 1. Add Convex

This is similar to the Convex [quickstart](https://docs.convex.dev/quickstart/react). In a new terminal (leave the other one running `npm run dev`):

```bash
npm install convex
npx convex init
```

If you haven’t used convex before, you’ll be prompted to log in, create an account, etc. I picked `convex-chatgpt` as the project name.

Let’s add the ability to send messages and list messages. We will add functions that run in Convex (on a server) that will read and write to the database with a [query](https://docs.convex.dev/functions/query-functions) and [mutation](https://docs.convex.dev/functions/mutation-functions).

Add `convex/messages.ts`:

```jsx
import { query, mutation } from "./_generated/server";

export const list = query(async ({ db }) => {
  return await db.query("messages").collect();
});

export const send = mutation(async ({ db }, { body }) => {
  await db.insert("messages", {
    body,
    author: "user",
  });
  const botMessageId = await db.insert("messages", {
    author: "assistant",
  });
});
```

In a separate terminal from the one running `npm run dev`, run `npx convex dev`. This will deploy these functions to your new Convex backend, and as you edit the functions, it will automatically re-deploy. This will ask you to save the deployment URL into your `.env` and `.env.local` files: these point at your convex backends for your production and development deployments. We’ll just be working with the development deployment.

To access Convex from inside React, you’ll need to add a `<ConvexProvider>` context at the top level of your app. Edit `main.jsx`:

```jsx
...
import { ConvexProvider, ConvexReactClient } from "convex/react";

const convex = new ConvexReactClient(import.meta.env.VITE_CONVEX_URL);

ReactDOM.createRoot(document.getElementById("root")).render(
  <React.StrictMode>
    <ConvexProvider client={convex}>
      <App />
    </ConvexProvider>
  </React.StrictMode>,
);
```

We can then use these functions from `App.jsx`:

```jsx
function App() {
  const messages = useQuery("messages:list") || [];
  const sendMessage = useMutation("messages:send");
	...
```

Great! Now we have messages being written to and from the database. Try it out! Those new to Convex will be surprised to see that adding new messages will automatically result in the `useQuery("messages:list")` hook returning new messages. This is part of the magic of Convex. Learn more about it [here](https://docs.convex.dev/understanding/convex-fundamentals/functions#reactivity). 

You can check out your data in the dashboard: `npx convex dashboard`. 

You may note that the query and mutation are named by the `filename:function`. See more about this [here](https://docs.convex.dev/using/writing-convex-functions#defining-convex-functions).

You’ll notice every time we send a message, there’s a “…” message from the assistant. Next let’s update that message from chatGPT. 

# 2. Send a message to the ChatGPT API

So far we’ve been working with a [query](https://docs.convex.dev/functions/query-functions) and [mutation](https://docs.convex.dev/functions/mutation-functions), which are Convex functions that interact with the database. In order to interact with external services, we need to do that in an “[action](https://docs.convex.dev/functions/actions)” - which is a Convex function that isn’t inside a deterministic environment and isn’t part of a database transaction. This frees us to do things with side effects, such as making requests to OpenAI’s API. We’ll do this in a few steps.

## Fetching messages to send to ChatGPT

In our `send` mutation, we can grab the latest 10 messages to send to ChatGPT using a database query:

```jsx
export const send = mutation(async ({ db }, { body }) => {
  //... insert messages to the table
  const messages = await db
    .query("messages")
    .order("desc")
    .filter((q) => q.neq(q.field("body"), undefined))
    .take(21);
  messages.reverse();
  return { messages, botMessageId };
});
```

This orders messages in descending order (sorted by creation time unless you use a different [index](https://docs.convex.dev/database/indexes)), filters out messages with no body (for instance, the new placeholder system message), and takes the first 21 (which are the 21 most recent messages). It then reverses the list so it’s ordered in ascending time order. I picked 21 so that we’ll have 10 pairs of user/bot messages, followed by the latest prompt. It returns the messages to be used as input to the chat completion API, which we'll add next.

## Creating the action

We’ll use the `openai` npm package. You can install it with:

```bash
npm install openai
```

Make a new file: `convex/openai.js`:

```jsx
"use node";
import { Configuration, OpenAIApi } from "openai";
import { action } from "../_generated/server";

export const chat = action(async ({ runMutation }, { body }) => {
  const { messages, botMessageId } = await runMutation("messages:send", { body });
  const fail = async (reason) => throw new Error(reason);
  // Grab the API key from environment variables
  // Specify this in your dashboard: `npx convex dashboard`
  const apiKey = process.env.OPENAI_API_KEY;
  if (!apiKey) {
    await fail("Add your OPENAI_API_KEY as an env variable");
  }
  const configuration = new Configuration({ apiKey });
  const openai = new OpenAIApi(configuration);

  const openaiResponse = await openai.createChatCompletion({
    model: "gpt-3.5-turbo",
    messages: [
      {
        role: "system",
        content: instructions,
      },
      ...messages.map(({ body, author }) => ({
        role: author,
        content: body,
      })),
    ],
  });
  if (openaiResponse.status !== 200) {
    await fail("OpenAI error: " + openaiResponse.statusText);
  }
  const body = openaiResponse.data.choices[0].message.content;
	console.log("Response: " + body);
});
```

This will first send the messages with the send mutation we modified, getting in return the list of messages and message ID to update with the bot’s message. It will then make a request to the `gpt-3.5-turbo` model, passing in one system message with instructions (hard-coded for now), followed by each message. We’re turning our body & author fields into “role” and “content”. See their docs [here](https://platform.openai.com/docs/guides/chat) for more details on the API.

## Add your API key to the dashboard

To authenticate requests to OpenAI, you’ll need to add your [API key](https://beta.openai.com/account/api-keys) to the Convex dashboard, so your action (which runs on Convex’s servers) has access to it. Go to your dashboard with `npx convex dashboard` and on the left panel go into Settings and add the key with the name `OPENAI_API_KEY`. While you’re there, you can add it as an env variable to both your production and development deployments by toggling the dropdown in the left panel.

![Dashboard side panel](https://cdn.sanity.io/images/ts10onj4/production/6ed549cf10845a91f6b6c8697a165b253705f4b8-1166x629.png?w=450)


## Triggering the action from the UI

We can change our call to `useQuery("messages:send")` to

```jsx
const sendMessage = useAction("openai:chat");
```

Note the action is addressed by the path to the file (`openai`) and the function (`chat`). The API is the same (taking one argument, `body`), so it’s a drop-in replacement!

At this point, if you run it, it will send a request to ChatGPT and console.log the response. Convex prints Convex function logs to the browser’s console, though you can also see them in the [dashboard](https://dashboard.convex.dev/), to prove to yourself it’s running in the cloud. Now let’s show them in the UI.

## Updating the message with the reply

In order to get the response into the chat message, we’ll want to update the empty placeholder message we added. Treat each call to a mutation as a transaction. Once we called our first mutation, the messages were committed to the database and the UI could show the new messages before doing the slow call to OpenAI. Once we get the response, we update the bot’s message and the UI will update automatically via the `messages:list` query. We’ll add a new mutation in the `convex/messages.js` file:

```jsx
// An `internalMuation` can only be called from other server functions.
export const update = internalMutation(async ({ db }, { messageId, patch }) => {
  await db.patch(messageId, patch);
});
```

This patches the specified message. You could pass in `{body: "hi"}` to change the message’s body to “hi,” for example. Since the first mutation returned the `botMessageId`, we can use that from the action in `convex/openai.js`:

```jsx
export const chat = action(async ({ runMutation }, { body }) => {
  const { messages, botMessageId } = await runMutation("messages:send", { body });

  // Call OpenAI

  await runMutation("messages:update", {
    messageId: botMessageId, 
    patch: {
      body: openaiResponse.data.choices[0].message.content,
      // Track how many tokens we're using for various messages
      usage: openaiResponse.data.usage,
      updatedAt: Date.now(),
      // How long it took OpenAI
      ms: Number(openaiResponse.headers["openai-processing-ms"]),
    }
  });
});
```

While we’re here, we can store a bunch of interesting data into the message along with the body. Convex’s database is flexible enough to store [strings, numbers, javascript objects, `Map`s, etc.](https://docs.convex.dev/using/types) while also letting you nail down a [schema](https://docs.convex.dev/database/schemas) later to get typescript types, autocomplete, etc. 

🎉 Now you have chatGPT replying to your messages!

# Summary

In this post, we made a full-stack web app to chat with OpenAI’s ChatGPT API. Let us know [in Discord](https://convex.dev/community) what you think, and if you’d like to see some extensions:

- [Customizing the identity you’re talking to.](https://stack.convex.dev/adding-personality-to-chatgpt-3)
- [Moderating the identities and messages to prevent harmful content.](https://stack.convex.dev/moderating-chatgpt-content-full-stack)
- Create new message threads. (See the [code](https://github.com/ianmacartney/convex-chat-gpt) for how it's done!)

Let's build a full-stack chat app to talk to ChatGPT on its new API!

Building a Full-Stack ChatGPT app

Is your project in Airtable ready for more code and less no-code? I’ve [published some code](https://github.com/k8reindeer/airtable2convex) to help you migrate your data from [Airtable](https://airtable.com/) into <QuickConvex/>.

# Doing the migration

There are 4 steps, with scripts to help you:

1. Map your Airtable schema to Convex.
    
    This gives you the opportunity to rename or skip any tables/fields.
    
2. Move the data.
    
    Download the data using Airtable’s API, and import it to Convex using `npx convex import`
    
3. Re-link documents’ foreign references.
    
    Both Airtable and Convex support referencing other documents by ID — this step is to make your Convex documents refer to each other by Convex ID, not their old Airtable ID.
    
4. Store Airtable attachments in Convex
    
    Airtable only provides expiring links to your attached files. Before the links expire (2 hours), this step moves them to Convex [File Storage](https://docs.convex.dev/file-storage).
    

Check out the [README](https://github.com/k8reindeer/airtable2convex/blob/main/README.md) for more details!

# Keep in mind

As with any data migration, you should be aware that:

- Future data added to Airtable won’t be automatically migrated. To have data sync, you could set up [Convex with Airbyte](https://docs.convex.dev/database/import-export/airbyte). (Despite the names, Airbyte and Airtable are 2 completely different tools!)
- If you re-import all the data, it will have different convex IDs for each document.
- In re-importing Airtable data, you can only append or replace tables, and due to the new IDs, existing references may break.
- To export from Convex, you can use [snapshot export](https://docs.convex.dev/database/import-export/export).

# Summary

In this post we shared a repo with scripts to help you migrate from Airtable. The code is [here](https://github.com/k8reindeer/airtable2convex). Let us know how it goes in [our Discord](https://convex.dev/community)!

Is your project in Airtable ready for more code and less no-code? I’ve published some code to help you migrate your data into Convex.

Moving From Airtable -> Convex

Learn With Jason

You can build a database-powered app with end-to-end type safety and real-time updates without needing to learn how to manage databases. This tutorial will show you how.


Type-safe, data-driven apps, even if databases freak you out

Yet Another Infrastructure Group

Hosted by Ian & Alex, with Alana (Readyset), Hojjat (Deltastream), Jamie (Convex).

Convex and the future of streaming infrastructure

Convex

Dynamic application developers need global state management, not a database.

James (@jamesacowling) presents his talk from the HYTRADBOI 2022 database conference on how Convex is rethinking how app developers manage global state.

Data Interactivity in the Serverless Future (HYTRADBOI 2022)

Jamstack TV

Today, a new wave of innovation is making databases approachable for developers without requiring a specialized skillset, opening the door to a whole new category of ambitious web experiences. In this panel, you’ll hear from the people pushing the boundaries of database technology and learn what’s possible — and what’s coming.

Jamstack Conf 2022 Panel: The Future of Databases

InfoQ

Alex Cole discusses dynamic web apps, how serverless solutions compare to in-house stacks, and how product development changes when individual engineers can own features end-to-end.


Everyone Can Be a Full-Stack Engineer