We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Building a reasonably popular web application for the first time.

Formal Metadata

Title
Building a reasonably popular web application for the first time.
Title of Series
Part Number
57
Number of Parts
169
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Erik Näslund - Building a reasonably popular web application for the first time. These are the lessons learned when scaling a SaaS web application which grew much faster than any one us could have ever expected. - Log and monitor from day one. - Things will fail, be sure you know when they do. - Choose components which allow language interoperability. - Horizontally scalable everything. - Plan for database downtime. - Have a way to share settings between backend and frontend. - Have a way to enter maintenance mode. - And more... ----- My name is Erik Näslund - I’m the co-founder and Head of Engineering at Hotjar. I'd love to share the lessons learned when scaling a SaaS web application which grew much faster than any one us could have ever expected. Words like “big” and “popular” carry very little meaning, so let me define how big Hotjar is right now using some numbers. We onboard about 500 new users on a daily basis. We process around 250 000 API requests every minute. Our CDN delivers about 10 TB of data per day. We have roughly 3 TB of data in our primary data store (PostgreSQL), another 1 TB in our Elasticsearch cluster, and a LOT more on Amazon S3. These are the key things we wish we knew when we started. They would have made our life so much easier! - Log and monitor from day one. - Have a way to profile your API calls. - Things will fail, be sure you know when they do. - Have a way to keep secrets. - Everything needs a limit (even if it's really big). - Be wary of hitting data type limits. - Don't get too attached to a framework. - Choose components which allow language interoperability. - Horizontally scalable everything. - Plan for database downtime. - Features are a great way to test things out before launching them to the public. - Have a way to share settings between back end and front end. - Have a way to enter maintenance mode. - Require different quality of code for different parts of your application.