The React Newsletter

If you’re a Visual Studio Code user and love to develop projects in React, then you’ve probably been experiencing plenty of annoying repetitive code like React.useState, React.useContext, React.useReducer(reducer, initialState), and so on.

These individual keys are scattered in all different directions on the keyboard, and it can become irritating having our poor little fingers write these characters over and over in all of our React projects.

I had the opportunity to work on scaling a React rendering service, adapting a fixed hardware provision to deal with increasing load. Over the course of many months, incremental improvements were made to the system to enable it to cope with demand. I thought it might be useful to share the more interesting insights that I gained during this process.

Some of the insights here are React-specific, but many are simply generic scalability challenges, or simple mistakes that were made. React server-side performance optimization has been covered elsewhere, so I’m not going to provide an overview of React performance, generally. I’m going to focus on the “big wins” that we enjoyed, along with the subtle, fascinating footguns. My hope is that I can give you something interesting to think about, beyond the standard advice of setting NODE_ENV=production. Something based on the real, honest-to-goodness challenges we had to overcome.

What I found so interesting about this project was where the investigative trail led. I assumed that improving React server-side performance would boil down to correctly implementing a number of React-specific best practices. Only later did I realize that I was looking for performance in the wrong places. With any luck, these stories will enable you to diagnose or avoid your own performance pitfalls!

Testing your apps is becoming so easy, it's starting to become worth the trouble!

Let me tell you a little Christmas secret: I've never really been a fan of testing. It takes up so much time, makes it harder to refactor your project, and you always feel like you haven't done enough. Testing is a recipe for feeling bad about your efforts. Unless, of course, you have 💯 % test coverage, but that's bad in its own right.

So screw testing, right? Well...

Truth of the matter is we need those grinchy buzzkills to keep us moving with any kind of confidence. Because no matter how bad writing tests seems to be, doing all of those checks manually on every deploy is definitely not going to happen.

Luckily for us JavaScript developers, testing our apps - and particularly React apps - have become much easier the last couple of years. I'll share some of my hard bought tips from the last couple of years worth of consulting, and hope that you'll find them enjoyable.

It all started when we (Oberon) noticed a certain pattern among a subset of our clients — festivals. Their sites tend to have lots of issues with server load and costs.

They are, after all websites that remain largely unused for most of the year — until they’re not. And at those few yearly moments (such as at the start of a ticket sale), server loads can get really, really high.

This makes most festival websites not particularly good candidates for hosting on servers that are shared by multiple sites, because they can bring down all other sites during this brief period. Additionally, clients are paying a fixed hosting fee for a server that mostly remains unused throughout the year.

In the past we’ve ‘resolved’ these issues by adding an additional caching layer like Squid, CloudFront, etc. Adding these kinds of extra layers does make you think about why these sites are built as dynamic applications anyway.

For example, festival programme items rarely change after their initial publication, and it’s not like most of the content on these type of sites is particularly ‘realtime’ anyway.

What if we could just keep the entire site static, only updating it if changes were made in one of the data sources? We could then put it on a pay-per-request static file hosting service (like AWS S3), where we can basically scale to infinity if need be, while keeping the costs low during the down periods.

When our company was approached by a new client (that had sadly earned a reputation for its website failing during peak hours), it felt like the stars were aligned, and we decided to go full JAMStack.

• Level 2 React Native with GraphQL
• Building 🔥 React components with Storybook. Now 66% off
• Styled Components
• Building 🔥 React components with Storybook in 30 minutes or so
• React 16 For Everyone
• 🔥 Building your first React application in 75 minutes or so 🔥.