Hacker News Reader

Comment by whalesalad | Hacker News Reader

Would love to see the infrastructure bill. Anything is possible if you throw enough $$$ at it.

I’m not a ruby hater, but the average joe can’t accomplish this. If you consider each store an individual instance with an isolated/shard of a db it makes sense. But the underlying foundation is immense.

Partitions are usually the key to scale.

I’d imagine parts of their infrastructure would be better served by different runtimes. They’d save a lot of money.

But if your entire team is hyper focused on ruby there is something to be said for a huge monolith.

View on HN

> the average joe can’t accomplish this

The average joe does not need this.

If you have decent margins on the pages you're serving, Rails is fine. Where you might want to investigate other things is if you're, say, an ad driven business with really thin margins and you want to minimize costs. Or if you've got things dialed and you're just not changing things much any more and you want to eke out some savings.

And in any event, Rails is a good choice to figure out the problem space you're working in. Even Twitter started with it, and objectively, Twitter is very much not the sweet spot for Rails.

If your app is just a postgresql database that needs to be exposed with auth, access control, etc then yes rails is fine.

If you’re doing a tremendous amount of parallel processing it will fall over without throwing lots of compute and scaling horizontally. Rails doesn’t scale vertically. You need to give it compute, and every other resource it uses will also need more compute. Average joes are fine with a 2 core VPS. Lots of businesses are not.

I need you to send 5-10 million API calls per day to 20 different API’s … are you using Rails? Every API is rate limited differently, with different batch sizes (each having unique parameters) and it needs to literally be done ASAFP to make certain deadlines. If you want to throw money at the problem, sure. If you want to do the same thing with 1/10th of the resources you’ll use a better runtime like Erlang/Elixir or Clojure/Golang something with CSP.

HN is so quick to dismiss things like kubernetes and wax poetic about simpleton life but there are very legitimate reasons to choose alternative tools for your problem space.

Elixir's a lot of fun, but it's not the most performant thing either; it just does concurrency pretty well.

It seems most really big companies make the boring but safe choice to go with the JVM.

Depends on what you’re doing. Elixir isn’t winning the war on raw compute but if you need to do literally 2 million things at once it can’t be beat. It’s ostensibly a drop in replacement for rails (Phoenix) but will do everything rails does better including background tasks.

JVM is indeed a powerhouse and that’s where I’d go Clojure without hesitation. Scala might be an easier sell but I’m a lisp fan and have used Clojure in prod (was briefly CTO at FarmLogs a YC company where most of our core infra was Clojure) and it’s really an amazing language but it requires very senior engineers to do correctly.

The key to scaling Rails applications is effective use of caching (at multiple levels).

For an online store (compared to, say, a live action game) so much of the content that you serve will be cached that regardless of your apps runtime a lot of the user experience will be defined by how effective your caching strategy is.

I think that Rails still offers enough compelling advantages for developer productivity to offset the (possibly) higher hosting costs.

Although they probably spend most of their time on the application layer, I suspect the most important and trickiest work was done to scale the database.

> I need you to send 5-10 million API calls per day to 20 different API’s … are you using Rails?

Yes.

We stand on the shoulders of giants - in this case Shopify. Once they have done things once, it is easier for the rest of us

Having built similar software, at a smaller scale, I think you're massively overestimating the complexity of shopify.

At it's core, what they provide is (largely) read only set of products, and a (largely) append only set of purchases.

The only write operation that needs to lock the database is when you adjust the quantity of available inventory. You need to pay attention and think things through to do that with good performance, but it's not that complex. and they wouldn't be doing millions of sales per second.

You can probably build an 80% Uber or Twitter simply. It’s the 20% that’s the rub. Did you know the Uber mobile app has thousands of native screens, for example? [1] it’s common to believe that a small simple version is the same as the scaled version but that’s rarely the case.

[1]: https://news.ycombinator.com/item?id=25376346

They might save money on infra, but their speed of development would probably go down, potentially requiring them to either hire more people or deliver features slower. The impact on overall cost might not be that great.

Shopify hasn’t released a new feature since Obama was in office.

Most software organizations (remember most are not FAANG) will be better served by paying the $$$ to have their engineers focused on building more/better features for customers.

True up until a point. Once you plateau and your infra spend is $25-50k+ per month it’s wise to start re architecting.

Rearchitecting doesn't necessarily entail changing technology/platform

> If you consider each store an individual instance with an isolated/shard of a db it makes sense. But the underlying foundation is immense.

Each instance is probably just a k8s pod

Reply on news.ycombinator.com