What does the chat data model look like?

Two tables, kept deliberately small. A conversations table holds one row per thread with an id, a user_id for the owner, a title, and a last_message_at timestamp so you can sort the inbox by most recent activity. A messages table holds one row per message with an id, a conversation_id that links it back to its thread, a role to mark who sent it, the content of the message, and a created_at timestamp for ordering. Newly generates this schema and the REST endpoints that sit on it: create and list conversations, get and post messages within a conversation. Everything is stored in Liquid Backend's Postgres database, so your message history is durable and queryable. Need attachments, reactions, or soft deletes? Ask in plain language and Newly extends the model.

Does Newly's chat update in real time?

Straight answer, since this is where a lot of guides overclaim: not on its own. Liquid Backend is REST-based. It does not ship real-time or WebSocket subscriptions out of the box, so a Liquid Backend chat fetches and refreshes messages over REST. You pull the latest when a thread opens, after you send, and on a pull-to-refresh or a short interval. For most messaging that is fine, think support threads, comments, slower back-and-forth. When you do need a message to appear on the other person's screen the instant it is sent, you have two options, covered in the next answer. So REST chat by default, with a real path to instant delivery the day you need it.

How do I make chat messages appear instantly without a refresh?

Two options, and you pick on the product. Option one: switch the project to the Supabase backend, one click inside Newly. Supabase has native real-time subscriptions over WebSockets, so you subscribe to row changes on the messages table and new messages push to every open client the moment they write. Option two: have Newly generate a dedicated WebSocket endpoint and connect to it from the app. A WebSocket is the right transport for streaming in React Native, a persistent two-way connection, where Server-Sent Events are unreliable on mobile and tend to drop on backgrounding and network changes. Both deliver the live, instant-message feel. The trade: Supabase real-time is the least work if you are happy on that backend, and a generated WebSocket endpoint keeps you on Liquid Backend while still going live.

Is building chat with Newly easier than coding it by hand?

Yes, and it is worth saying why. Hand-building chat means you design the schema, write and version the REST endpoints, wire up auth so people only read their own threads, then build the state sync on the client so the UI stays consistent as messages come and go. That is real work even for a senior developer, and most of it is plumbing rather than product. Newly does the plumbing: the conversations and messages tables, the create, list, get, and post endpoints, and the chat UI. Then it hands you React Native and Expo code you own and keep editing, not a black-box widget. From $25 a month you get a working chat feature and the source behind it, which is the difference between describing a feature and assembling one piece by piece.

Can I add an AI chatbot instead of person-to-person chat?

Yes, and the data model already fits it. The messages table has a role column so a row can be marked as coming from a user or from an assistant, which is how you store a back-and-forth with an AI. In a person-to-person chat the role tells the two participants apart; in an AI chatbot it separates the user's prompts from the model's replies in the same thread. The tables, the REST endpoints, and the thread UI carry over barely touched. You are only changing who, or what, is on the other end. If a chatbot is what you are really after, start from the same chat foundation and point the assistant side at your model. The add an AI chatbot guide covers that flow in more depth.

Articles · GuideUpdated May 2026

How to add chat to your app.
Describe it, ship real code.

The short version of how to add chat to your app with Newly: you describe the messaging you want in a sentence, and the AI builds it. No chat SDK to bolt on, no schema to design by hand. One catch most guides skip, so we put it up front below: live updates take a deliberate choice, and we tell you exactly which one.

Start building today See the five steps

The five steps

The five steps to add chat.

Here is how to add chat to your app in Newly, start to finish. Five steps. Four of them are you describing and refining; only the last one asks you to actually decide something.

1
Describe the chat you want
Open your Newly project and tell the AI what messaging should do, in your own words: one-to-one threads, a group channel, a support inbox, a chatbot. Name the behaviour you care about. Who can start a conversation? What does a thread show? Do messages need timestamps? The sharper the description, the closer the first pass lands. This is the whole interface to how to add chat to your app in Newly. Plain language, no schema editor.
2
Newly generates the data model
From that one description, the schema appears: a conversations table and a messages table, wired together so each message points back at its thread and the inbox can sort by recent activity. The next section breaks down every field. For now, the thing to know is that it persists in Liquid Backend, so your history is durable from the very first message rather than living in memory.
3
REST endpoints get wired up
The tables need routes, so Newly writes them: create a conversation, list a user's conversations, read a thread, post a message. These hit your real Postgres data, not a mock. The client calls them to open a thread, send, and refresh. That request-and-response rhythm is plain REST, and it carries the large majority of messaging products without anyone noticing.
4
The chat UI lands on your phone
The screens come too: an inbox of conversations and a thread view with a scrolling history and a text box at the bottom. Preview it on your actual phone, fire off a few test messages, watch them stick. Since the screens are React Native code rather than a configured widget, you can rename them, restyle them, or tear them apart.
5
Refine, then decide on live updates
Keep iterating in plain language: avatars, read indicators, group threads, a longer history. Then make the one call that actually needs you. Liquid Backend chat refreshes over REST, which suits most messaging fine. If a message has to land on someone's screen the instant it is sent, switch to Supabase for native real-time or have Newly generate a WebSocket endpoint. The next section weighs both.

Chat, at a glance.

2 tables

conversations and messages, the whole chat data model Newly generates

4 endpoints

create and list conversations, get and post messages, all REST

Supabase

One click away when you need real-time chat over WebSockets

REST

