“Uhh… I work with computers, Gramma,” I stammered out loud (and yes, Gramma’s the name us grandkids call her). Not satisfied, I follow up with “I help to build websites.” She flashed her genuine smile, politely remarked how proud she was, and we finally start catching up on the important stuff: family, food, and (for better or worse) those Red Sox.
After coming up short with “explaining” my job, an ideal solution dawned on me: I was going to build a website with her infamous recipes. This idea also fit perfectly with the fact that I’m a consumer of the serverless product I work on here at MongoDB: MongoDB Stitch. I could show Gramma what I do for a living all while learning what it’s like to be the very user I support every day.
Enter stage left: https://grammas.kitchen
Here is what I initially set out to build: a simple website capable of browsing through Gramma’s recipes.
In no particular order, a few of my goals with this project included:
- Continue to familiarize myself with TypeScript, React, and Redux
- Standardize the email/password auth flow with Stitch (e.g. register -> confirm -> login)
- Develop an “Authenticated Route” component utilizing Stitch’s auth listener
- Leverage Stitch’s “document rules” to support a complex network of recipe sharing amongst a user’s family, friends and other public recipes
- Make Gramma proud
Time and planning aren’t the most readily available resources but one of MongoDB’s core missions is to empathize with our users. My team often dedicates time to use our product and figure out ways we can continuously innovate it for every developer. Considering the email/password auth loop was one of the less utilized features of our system, I had an opportunity to work on a project both meaningful for my day job and my personal life.
The rest of this blog won’t be a “how-to” on the implementation. I’ll leave the Github repo here to do that talking. Instead, I’ll walk through some of the larger themes I felt while working on this project, the obstacles I faced and lessons I took from it all.
The feeling you get when you solve a problem
No matter how mundane a problem may seem to someone, it is brand new to someone else. That feeling of approaching, taking on, and ultimately solving a new problem is what keeps us coming back as coders. The moment I first successfully completed an auth loop by registering, confirming and then logging in was riveting. There’s no project too small or already solved too many times for you to take on if you’re interested. That moment of satisfaction is what continues to push us as professionals to bigger and better things — and I was able to provide meaningful feedback for our auth provider documentation.
Don’t reinvent the wheel
Obviously as developers, there is no problem we don’t think we can’t solve, but there is time and complexity involved in the calculus used to determine whether something is worth learning or not. For me, proper security was daunting enough that it always remained on the backburner. This project taught me something about the product I had developed on for over a year that I didn’t quite yet appreciate: it very capably handles auth for whatever your purpose may be. Maybe you want to implement no auth, or event restricted guest access. Maybe you have users with emails and passwords to share, or perhaps you have JWTs at your disposal. Stitch covers it all in a simple fashion. In this day and age when rapid development and quick turnarounds are vital to a company’s livelihood, any shortcut you can reliably take to get to your end goal is worth taking.
Reinvent the wheel (hypocrisy intended)
I still remember the first time I looked at Redux code and wondered exactly how much black magic was involved in getting it to successfully work. And when working with the TypeScript utilities, that black magic only seemed to increase. As any good hypocrite will tell you, what I said before about leveraging existing solutions is totally different from this. Instead of yarn installing my way out of a week-long deep dive into strong and wildly varying opinions on Redux architecture, I can tell you I feel better off for it. Gone was the black magic with Redux actions, and hello was the confidence I needed to actually pick a library that best suited my needs.
Choosing the right approach
Conviction is a double-edged sword. Without it, it’s tough to convince yourself you truly believe any course of action. Have too much of it though and suddenly you are at risk of overlooking potentially simpler or more scalable solutions. In my previous endeavor of reverse-engineering the many TypeScript Redux frameworks out there, I developed a pattern I began to really like for creating actions and their associated state management reducer functions. I would write the action creator and reducer together, then later combining related reducer functions together to manage a common, local slice of the app state. Suddenly, my individual actions and corresponding reducers were nicely co-located. When working on side projects, I didn’t quite have a long-term plan for proper state management, so handling the logic to modify that slice of app state all around my codebase was not too much of a problem.
Despite how much I enjoyed my type-safe builder approach for quick and dirty action/reducer definitions, I soon realized that as the state grew, the overhead with managing the state changes across many different places became difficult. I decided it would be in the project’s best interest to use a framework already developed for these purposes rather than my own. I still enjoy my utility, but it’s always important to constantly reevaluate the tools and approaches you may utilize every day in order to keep you and your productivity on point.
Learning new languages
When I joined MongoDB, I was signing up for a Go and JavaScript tech stack – two languages I had previously either no or very minimal experience with. Obviously, the chance to professionally expand my toolset was a no-brainer for me; I am always grateful to have been given the chance to grow into a role I was hired for. It’s an acquired taste, to consistently put yourself in uncomfortable positions. However, at the end of the day, I truly believe that is the path to consistent self-improvement. Six months ago, the idea for a recipe site honoring Gramma’s exceptional cooking never crossed my mind. Now, my family has a way to conveniently look up how to make her stuffed long hots and famous chicken cutlets.
Skunkworks at MongoDB
Every year during a specified week we call “Skunkworks,” engineers are given days off from their regularly scheduled programming to take on whatever project they’d like. I’m looking forward to this year’s Skunkworks to start my next dedicated iteration on this site.
I want to work on styles and colors and bring in some form of CSS in JS. I also want to introduce the idea of “families” that users can belong to, automatically see new recipes posted within, and invite others to join as “friends” or “new members.”
Skunkworks is one of the best times to share with my coworkers what I am passionate about and find people with similar interests.
Beyond all the skills I honed building the site, the best reward was Gramma and my family the recipes once the website was finished. She loved seeing it and we even cooked one of the recipes for dinner that night, just in time for Christmas.
If you are interested in learning more about engineering at MongoDB, check out our open roles around the globe and build with us.