I love how Shopify’s Polaris team researched their options on replacing Sass in the open:

The Polaris team is exploring alternatives to Sass that better serve our current needs from CSS. Stay tuned for a follow up on our explorations and learning.

In the meantime, we want to know your thoughts on removing Sass! Join the conversation in the comments below..

The comment thread that follows details the pros and cons of many replacement options including Tailwind, CSS Modules, and vanilla-extract (which they ultimately decided on).

Maxime Vaillancourt shared the background and details of how Shopify reduced their storefront response times with a rewrite.

The Rails monolith still handles checkout, admin, and API traffic, but storefront traffic is handled by the new implementation.

Designing the new storefront implementation from the ground up allowed us to think about the guarantees we could provide: we took the opportunity of this evergreen project to set us up on strong primitives that can be extended in the future, which would have been much more difficult to retrofit in the legacy implementation. An example of these foundations is the decision to design the new implementation on top of an active-active replication setup. As a result, the new implementation always reads from dedicated read replicas, improving performance and reducing load on the primary writers.

Similarly, by rebuilding and extracting the storefront-related code in a dedicated application, we took the opportunity to think about building the best developer experience possible: great debugging tools, simple onboarding setup, welcoming documentation, and so on.

Jessica Xie:

I’m not implying that one shouldn’t write tests. The benefits of quality assurance, performance monitoring, and speeding up development by catching bugs early instead of in production outweigh its downsides. However, improvements can be made… Test selection sparks joy in my life. I wish that I can bring the same joy to you.

This is an excellent refactoring story using one of Shopify’s core classes.

As you can imagine, one of the most critical areas in Shopify’s Ruby on Rails codebase is the Shop model. Shop is a hefty class with well over 3000 lines of code, and its responsibilities are numerous. When Shopify was a smaller company with a smaller codebase, Shop’s purpose was clearer: it represented an online store hosted on our platform. Today, Shopify is far more complex, and the business intentions of the Shop model are murkier. It can be described as a God Object: a class that knows and does too much.

They use Martin Fowler’s Strangler Fig pattern to achieve the refactoring. You may recall we discussed this on our episode with Amal Hussein.

Facebook’s ‘learn once, write anywhere’ mobile framework gets a huge vote of confidence:

After years of native mobile development, we’ve decided to go full steam ahead building all of our new mobile apps using React Native. As I’ll explain, that decision doesn’t come lightly.

So why the switch to React Native? And why now? How does this fit in with our native mobile development? It’s a complicated answer that’s best served with a little background.

The biggest reason seems to be exactly what React Native promises: knowledge transfer between web and mobile with React at the heart of it all. But there’s a lot more to the story, so definitely click through and read for yourself.

New to back-end/infra development? Just need a refresher? Here’s an intro to some common data storage options and when you might use them.

If I had to pick one engineering team to write up how they make (and keep) Rails running fast, it’d be Shopify’s. What a treat!

Part of Shopify’s success with Ruby on Rails is an emphasis on writing fast code. But, how do you really write fast code? Largely, that’s context sensitive to the problem you’re trying to solve. Let’s talk about a few ways to start writing faster code in Active Record, Rails, and Ruby.

Shopify’s engineering team has been doing some serious engineering on their codebase:

Shopify is one of the largest Ruby on Rails codebases in existence. It has been worked on for over a decade by more than a thousand developers. It encapsulates a lot of diverse functionality from billing merchants, managing 3rd party developer apps, updating products, handling shipping and so on. It was initially built as a monolith, meaning that all of these distinct functionalities were built into the same codebase with no boundaries between them. For many years this architecture worked for us, but eventually, we reached a point where the downsides of the monolith were outweighing the benefits. We had a choice to make about how to proceed.

Click through for a breakdown of the benefits/drawbacks of monoliths and what they build to address the drawbacks without losing the benefits.