how Liquid Backend chat syncs; reach for Supabase or WebSockets to go live

What you get

The chat feature and the React Native code.

Newly is a paid AI mobile-app builder. You describe the app you want and it writes real React Native and Expo. The generated code is yours to keep and edit. Every project ships with Liquid Backend, the bundled backend, so your data has somewhere to live from the first prompt.

Chat arrives as code you can open and read. To change how a thread renders or rename a field, you edit the files directly.

One backend detail to note for later: if Liquid Backend stops fitting, Supabase is a one-click swap. That comes up again in the live-updates section.

The data model

The two tables behind the chat.

A messaging feature comes down to two related tables with a few endpoints on top. Here is the exact shape Newly produces, field by field, so you know what you are getting before you ask for it.

conversations

One row per thread.

idUnique identifier for the conversation.
user_idWho owns or started the thread.
titleA label for the thread in the inbox.
last_message_atTimestamp used to sort the inbox by recent activity.

messages

One row per message.

idUnique identifier for the message.
conversation_idLinks the message back to its thread.
roleMarks who sent it: a user, or an assistant.
contentThe message text itself.
created_atTimestamp used to order the thread.

And four REST endpoints on top.

Four routes drive those tables: create a conversation, list a user’s conversations, read a thread, post a message. Create, list, read, write – that is the entire surface a chat client touches, nothing extra to learn. Outgrow it and you just ask for more. Attachments, reactions, soft deletes: describe the field and the model grows to fit.

The honest part

REST by default. Live when you need it.

One detail to be clear about: Liquid Backend is REST-based. It does not provide real-time or WebSocket subscriptions out of the box. A Liquid Backend chat fetches messages over REST and refreshes them: on thread open, right after you send, and on a pull-to-refresh or a short polling interval.

For most messaging that is plenty. Support threads, comment inboxes, and slower one-to-one conversations feel right on REST, because nobody is waiting on the millisecond. If you want a message to land on someone else’s screen the instant it is sent, with no refresh, you pick one of the two paths below.

REST chat is great for

Support and helpdesk threads
Comment threads and feedback inboxes
Slower one-to-one conversations
Anything that refreshes fine on open, send, and pull-to-refresh
Most messaging in most apps, honestly

Reach for live updates when

Two people typing to each other live
A message must appear without any refresh
Typing indicators and presence dots
Live order tracking or multiplayer state
The instant-delivery feel of a dedicated chat app

Switch to the Supabase backend

One click in Newly

Supabase is Newly's alternative backend, and the switch is one click. It has native real-time subscriptions over WebSockets, so you watch row changes on the messages table and every open client gets a new message the instant it is written. No polling, no manual refresh. If you are content running on Supabase, this is the shortest path to live chat: the real-time layer is already there, and the AI assistant knows how to hook the subscription into your thread view.

Best when. You want live updates with the least work and are fine on the Supabase backend.

Generate a dedicated WebSocket endpoint

Stay on Liquid Backend

Prefer to stay put? Ask Newly to generate a dedicated WebSocket endpoint and wire the chat screen to it. A WebSocket holds a persistent, two-way connection open and pushes each new message to the client the moment it lands, which is what you want for streaming in React Native. You keep Liquid Backend and still get instant delivery. (On why a WebSocket beats Server-Sent Events here, see the note just below.)

Best when. You want to stay on Liquid Backend but still need messages to arrive instantly.

Why WebSockets, not Server-Sent Events.

On the live route, the transport you pick matters. Server-Sent Events read well in a tutorial and then let you down on a phone: they drop when the app backgrounds or the network flips between Wi-Fi and cellular. A WebSocket holds the connection open through all of that and carries traffic both ways. So when you want instant delivery without leaving Liquid Backend, generate a WebSocket endpoint, not an SSE stream.

Newly vs hand-coding

Building chat by hand vs with Newly.

Doing how to add chat to your app the hand-coded way is a fair bit of work. You design the schema, write the endpoints and version them, lock down auth so one user never reads another’s threads, then build the client-side state sync that keeps the UI consistent as messages come and go. Most of it is plumbing, and every bit of it has to be correct.

Newly handles that work and hands back the generated code, which you can keep editing. The conversations and messages tables, the endpoints, and the chat UI are all in place from the start.

The trade-off is straightforward. Newly is paid, from $25 a month, and in exchange you skip the boilerplate and start from a chat feature already running on your phone.

Try Newly from $25/mo See pricing

FAQ

How to add chat to your app, in plain language.

You describe it. Tell Newly something like “add one-to-one messaging so users can start a conversation and send messages back and forth,” and the AI builds the whole feature: a data model with a conversations table and a messages table, the REST endpoints to create and list conversations and to read and post messages, and the chat screens, a conversation list and a thread view with a text input. Messages persist in Liquid Backend, the backend bundled with every Newly subscription, so the history survives a refresh and a reinstall. You get a working chat feature on your phone and the React Native and Expo code behind it, from $25 a month. From there you refine in plain language: avatars, group threads, read receipts, timestamps. No separate chat SDK to wire up, no schema to design by hand.

Keep reading.

Add User Login to Your App Add an AI Chatbot How to Choose a Backend Browse All Articles

Describe the chat. Ship the real thing.

That is how to add chat to your app with Newly: from $25 a month, you describe the messaging and walk away with code you own. REST handles the everyday case. When a message has to arrive the instant it is sent, you reach for Supabase real-time or a generated WebSocket endpoint.