Advice on project refactoring
Unanswered
Clown posted this in #help-forum
ClownOP
Hello there.
So for context i have this old project of when server actions weren't stable and app router was new. The project does use prisma. Most of the meat and potatoes of the api are done using route handlers. Initially this was because:
* Server Actions weren't stable or widely used at the time.
* As a safeguard for if the API ever goes public.
* To provide quick demo i wont have to buy a VPS or something to host the API server itself.
The problem is, this works but it is no longer a very clean solution because:
* The project has authentication and i need to pass the headers around every single fetch, same with the URL, since most the fetching is happening in the server(i know, yikes antipatterns)
* The route handlers are rigid as such i need to either be passing many headers around to change their behaviour OR call many different route handlers and then post process to gain the same information.
* Since authentication and headers are involved, the API isnt very public anyways.
* Since i am calling many different route handlers and then post processing to handle the rigidness, it can be slow and timeout if i go for a serverless platform.
So the advice i needed is what should be the best path ahead. What should i refactor or use? Should i move away from route handlers, use server actions entirely or move away to separate API server using express or something? Some things i need are:
1) Be open to transition to a public model while providing the services to the next server itself.
2) If possible not have to buy a VPS or something to provide demonstrations atleast for this phase since we are still in development.
3) Still work with prisma.
So for context i have this old project of when server actions weren't stable and app router was new. The project does use prisma. Most of the meat and potatoes of the api are done using route handlers. Initially this was because:
* Server Actions weren't stable or widely used at the time.
* As a safeguard for if the API ever goes public.
* To provide quick demo i wont have to buy a VPS or something to host the API server itself.
The problem is, this works but it is no longer a very clean solution because:
* The project has authentication and i need to pass the headers around every single fetch, same with the URL, since most the fetching is happening in the server(i know, yikes antipatterns)
* The route handlers are rigid as such i need to either be passing many headers around to change their behaviour OR call many different route handlers and then post process to gain the same information.
* Since authentication and headers are involved, the API isnt very public anyways.
* Since i am calling many different route handlers and then post processing to handle the rigidness, it can be slow and timeout if i go for a serverless platform.
So the advice i needed is what should be the best path ahead. What should i refactor or use? Should i move away from route handlers, use server actions entirely or move away to separate API server using express or something? Some things i need are:
1) Be open to transition to a public model while providing the services to the next server itself.
2) If possible not have to buy a VPS or something to provide demonstrations atleast for this phase since we are still in development.
3) Still work with prisma.