After a decade of software engineering work (professional and personal), particularly in front-end development, I’ve crafted something I’m proud of.
In this article, I’ll walk you through my ideal tech stack and the intricate decisions that shaped MeetMomentum. Join me as we explore the nuts and bolts of building a tool designed to revolutionize how we manage time across global time zones.
In today’s connected world, tools to track global timezones aren’t just a necessity; they’re a lifeline for professionals and travellers alike.
Unfortunately, most calendar solutions do not offer effective multi-time zone support when scheduling and I personally faced many struggles because of this.
That’s how I started to come up with the MeetMomentum vision. I wanted to build something that truly accounts for infinite time zones, visually and intuitively. I also wanted to make sure it integrates with my existing calendar, so I don't have to look at multiple screens just to book a single meeting.
The design was one of the biggest challenges. There is a good reason why most applications don't support more than two time zones. It is not possible to fit all that information, in a digestible manner.
At least not with the existing approach.
The existing approach is having all five days aligned and invitees’ agendas overlapping. Instead, we flipped the calendar view on it’s side, presenting each invitee's schedule on their own horizontal line, offset by their unique time zone.
To navigate the calender users can simply swipe or scroll horizontally, and by maintaining the offset, we ensure perfect time zone alignment, in a very clean manner.
This is the core of our innovation, however, it came with a surprising set of technical challenges!
Have a play on the final outcome here: https://www.meetmomentum.tech/
Before diving any deeper, let's start by painting the landscape. Embarking on any software project requires a solid foundation, and the technical stack is where it all begins. In the development of MeetMomentum, choosing the right technologies was crucial to ensure flexibility, efficiency, and scalability.
Programming Languages Used:
TypeScript/JavaScript
CSS
Markdown/MDX for the blog
Frameworks and Libraries:
react-hook-form for user input with its great integration with zod.
Tools and Development Environment:
The architecture leans serverless. Being on Vercel, we leverage functions for our serverside compute. As we use supabase, we can also utilize PostgREST and Row Level Security (RLS) to directly and securely access data in the database.
And being React on NextJS we can lean into SSG and client-side processing.
As mentioned above the database is Postgres on Supabase with RLS and PostgREST being key plugins.
Hosting on Vercel.
Design Patterns:
Design patterns such as MVC don’t really map onto React very well. The general approach is to keep the state as close to where it’s used so updates are only triggered for relevant areas of the page. Optimizations can be made in cases where updates are triggered but inputs have not meaningfully changed.
State that is important across the application is handled via Zustand.
In some cases, components are split into the part that handles and provides state, and the part that is visual with elements and styles. This can help to build out the component’s style and debug without needing to replicate the exact state in a more real-world scenario. However, sometimes it’s easier to have a combined component just to get something finished.
Continuous Integration/Continuous Deployment (CI/CD):
Vercel integration with GH runs ‘build’ and we run most of our linting and tests as part of that build.
With a focus on SSG and client-side processing server-side compute is reduced. The vast majority of server-side compute is tied to accounts that can be managed carefully, and Vercel has capabilities to defend against abuse such as a DDoS attack.
So, in general, the platform should scale very well without much intervention.
There is room to improve some actions so we can leverage caching more or consolidate some requests but these are not of high concern until we reach much larger scales and can be worked on in the background.
As mentioned before, one of the biggest challenges was building the horizontal scroll for the scheduling offsets. This would technically be called an ‘infinite horizontal scroll sync,’ and it seems like we were the first use case for it!
The reason why it was so challenging was managing the browsers’ performance while triggering many browser events due to scrolling and lining up timezones accounting for their offsets.
Keep in mind that each horizontal line had to be kept independent, as the user could at any point change the order with our ‘drag and drop’ features. And to make things harder for ourselves, we also had multiple time pickers that worked by aligning the exact position of the scroller.
We tried multiple approaches, like having individual hour elements, and had to restart on at least four different occasions.
But the result was worth it!
Another major challenge was transitioning from the public scheduler to a personalized one, that integrates with your agenda. This time, the problem lies in trying to fit the agenda-related information into a small horizontal view.
To get to our fleshed-out product, we had to undertake a lot of iteration, trial and error, and of course, user feedback! We also faced multiple technical challenges, such as integrating with the Google Calendar APIs, getting permission to handle user’s data, and so on.
User feedback for MeetMomentum.tech has been very positive. Users enjoy the convenience and creativity aspects, but we are still very early in our journey. Stay tuned as we evolve, enhancing MeetMomentum.tech to better serve you and the global community; one update at a time.