Hacker Noon 2.0 Dev Update 2: Electric Boogaloo

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.

How do you implement SSO using Firebase, along with Discourse for our community forum? The details are a bit hairy, but essentially the process is this:

1. You click the “Get Started” button at the top-right of community.hackernoon.com
2. You’ll be redirected to an authentication page on auth.hackernoon.com, which carries with it “sso” and “sig” parameters in the URL.
3. You enter your email. If your email address hasn’t been verified, you’ll receive an email with a link to continue.
4. At this point, you’ll be on the password page. This will accept your email and password, logging into Firebase and generating a Firebase ID token.
5. The ID token, “sso”, and “sig” parameters are sent to the backend.
6. The backend deconstructs the “sso” parameter, extracting a nonce and verifying the payload’s authenticity in the process using an HMAC and comparing the result to the “sig” parameter.
7. The backend generates a new payload containing the user’s verified email, name, handle, and so on, and packages it together with the nonce in a base64-encoded blob.
8. This payload is sent back to Discourse (the community forum) and you’re signed in!

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:

• You’ll have one login for all Hacker Noon 2.0 properties, including community.hackernoon.com, the community forum, and app.hackernoon.com, where you’ll write and submit stories in 2.0.
• Thanks to email verification, no one can claim your email as their own.
• You can request any handle you desire, as long as you don’t take a trademarked name or impersonate someone. Pseudonyms are a-ok though! There’s plenty of prime real estate left as I write this, so use your imagination — the sky’s the limit!
• Thanks to the CDN, your stories are going to load fast. Since they’re largely static pages, and all of the essential data is embedded statically, there will be hardly any load time and the pages will be SEO-friendly by default.

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.