So is Shopify the biggest fish still on the Ruby stack?
Nice article detailing how they did an upgrade to openId connect to allow SSO on multiple shops within a client company.
Remember that the hyped-up companies you hear about on HN & other social media aren't the entire world. There are plenty of companies out there that stay quiet and outside of the spotlight and use the language just fine. The same applies for PHP and other languages that are considered (unfairly IMO) "old-school".
IIRC there are still many large companies using Ruby/Rails still, they've just also diversified their tech stacks (as larger companies tend to do). AFAIK the list includes: GitHub (MS has a few Rails-based acquisitions now), Airbnb, Groupon, Square, Cookpad, Kickstarter, Hulu, etc..
Funny you mention this. I just today had to implement a painful workaround for Shopify's insanely short timeout on product image uploads. On submitting an image url, you apparently get 4s to complete the whole transfer.
I found hundreds of people complaining about this in the community forums, going back years. If you're dynamically generating images, or on a congested network, 4s is far too short.
Since this is a simple config property, the only justification I can imagine is that they are trying to restrict the amount of time that their (single-threaded, memory-hungry) instances are occupied. Because of Ruby's poor resource management, a core part of their API is barely usable.
They’re still using a rails setup for their core services. But, this core falls over with him RPM. It’s failed in nearly all flash sales it has had to handle.
Rails is great. But commerce is heavy and I don’t believe Shopify can keep its existing core code base around much longer without a significant change to aid with performance.
Running an OAuth2 server isn't tremendously involved. There are good open-source projects like https://github.com/ory/hydra that are pretty easy to configure.
Hey, I worked on this project for ~2 years, though I'm no longer with Shopify.
We started with Doorkeeper and gradually switched to building our own OAuth2/OIDC implementation over time, partially using glued together lower-level libraries like https://github.com/nov/openid_connect
Well design of one-to-one relationship between users and shops. Then, they solve the problem that approach has brought. Nothing particular at the article.
[+] [-] ivankolev|6 years ago|reply
[+] [-] Nextgrid|6 years ago|reply
[+] [-] noodle|6 years ago|reply
[+] [-] stickfigure|6 years ago|reply
I found hundreds of people complaining about this in the community forums, going back years. If you're dynamically generating images, or on a congested network, 4s is far too short.
Since this is a simple config property, the only justification I can imagine is that they are trying to restrict the amount of time that their (single-threaded, memory-hungry) instances are occupied. Because of Ruby's poor resource management, a core part of their API is barely usable.
I'm pretty disappointed.
[+] [-] uyuioi|6 years ago|reply
Rails is great. But commerce is heavy and I don’t believe Shopify can keep its existing core code base around much longer without a significant change to aid with performance.
[+] [-] Thaxll|6 years ago|reply
[+] [-] pm90|6 years ago|reply
It would be interesting to know the details of how they’re doing authorization. It appears that it’s all or nothing but I might be mistaken.
[+] [-] YawningAngel|6 years ago|reply
[+] [-] meagar|6 years ago|reply
We started with Doorkeeper and gradually switched to building our own OAuth2/OIDC implementation over time, partially using glued together lower-level libraries like https://github.com/nov/openid_connect
Edit: I forgot, I even have a few small commits to that last project from my time at Shopify: https://github.com/nov/openid_connect/commits?author=meagar
[+] [-] delidumrul|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] derptron|6 years ago|reply
[deleted]