Search for a command to run...
How I rebuilt my PERN stack app using Next.js, Prisma, and serverless architecture to improve performance and simplify APIs.
Self-taught Software Engineer from Singapore (that eventually goes to school for it). Passionate about building new stuff that helps people save time!
No comments yet. Be the first to comment.
My stint with Apple Music has come to an unfortunate end. I’m not trying to make it sound like a huge breakup note reveal. I’m actually writing this to reflect on my time with both services. It was an
Why my RAG system failed using ChromaDB and local embeddings — and how better context and data structuring fixed retrieval accuracy.
How we used Roblox Studio and Lua to build a 3D cybersecurity CTF game for students — and what we learned from bugs, refactors, and live demos.
Is Swift worth learning for React Native developers? An in-depth comparison of SwiftUI, SwiftData, DX, performance, and ecosystem maturity.
How I built a personalized graduation website with Next.js, Redis, access codes, and a server-side countdown to stop cheating.
When I first created the other Musicn, I was putting my skills at that time to use. I used my knowledge in API design, React, and the PERN stack to create the application.
As time passes, new technologies emerge, and I want to use them to create the best possible application.
Musicn-next (or the new Musicn) is powered by Next.js and Serverless architecture. The speed is unbelievable as compared to the previous Musicn.
The problem with the old Musicn is that it is a slow website. It is really slow. Each API request can take up to 2 seconds, which is such a big no-no, especially for users.
In research by Jakob Nielsen titled "Respone Times: The 3 Important Limits", he said:
It is important to note that the response time is not the same as the time it takes to render the page and the time it takes to send the response to the user. And it is my mission to make the response time as fast as possible.
The old Musicn has many endpoints. And a bulk of them is focused on authentication, and my goal with the new Musicn is to make it a full-stack application. This new goal came to light so that development will be maintained on ONE codebase.
However, Next.js allows us to make API routes simply by making a file in the pages/api directory. The mapping of the route will be the filename. So user.ts will map to /api/user in the URL. How cool! Moreover, Next.js API's API and syntax are akin to Express.js, making the switch even easier!
The old Musicn uses pg for ultimate speed. But there is a trade-off regarding readability and how developers can get on board with development. It is hard because you need to type in SQL databases manually, and then you need to know the table names, column names, the datatype, and relations. AH! IT'S A MESS!
To integrate an ORM into the old Musicn will be counter-productive and many of its codes need to change, and that will make everyone go insane.
This new Musicn has one goal, and that is to use an ORM to get data. And Prisma is the ORM of choice. it is our choice because of how developer-friendly it is, the autogeneration of the schema files, and many other features that make it stand out from other ORMs such as Sequelize and TypeORM.
No implementation has 0 shortcomings, it's always a compromise. And building the new Musicn, I am humbled by some of the shortcomings.
Although Next.js has a similar syntax to Express.js. One of the things I missed in Express.js is the middleware. After one hour of looking for middleware solutions and then looking for more, even trying the new Middleware feature introduced by Vercel. I used an old method:
import APITokenHandler from '@/util/APITokenHandler';
import { NextApiRequest, NextApiResponse } from 'next';
export default function withProtect(
handler: IHandler,
rejectWhen: APITokenHandler.REJECT_WHEN = 'none'
) {
return (req: NextApiRequest, res: NextApiResponse) => {
console.log(
`=====CHECKING FOR TOKEN IN ${req.url}, (REJECT TYPE = ${rejectWhen})=====`
);
// TODO: Cleanup code
if (rejectWhen === 'none') {
if (!APITokenHandler.hasAPIToken(req)) {
return APITokenHandler.reject(rejectWhen, req, res);
}
} else if (rejectWhen === 'has') {
if (APITokenHandler.hasAPIToken(req)) {
return APITokenHandler.reject(rejectWhen, req, res);
}
}
return handler(req, res);
};
}
And then, it is used by wrapping the API handler:
export default withProtect(handler as IHandler);
Vercel provides hosting for Next.js sites, and it's a one-click solution. Register for an account, link your GitHub, select your repo and deploy! (and also some configurations of environment variables)
Some tweaks I have done are:
By changing the Serverless Function Region, the speed of API calls increased significantly. (and obviously will introduce some extra time if someone is further away from the Singapore server)
Read more: https://nextjs.org/docs/going-to-production#caching
Using caching, I can cache responses for the APIs and pages. This makes it fast! I even made a class to handle caching headers for me:
export default class Cache {
private static headerName: string = 'Cache-Control';
/**
* Revalidates the cache in the edge server while showing the old stale data meanwhile.
* @param res NextApiResponse
*/
public static revalidateInBackground(res: NextApiResponse): void {
res.setHeader(this.headerName, 's-maxage=1, stale-while-revalidate');
}
/**
* Caches the data in the edge server and expires after the given seconds, to which, it'll refetch and cache new data again.
* @param res NextApiResponse
* @param expiresAfterSeconds number
*/
public static inEdgeServer(
res: NextApiResponse,
expiresAfterSeconds: number
): void {
res.setHeader(this.headerName, `s-maxage=${expiresAfterSeconds}`);
}
}
I have learned a lot about the React ecosystem and the ecosystem of Musicn. I have redefined endpoints to be more useful and as simple as possible.
Along the development journey, I learned more about technologies and how they work, and how it is important.
I learned even more stuff from when I built the old Musicn.
Rebuilding applications using new shiny technology is always fun, it allows you to explore and learn more (even refresh your memory on what you thought you knew).
My message to upcoming aspiring developers: Build what you're passionate about, and continue building it. There's never a "complete" software, there's always room for improvement, and you shall pursue it in terms of watching talks of technologies and figuring out a way how to integrate it with your product.