
Shopify now on Rails 5.0. started 12 years ago on 0.5, the First version released - kristianp
https://twitter.com/tobi/status/819246328211443713
======
ksec
It seems Cookpad's claim of largest Rails Monolith may not be true anymore.
(1) But I have known this for sometime when I heard China' Rails Ticketing
System were built on Rails, then I assume peak traffic would be larger then
Google + Twitter + Amazon Combined. Although they have moved off the Rails due
to scaling issues.

I wonder if Shopify have any Ruby performance or Rails Scaling issues to
share?

And the last thing is Rails just prove to be popular and works well for ( and
may be only ) paid SaaS. It allows you to quickly iterate your product until
you find a product / market fit. And once you have generate a revenue stream,
the Server / Software Scaling Cost becomes relatively minor compared to Human
Cost. But for those who are on a freeminum model and depends on Ads, Cost of
running Ruby Rails may quickly out pace your budget before you have large
audience to generate revenue.

1\. [https://speakerdeck.com/a_matsuda/the-recipe-for-the-
worlds-...](https://speakerdeck.com/a_matsuda/the-recipe-for-the-worlds-
largest-rails-monolith)

~~~
nateberkopec
Somewhat of a tangent - are there _any_ huge Ruby apps that are not Rails
monoliths? All of the big Ruby apps are big Rails monoliths - Cookpad, Github,
Shopify. Of course they probably have some services, but you wouldn't call
them a "microservices" architecture by any means.

~~~
hopsoft
Sounds like Stripe may be a large service oriented system written in Ruby but
not Rails. [https://www.quora.com/Why-did-Stripe-choose-to-use-Ruby-
for-...](https://www.quora.com/Why-did-Stripe-choose-to-use-Ruby-for-its-
backend-language)

~~~
dvdhnt
Interesting that the bulk of their web interface was written in CoffeeScript
at the time of the answer even though they weren't using Rails. I've just
never seen a well-known product using CoffeeScript without Rails.

I do wonder if that remains to be the case or if they've moved their web
interface to something else. They've released a number of new products the
past year, and I'm sure at least one isn't CoffeeScript given the content of
the post.

------
grandalf
I'd be quite curious how much money keeping Rails up to date has cost Shopify
over the years, compared to the benefits.

Compared to a lighter weight framework like Sinatra, Express, etc., it seems
that Rails is only a benefit if you were unable to make halfway decent library
and architecture choices on your own, or if for some reason you benefit from
hiring people who are already familiar with a particular Rails version.

It's very interesting that companies like Shopify and Github have continued
paying the upgrade tax with Rails... a tax that is necessarily mainly because
of the tight coupling between core components and the assumption of tight
coupling included in most of the library ecosystem. Seemingly, Shopify is well
beyond the phase where "hey that gem will save us two weeks" is really a
relevant factor.

This is not a criticism of Rails, just an expression of surprise that
companies like Shopify and Github still consider it a value-add after the
upgrade tax.

~~~
dasil003
I've personally shepherded a 100kloc Rails app from 1.2 in 2007 through 4.2 in
2016, so I can offer some perspective.

First, I think you overestimating the upgrade tax of Rails, and
underestimating both the value-add of Rails and the upgrade tax of any other
library.

In my experience, the most painful upgrades just as often come from random
gems (or gem interactions), or ruby itself. You aren't going to avoid this
pain by using Sinatra. If you choose only low-level libraries and you roll
everything yourself, then yes, you can potentially avoid this pain, but now
you're reinventing a lot of wheels.

It's not just a matter of a gem saving two weeks, it goes to the very heart of
the buy-vs-build question. Assuming the same quality of work, upgrading a
well-maintained gem is going to be less work than maintaining the
functionality yourself. The conventions and tight coupling of Rails may run
counter to architectural decisions you want to make, but on the flip side they
prevent a _huge_ amount of bike-shedding (I didn't appreciate this until I
jumped onto a legacy Django project and discovered a different flavor of
chaos). Assuming you have the chops to design a better architecture from
scratch, and assuming you put forth the effort to achieve a similar level of
polish to what you get with large community-driven open-source frameworks like
Rails, you still have to document and enforce your style guide and
architectural decisions, and train your engineering staff on them in a way
that you get for free with every Rails dev. On balance if you are building
typical web applications Rails gives a ton of value, and if you are using a
non-trivial subset of features then the upgrade tax is probably lower than
curating your own stack, and much lower if you are re-implementing parts of
the provided stack from scratch.

