For the past few months, I’ve been hacking away on Hacker Noon 2.0. In that time, I’ve encountered a wide array of technical challenges, gotchas, tricks, and treats. Today, I’d like to share some of that with you, our community.
Let’s start with some of our architecture: we started by using Firebase on the backend, and React on the frontend. As discussed at our Github event at the beginning of March, we quickly discovered that Firebase costs would get out of hand. Long story short, we decided to go with a hybrid system, one that uses a CDN (content delivery network) to serve high-traffic pages like the homepage, story pages, and so on, and a fully-powered Firebase app will serve pages like the story editor, the editor dashboard, the admin dashboard, etc. This structure will reduce our hosting costs by an estimated 90%!
This architecture has served up some interesting challenges, not least among them single sign-on, or SSO. SSO is, to be blunt, a pain in the ass, but it’s necessary. We’re going to have the root domain, the app subdomain, and the community subdomain, and we certainly don’t want you to have to log into 3 separate apps, with different logins…that would be a nightmare, and most people simply wouldn’t do it.
The process is a little bit different for login, but the meat of it is the same. This ended up being an extremely involved process that took a lot of trial-and-error to implement. I was extremely thankful for the guides I linked above — without those, we may not have SSO.
So what’s the upshot of all this jibber-jabber? A few benefits:
Next up: I’ve been working on a ton of optimizations to our page building system. The system, as of a few days ago, was extremely naive, simply rebuilding the pages when anything was updated. Soon, the system will build only what’s necessary. In the coming days, I’ll be working on a split between markup and data for certain things like emoji reactions, sponsorships, and so on, which will allow us to update a simple JSON file instead of regenerating the entire HTML page. I’m also writing queries to “fill in” parts of the page that are currently static, like the “More Stories” section or “related tags”.
Overall, it’s been a wild ride so far, and I wouldn’t trade it for anything. We’re working at breakneck speed to get this to launch, and it’s honestly thrilling. Not to mention fun! I’m having an absolute blast building 2.0 from the ground up, and iterating on initial approaches to content generation, SSO, and a host of other problems we’ve solved.
Iteration, in the end, will make or break this platform. This isn’t just cleaning up troublesome code, or refactoring, or clearing tech debt. This is fundamentally reconsidering your approach, your assumptions. I guess it could fall under the umbrella of refactoring, but it’s an extreme form.
To me, iteration has meant I can code quick and dirty solutions, but I have to clean up my mess when I’m done. It means we can ship bare bones functionality now and handle edge cases after. These ideas might be raising alarm bells for some of you — they certainly did for me, at first. However, keep in mind we’re talking about fixing things immediately after you first publish them. And with the boy scout rule in mind, the code is getting cleaner all the time.
That is, you clean the code if the concept is worth pursuing. There’s no sense in cleaning something up when it’s going to be thrown away, after all. Test the concept, not the code, and see if it has legs. Then, given user feedback, decide whether it has value and clean and refactor from there, incorporating the better parts of the feedback you received.
On the opposite end, you have some companies with processes that dictate clean production code, always. You can’t deploy “dirty” code, even if it gets the job done. Sometimes there are good reasons for this. But too often, companies imitate the processes of larger companies without thought as to how they apply to their particular situation. This turns a 3 day task into 3 weeks.
I’m not suggesting this is all there is to iteration. It especially applies to the UX as well, but that’s not something I’m as well-versed on as backend code, authentication systems, and so on. I could give you examples of iterations on user-facing features, but our CPO, Dane Lyons, has done a better job than I could.
Ultimately, iteration means we have to always be improving. It means that launch isn’t the finish line. It means we have to swim or die. Which means: I should be getting back to work.
Originally published at community.hackernoon.com on April 12, 2019.