How hard is it to setup the sys admin side of things ? Deploying a prod server behind an nginx with a non-sqlite db and pointing it to your own cdn
It’s pretty poor, and also in flux. We use Meteor and mup-aws-beanstalk, but are dissatisfied with them (due to slow client-side Javascript initialization, slow development-cycle build time, and extremely slow server deploy time), so I’m converting it to esbuild and a yet-to-be-chosen deploy/CI setup. So if you deploy an instance of the LW codebase today, you will probably find that the recommended deployment mechanism has changed to something else entirely different a month from now. A month from now it’ll hopefully be pretty good, though!
What kind of machine (very roughly speaking) would you need to handle top volumes ~20,000 visitors/hr (say, max 3,000/min) without the core functionality breaking and ~500 visitors/hr (say, max 100/min) with top-notch user experience (assuming optimal db, distro and reverse proxy choices)
Logged-out users visiting the front page and a few post pages (ie, getting Slashdotted) will all be served from the page cache, so pretty much only limited by bandwidth. Lesswrong itself runs on a dynamically scaling pool of t2.small instances (though one would probably be enough) and a MongoDB Atlas M30 cluster.
How hard is it to modify the theme (e.g. fonts, color-scheme, icons) ?
If you’re familiar with CSS/JSS, this should be pretty straightforward.
How hard is it to integrate your own 3rd party service or get rid of them ? Specifically, add your own app cred for the signups and remove google analytics, intercom and all other 3rd party integrations that would make Richard stallman cry which aren’t critical to the commenting experience.
OAuth, Google Analytics, and Intercom are all already used, so integrating them is just be a matter of getting an API key and putting it into the right config setting.
Are the makers of LW explicitly fine and open to it being used by other people or is it open source mainly for the sake of community debugging?
We are explicitly fine with this. We just haven’t gotten around to optimizing it much for this use case.
What are particularly difficult/annoying/deal-breaking parts of the setup that were unexpected?
Site search is powered by Algolia, which is kind of expensive and not especially good.
I had to use it for a project (completely unrelated) and integrating it into a website is a sub-hour task, it’s also silly portable since with rust you can just get a statically compiled version of packages that just need a dynamically linked libc.
Yeah, I expect we will eventually deploy our own version here, but Algolia was pretty straightforward to set up initially, and I was familiar with it from a smaller project earlier (it works great for small corpuses, and their free-tier is great, but the pricing is steep and the performance gets worse in larger corpuses).
I appreciate the pointer to meilisearch. Will look into it.
It’s pretty poor, and also in flux. We use Meteor and
mup-aws-beanstalk, but are dissatisfied with them (due to slow client-side Javascript initialization, slow development-cycle build time, and extremely slow server deploy time), so I’m converting it toesbuildand a yet-to-be-chosen deploy/CI setup. So if you deploy an instance of the LW codebase today, you will probably find that the recommended deployment mechanism has changed to something else entirely different a month from now. A month from now it’ll hopefully be pretty good, though!Logged-out users visiting the front page and a few post pages (ie, getting Slashdotted) will all be served from the page cache, so pretty much only limited by bandwidth. Lesswrong itself runs on a dynamically scaling pool of
t2.smallinstances (though one would probably be enough) and a MongoDB Atlas M30 cluster.If you’re familiar with CSS/JSS, this should be pretty straightforward.
OAuth, Google Analytics, and Intercom are all already used, so integrating them is just be a matter of getting an API key and putting it into the right config setting.
We are explicitly fine with this. We just haven’t gotten around to optimizing it much for this use case.
Site search is powered by Algolia, which is kind of expensive and not especially good.
Why not use something like https://github.com/meilisearch/meilisearch ?
I had to use it for a project (completely unrelated) and integrating it into a website is a sub-hour task, it’s also silly portable since with rust you can just get a statically compiled version of packages that just need a dynamically linked libc.
Yeah, I expect we will eventually deploy our own version here, but Algolia was pretty straightforward to set up initially, and I was familiar with it from a smaller project earlier (it works great for small corpuses, and their free-tier is great, but the pricing is steep and the performance gets worse in larger corpuses).
I appreciate the pointer to meilisearch. Will look into it.