I recently launched a Slack app to help with channel bloat! Simply installing it would help me out a bunch. I have 2/10 installations required to submit my app to the Slack Marketplace. Thanks for helping me reach that goal.
I recently decided to swing back around to Elsewhere. Probably because post-COVID travel has picked back up, so I have been planning more trips and wanted to scratch that itch again. Elsewhere was the first web app that I ever made by myself. The first API, UI, idea, everything. I have since made plenty more things that are online.
When I started Elsewhere, the idea was to make an app that converged all the software that I used to plan a trip into one. Mostly that meant Google Maps and some form of a spreadsheet. The map was used to keep track of places that I wanted to go and the spreadsheet was for jotting down notes about those places and planning the timing, the actual itinerary. I didn’t need those technologies for all the wonderful things that they can be used for, I needed a very small subset, mostly revolving around being a data store for my ideas before they were fully fleshed out.
With my idea in place, next came the technology. I knew what AWS was, and I had also heard the tales of how expensive it could get. My frugal, bootstrapping self did not want to wake up to a surprise bill. (In hindsight the problem was that I did not fully understand AWS and how pricing worked.) So I decided to look around online at an ideally, free hosting solution. Something popped out. At the time it was called Now but it is now known as Vercel, and they hosted a framework that they made called Next.js. I could host a frontend React app and a backend for free? Sold. On top of that (or behind it?) I used MongoDB’s free database. (It is worth noting that this was my first exposure to NoSQL and I knew nothing about it.)
My original idea for Elsewhere still stands but the technology choices do not. I ended up completely rebuilding Elsewhere from the ground up. Gone are the days of a strangely cobbled together, Next.js-hosted, GraphQL backend. Gone is the free MongoDB instance (although I think it would probably still be a good choice). Gone is the poor state management in the front end. In comes the new and improved tech stack. The UI has also been completely rethought and I want to spend some time later discussing that aspect of the project.
The first major shift in the new version of Elsewhere was to move off of the native auth onto my authentication service. That meant no more social login but also a faster and cleaner experience both for users and for me. I originally based my many iterations of the authentication service on Elsewhere’s auth so it only seemed fitting.
The next major shift was the backend. I moved to a fully serverless, AWS-powered backend with my usual stack of API Gateway, Lambda, DynamoDB, and SNS. Everything is defined with the CDK. At this point, I have so much CDK code that I have probably already written just about anything that I want. The Lambdas are written in Go to minimize cold start times and overall latency just like the authentication service. The data model is slightly wild and not exactly what I was hoping for, but what are you going to do 🤷. And SNS facilitates any of the background processing I need. The API itself was completely redesigned with different levels of entities in place. Having a well-thought-out API made hooking up the frontend so much easier. I don’t want to get too into the weeds with the backend right now because I am planning on writing a separate post about the API’s architecture. Edit: Linking the architecture post I wrote.
Moving up the stack, the frontend has been almost completely redone. I am still using Next.js hosted on Vercel, but I went from Next.js version 9 to version 13. Luckily, there were not too many changes involved with that version jump. I was also able to lose quite a few dependencies that I simply didn’t need anymore. I had originally used Material UI and heavily modified and styled it. I jumped from MUI version 3 to version 5 and scaled back a lot of my poor design choices in favor of MUI defaults. This package’s version change did involve code changes on my end, particularly around theming and styling. Most of the components were still available with the same props too, but I had to track down some tricky prop name changes.
Once I figured out the frontend technology, I moved on to the design of the UI. Overall, the design feels much less cramped and easier to interact with. I used to walk on eggshells when I used the old app because I was worried about breaking something. Now, I feel much more confident in how the state is managed and how everything interacts with each other. I also added a view for a schedule, which was probably the single hardest piece of software I had to write for all of this. I had wanted to add a scheduling view since I last stopped developing Elsewhere and never got back around to doing it until now. I knew I wanted to completely remake the API before attempting anything in the UI, which is what slowed me down. The most difficult part of the schedule was planning out how to place events with overlapping times. I am planning on writing a dedicated post about the scheduling view and how I wrote the algorithm to accomplish it, so I won’t get too technical here. Edit: Linking the schedule component post I wrote.
The latest and greatest iteration of Elsewhere is now live! I am pleased with the outcome of my work and I am much keener to show this iteration off than the last one. There is still improvement to be made. I will be testing and improving as I go, and if anyone else uses it and wants to suggest improvements or features, please do. I can be reached at thomas@thomasstep.com or tstep916@gmail.com. I would be happy to hear any feedback!
Categories: aws | databases | dev | front end | go | javascript | meta | ops | serverless