It's a beautiful sunny day, birds are chirping, your side project is running seamlessly...
but then...... you get a $5.90 bill payment reminder for the nth time due to a s3 bucket you made on DigitalOcean Spaces that merely has 500MB data.
That's it. You have had enough. It doesn't make sense to pay at all for such a small storage. You got to put all your assets somewhere else. But before that let's have a little flashback :-
So more than a year ago, I participated in a hackathon organised by dev.to in collaboration with DigitalOcean. We had to make an app that has to be deployed on DigitalOcean's App Platform. So I made animeccha.com which is documented as a series of blog posts starting here. The images being served are powered by imagekit.io, the deployment by DO's App Platform and storage of those images in s3 bucket in DO's Space (this was free for starting 2-3 months due to $100 credit you get as free trial).
Now back to the present :-
My Image transformation was already powered by Imagekit but the storage was in a s3 bucket far far away (well not really, they have edge CDNs). So, I deleted the s3 bucket and just used the media library given by Imagekit as part of free plan with 20GB of monthly BANDWITH!!!. Lol should have done that in the first place.
So just by switching to it, I started saving $5.90 a month. Srsly, why was I even paying. Such laziness, much wow. But I did one more thing that was not required at all. I mistakenly also deleted my App Platform deployment so animeccha.com was now a template site of L'ORÉAL Products. No srsly, that's what my domain vendor thought of showing as a fallback.
Anyhow, I decided that my deployment platform should also shift and I chose Vercel because I have already used their services and find the setup relatively easy. As this project also has it's custom domain - animeccha.com, I had to switch my name servers from DigitalOcean's to Vercel's in my domain's DNS records. Cool the site was now up and running on Vercel, everything is back to normal.
But but....the developer urge to go further.
My App deals with images a lot and being a CSR (client side rendering) web app, the image loading even with placeholders wasn't the best UX. This is something I had in mind for long and now that I gained some experience in Next.js from my job (btw I work @Hashnode), I thought of migrating the whole thing to it and take advantage of their sweet Image component.
Their official docs have a great guide to do so and I followed it step by side. TL;DR - Getting rid of
react-router-dom and installing
next and updating
package.json scripts. Also taking advantage of their
pages route structure for flexible routing.
My old routes:-
/home- Landing page
/anime/:anime- Specific Anime Page
/anime/:anime/:montage- Specific Montage of that Anime.
My new routes:-
/- Landing page
/:anime- Specific Anime Page
/:anime/:montage- Specific Montage Page of that Anime.
The new Next.js powered routes made much more sense.
/:anime got transformed to purely SSR pages powered by
/:anime/:montage loaded the whole
Montage component dynamically on client side since it required a lot of interaction with browser APIs (probably more time there and something else could be worked out but it's f9 for now).
And while this migration was happening, I realised something. I found modifying my CSS Modules powered styling less flexible now that I have used Tailwind at work. So yes I installed tailwind following this guide and changed most of my CSS to it except the
Montage component since it had more moving parts and I wanted to keep them intact.
With all this, I deployed my changes in a new branch and raised a PR to the main one.
With two-three failing deployments, due to typescript errors and the fact that I forget to tell Vercel that what I am deploying is not a CRA project but a Next.js one, the project was finally live with much better UX.
But but....there could be
I also realised that both my
/:anime pages are static and don't rely on server data. It was time to let them be treated likewise as well. Enter
getStaticPaths as part of SSG feature of Next.js. So I updated both the pages accordingly replacing
getServerSideProps with the above functions and though not as such a visual difference, I somehow felt at ease now.
This was also my first time making efforts to migrate an existing side project. Though it's a very simple one and really doesn't have any customers and what not, refactoring it to make give a superior UX (even just to me) was a nice experience.