Case Study: Launching the new Sidebar.io

I launched a new version of Sidebar yesterday. Sidebar is a daily design links newsletter, and it’s built with Meteor. Actually, as a four-year old project it might be one of the earlier Meteor production apps that’s still standing today!

The new version is built on top of Telescope Nova, the new React version of Telescope.

Since we’ve had some talks about deploying and scaling recently (including a case study about poor Meteor scaling) I thought I’d share my experiences and answer any questions.

Disclaimer: most of the actual scaling work was done by Josh Owens and Michael Shilman, who I know are both working on more detailed posts about what it is they actually did. So this is more like a very high-level overview.

Sidebar runs on Digital Ocean deployed via MupX. Josh helped me set up a load balancer using Nginx, meaning that traffic is spread across four Digital Ocean 1GB droplets. I started off with two but ran into CPU issues, so stepped things up to four.

The site received quite a bit of traffic yesterday, with peaks of about 400 concurrent sessions (which might not mean 400 active users, some people just open the tab and leave it open). Here’s my Kadira stats:

My main worry from a scaling perspective was that server-side rendering (done using React-Router-SSR) would eat up the CPU. Thankfully Michael was able to set up caching via Nginx to mitigate the effects of traffic. Of course, Meteor itself still requires a lot of CPU power, and maybe there’s things I could do better with my publications and subscriptions to fix this. Or maybe I should just switch to Apollo…

So my conclusions about Meteor scaling: it’s not easy but it can definitely be done. But I think it’s fair to say Meteor is not a platform where you can just code up an app, deploy it, and expect great scaling (if that’s what you’re after I would recommend sticking with Jekyll instead!).

It’s also true that Meteor isn’t really made for largely static, high traffic, public applications like Sidebar. But you know the saying: when all you have in your toolbox is Meteor, everything looks like a real-time, dynamic single-page web app.

You might also wonder why I didn’t just use Galaxy. I would’ve loved to, but for some reason (maybe related to server-side rendering?) running Nova on Galaxy triggers a memory leak, even with no traffic at all. If this can be fixed in the future I’d be happy to switch to Galaxy and not have to manually spin up extra instances myself anymore.

5 Likes

thanks for sharing these info.

Do you have the nginx setup code somewhere if someone wants to setup their own setup this way ?
I’d love to have the same setup in the future for one of my apps.

Would love to have a central github readme probably where we could have the nginx scaling step by step guide or something similar with code examples ?

Thanks

I think @shilman and/or @joshowens are both working on blog posts which will share more details about the exact config.

it’s behaving a bit oddly for me. keeps refreshing the page in a look. A sketch article keeps appearing and disappearing. finally it crashed and returned undefined

took a second to make a screencast

Contentful with gatsbyjs hosted on Netlify may have been a good approach!

Hmm, maybe part of it is that I was adding/removing links when you checked it out. Definitely weird behavior though.

My article went up here: https://medium.com/p/919972dfd9e0

Feedback, hearts, and shares welcome :smiley: