Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
If you follow Hacker Noon, you are probably aware that the cat is out of the bag. We’ll soon be taking on the important challenge of building the next version of Hacker Noon. This post is a way for me to share some of my thoughts on 2.0 and hopefully solicit even more feedback from our amazing community.
Before we talk about the road ahead, let’s take a minute to look back. I’ve been a part of several products that have transitioned from v1 to v2. Unfortunately, many v2 teams view v1 not as an evolutionary stepping stone but as a deeply flawed dependancy wall. Hacker Noon would not exist as it does today without Medium. So I’d like to thank Medium for the many innovations that have powered Hacker Noon thus far. 🍻
Disclaimer: None of the following is set in stone. We’re in the process of hiring our initial dev team and expect everyone to play a part in figuring out what we build, and how we build it.
Requirements
A few boundaries to lend context to my thoughts.
- We can’t continue to use MediumIf you read the crowdfunding description, David Smooke talks about why this can’t work from a business perspective.
- We’d like to launch at the end of Q1 2019As a startup, you have to be keenly aware of your runway. We’ll have to make compromises for that to even be a possibility.
- ScalingI think it goes without saying that v2 has to adequately accommodate the needs of our readers and writers. We’re currently ~15M pageviews, ~7K contributors, and XXXK stories.
- SecurityOur community will demand a higher level of security than a typical app.
- FunctionalityMuch of the desired functionality has been outlined in the crowdfunding campaign. It’s likely that the first launch will not include everything. But we do need to include enough to be a viable product with a foundation to build onto.
- Hacker CentricEverything we do should take into consideration the unique needs of our community. We aren’t building a generic publishing platform. We’re building a publishing platform for technologists.
Could Wordpress power 2.0?
Photo by NeONBRAND on Unsplash
I doubt it. It is possible to migrate everything over to a Wordpress and have a functional publishing platform up in no time. However, I have serious reservations about using Wordpress for a few reasons:
The data model is not easily adaptable for Hacker NoonI could be wrong here, it has been a while since I last worked with WP, but the wp_postmeta table is often how people extend WP functionality. I find that key/value table to be very inflexible. Every single thing you do with it feels like a dirty hack.
The plugin system is limitedI’ve not had a lot of great experiences getting plugins to play nicely together. I also find that plugins are meant to be configurable from the admin interface. This is great for bloggers who don’t write code but bad for coders who need more configurability.
Caching is always a problemWe’d very likely need caching from day 1 and the various caching plugins for WP always seem to cause problems. We’d probably need to build a custom solution which would eat up a lot of time.
There are other challenges I see with WP but don’t want to get too deep into this topic. WP is a great tool for a variety of use cases, I just don’t think it would work well for us at this stage.
What about a Ruby on Rails app?
Possibly. Compared to Wordpress, Rails has a lot of advantaged. We’d have the benefit of getting a lot nice things like routing, a well structured MVC and asset management out of the box. Rails is also a much more generic application framework which makes it much more extendable. Even though it is designed primarily to be used with relational databases, we’d have so much more freedom when it comes to modeling and storing data.
The dark side of the Rails moon:
- Rails favors convention over configurationThe explorer in me hates this. But I have to say, if you have an experienced Rails team that is already familiar with the “Rails way”, then this can work well. Using established patterns can discourage a team from innovating on details that aren’t worth the effort while building an MVP. Long term, I believe a dependance on reusing existing patterns is a bad thing.
- Scaling Rails isn’t funExperts will disagree but even at the current scale of Hacker Noon, there is no way we could just take an out-of-the-box Rails app running on Webrick and expect it to just work. We’d immediately have to upgrade the application server to something like Unicorn or Puma and likely have to deal with multithreading issues. Then we’d need to deal with greedy ActiveRecord gobbling up all the memory. After that, it might make sense to look into caching issues…
- DevOps and RailsEvery tech stack requires at least a little DevOps ointment. Rails apps just need a little more than most. It probably has something to do with the obscene number of dependancies.
- Rails really isn’t designed to use modern JS frameworksDebatable but configuring Rails to run a SPA (single page application) isn’t exactly intuitive. Putting an app inside an app causes duplication (routes, layouts, views…) which creates a lot of confusion.
What about using Node.js to power 2.0?
Photo by Thomas Kvistholt on Unsplash
I’m a fan. Using JS on the frontend and the backend is a great way to break down silos that exist when pieces of your application are powered by dramatically differing technologies. Having an “app/frontend team” and a separate “core/backend team” creates communication barriers that limit collaboration.
This isn’t to say that every engineer should understand every part of the code base. I’m really not a fan of optimizing for the “bus factor”. Specialization is a good thing so long as people are effectively communicating and working towards a common goal.
Node’s async nature is also pretty great at handling a high volume of concurrent requests with a minimal amount of configuration.
Is it a good idea to make the blog static?
This doesn’t address the CMS side of things. Writers will need to manage their content. Admin will need to manage submissions. An app will definitely be needed behind the scenes. But the content itself could be delivered as static HTML/CSS/JS over a CDN.
I’m pretty intrigued by this approach. Here are some of the benefits:
- Low costSomebody really needs to create a nice CDN cost calculator with an intuitive UX and price comparisons. Google Cloud calculator doesn’t offer comparisons but it probably the least bad option I’ve seen so far. If I estimate 500GB of US storage and 15M HTTP requests, it comes out to about ~$100/mo.
- Very fastWith a CDN you’re able to distribute content around the world and greatly reduce the average distance each request needs to travel in order to fetch content.
- Supposed SEO benefitsFaster content delivery supposedly impacts ranking. I don’t know how true this is or to what extent ranking is impacted. But even a modest bump could be significant.
- ScalabilityGrowing 10x in pageviews should theoretically not be a problem. Reality almost always presents unforeseen challenges, but the problems are likely far less painful than scaling a centralized host.
I see 2 major challenges in going static.
- Maintaining the static filesScripts would need to watch for changes in content and create/update/delete files and deal with caching issues as needed. Not having a single source of truth is a challenge but not one that can’t be overcome.
- Accommodating comments, likes and interactionsIf the static files are primarily used for content while comments, likes and other meta data are dynamically loaded via JS then you lose a lot of the benefit. Sure the initial content would load fast but every request would ping a server to make a DB request to augment the content. Ideally this meta data is part of the static files which adds to the maintenance challenge.
Which cloud should we hitch our wagon to?
So many options. I will say when it comes to building and iterating on a new product, I prefer configuration over convention for the business logic. When it comes to hosting a new product, I prefer convention over configuration.
Docker fans will probably say that isn’t necessary. It is easier than ever to containerize an application and give yourself the flexibility to do whatever the hell you want. While that seems to be true, it still requires time and effort to make it happen. Early on, I believe it is best to minimize time invested figuring out where your code lives and maximize time invested in figuring out what your code does.
It might be tempting to explore something like Kubernetes on Digital Ocean but AWS or Google Cloud is probably a better early stage choice. My preference is actually Google Cloud. I like Cloud Functions as a serverless option. I like Firestore as a flexible NoSQL option with powerful security rules. Firebase is also incredibly simple, scalable and powerful with things like SSO authentication baked in.
Thoughts on frontend JS frameworks
Over the last few years, I’ve become a believer in reactivity on the frontend. There is a huge amount of overhead when you’re forced to write code to manipulate the DOM in order to maintain the application state. State should be automatically maintained and represented by a simple data structure. Less busy work allows you to be far more expressive as a coder.
My preference would be to use Vue.js, I find it to be the most intuitive and flexible option. React is also a fine option. I find it to be more rigid and frustrating but entirely viable. I don’t really know Angular but would be happy to entertain it as an option.
If the team is against the idea of using a frontend JS framework, native JS could be an option if we make that decision for the right reasons. We can’t spend a few months building a minimal version of Vue or React in order to satisfy some philosophical agenda. Going native or jQuery would likely mean we’re willing to minimize time spent on frontend interactions in order to get to an MVP faster. I’m skeptical but open to the idea.
Is a CSS framework needed?
Not in my opinion. CSS frameworks often:
- Butcher any notion of ever having semantic markup.
- Make your app feel very cookie cutter in spite of your best efforts.
- Force people to spend a lot of time referencing documentation and learning cryptic acronyms.
- Force you into adding unnecessary additional dependancies.
I’d prefer to keep things simple with raw CSS. I’m not against using a preprocessor like SCSS to help keep styles organized, code minimal and aid in cross browser compatibility.
If our team ends up being very experienced in a framework with limited raw CSS knowledge, I certainly wont force us not to use a framework. It’s much better to optimize for a faster/happier team over a tech stack that I prefer.
Thoughts on testing, deployment & monitoring
It’s tempting to skip testing, skip monitoring and manually deploy code early on. I’ve gone that route in the past. It has saved a ton of time but there were predictably some negative consequences. It’s never fun when a user points out a pretty significant bug and you aren’t sure why your code is misbehaving but it’s likely the app has been broken for over a week! 👻
I’ve also been frustrated by teams that are overly rigorous and too eager to sacrifice progress for stability. Without stability, users will churn at a higher rate. But without progress, you’ll have no users to begin with.
Early on we should strive to:
- Automatically test the most critical parts of the application
- Monitor the basic health of the app
- Have a staging environment to QA major releases
- Have the ability to roll back if things break
- Work towards continuous deployments
Should Hacker Noon be mobile first?
I’ve never really been a disciple of the mobile first crowd. If anything, I’m more of an API first believer. Once your data has a good home, is well structured and easily/securely accessible, you have the flexibility to explore a variety of use cases with a minimal amount of effort.
But every app has a unique set of characteristics which need to be taken into account. Choosing to be anything first should be a thoughtful and deliberate decision.
I don’t consider myself to be a mobile power user by a long shot. Still, when I think of my mobile usage in terms of content consumption, the ratio is probably 1:1 compared to desktop consumption. At times the ratio spikes to around 5:1 in favor of mobile. Mobile apps also annoyingly have powerful reengagement capability in the form of notifications.
If my personal consumption favors mobile and is below average then choosing not to go mobile seems like an asinine decision. The only questions are when and how.
- When: As soon as possible. Maybe it’s possible to launch with mobile support but I wouldn’t count on it. Any advice/help on this front would be greatly appreciated!
- How: Starting with a PWA (progressive web app) is likely the first step. Then investing in a React Native app to get store distribution is probably a good idea.
Conclusion
There are more ways to build an app than the human race will ever have the opportunity to explore. If you disagree with my thoughts on anything above, please leave a comment. Also feel free to ask questions I haven’t addressed.
In the coming weeks, I’d like to do a deeper dive into important chunks of the Hacker Noon 2.0 architecture. I’ll likely start with the content editor.
Thanks for reading!
Please consider supporting Hacker Noon by investing in our crowdfunding campaign. You can also wear your support with a Hacker Noon tshirt from Cotton Bureau.
— Dane LyonsFounder of v1Labs &Interim CTO for Hacker Noon
Building Hacker Noon 2.0 was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.