Hi there! My name is Austin Pocus (like “hocus pocus”), and I’m a Full Stack Developer here at Hacker Noon. For the past couple months, I’ve been hacking away on Hacker Noon 2.0, and I’m itching to share more about the process, our decisions, our tooling, our architecture…basically anything and everything is fair game here. Ask me anything!
Can you give me some explanations of HackerNoon 2.0 tech stack? What would it use and where would it be hosted? (Perhaps something like Digital Ocean or Linode?)
Does your team go with new shiny stack (React, MongoDB, Node, etc)
Or the already proven stack? (Laravel, Rails, Postgre, etc)
Hi Nathan! I’d be happy to dive into the details of our stack: we’re using Firebase as a backend (if you can call it that – it’s more “serverless” than a “backend”), and React on the frontend. Hosting will be on Firebase, along with the database, authentication, and everything else Firebase provides.
We found that React is stable and well-supported at this point, with a wonderful ecosystem and community, so we’re willing to bet on it. As for Firebase, they have an excellent service that takes care of a lot of backend and devops work that would normally go into a platform of this type and magnitude, so we can focus more on the frontend and the user experience, and creating an excellent experience for our community.
To give a little more detail: not all of the platform is going to be fully Firebase-powered. It would be incredibly expensive to query hundreds or even thousands of records, for each reader viewing each story, so we decided to go with a hybrid approach. The app.hackernoon.com subdomain, where writers will write, editors will edit, and admins will administrate, will be fully powered by Firebase. However, the main site at hackernoon.com, where readers will see your stories and others, will be a mostly static page served over a content delivery network (using Google Cloud’s CDN). This approach, while a bit unusual, was able to save us an estimated 90% on hosting costs! I’d be happy to go into more detail here if you like.
The upshot is, your stories will be served quickly, efficiently, and reliably.
I hope that answers your question thoroughly! If you have any more questions, please, post them here. Thank you for being a part of the Hacker Noon community!
@austin has there been any movement that can be made public about methods for author monetization on HN 2.0? understandable if not. Fascinating about using Firebase, is there any integrations with their push notification frameworks? That’s the only exposure I have to Firebase.
Hi @jare! We aren’t currently working on author monetization for day 1 of version 2.0, but we’re definitely thinking and talking about how to do this in future iterations. What would your ideal monetization structure look like? We have some ideas, but nothing beats feedback from an actual writer.
We aren’t currently using their push notification frameworks, no. I believe what you’re referring to was a feature of their Realtime Database, and we’re using the next-generation database, Cloud Firestore, which is much more powerful than its predecessor.
We’ll have an activity feed of some form in 2.0, showing you when an editor has opened, edited, or approved your story, and of course, we’ll continue to build on that with feedback from the community, but we won’t have push notifications from day 1. I wouldn’t rule them out in the future, though – how cool would it be to get a desktop notification that your story has been approved? You will be able to see that in the app from day 1, in the activity feed I described, but I just like the idea of a push notification for this case.
Thanks for your questions! If you have any more, post them here!
Oh that’s great! I’m familiar with Firebase and their services.
So let me guess, does this mean the main site will use static site generator like Gatsby or Hugo? Since you’re going with React, I think Gatsby with GraphQL it is
Thanks for the answer! Can’t wait to see HN 2.0 in action!
I hate to disappoint you, @nsebhastian, but we’re not using Gatsby at this point. We’re using a much simpler, more flexible solution for now, using a combination of Lodash templates, and Vue on the static pages (!) to add interactivity.
I know it seems strange, to have a “React app” that uses Vue. However, it makes sense to me because:
- They’re completely separate. There are React pages on the app subdomain, then there are Vue pages on the root domain. Never both in the same place – that would be utter madness.
- Vue is better at attaching to existing static markup and adding interactivity. Using React on these static pages would’ve been a pain. Using Vue on these pages is a joy.
I’d be happy to dive into some more detail on why we chose to use React and Vue, if you like. Or perhaps @Dane has a few words on the subject? I know, it sounds strange to use both, but it makes sense for our use case, for our team.
Where can “utter madness” be beneficially applied to site development?
Great question! I think “utter madness” can be applied all over software development. What we call “scrappy”, others would call “madness”. A lot of things done at startups and small companies would be considered madness by larger companies, and both sides are right. A lot of things that are done at startups would be madness at a larger company (for example, “Shadow IT” as outlined by @davidcj in his thought-provoking post). You know how Paul Graham says “do things that don’t scale”? He’s talking about utter madness!
On the other end, implementing large company practices at a startup would be utter madness, in a bad way. A previous company I worked for, which shall not be named, was a smaller company but with big clients, and they had to implement practices that at Hacker Noon would be considered completely insane and would probably drive us into the ground. But those practices made sense for that company, for their product.
In short, “utter madness” can be useful and in some cases, absolutely necessary to a startup’s survival.
For me online reputation is even better than direct monetization - reputation and not seeing banners when you have enough reputation like stackoverflow does.
Hey Austin, good work on everything! I’m curious about the design so far! Do you have an internal designer currently? I believe Teehan + Lax - the designers of Medium- have some open source code that might be usable as well! Things look good now, but definitely don’t have that “Medium feel” just yet.
I absolutely agree! I’ve thought a lot about online reputation and trust, as part of my cryptographic studies, so this really resonates with me. Ideally, a Hacker Noon contributor should be able to become an editor (or maybe even a site admin!) by gaining reputation and trust in the community. Of course, this is a hard problem, to quantify reputation and trust, but I’d definitely look to Stack Overflow (and Discourse) for inspiration. Thanks for your input!
Hey Pat, thank you! We’re working with two designers, @lastresmoyallc and @faithcorinne, who have done excellent work so far. We’re still iterating on the design, so nothing you’ve seen is final, but it’s safe to say we’re going for more of a “Hacker Noon feel” and less of a “Medium feel”. Naturally there are things we’d like to do that are similar to Medium, things that are just good patterns, but we’re definitely going for our own look. Is there anything in particular from Medium that you’d miss if it wasn’t on Hacker Noon 2.0? Are there any annoyances or anti-patterns you’d like to see us avoid? Any specific feedback on the designs would be super helpful! Thanks for your question!
I really appreciate the simplicity of Teehan and Lax’s style for everything. I think, not being a designer myself, the biggest thing I appreciate about Medium is the sexiness of the font/ look. If I’m posting and can draw at my quotes, and have a big sexy title, and then add an awesome picture or 5, this is all great! Thanks Austin!
They actually made it super easy to deploy a Discourse site – anyone could do it, with a click of the mouse. The hard part is getting content onto the site, making sure emails get delivered, responding to the posts on here, writing new topics, and generally making this a place our community wants to join. It takes a lot of care, attention, and time.
I know, this probably isn’t the answer you were hoping for – it’s a bit light on the technical details, right? I can tell you something a bit juicier…
I’m working on a single-sign-on (SSO) solution for Discourse as we speak, to integrate with Hacker Noon 2.0, so you can use the same login and have the same handle across the community and all of Hacker Noon’s subdomains.
The flow looks something like this: first, Discourse will redirect you to our auth.hackernoon.com subdomain (coming soon!). This includes an
sso parameter and a
sig parameter, which in short, will be used to verify the request came from Discourse. You’ll enter your email, which will be verified to ensure you don’t claim an email address that doesn’t belong to you. After that’s squared away, you’ll be prompted to enter a password, and if you’re visiting the site for the first time, a name and handle.
The first time you use the new authentication system, you’ll have to reset your password. This is necessary because we don’t have access to your current password in plain text (as it should be), but this is a one-time step, and we’re working hard to make sure the process is as painless as possible. The upside is, you’ll have an account already when Hacker Noon 2.0 lands, with the handle you want – the possibilities are endless!
There has been a wide array of technical challenges in building the auth subdomain app, not least of which was verifying the SSO payload and generating a response payload of my own. That wasn’t particularly difficult, exactly, just tedious and error-prone. The first time I got that part working, I nearly jumped for joy.
Another difficult part of this has been email verification. You wouldn’t think this would be that challenging, since our Firebase backend will send that email for us. The hard part has been redirecting to the right page, with the right state, and splitting up the pages I had initially created for login and signup. Again, not particularly difficult work, just a lot of trial-and-error, as I had to ensure that the Discourse SSO payload is verified and the response payload is generated in one go, not split up across multiple API calls.
Getting the state of each page right, and ensuring that it remains secure, has been a real challenge, but a welcome one, as I haven’t implemented SSO in this way before. I’ve been writing software for the web for over 8 years, and I know the pieces, but I’ve never quite arranged them in this way. It’s like I had all the Lego pieces for a Millennium Falcon, but I just made X-wings and TIE fighters, never fully assembling all of it into the full, complete solution we’re going for here. Hopefully that simile makes sense – it’s a bit nerdy, but it gets the job done.
I could go into more detail, but this is already a wall of text, and I need to get back to work and actually get SSO working end-to-end. Thank you again for your question! Hopefully this sates your curiosity.
Great response, thank you! It sounds like you guys are doing a good job, hope everything turns out well, excited to see Hacker Noon 2.0
Thank you for sharing the tech details. Love your tech decisions so far.
The only concern I have is React + Vue setup, specifically:
- fewer opportunities for component reuse
- the need to maintain two separate build chains for both setups
- a heavier learning curve for new team members
That’s just my opinion, but I’d personally stick with one or another.
It would be great if you can elaborate on this decision
Another question that interests me a lot: will you be adopting AMP?
As far as I know, while being a great feature for the customers it interferes with some of the monetization strategies. Maybe you have insights on why some commercial publications are adopting it?
Hi Vitaly, thank you for sharing your concerns! I’d like to address your points individually below.
Component reuse would make sense if we were serving the high-traffic pages as a single-page app, I absolutely agree. However, we’re using Vue to simply add interactivity to existing HTML. It’s really more of an alternative to vanilla JS than an alternative to React, in this case.
As mentioned above, we’re adding Vue to static markup. This means there is no build chain, for the Vue code.
I had the same concern when I first considered using Vue on the static pages. However, since I implemented it, it’s not as much of a worry for me. We’re using it in an extremely simple capacity, to add event handlers and a sprinkling of state management to these pages. Any more than that, and I’d have to agree. But as it stands right now, the code is so simple that it’s not much of a leap from vanilla JS.
I hope that addresses your concerns! Like I said in a reply above, we decided to go with Vue over React for the static pages because it’s a much simpler process to add Vue to a static page, than to use React. React makes sense for SPAs, but it didn’t really fit the problem here.
As for AMP, my biggest gripe is that it hijacks links – when I share a link, I want to share a direct link to that site, not some Google AMP link. Other than that, I honestly don’t know a whole lot about it. It might make sense for our platform, and I’ll definitely bring it up with the team. Thanks for the suggestion!
@austin First of all, a big shout out for SSO integration! Congrats!
On the tech stack, what do you think about Firebase being a proprietary technology? What if Google decides to shut it down (I highly doubt it anyways)? I can’t stop thinking about it because of how medium decided to shutdown hackernoon publications.