This file is meant to capture project level decisions that were made in this project and why. In many cases, there are no obvious right answers and we have to make a decision with multiple options.
Log processing stack helped us:
- Auto-expire all Lambda function CloudWatch Log (CWL) Groups
- Subscribe all Lambda function CWL to a Kinesis Stream
- Create CloudWatch Metrics asynchronously via canonical log lines (akin StatsD)
CloudWatch now allows metric creation asynchronously via Metric Embedded Format (EMF) thus making this irrelevant and less costly.
As we have recently open sourced Lambda Powertools originally created in this project as a shared lib, we have now replaced the log-processing stack with Powertools Metrics utility.
This reduces deployment time by 2m per build, and our metrics cost by approximately 90 USD per month.
Shared dependencies that are used by more than one service within the project are now bundled as a Lambda Layer - This includes Lambda Powertools, requests, boto3, and a custom process_booking middleware.
We fully migrated from the original powertools to the now public OSS version.
As part of this process, we ported custom logic for processing booking information as part of our ProcessBooking State Machine into a custom Powertools middleware.
This reduces nearly 4 minutes from our total deployment time improving developer productivity, and reducing a shy four cents per build
Quasar (UI framework) had a major release and deprecated the 0.17 version, and soon after Amplify had a major release cut as well as completely refactored UI components such as Auth.
While Quasar had a great upgrade guide there were components and style changes that would no longer fit in the project, thus requiring at least a month or so to get familiar with the new docs, structure, and recreate what we had.
Given the size of changes, it is best to to treat as a new version as it cannot be easily synced into one's fork.
Both Quasar and Amplify JS are fundamental to this project, and using deprecated versions meant we had to spend more time working around CVEs encountered in transitive dependencies along with other fixes.
This upgrade gives us two major benefits: 1/ Eliminates patching CVEs and transitive dependencies, and 2/ Pays technical debt in time to do another major upgrade (Vue 3, Quasar v2), where it'll further simplify the Frontend.
Due to the amount of breaking changes in Quasar, and Amplify's move to Web Components , we had to recreate the UI from scratch as tools also changed, and with this we had a chance to make the following minor improvements:
- Search flight orientation can now swap departure/arrival
- Flight results now have a toolbar to quickly change flight schedule, including a new set of Filter we will implement later on
- Profile no longer has preferences as they were unused
- Flight cards and bookings are cleaner and more modern
- Up to 30% perf improvement due to Quasar upgrade
- UI prototype is now available for anyone to recreate in anticipation of a hardcore workshop to be published later on
- Flight autocomplete is now a separate mixin making it easier to reuse (more to come for a new Booking toolbar)
- Quasar supports dotenv so no more need for
VUE_APP_<VAR>environment variables