I like Firestore because it’s an easy-to-use database. Especially because it’s easy to build queries that are just fast. It’s designed to work at scale - by providing queries that have a constant time, regardless of the query conditions. But if you have worked with Firestore before, you will know that this limits the types of queries you can do. This can make range queries, for example for calendar applications, a challenge.
Creating a UI where a user can manually reorder items based on their needs is neat, but can be quite challenging to implement in the backend. One need to store the order of the items somehow. There are different approaches to doing this, but each of them has trade-offs when it comes to performance and scalability. In this post I want to explain my scenario, compare them, and choose the best implementation.
I recently helped a team improve the performance of one of their services. They had already invested some time, but over time the performance was getting even worse! Their Node.js service was suffering from slow response times. At some point, the team added performance tracing using performance.mark() and performance.measure() to understand why the response time was so long. Little did they know that this would make things even worse…
Even with fast internet speeds, one key metric for improving initial page load times for websites or web apps is reducing the data transmitted over the wire. While you can optimize all kinds of assets, like styles and images, I want to focus on the size of the JavaScript bundles. Code size has an impact on download duration, but also on parsing and JavaScript execution. This can be measured as Total Blocking Time (TBT) or First Input Delay (FID), a metric suggested by Google to measure page performances as part of the Web Vitals.
