Just when I thought I was done with my first SaaS, DebateTrend, coded in Express I decided it would be a great learning experience to recode it entirely in another framework…
That’s how my three-week journey with Next.js started. It was one of the best decisions I’ve made as a developer. In fact, I’ve grown to love Next.js so much that I plan to use it for all my future full-stack apps.
Here’s what I learned and the major changes I made during the transition:
Quick Overview Of DebateTrend?
First of all, let me explain what my SaaS is about. DebateTrend is a web app, where you can debate with AI on different topics!
You can have multiple debates with different debate styles for different lengths of time!
Here’s a quick overview of what changed in my tech stack:
- Language: Javascript -> Typescript
- Framework: Express -> Next.js
- Auth: PassportJs -> NextAuth
- Front End: TailWindCSS, ejs, some regular CSS and DaisyUI -> React, TailWindCSS, mjs, and some regular CSS
1. Switching from JavaScript with Ejs to TypeScript and React with MJS
I had never used TypeScript, React, or MJS. This shift completely changed how I think about coding. While coding TypeScript was confusing it gave me more confidence in the code I was writing. Breaking down repeating code into React components helped me think of HTML as reusable code which felt like unlocking a cheat code.
2. Authentication Challenges
The struggle with authentication keeps going. It was as painful as ever. I implemented both email and Google authentication but decided to move from Passport to NextAuth. While there was a learning curve, I found that NextAuth integrated better with the Next.js ecosystem and simplified future setups.
3. File-Based Routing
One of my favorite parts of working with Next.js was rewriting API endpoints using file-based routing. Unlike code-based routing, file-based routing requires less boilerplate code. It took some getting used to but I would say I enjoyed it more and thus prefer it.
4. Database Shenanigans
One of the main reasons I moved to NextJS was because I was getting some weird errors from the DB connections (most likely due to the serverless nature of Vercel) I couldn’t fix the problem even with help from others for more than 2 weeks. I then decided moving to Next would eliminate the problem since it was native to Vercel.
Needless to say, when it came time to recode my MongoDB implementation I was quite stressed, since if I was still getting the same problem I would have to move the hosting and do dev-ops.
Interestingly enough my code integrating MongoDB stayed almost identical, yet the problem never showed up again.🤷
5. First encounter with ESLint.
Since I was new to NextJS I hadn’t run “npm run build” which makes the application production-ready and activates ESLint powers.
Honestly, I didn’t even know what ESLint was. All I had heard from it were some memes.
So I ran “npm run build” for the first time right before pushing it to production after 3 weeks of coding and remaking the app…
I had 104 lines of errors.😶 My heart dropped.
It was an even bigger shock when I managed to knock out all of the errors in just 3 hours. Keep in mind that it was my first time encountering ESLint errors! I’d say I did relatively well!
Actually, after refactoring my code to be ESLint compatible I genuinely felt like my code was better and that I had become a better developer.
6. SEO kinda
While I didn’t optimize SEO to the fullest capabilities that Next.js has, the transition has opened doors to explore features that are crucial for driving organic traffic.
For any SaaS aiming to attract users without a massive ad budget, SEO should not be ignored, and Next.js makes it a lot easier.
Conclusion
Next.js has redefined how I think about building full-stack apps. Its efficiency and modern features have made it my go-to framework moving forward. If you’re considering switching frameworks or trying something new, give Next.js a shot!
Thank you for reading, and best of luck!
Top comments (0)