Implementation of expo app with turborepo backend

[Harsh-vardhan09]

Summary

Previously with next js i could create the backend and and apps with same api route
Now since working with turbo repo i want to create the app and web application in same place
But the implementation of the expo app and its dependency in same application and its deployement have become problem

Additional information

i want to create an web and app in same application 

## problems
- sepeate deployment of app web application
- managing of expo app with the the backend

My question is should i create an seperate backend and allow app to connect to it or like always make the next with its internal backend 

**but how do i connect the expo-app integration with it**

please guide me to similar project or the documentation for it

Example

No response

[apoorva-01]

The thing that trips people up moving from a single Next app to a monorepo: Expo can't share Next's API routes as a runtime. Next API routes run on a Node/edge server; Expo is React Native and just makes HTTP calls to a server. So there's no "same api route" the way you had it before, but you don't need a second backend either.

The pattern that works in Turborepo:

• Keep the Next app (apps/web) with its API routes as your backend. Deploy it as-is (Vercel or wherever).
• The Expo app (apps/mobile) calls those same routes over HTTP. Point its fetch base URL at the deployed web URL in prod, and your machine's LAN IP in dev (localhost won't resolve from a phone/simulator).
• Put anything both sides share (types, zod schemas, a tiny API client) in a packages/shared workspace package and import it from both apps. That's what actually gives you the "one place" feeling.

So: one backend (Next's routes), two frontends calling it, shared code in a package.

The separate deployment isn't a problem to solve, it's just how it is. Web goes to Vercel, the mobile app goes through EAS Build to the app stores. Different targets, different pipelines, same monorepo. If you ever outgrow Next routes (need websockets, background jobs, non-Vercel hosting), that's when you split out a standalone apps/api with Hono or Express and have both frontends hit it. No need to start there.

If you want a reference, the create-t3-turbo starter is exactly this shape (Next + Expo + shared packages in a Turborepo) and worth reading even if you don't use tRPC.

[Harsh-vardhan09]

so what i do is deploy the monorepo as a standalone app in deployment and use the api/routes from it in the expo app
two projects with same backend and also the same db
but how to deal with the db since that will be on deploment with docker
are there any projects with similar architecture.

[hanityx]

If the database is also running in Docker, I’d probably keep it as a separate service from the Next.js app rather than putting it in the web container.

The Next.js app can connect to it, while the Expo app keeps calling the Next.js API over HTTP. For a self-hosted Docker database, I’d also keep the data on persistent storage such as a Docker volume.
Something roughly like:

apps/
  web/       # Next.js + API
  mobile/    # Expo

services/
  database

packages/
  ...        # shared types, API client, etc.

create-t3-turbo may be useful as a reference for the Next.js + Expo + shared API setup, though its database setup is different.

[MILLERMARRU]

The short version: keep one backend, but stop thinking of it as "inside" the web app from the phone's point of view. Expo apps are clients, they can only talk HTTP to a server, so the decision is just where that server lives.

Both of these work fine in Turborepo:

Option A, keep the Next.js route handlers as your API. Structure looks like apps/web (Next, includes /api/*), apps/native (Expo), packages/validators or packages/api for shared types and schemas. The Expo app calls https://yourdomain.com/api/... through an env var (EXPO_PUBLIC_API_URL), pointing at your machine's LAN IP in dev and the deployed domain in prod. Web deploys to Vercel or similar, the native app builds with EAS, two separate deploy pipelines and that is normal, not a problem to fix.

Option B, a standalone apps/api (Hono, Express, Fastify). Worth it when the API stops being "the web app's backend" and becomes shared infrastructure. Same client story for Expo, and the web app also becomes just another client.

For the type-safe version of option A, look at create-t3-turbo (github.com/t3-oss/create-t3-turbo). It is exactly this setup: Turborepo with a Next.js app, an Expo app, and tRPC in a shared package so the phone gets end-to-end types against the API served by Next. Even if you do not want tRPC, the repo layout answers most of the structural questions you are asking.

Two practical gotchas: your dev machine's localhost is not reachable from a device or emulator, so use the LAN IP or a tunnel for EXPO_PUBLIC_API_URL during development, and make sure EAS builds from the monorepo root so workspace packages resolve (EAS handles pnpm/yarn workspaces out of the box these days, it just needs the project root configured).