Unfortunately they are still highly dependent on other APIs. When San Diego Comiccon went live on funko.com (shopify) the website was fine but the checkout was bottlenecked by the API calls to shipping providers. Many never were able to checkout and Funko had to issue an apology. Unfortunate that no matter how great you can improve your own product you may still be dependent upon others.
How Shopify reduced storefront response times with a rewrite
51–60 of 76 posts
Re: How Shopify reduced storefront response times with a rewrite
#52Is the new implementation still Rails?
I'm assuming the details of exactly what the new implementation is have been deliberately withheld for some future post where they talk specifics (especially if it's something exciting like Rust/Elixir/Go). This keeps the focus of this post on the approach to migration, using the old implementation as a reference in order to burn down the list of divergences, etc.
Re: How Shopify reduced storefront response times with a rewrite
#53I’m aware that Ruby/Rails isn’t that quick, but it seems mind boggling that an 800ms server response time is considered tolerated, and 200ms is satisfying. I’ve never used Ruby in production so maybe my reference point is off and this is more impressive than I’m giving it credit for.
Re: How Shopify reduced storefront response times with a rewrite
#54Could someone please explain how the ‘as a result’ follows from the active-active replication setup?
Re: How Shopify reduced storefront response times with a rewrite
#55Unfortunately they are still highly dependent on other APIs. When San Diego Comiccon went live on funko.com (shopify) the website was fine but the checkout was bottlenecked by the API calls to shipping providers. Many never were able to checkout and Funko had to issue an apology. Unfortunate that no matter how great you can improve your own product you may still be dependent upon others.
I'm interested to know more about this. I've used about five different e-commerce solutions and they all make API calls to shipping providers. What was different here?
https://comicbook.com/irl/news/funko-pop-comic-con-2020-excl...
Re: How Shopify reduced storefront response times with a rewrite
#56Some of the listed optimizations were: > We carefully vet what we eager-load depending on the type of request and we optimize towards reducing instances of N+1 queries. > Reducing Memory Allocations > Implementing Efficient Caching Layers All of those steps seem pretty standard ways of optimizing a Rails application. I wished the article made it clearer why they decided to pursue such a complex route (the whole custo…
(contributor here) The project does still use code from Rails. Some parts of ActiveSupport in particular are really not worth rewriting, it works fine and has a lot of investment already. The MVC part of Rails is not used for this project, because the storefront of Shopify works in a very different way than a CRUD app, and doesn’t benefit nearly as much. Custom code is a lot smaller and easier to understand and optim…
Re: How Shopify reduced storefront response times with a rewrite
#57Earlier quoted context omitted.
(contributor here) The project does still use code from Rails. Some parts of ActiveSupport in particular are really not worth rewriting, it works fine and has a lot of investment already. The MVC part of Rails is not used for this project, because the storefront of Shopify works in a very different way than a CRUD app, and doesn’t benefit nearly as much. Custom code is a lot smaller and easier to understand and optim…
Out of curiosity, why continue to implement in ruby? If milliseconds are important as you mention, interpreted languages will always be slower.
If you're 75/100 of where you want to be on performance, it can be easy to lose immense amounts of time chasing a 95/100 type ideal performance outcome when you can maybe far more easily get to 90/100 by making eg straight-forward caching improvements to what you already have and not have to rewrite all of your code.
Good enough is almost always underrated in tech. People destroy opportunity, time, money, and entire businesses chasing what supposedly lies beyond good enough.
John Carmack has a good example of this in his Joe Rogan interview [1], in how id Software burned six years on Rage, making incorrect (in hindsight) choices that involved trying to do too much. He regrets his old standard line and approach that it'll be done when it's done. He wishes they had made compromises instead and shipped Rage several years earlier. That's a pretty classic storyline in all of tech, taking on far too much when 85% good enough would have worked just as well most likely.
Re: How Shopify reduced storefront response times with a rewrite
#58Earlier quoted context omitted.
Out of curiosity, why continue to implement in ruby? If milliseconds are important as you mention, interpreted languages will always be slower.
They have a very good thing going. Perhaps there is no great reason to bite off so much at one time. They can take their time and do that later if it makes enough sense. I would expect it would require a very substantial effort to rebuild their platform in a different language. If you're 75/100 of where you want to be on performance, it can be easy to lose immense amounts of time chasing a 95/100 type ideal performan…
very good example
Re: How Shopify reduced storefront response times with a rewrite
#59What users saw in terms of response time
and perceived response time
And what users are seeing after the improvements
*
We had evaluated spotify for one of our projects and aesthetically it is really good. However, time wise their store takes forever to do stuff
This was a couple of years back, so hopefully things are much better now
Basically, the article covers how much better THE TEAM doing the coding feels
What is the effect on the users using the stores?
Re: How Shopify reduced storefront response times with a rewrite
#60Earlier quoted context omitted.
If you have thousands of rubyists then you surely have hundreds who also know other languages? Seems to make sense to use a fast langauage for the small performance sensitive part of your codebase.
"Faster" languages often have big advantages in small benchmarks which get a lot smaller or even reverse once you're looking at whole application performance. Mandelbrot (from CLBG) Ruby 246s NodeJS 8s Java 4s Web (fortunes from TE benchmarks) Ruby + Roda + Sequel 51k rps NodeJS + Express 46k rps Java + Dropwizard 62k rps
Java (vertx-postgres) 347k rps, Go (fasthttp) 320k rps Rust (actix-postgres) 607k rps