The important question is not really Rails vs Sinatra, but rather the
stability of specific libraries. In that regard I used to consider ruby the
most unstable and I would recommend against using ruby for anyone that cares
about maintenance cost. However over the last few years it seems like Ruby has
stabilized significantly (Rails 4.0 => 5.0 was dramatically easier than Rails
2.0 => 3.0), and Node has really taken up the mantle of moving-fastest-and-
breaking-the-most-things.

My general feeling is Rails is pretty effective for any significantly sized
web backend, even if it's just an API, as long as it's talking to some kind of
relational database and make use of Rails RESTful routing conventions. If
you're talking microservices then I would prefer Sinatra, but at that point I
would probably consider Go or Node or Elixir for the improved performance
profile that likely would be a more primary consideration if I was going down
that route in the first place.

~~~
grandalf
Thanks for the well thought out comments. Very insightful.

------
Humjob
That's a LOT of code in the controllers. If I had to guess, it sounds like
they're putting business logic in their controllers, which is a fairly well-
established anti-pattern.

How's Shopify's platform performing these days?

~~~
pmontra
They have 452 classes in controllers and 41374 LOC. It's an average of 91.5
lines of Ruby per controller, not so many for the usual 7 scaffolded methods
and some extras like strong params.

About performances, I always thought that writing logic in controllers, models
or lib was a matter of readability and ease of maintenance.

Does it make a difference to the CPU if 50 lines of code run in a controller
or in a model or in a file in lib or in a gem?

Maybe do 452 controllers slow down the router?

------
dankohn1
My holiday project was to upgrade a Rails project I helped create to Rails 5.
The BadgeApp [0] is used to certify open source projects as satisfying the
Core Infrastructure Initiative's Best Practices Badge. It is open source, so
you can see the diff [1] if you're interested. The upgrade took me several
hours, and was greatly assisted by our 99% test coverage. Biggest line count
change was from needing to explicitly specify params in tests. The biggest
annoyance was that Fastly's gem still doesn't support Rails 5, so I needed to
fork it [2].

I too am hugely appreciative of the Rails ecosystem.

[0] [https://github.com/linuxfoundation/cii-best-practices-
badge/](https://github.com/linuxfoundation/cii-best-practices-badge/) [1]
[https://github.com/linuxfoundation/cii-best-practices-
badge/...](https://github.com/linuxfoundation/cii-best-practices-
badge/commit/405e012f433814e049f0198b12841d008740b84b) [2]
[https://github.com/fastly/fastly-
rails/pull/67](https://github.com/fastly/fastly-rails/pull/67)

Here are the app statistics:

    
    
      +----------------------+--------+--------+---------+---------+-----+-------+
      | Name                 |  Lines |    LOC | Classes | Methods | M/C | LOC/M |
      +----------------------+--------+--------+---------+---------+-----+-------+
      | Controllers          |    687 |    476 |       8 |      59 |   7 |     6 |
      | Helpers              |    184 |    134 |       0 |      21 |   0 |     4 |
      | Models               |    711 |    470 |       5 |      55 |  11 |     6 |
      | Mailers              |    160 |    115 |       3 |      12 |   4 |     7 |
      | Javascripts          |    405 |    308 |       0 |      35 |   0 |     6 |
      | Libraries            |    369 |    281 |       0 |       0 |   0 |     0 |
      | Tasks                |    369 |    281 |       0 |       0 |   0 |     0 |
      | Controller tests     |    605 |    513 |       6 |      53 |   8 |     7 |
      | Helper tests         |     56 |     45 |       2 |       7 |   3 |     4 |
      | Model tests          |    398 |    309 |       9 |      37 |   4 |     6 |
      | Mailer tests         |     71 |     54 |       4 |       5 |   1 |     8 |
      | Integration tests    |    614 |    446 |      10 |      25 |   2 |    15 |
      +----------------------+--------+--------+---------+---------+-----+-------+
      | Total                |   4629 |   3432 |      47 |     309 |   6 |     9 |
      +----------------------+--------+--------+---------+---------+-----+-------+

~~~
technion
If I can bother you with a dumb question, how do you produce these statistics?

~~~
christophe971
bundle exec rake stats

~~~
dasil003
Also, for discovery of a bunch more goodies:

bundle exec rake -T

