I am the founder and webmaster of dev.to, a platform where programmers write articles like this one, have discussions and make friends. It is a lot...
For further actions, you may consider blocking this person and/or reporting abuse
From In the Plex (which I know you've already read):
Basically, DEV will be Google soon. Hurrah!
Well... duh. But seriously, it's in my nature to have my head in the future (or in the clouds) and the important part at this stage is resisting the urge to actually work on the problems this far ahead of time.
Correct me if I didn't understand you but, you thought about the how in your potential scaling issue. If this problem occurs in the future, you already know what solution you will apply.
How do you decide when you have to apply the solution? Do you have arbitrary metrics? User feedback? Is it something along the lines of: If you ask yourself if you need this, you don't?
Curious about the process.
Good question. This is actually more about product evolution than it is about scale. Right now, we've built our product to, more or less, scale to any possible number of users. It leverages shared cached resources a lot. But as we evolve, we're trending more towards personalization. Even just the current user's profile on the home page was a product evolution that could potentially degrade the user experience.
As we add more features like this we trend in the direction where it could make sense to distribute our data. At some point, this will be easier than managing our current solution. That's when this sort of thing will make it into the app.
At least that's how I see it now. Things change all the time. This is something I'll revisit whenever I am inspired to and perhaps a teammate will jump in and have some ideas. I'll add that in a lot of ways, this app is an excuse to concretely think through this problem for some future unrelated endeavor. I'm not very good at learning about things in completely abstract terms. This kind of exercise helps with that.
Hey Ben - Great post on deciding when to solve scaling problems from a startup engineering perspective. Coincidentally I wrote a similar post yesterday about a new product launch but with commentary around thinking about scaling in a startup too.
astronomer.io/blog/apache-spark-st...
I'm looking for opportunities for us to start cross publishing semi-technical posts like this one or deeply technical posts on dev.to as well.
If you're looking for opportunities, they're here for you. If you want to start an org account like dev.to/clarifai, talk to @jess (jess@dev.to)
The posts on your blog seem perfect for the community. What we try to provide with the org account is an opportunity to have your branding and credit on all the posts while still letting folks consume and comment on the content here.
I believe the key to scaling correctly is avoiding a reduction in performance of the current features. New features should be treated as a new concern, but very often they end up breaking existing features. Either you need a way to test out new features in scale, or have a rollback strategy should it not work as desired.
The reason is primarily for user retention. What a service has now is obviously working, and attracting new people. During a growth phase there isn't a need to add new features, since obviosuly the current ones are working. But too often I see companies try to keep piling on features in this phase instead of worry about scaling. This has the double effect of putting a new kind of load on the system, wile also trying to deal with the influx of people. It may end up pissing everybody off and putting a quick end to user growth, or actual reduction in user base.
Just the right approach I'd say. Start simple. Don't optimize as long as you don't have to. But start DevOps'ish and be careful to deal with Dickersons Hierarchy of Reliability (david-merrick.com/2017/06/26/dicke...), especially the lower layers (monitoring). Keep eyes open to know how to address scalability issues as soon as they arise but even more keep eyes and ears open to see them when they actually start arising, to be able to figure out bottlenecks, scalability limitations fast. In our experience running a modestly sized system that has seen 15+ years of growth, fixing scalability issues is not trivial but in most cases it's way easier than actually finding scalability limits using good instrumentation. Make sure your application has this baked into from day one.
This inspired a great talk by Laurie Voss at DinosaurJS.
Oh yay, Laurie told me he was planning this but I hadn't seen it.
So... Dev.to won't adopt Preact.JS for a new level of UX?