Couple of months ago I started building a mini project called ToolDeck. It's basically a launchpad for little tools developers and designers use. As its backbone; it uses Next.js for frontend, and Apollo Server for backend. MongoDB was also my choice of storing data. On top of that, everything is written in TypeScript, and I used SASS with modules for styling. I also made a mistake of using React Spring for some animations. I'll get to that in a bit... Now it's time for me to dive into the clusterfuck I created. Let's get started!
I like the routing API of Next.js, and I certainly don't like creating a webpack project with bunch of external packages like SASS and TypeScript. Since it handles all of that, I'm happy with my decision. I made sure to waste all the time it saved me on other parts of the project with completely unnecessary details.
I used SASS with a header file that contains all the variables like colors, paddings, etc. And since I hate naming classes, I used it with modules. It's very easy to get SASS modules running in Next.js. This setup, in my opinion, is a very comfortable way of working with CSS.
Querying your GraphQL requests is effortless with Apollo React Client. It also takes care of most of the caching you'd normally do with Redux or other state management options. However, when it comes to altering that cache, it lacks simplicity. It isn't as easy as React Query's mutation function for instance. If you are aiming for creating an optimistic UI as I do, it'll fire back.
I mentioned I used TypeScript across the project right? Well... This is a day in ToolDeckLand:
1) Write types for mongoose models
2) Write types for resolvers with TypeScript
3) Write types for GraphQL schema
4) Write Apollo Client queries
5) Write types for Apollo Client queries with TypeScript
Yes, I should have used codegen. But this is a small project and it shouldn't have that kind of complexity. Of course I knew this stack would be an overkill for a project in this scale, but I thought it would be fun. Turns out it's not... Writing same queries and same types over and over again takes away all the fun of adding new features. And I always miss something with either query fields or types. It easily becomes another debug adventure.
MongoDB was a good choice for this project. And MongoDB Atlas made it even easier to implement. You might need to do some configurations for Mongoose to work with findById or etc., but I had no serious problems while working with Mongoose.
This project lives here if you're curious: tooldeckhq.com.
I hope this was useful, you can also follow me on Twitter for future content: