The abstract api directory is used by multiple projects
Unanswered
Air Penguin posted this in #help-forum
I have three nextjs projects that were spun out of the same code and have different representations for different business needs, such as different page presentation, but they all have the same api. So every time I change the api I need to maintain three sets of code at the same time, about the api directory how to abstract?
11 Replies
Is there a case can give me for reference
@Air Penguin I have three nextjs projects that were spun out of the same code and have different representations for different business needs, such as different page presentation, but they all have the same api. So every time I change the api I need to maintain three sets of code at the same time, about the api directory how to abstract?
only maintain one of them, and for other projects, simply [rewrite](https://nextjs.org/docs/app/api-reference/next-config-js/rewrites)
/api requests to the project hosting the apiand... this is where i'd make a separate project just for the api routes (and you no longer have to use nextjs there), then rewrite
/api in all nextjs apps to that backendthat means all project requests will go to the service that provides hosting for the api ?
if it strikes...my boss will kill me🤣
if it strikes...my boss will kill me🤣
@Air Penguin that means all project requests will go to the service that provides hosting for the api ?
if it strikes...my boss will kill me🤣
Isn’t it the same codebase, no?
If it has to be different api services running with the same codebase, you can use trpc (https://trpc.io):
* Write the logic in a separate package, structured as a trpc router
* Export that router and its type
* Use that same router across your projects
If it has to be different api services running with the same codebase, you can use trpc (https://trpc.io):
* Write the logic in a separate package, structured as a trpc router
* Export that router and its type
* Use that same router across your projects
yeah,backend is same codebase
to be more precise, the current backend is a generic interface, but each next project will have its own differences later, because the business is different
yes then make a separate package hosting the logic and use that package in the codebases
so trpc can be satisfied, right?
you can choose to use trpc or not use trpc but yeah in this case trpc would help a lot since you just need to export the router variable
I'll look into trpc, thank you~ I follow your github, I think you are very good, I can definitely learn a lot from you🙇♂️