Our dashboard “worked.” It also made new users stare at a spinner for five seconds while seven separate network calls each repeated the same auth and data shaping logic.
About a year ago I was refactoring a backend for a travel platform. A year later, it seems like I'm back doing the same thing. Rebuilding the backend for TaDone.
At the time it was challenging getting across why it needed to be done. And even though TaDone is in a much better place than that codebase ever was, It met three of my refactor triggers in one path, so I set out to do a scoped rewrite with a clear success metric.
My simple refactor triggers
I don’t refactor because I’m bored (most of the times 😅). I refactor when at least two of these fire:
- Core path p95 latency > 2s
- Same auth / validation logic duplicated 3+ times
- A small visible tweak touches 3+ endpoints / handlers
- Security boundary inconsistent or drifting
- Adding one field feels “risky” because logic is scattered
That dashboard path hit three in one go. Game on.
The big dashboard rewrite
I reconsidered most our dashboard backend logic because it was taking around 5 seconds to get everything to the client. Why? A few reasons:
- Each tile had its own endpoint that it would fetch;
- This meant that for each endpoint these verifications were made: a. AppCheck to validate the request comes from a legitimate user; b. Authentication making sure the user is properly logged in; c. Authorization to make sure the user can access the data they're requesting; d. Retrieve data from the database; e. Map the data to a format that is suitable for the client and doesn't leak sensitive information.
In retrospect this was obviously problematic and never how you create a dashboard. But how does such a thing come to be? Easy! You start with a set of components that already exist across the application and put them together in a single page. And presto! You have a dashboard!
Let the rewrite begin!
I defined a shared schema definition to make composition predicatable. Instead of creating a schema for each tile I had I grouped those into the 4 kinds of tiles and created a schema for each.
Then all I had to do was to create an endpoint that gets all the same data as before, do the mapping and return the composed object with ETags to help with caching and prevent subsequent requests to the database until the data changed.
On the client side some adjustments had to be made to the components so that they didn't need to fetch their own data and instead relied on a composer to pass it on. And that was it.
With that done the cold start for the dashboard went from around 5 seconds to less than 200ms!! That's a great boost to user experience.
Why ‘It works’ isn’t a strategy
That initial dashboard fits perfectly in line with some of the past experiences I've had with other founders. Where it doesn't matter how long it takes and how many resources you spend. "Users will let us know, so it doesn't really matter right now" the saying was.
Because of this clash of ideas (you can call it ideals if you want) I've struggled to deliver something I couldn't stand behind. Don't get me wrong, the idea behind the quote is valid but most certainly about how a feature works and not how it performs. In funding stages of any startup I get why founders get blinded by the need to get money as quickly as possible. So showing up with a load of capabilities to a pitch is core to their rationale.
Sometimes it 'has to work'
Most common reasons avoid a rewrite include:
- Capital
- Changing requirements
- Team size
- Time
In the early stages of any startup everyone will tell you need to move fast and break things. Fair, unless you can raise capital or get customers there's no way you can survive long term.
Understanding your product and how it is going to be used doesn't always justify the time effort of rewriting core parts.
Once you have capital and can start hiring people, you'll be able to change it and mold it to customer's feedback.
Just do it!
There is nothing worse than betraying a costumer's trust. It burns you forever at such early stage. Having worked in healthcare most of my life, it comes with the territory.
Quality involves having standard ways of accessing and securing data, handling errors, managing roles, etc. If you don't have a centralized standard way of doing it, you're bound to forgetting it.
Establishing a practice and automating verifications through configuration makes software more reliable, easier to reason about, and above all, easier to fix when things go wrong.
It is a fine balance to abstract away complexity. But it comes with the clear benefit that Jeff Attwood said best back in 2007.
... the best code is no code at all Coding Horror blog
If you think of it, it makes absolute sense. But it isn't always obvious when you're in the midst of creating something and don't see the forest from the trees. Other times you need to wait for patterns to emerge to take the step. But authentication, authorization, schema validation are things that should be consolidated as much as possible. While software is written by humans at least because we tend to forget things.
Secondary gains
You may also want to do rewrites because you realise something isn't going to pan out as you expected. You know, plans change, requirements change.
Dev experience is also important. The recent Tea app debacle is a great lesson on how things just get forgotten and left behind. You have a moral obligation to protect the data of your users. If you need to create an abstraction to guarantee that all endpoints have a consistent way to protect data, do it! Not only it will reduce your burden on each endpoint you have to create as well as makes it obvious where to go when you discover any issue. This is especially true if you work in a team. Don't rely on everyone thinking the same way you do and implement all validation or testing.
In summary
With all that said, it took me quite a bit to accept and externalize my points and that they're valid.
Shipping matters. Revenue matters. But ignoring obvious structural drag is not “hustle”. It is deferring compound interest on pain.