Welcome to my PinkLetter. A short, weekly, technology-agnostic, and pink newsletter where we cultivate timeless skills about web development.
Let’s be honest, doing good enough is more difficult than doing great for people like us. There’s only one catch: doing great is more expensive.
It was good enough until we decided to integrate with a third party that produces tens of thousands of data points every 10 minutes. And, let me tell you, what the application does now doesn’t scale:
Are you surprised it takes a minute? Well, I am: I would expect that to take much longer!
Still, I don’t know about you, but I start doomscrolling twitter when CI runs for more than 5 seconds and I’m gone in 60 seconds—like Nicholas Cage on a Mustang.
I’m confident that given the time, we could bring it down to less than a second.
But I don’t have the time. And I’m struggling.
Paginating records across large datasets in a web application seems like an easy problem that can actually be pretty tough to scale. The two main pagination strategies are offset/limit and cursors.
We’ll first take a look at the two methods and then a slight modification that can make offset/limit extremely performant.
Some people test in isolation, mocking everything except the class under test. We’ll start with that idea, quickly examine the drawbacks, and ask how we might fix them without losing the benefits. This will send us on a trip through behavior vs. data, mutation vs. immutability, interface vs. data dependencies, how data shape affords parallelism, and what a system optimizing each of these for natural isolation might look like.
What we got is type safety for programs that live by using a flexible, string-based API. We transformed string types to strong types. All with just a couple lines of code and some of the more advanced features of TypeScript.
The best of the best links I curated in the last couple of years