Open sourcing the DEV community
We talk with Ben Halpern the founder and webmaster of dev.to — a community for developers to talk about software. Last Wednesday they open sourced the codebase of the dev.to platform, so we wanted to talk through all the details with Ben. We talked through the backstory, how Ben realized this could become a business, how the team was formed, their motivations for open sourcing it and why they didn’t open source it from the start, the technical stack, and their vision for the future of the site.
Matched from the episode's transcript 👇
Ben Halpern: Yeah, so because this was a side project, so much of it was like scratching my own itch, and I’m a very impatient internet user. In terms of people’s blog posts, if it’s not loading quickly when all I need to do is read texts on a page, like the most basic thing that ships with HTML version 1… You know, it’s a frustrating thing. So from the technical perspective, this project was built around performance ideas, in a lot of ways, and also delivering performance around the whole world. Americans don’t realize how slow the internet can be in other parts of the world because of latency…
But yeah, despite that, we chose Rails, which is not built for speed as the primary use case. But what we do is – Rails doesn’t do a lot of the work on most page loads, so 90% of traffic is handled exclusively on the CDN layer… So we deliver pages which don’t have the users’ sort of personal identified information on that first page load, but the additional stuff is a quick asynchronous call, so worst-case-scenario you’re waiting longer for your image to show up… But even that is actually cached locally, in local storage.
Basically, you’re getting the edge-cached version of pages on the site, and I have written about this and I actually did a talk at Rails Conf on the same subject, so we can put the links to all that stuff…
And yeah, it’s just like a few new tricks, but also understanding – as a team, you have to know you have these constraints; you can’t use the current user method in the view, like in most cases, because we don’t send over a server-rendered view; we send over an edge cache view.
[01:00:14.11] There’s a few ways to do that with edge, with VLC and stuff like that on the edge… That’s Varnish Caching Language - VCL, sorry… And there’s a few different ways people do that, and we’re taking kind of the less standard way to even do that, because most edge caching still kind of makes round trips home for certain information in certain cases… But we just said like “If 1,000 people are reading the same article, we don’t want to recompute it 1,000 times.” You’re getting it once, and when the page changes, you get the new page. This is possible because of the services we use.
Fastly, our CDN, has basically – they have instant purge, so if we have caching issues, it’s a bug on our end, their API is really just virtually instant; 100-200 millisecond cache clear… So when a user updates an article, we serve a fresh one once, and then the rest of them are cached version.
That’s just the architecture that makes sense for website content-driven stuff. I’m sure all the podcasts that are doing anything right are also coming from some kind of CDN… And really, people’s location, the place things are getting served from, the way they’re being cached - it’s all kind of like fundamentals of computing, but I think some of this stuff gets abstracted away and then programmers forget it’s part of the problem… But that was never my mindset. If anything, it’s a very typical Rails app, with one differentiating feature, which would be the same kind of approach you would take with any framework. The big difference here is the speed of light is constant; you can’t change that, so you need to bring the code closer to the people, and people are used to doing that with purely static content… But Fastly has always been trying to push people to do more stuff this way, from themselves, and I didn’t coordinate with them, but I read their blog posts, and it was a great idea, so I ran with it.
It’s funny - people themselves really know the best use cases for their own software, and sometimes you just have to listen. There’s some really cool stuff out there, and we have the same concept with some of our other services. We use Algolia, which is a distributed search index; so we don’t host our own search, because we actually have nodes distributed all over the world. So if you’re in Tokyo, you’re gonna get a search response and a site response both from the edge, within milliseconds.
I do live in the U.S., so this really wouldn’t be a problem for me, but at some point in my life I became very interested in not being exclusive to the rest of the world, and from a business perspective it just made sense to do that right away… Trying to [01:03:22.05] that kind of optimization at the end, when you already have all your – so if open sourcing was tough because we had already kind of just been writing code without that in mind right away, optimizing edge caching like that would be ten times tougher if that wasn’t initially your use case… Because you’d have to really start tearing things out, and it would be really frustrating and possibly not worth it.
[01:03:44.25] And the wonderful thing about being the coder, the founder, the project manager or whatever - I didn’t have to convince anyone else that this is a good idea; I just had to really know in my heart that this was a good thing to try to do, and see if it worked… And it really did, and over time we’ve found things that are like “Damn, I wish we would have not gone so hard on this part, because it made everything else harder…”, but things kind of work themselves out over time and we get to like a happy medium.
It’s just really exciting, and I liken it to being a painter… If you’re trying to found a project and you don’t know how to code or do the thing that needs to get done, I feel like it’s kind of like being a painter but you can’t paint; trying to tell someone else live what you want the canvas to be, but you need to describe it instead of just doing it.
Early on in a project, a software developer has so many super-powers in terms of just being able to take that paintbrush and do whatever they want… Like, translate what it’s their head to what’s on the canvas.
I just felt like early on in the project, as a business, and as a project, just the fact that I could kind of work that all in myself, without too much pressure, and without too many external obligations… I really chose a technical project that was really on my alley; I didn’t try to learn 100 new things to do this. It was like, “Okay, what do I actually know better than anything, and what’s the most optimized thing I can do with what I know?”
A lot of this was really growing up for me. I’ve made mistakes in the past where I chose cool technology I didn’t really have a good grip on, even if it was an interesting project, and then I didn’t even really have cared too much about the project material, and stuff like that… So this really was just a coming together of a lot of different spaces and interests, and the tech really met with the human side, and the team was great… That’s why it worked out to this point.