Replies: 2 comments
-
For now I come up with the idea and a basic POC of a separate project which imports the service routes. In my main App which is used for development I have all the routes. MainApp // app/api/service/one/some-route/route.ts
export async function POST(request: Request) {
return Response.json({ status: "OK" })
} ServiceOne // app/api/some-route/route
// Just import the route from the mainapp
export * from '@monorepo/mainapp/app/api/service/one/some-route/route' You can basically just create a build of the service app and use it as a long-running service. And develop like a monolit. Sure one need to ajdust the routes provide env variables etc, but this is not a big deal and makes you aware of it. Next step is to add a script which would basically map those simple Need help! How to filter out the sevice routes from the main-app build? |
Beta Was this translation helpful? Give feedback.
-
This is the approach I'll use as it covers everything to create separate builds from a single project. |
Beta Was this translation helpful? Give feedback.
-
Goals
pages/functions/edge
+node start
(slim expressservice
orservices
)Non-Goals
No response
Background
Some apps require long-running services, like websockets, certain clients etc.
While developing the app all parts can be created inside a single next application. But when it comes to deployment the developer may face the problem of separating the parts from each other, creation of monorepos, changing apis like next/headers (cookies) rebuild parts in those separates services etc.
Proposal
It would be a real game changer, if the developer could keep the DX, and when it comes to deployment the
service
components would build into separate artifacts apart from serverless pages+functions. The developer would need to mark/group those service endpoints for example by path, or some kind of export constant. Theservice
components would not be part of theserverless
so the whole repository could be still deployed to vercel, while the build artifacts would be extracted into a separate build and available to a docker build.TLDR:
next build --service MyService
--> build/MyServicenext start build/MyService
Beta Was this translation helpful? Give feedback.
All reactions