using eve/next with multiple projects

[davecarlson]

Topology:
I have a mono repo with 2 next.js apps:

apps/frontend
apps/api

eve will be living inside the api project, and I want to use the withEve() in the frontend to connect to the other app ( it is on https://api.domain and the frontend on https://www.domain

Is this possible ? the frontend is just a dumb app, all logic and database access is in the api project, but i'd like to expose eve's chat interface via it

[MrTONYCHAN]

The two deployments can stay separate, but withEve() in the frontend should not be expected to turn the browser into a direct client for an arbitrary second Next.js deployment automatically.

I would keep Eve and its data/tooling in apps/api, then expose a same-origin route from apps/frontend that proxies the Eve chat/stream endpoint to https://api.domain. Point the frontend integration at that local route. This keeps cookies/auth, CORS and streaming behavior under your control and avoids exposing database credentials or server-only Eve code to the frontend bundle.

For example, the frontend route handler can forward the request body and authorization headers and return the upstream response body/status/headers without buffering it (important for SSE/streaming). If both apps use session cookies, either use a shared parent-domain cookie intentionally or translate the frontend session to a server-to-server token in the proxy.

So the topology is viable, but the boundary should be an explicit HTTP transport/proxy between the projects; do not import the API app’s server module into the frontend just because they share a monorepo.

[davecarlson]

The two deployments can stay separate, but withEve() in the frontend should not be expected to turn the browser into a direct client for an arbitrary second Next.js deployment automatically.

I would keep Eve and its data/tooling in apps/api, then expose a same-origin route from apps/frontend that proxies the Eve chat/stream endpoint to https://api.domain. Point the frontend integration at that local route. This keeps cookies/auth, CORS and streaming behavior under your control and avoids exposing database credentials or server-only Eve code to the frontend bundle.

For example, the frontend route handler can forward the request body and authorization headers and return the upstream response body/status/headers without buffering it (important for SSE/streaming). If both apps use session cookies, either use a shared parent-domain cookie intentionally or translate the frontend session to a server-to-server token in the proxy.

So the topology is viable, but the boundary should be an explicit HTTP transport/proxy between the projects; do not import the API app’s server module into the frontend just because they share a monorepo.

Thanks for the reply, I basically did ecactly this !

[MrTONYCHAN]

Great—glad to hear that approach worked for your setup. If you have a chance, sharing whether you used a Next.js Route Handler for the proxy and how you handled authentication and streaming would make this thread especially useful for others with the same monorepo structure.

The main detail worth preserving is returning the upstream response body without buffering it, so Eve’s streaming behavior remains intact.