Knowing how to profile a React application to improve real-world performance is a good tool in any front-end developer’s toolkit. The Profiler API allows us to do just that with insights on why and how long our components are rendering for.

We can use the profiling data to find unnecessary and expensive renders that may be impacting performance negatively. Thankfully, it’s not that complicated. Let’s take a look at the Profiler API that comes bundled with every React install.

You can interact with the React Profiler API in two ways:

- The React Devtools extension
- The Profiler Component

Both allow you to interact with the same data, but in different ways. Whichever one you choose depends on your use case. By the end of this article, we will have covered how to use the Profiler API to measure and improve the performance of a React app.

## The React Devtools extension

The Devtools profiler offers a simple, visual way of profiling a React app. We can visually see components that re-render and even pinpoint the cause of the render. Using such valuable information, we can make decisions to reduce unnecessary renders and optimize performance.

![We can navigate the component tree and gain valuable insight](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615284491738_Screenshot+2021-03-09+at+10.55.19+AM.png)

Let’s take a look at the interface of the profiler so that we’re able to understand the profiling data. I’ve numbered each section (in red) so that we can break it down bit by bit.

__1. Component chart__
This is a chart of all the components being profiled in a commit. To understand what a commit is, we have to understand how React renders a component. It does this in two phases —

- The render phase where it determines what changes need to be made to e.g. the DOM. During this phase, React calls `render` and then compares the result to the previous render.
- The commit phase is when React applies any changes. (In the case of React DOM, this is when React inserts, updates, and removes DOM nodes)

So a commit is basically all the changes applied from the render phase. A render may not always lead to a commit (i.e there are no new changes) but a commit is always from a render so you can think of a commit as a render even though they don’t exactly mean the same thing.

The component chart can display different types of information depending on the currently selected view. It can display either —

- A tree of all components being rendered in the commit
- A sorted view of all the components in order of slowest to fastest

In this view, we can also hover over the component bars to see information like if and why the component rendered, the duration of the render (or commit), and based on colour of the bar, whether it’s a relatively slow or fast render.

__2. Tabs__

- __Flamegraph tab__ — shows the component tree for the current commit. It Includes render information about each component in the tree. The length and colour of the bars indicates how long the render took.
![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615277833592_Screenshot+2021-03-09+at+9.14.02+AM.png)

    - The longer a bar is relative to the other bars, the more time it took to render
    - The yellower a bar is, the more time it took to render
    - The bluer a bar is, the less time it took to render
    - If the bar is grey, it didn’t render

You can also hover or click on a component bar to get information on why the component rendered (you have to enable this in the profiler settings using the gear icon before profiling)

- __Ranked tab__ — Similar to Flamegraph but sorts the components based on which took the longest time to render. The slowest components will be at the top and the fastest will be at the bottom. This makes it easy to identify which components are affecting performance the most.
![It seems the Input component is taking the most time to render](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615278303810_Screenshot+2021-03-09+at+9.20.17+AM.png)

- __Interactions tab__ — Shows information on how long certain UI actions take using the [experimental tracing API.](https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html#interactions) It can track actions like whether a specific button was clicked or whether a form was submitted. Because it is still experimental and the API is prone to change at any time, we will not be focusing on it.

__3. Commits overview__
This shows an overview of all the commits (renders that led to actual DOM updates) being made as the app renders. The slower a commit is (i.e the slower the render), the longer the bar will be. We can navigate back and forth between commits to get more information about a particular commit.

![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615381592986_commit+overview.png)

This is useful in instantly identifying when an app is making more commits than expected. For instance, if you type a single word in an input and there are 20 commits being made for just that action, then there’s a good chance some of those commits are unnecessary.

__4. Commit information__
This shows information about a specific commit. You can gain useful insight like when the commit was made (Commited at), how long the commit took (Render duration), and if enabled, the interactions that triggered the commit (Interactions).

When a component is clicked from the component chart, the commit information section also shows extra details like why a component rendered and a list of all the commits recorded during profiling.

![We can see that the Input component rendered because the inputValue prop changed](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615279289337_Screenshot+2021-03-09+at+9.38.35+AM.png)

This can help us identify props, state variables, and hooks that may be causing unnecessary renders i.e a function prop being redefined in the parent component.

## The Profiler Component

This is a lower-level way of interacting with the same profiling data as with the extension. Instead of a visual representation of performance using colours and bar lengths, the Profiler component provides a more textual way of profiling a React app.

It is in fact what the extension uses under the hood to display the performance data in a visual way. This means that it is more flexible to use as you can choose to do whatever you want with the data. For example, you could render it as a graph or store it in a database so you could track performance changes over the lifetime of your app.

__How to use the Profiler component__
In the simplest of terms, it wraps over a React component and measures how often the component renders and how long the renders take. To use it, you wrap the component you want to measure in the Profiler component —

    <Profiler id="definition" onRender={callbackToProcessRenderInfo}>
      <Definition />
    </Profiler>

It takes in two props —

1. `id` — A unique identifier for the component you’re profiling. This is useful for differentiating between different components if you’re profiling more than one at the same time or just for identification purposes.

2. `onRender` — A callback function that receives the profiling data as arguments. You can do whatever you like with this data such as logging it, graphing it, etc. It receives the following arguments —
  - `id` → An id string prop passed to the Profiler component
  - `phase` → Can be either “mount” or “update” and tells you if the component is mounting for the first time or whether it’s updating due to a props, state, or hooks change (i.e re-rendering)
  - `actualDuration` → The time spent in milliseconds rendering the Profiler component (The Profiler adds a tiny performance overhead) and all its descendants
  - `baseDuration` → The estimated time in milliseconds that would be spent rendering the descendants without any memoisations. The delta between this and `actualDuration` should tell you how useful your `React.memo` and `useMemo` callls are (for more information about these calls, you can read [this article on memoisation in React](https://ovie.dev/blog/memoisation-in-react-memo-use-memo).
  - `startTime` → A timestamp of when React began rendering the current update
  - `commitTime` → A timestamp of when React committed the current update
  - `interactions` → A [Set](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set) of interactions (if any) that were being traced when the update was scheduled

A simple `onRender` callback would look something like this —

    function callbackToProcessRenderInfo(id, phase, actualDuration, baseDuration, startTime, commitTime) {
      // we can log it to a database or render it out as a chart 
      logToDatabase({ id, phase, actualDuration, baseDuration, startTime, commitTime })
    }

In this case, the callback function is simply logging the performance data to a database where we could do more things like rendering it in a chart similar to what the devtools extension does.

## Profiling a React app

Let’s profile a simple dictionary app using the Devtools extension to see how to improve the performance.

![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615295777239_Screenshot+2021-03-09+at+2.12.44+PM.png)

This is a very simple app consisting of three components —

1. SearchWord - This is the main wrapper component. It has the following state variables —
    - `formInput` → This is the word we want definitions for. Also used in the `Input` component
    - `entries` → Used to store the definitions for `formInput`. Also used in the `Defintions` component

2. Input  - Used for capturing user input. It receives its value (`formInput`) and `onChange` handler from the parent `SearchWord` component.

3. Definitions - Used to display the definition entries and the current selected entry. Receives the definition entries (`entries`) from it’s parent `SearchWord` component.

When a user types into the input field, we set the value into `formInput`. We have a `useEffect` that runs when `formInput` changes to fetch the definitions for its current value which we store in `entries` and pass on to the Definitions component as a prop.

![Link to source code of code snippet](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615296341294_Screenshot+2021-03-09+at+2.25.33+PM.png)

This is very barebones without any error handling but it’s good enough for the purposes of showing how the devtools profiler works. To get started — 

__Profiling and optimizations__

- We’ll install the [React devtools Chrome extension](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi/related?hl=en)
- Start a profiling session
- Search for the word “flame” by typing into the input field
- End the profiling session and view the data
![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615296790456_start+profiling+session.gif)

This is the result of the first render and the results are certainly interesting.

![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615301333233_Screenshot+2021-03-09+at+3.29.08+PM.png)

- We have a total of 14 commits, and it seems they’re pretty slow too. We can tell from the commit bar height and colour.

- The root SearchWord component is taking 73.5ms to render on mount. This isn’t bad enough to cause noticeable problems but it is taking up valuable CPU resources that could be shared by other programs on the computer.

- The Input component contributes around 13% to the render duration at around 10ms of render time. This sounds about right and doesn’t seem like it would benefit from some performance optimisations.

- The Definitions component on the other hand is a bit alarming. It renders for around 60ms which contributes over 80% of render time. Looking at other commits using the commit overview, we can see it is also the main cause for the slow commit times on re-renders.
![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615302156683_Screenshot+2021-03-09+at+3.58.47+PM.png)

We can pick a commit in the middle of the history where the app is updating and we seee that the rendering times are similar to the mount render times.

Compiling the results along with data from the “Networks” tab in the Chrome inspector tools, we get the following results for a search of the word “Flame” —

- 14 commits
- All commits updated Definitions (It’s re-rendering too much)
- 5 network calls (But we only want definitions for one word)
- 1127ms total SearchWords render time
- 1029s total Definitions render time

How would we improve the performance in this case?

A first step would be to take a look at why the Definitions component is re-rendering on every commit. The answer lies in the logic of the app. We’re making a new search every time the user types a letter. This is making a network request and updating the definition entries on each keystroke triggering re-renders.

Ideally, we want the search to kick off only when the user stops typing and only then updating the definition entries. 

![Link to source code of code snippet](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615302136631_Screenshot+2021-03-09+at+4.01.49+PM.png)

The fix is to make the Input control it’s own state and only make a request when the user is finished typing. This would make the Definitions component render far fewer times as it would only update when we make the request at the end of the typing session.

The SearchWord component would also re-render fewer times as it will no longer re-render on the input change event.

Finally, instead of 5 network calls for the word “flame”, we’d only make 1. Let’s see if this improves the rendering times. I’ll commit the change, refresh the app, start another profiling session, and search for the word “flame”.

![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615302675890_Screenshot+2021-03-09+at+4.06.57+PM.png)

Immediately, we can see improvements in our rendering times. The rendering times for the first mount didn’t change much. The commits overview, however, is where we see the improvements.

Previously, the Definitions component rendered every time the Input component rendered. Because it is a slow component, it used up a lot of time and resources on every keystroke. Now, however, we’ve reduced the number of times it has to re-render and the app becomes more efficient.

![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615383708054_optimisation+results.png)

Subsequent updates where only the Input component re-renders are fast and complete in around 10ms. Since the definition entries are not updated until the user stops typing, the Definitions component does not re-render.

Also, because the Input component now manages it’s own state, typing in the input field doesn’t re-render the parent SearchWord component. Only the Input component re-renders on the onChange event.

The profiling data for the session now looks like this

- 14 commits
- Only first and last 3 commits updated Definitions (We’ve reduced the number of renders)
- 1 network call (We only make a call for the exact word we want)
- 296.4ms total SearchWords render time
- 273.3ms total Definitions render time

This is some amazing improvements in just one change. We can take it further if we want like optimizing the Definitions component to reduce rendering time. However, you could argue that it is pointless chasing after milliseconds of improvement at this point. I say it’s fun and can be useful 🙂

Next steps

Once you know how to identify bottlenecks in your React application using the Profiler API, you can explore other ways, especially if performance is important to your business. 

Additional ways to measure performance in JavaScript apps —

- [User Timing API](https://developer.mozilla.org/en-US/docs/Web/API/User_Timing_API)
- [Lighthouse](https://developers.google.com/web/tools/lighthouse)
- [Chrome Devtools performance panel](https://developer.chrome.com/docs/devtools/evaluate-performance/)
- [Custom Metrics](https://web.dev/custom-metrics/)

After profiling and analyzing bottlenecks in your app, you can then look into ways of improving performance using techniques like memoisation and lazy loading.

[Here’s an article on implementing memoisation in React using React.memo and useMemo and one on lazy loading in React apps.](https://ovie.dev/blog/memoisation-in-react-memo-use-memo)

If you’re interested in general improvement tips for the web, [here’s an article on 10 of some of the weirdest web performance tips.](https://blog.asayer.io/10-of-the-weirdest-web-performance-tips)

[Link to source code](https://github.com/ovieokeh/dictionary-profiler-api) for the application profiled in this tutorial.

Learn how to use the React Profiler to measure and improve the performance of your app.

react-logo

Practical guide to profiling a React app

As a React developer, you’ve most likely come across situations where optimizing the performance of a component is necessary. There are certain cases where rendering a component might be so expensive that it uses up a lot of CPU resources and/or memory (i.e rendering a graph with thousands of data points).

When this happens, there are some React APIs that we can reach for to improve performance and today, we’ll focus on two of the most misunderstood ones — React.memo and useMemo.

Before we do this, however, it’s important to get a clear understanding of the concept of memoization and how it relates to these two APIs.

What is memoization?

Memoization is a fancy computer science buzzword that just means a way to avoid doing unnecessary work. Wikipedia describes memoization as —

> “In computing, memoization or memoisation is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again.”

Let’s think about it this way. Say you were taking a Mathematics quiz and you were asked the products of 99 and 22. The first time you hear the question, it might take you some seconds to perform the calculations and you arrive at the answer 2,178.

However, if at a later stage you were asked the same question of 99 * 22, you already know the result  from the last time you answered it and you can answer the question immediately without having to do the calculations all over again.

In essence, you memoized (memorized) the result of 99 * 22 the first time you calculated it and every time someone asks you what the answer is, you no longer have to calculate it again. You already know the answer.

This is exactly how memoization works in programming as well. If I had an unoptimized function that calculated the digits of PI, it would consume a lot of CPU resources every time I called this function.

    function digitsOfPI(numOfDigits) { ...some logic }    
    // First call, we use up a lot of resources to calculate the answer
    digitsOfPI(100)

But if the result from this function was memoized, then it would only use up CPU resources the first time it was called. If you called it a second time and asked for the same number of digits as before, the function can just return the memoized result without having to calculate anything again.

    // Second call, we've calculated 100 digits of PI before
    // so the function already knows the answer and doesn't use
    // up any resources calculating it.
    digitsOfPI(100)

It is important to note, however, that memoization is not free and in some cases can actually lead to worse performance. We’ll explore this in more detail below.

## React.memo
How does this relate to React? It becomes useful when you consider how React updates the DOM. When updating the DOM, React renders a component and compares the current and previous render. If they are different, it updates the DOM with the new render, and if they aren’t, it just discards the current render.

But notice that for React to decide whether to update the DOM, it first has to render the component. And if doing so is expensive, you want to minimize the number of times it happens. You can do this by bypassing unnecessary renders using `React.memo`.

If you wrap a component in `React.memo`, React will still render the component normally the first time but it also remembers the props. Before the next render, React will compare the new props and the old ones. If they are the same, it just returns the previous result instead of rendering it again.

### Example use case of React.memo
Take this component which renders a bar graph based on data it receives from props.

    const BarGraph = ({ data }) => {
      ...some expensive calculations
      ...render method
    }

This component will always render the same graph given the same dataset while performing some expensive calculations (expensive here might mean it takes 400ms to process the data). So we only want it to render when the `data` prop changes.

However, the data prop is most likely an array or object so React will always see it as a changed prop between renders even when it hasn’t really changed. This is because of how object equality works in JavaScript. An object is only equal to another object if they point to the same location in memory regardless of the actual contents. (Learn more about object equality on MDN).

This means React will waste some time rendering it and comparing the result before seeing that the result is the same and discarding the render. This is not ideal because it’s an unnecessary cycle and more importantly, an expensive one too.

We can fix this by telling React not to render the component unless the actual value of the `data` prop changes using React.memo like so —

    export const memoisedBarGraph = React.memo(BarGraph)

Ideally, this should fix the issue but in this case, it does not. React.memo uses a shallow comparison of the component props and because of how JavaScript works, comparing objects shallowly will always return false even if they have the same values.

This is why React.memo also takes in a second argument. This argument is a custom equality check function that you, the developer, uses to decide if the component should render (Think shouldComponentUpdate).

The solution then, for our initial problem would look something like this —

    const barGraphPropsAreEqual = (prevProps, newProps) => {
      ...some custom logic to determine if the props are equal
    }

    // we update our React.memo usage
    export const memoisedBarGraph = React.memo(BarGraph, barGraphPropsAreEqual)

Now, when a render is triggered (i.e the parent component rerenders), React.memo can use our custom equality check function to determine if the props for the BarGraph component have changed and if it should rerender.

If our function returns true, React bails out of the render and doesn’t update the DOM. If it returns false, React renders the component again and updates the DOM.

When to use React.memo
You can use React.memo if your component —

- Will always render the same thing given the same props (i.e, if you have to make a network call to fetch some data and there’s a chance the data might not be the same, do not use it)
- Renders expensively (i.e, it takes at least 100ms to render)
- Renders often

If your component does not meet the above requirements, then you might not need to memoize it as using React.memo can, in some cases, make performance worse as it’s more code for the client to parse.

When in doubt, profile your component to see if it would be beneficial to memoize it.

Potential performance pitfalls
There’s a reason why React.memo utilizes shallow comparison by default for determining when to rerender. This is because there is an additional overhead in checking if a value has been memoized every time we need to access it and the more complex the data structure of the value, the worse the overhead is.

For strings, numbers, and dates, comparing the values is trivial but for objects, it can get very resource-intensive based on how complex the object is.

So if a component renders often but the custom equality check function is more expensive, then the performance gets worse instead of it getting better. This is why it is important to benchmark a component before and after using React.memo to ensure that it is actually worth memoizing.

Callback functions
Before springing for React.memo, it is important to check if the component accepts any callback functions. This is because a function in JavaScript is only equal to its instance. What does this mean?

If I pass in a prop to a component like this —

    <BarGraph
      data={data}
      onRenderFinish={() => showNotification(subscribedListeners)}
    />

`onRenderFinish` will have a different instance on each render and if you don’t provide a custom equality check function, then React.memo will re-render everytime the function instance changes even if it is basically the same function. This can lead to worse performance as React will have more work to do when rendering the component — first doing a props comparison, and then rendering anyway because the callback prop has a different instance every time.

There are multiple ways to fix this issue but the officially recommended way is to wrap the callback prop in a useCallback hook like so —

    const onBarGraphRenderFinish = useCallback(
      () => showNotification(subscribedListeners),
      [subscribedListeners]
    );

    <BarGraph
      data={data}
      onRenderFinish={onBarGraphRenderFinish}
    />

Learn more about the useCallback hook.

Another way to fix this is through the custom comparison function passed to React.memo. You can convert the function prop to a string and compare the string values but this comes with some caveats.

    const barGraphPropsAreEqual = (prevProps, newProps) => {
      ...some custom logic to determine if the props are equal

      if (typeof prevProps[propKey] === 'function') {
        const isEqual = prevProps[propKey].toString() === newProps[propKey]
    }

This could also be an expensive operation depending on the size of the function but in most cases, should work fine.

You could also decide not to compare the callback function in the custom equality check function since you can decide which props trigger a re-render. But there are cases where it is actually important to compare a callback function prop.

In our case, if `subscribedListeners` changes and you ignore the `onRenderFinish` prop in the equality check function, you’ll effectively be showing notifications to an outdated list of subscribers.

However, If you do not have any values in the callback that could change over the course of time, then ignoring it in the equality check function would be fine.

useMemo

useMemo is one of the built-in hooks in React and it performs a fundamentally similar but different job to React.memo. Similar in the sense that it also memoizes values but different because `useMemo` is a hook and as a result is limited in how it can be used.

Where we used React.memo to optimize a graph component, we can’t use `useMemo` for the same purpose. Instead, it should be used in cases where a derived value is expensive to calculate on every render. What does this mean?

Example use case of useMemo
Say we have a component that takes in some data and encrypts it using a string key from props like so —

    const Encrypter = ({ dataToEncrypt, encryptKey }) => {
      const encryptedData = encrypt(dataToEncrypt, secretKey);
      ...render method
    }

Whenever this component renders, it has to encrypt the data passed to it every time regardless of if the props change. If the `encrypt` function takes a long time to do this, we might want to reduce the number of times we have to run it.

This is where `useMemo` shines. If we have a variable inside a component that is expensive to compute, we can use `useMemo` to reduce the number of times this has to happen by memoizing the computed variable.

In our example case above, this would look something like —

    const Encrypter = ({ dataToEncrypt, encryptKey }) => {
      const encryptedData = useMemo(
        () => encrypt(dataToEncrypt, secretKey),
        [dataToEncrypt, encryptKey]
      );
      ...render method
    }

Now, every time the `Encrypter` component renders, before running the expensive `encrypt` function, `useMemo` checks to see if the `dataToEncrypt` and `encryptKey` values have changed between renders.

If not, it simply returns the result of the previous render without calling the  `encrypt` function. If it changed, then we calculate the result again.

Instead of a custom equality check function as in React.memo, `useMemo` takes in a dependency array (i.e the values that need to change for the result to be calculated again) to determine when to “forget” the previous result and recalculate it (I’m not a 100% sure if React only memoizes the previous render or if there’s an internal cache of previously memoized renders).

If the values in the dependency array are objects or functions, `useMemo` checks for referential equality to determine whether to recalculate the result. This means that for an object or function value, React only considers the value changed if the reference in memory has changed regardless of the actual contents.

In many cases, the object and function instances (except arrow functions because they’re always recreated on each render) don’t change between renders but in cases where deep comparison is necessary, you can use a custom hook like useMemoCompare.

When to use useMemo
Before deciding to use `useMemo`, make sure that —

- You have profiled the component and determined if it’s calculating an expensive value in every render
- There are no side effects (e.g async calls) in your `useMemo` hook because it runs during rendering and all side effects belongs in the useEffect hook.
- You do not break the rules of React Hooks
Which one should I pick?

Now that we have a solid understanding of both `React.memo` and `useMemo`, deciding which one to use should be simple.

- If you’re memoizing a whole component, use `React.memo`
- If you’re memoizing a value inside a functional component, use `useMemo`

It’s noteworthy to mention again that before you spring for either of these solutions, ensure that your use case warrants it as if used carelessly, they could harm performance instead of improving it.


Memoisation sounds fancy but it is really just saving a value and using it later.

If you're searching for new ways to boost your React app performance then this article might be for you.

memoisation-in-react-feature-image

Improving React application performance: React.memo vs useMemo

Over the years, there’s been a gradual shift in the way we build and ship web apps. We’ve gone from monolithic apps running on a server to flexible units running on ephemeral instances.

You only need to look at the [trends data for the term “aws serverless”](https://trends.google.com/trends/explore?date=all&q=aws%20serverless) to see how popular serverless has gotten over the years. So why the trend? What does the term serverless mean? How can there be no server?

All serverless means is that you can ship code to your users without having to worry about the underlying architecture required to run it. There is still a server running your code somewhere, but you don’t have to worry about setting it up or managing it.

"Let someone else be your DevOps team" - Serverless in a nutshell

Before we go any further, I'll come right out and say that I'm an advocate for serverless. [If the use case is right,](https://cloud.google.com/functions/docs/concepts/overview#use_cases) it can carry massive reductions in hosting costs, among a whole host of other benefits.

There's a caveat, though — notice that I used the phrase "if the use case is right." That's because not every app should be built on a serverless architecture. You might end up paying more for hosting and still end up delivering a subpar experience to your users.

This is why you have to weigh the pros and cons of going serverless on a case-by-case basis. In this article, we'll look at how to determine if serverless is a good fit for your project.

Firstly, let's see what servers are before we move on to serverless.

"Learn the rules like a pro, so you can break them like an artist"
          - Pablo Picasso

## Servers and why you need one

[A server, in the context of web apps,](https://www.lifewire.com/servers-in-computer-networking-817380) is hardware or software dedicated to running and serving your code to your users. You need a server to run your HTML, CSS, and JavaScript as well as your backend environment like Node.js. Even your database runs on a server.

All requests made by your browser are eventually handled by a server somewhere, so you can see how important a server is in software development.

OK, so what's wrong with the way we use them right now? Well, a traditional server is like a 24/7 restaurant. It's always open and ready to serve requests. This is how it has always been since [Tim Berners Lee invented the web in 1989](https://home.cern/science/computing/birth-web/).

But the problem with being on all the time is that when there's nothing to do, you'll start wasting resources. If your restaurant is open for ten hours but is filled for only three, you've wasted time and power for seven hours. Do this long enough and the costs begin to accumulate. It eats into your revenue and causes [adverse effects on the environment.](https://www.computerworld.com/article/3431148/why-data-centres-are-the-new-frontier-in-the-fight-against-climate-change.html)

Let's look at a fictional case study to show how inefficient it is to run a traditional web server in a specific case.

## The gross inefficiency of a traditional server

Trakkr is a young startup trying to make package tracking and delivery easy and convenient.

They have an API endpoint that enables you to track the location of your package through a unique tracking number. You put in the tracking number and it tells you the location of your package.

Let's imagine that they host this API on a traditional server, and it takes approximately 200ms to process a single tracking request. We’ll assume that they process an average of 10,000 requests every day.

    10,000 requests per day * 200 milliseconds per request
    =
    2.000.000 miliseconds of work done by the server in a day
    or
    33 minutes of work done by the server in a day

From multiplying the number of requests by the time it takes to process each request, we can see that they need the server to be on for only 33 minutes per day.

The average cost to run a server for a whole day is approximately $3. Running that same server for 33 minutes is approximately $0.07.

Scale that up to a month and Trakkr is shelling out **$****90** for a server that is idle for 97 percent of the time instead of paying only **$****2** for the 33 minutes they need.

This brings us to the major selling point of serverless architectures: [You only pay for what you use.](https://aws.amazon.com/lambda/pricing/)

## Benefits of a serverless architecture

Unlike a traditional architecture, where your server is always on regardless of whether it is being utilized, a serverless “server” is only on whenever there’s something to do. This means that you only pay for the time and resources used within a given period. How does this work?

If you decide to build on a serverless architecture, you’ll have to make some major changes to the way you structure your code. Instead of a single server that handles all requests, your app will be composed of smaller functions that are spun up each time when called.

Let’s look at our previous example with the Trakkr API. In a traditional approach, the API would be hosted on a single, always-on server (this is simplified, as you could implement [load balancing](https://www.znetlive.com/blog/what-is-load-balancing-in-cloud-computing-and-its-advantages/)), and the server would stay on, waiting for tracking requests to process.

In a serverless architecture, the API would be modularized. All the endpoints would be split up into smaller functions that live on the cloud. These functions can access a file system, a database, talk to each other, or use third-party services.

![Serverless favors modularity.](https://paper-attachments.dropbox.com/s_51CEFF421197FF68277EDC7A3C9981B7AC0CA0E76ACCE95BE3D751FD6DAAA120_1586130341650_serverless+vs+traditional.png)

So the Trakkr API, in this case, would consist of these functions hosted on a service like [AWS Lambda](https://aws.amazon.com/lambda/) or [Google Cloud Functions.](https://cloud.google.com/functions) Each request can then be routed to the corresponding function through an API gateway. So what happens when a user makes a request to track a package?

When a tracking request is made, [an API gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) intercepts the request and calls the appropriate function to handle the request. An ephemeral instance of the function is then spun up in an isolated container. The function does its job, passes the response back to the user like a normal REST endpoint would, and then the instance is destroyed.

So, to recap:

- A serverless architecture requires you to modularize your public endpoints into functions
- Each function lives on the cloud, and new instances are created every time a function is called *
- Each function instance has access to a file system, database, and resources
- A function instance can only run for a short time before getting destroyed **

> \* In some cases, instances are reused for faster load-up times
> \** Up to 15 minutes for AWS Lambda, and 9 minutes for Google Cloud Functions

The major strength of a serverless architecture is that you’re only charged for the resources you use in a period. If the function runs for 10 minutes in one day and uses 128MB of memory, you will be charged for only those 10 minutes and 128MB of memory.

**Trakkr on** **s****erverless**
What if Trakkr switched to a serverless platform like AWS?

Well, we already know that their tracking service handles approximately **10,000 requests** per day and that each request takes **200ms** to be processed.

We also know that Trakkr is paying $90 to host the server that powers the service. How much would they pay if they switched to AWS?

AWS charges by the number of requests and the duration of each request, and their free tier offers you **1 million requests** and **400,000s** of compute time. With these freebies, Trakkr’s monthly hosting costs would effectively drop to $0.

What if they decided not to opt for the free tier for some reason? Well, [AWS charges $0.2](https://aws.amazon.com/lambda/pricing/)[0](https://aws.amazon.com/lambda/pricing/) [per 1 million requests](https://aws.amazon.com/lambda/pricing/)[,](https://aws.amazon.com/lambda/pricing/) [and $0.0000002083 per 100ms of compute time.](https://aws.amazon.com/lambda/pricing/) Let’s revisit the calculations we made before.

Since Trakkr requires just **2,000,000ms of compute time** in a day, they’d be spending;

2,000,000ms x ****$0.0000002083 / 100ms **=** **$0.004166 per day****,** or **$0.125 per month**

That’s a reduction of more than 860 percent in server costs for the same service. You can begin to see how, in some cases, switching to a serverless architecture can help you cut down on infrastructure costs massively. This is just one example with one serverless provider, but most offer similar savings.

Apart from the financial gains you could enjoy by switching to a serverless architecture, there are other advantages of building your app this way:

- Scaling is handled automatically in response to load
- Multi-language development
- Code optimization directly impacts operational costs
- Scale different parts of your app independently
## Trade-offs of going serverless

You may have noticed some issues with the way serverless functions are run. Most times, they have to be spun up from scratch when called — [a cold start](https://cloud.google.com/functions/docs/concepts/exec#cold_starts). This includes some overhead like setting up a file system, allocating memory, pulling in dependencies, etc.

This extra work that has to be done before a function is ready can lead to slow startup times, which, in turn can lead to a bad user experience. This is why providers like AWS and Google Cloud Platform will sometimes reuse an instance of a function to reduce latency (warm starts).

Apart from slow startup times, a serverless function is also constrained in other ways.

Because each function is ephemeral (i.e., short-lived), a new function can’t depend on the data from a previous function — that is, unless the data is stored in a separate, persistent layer, like a Postgres database somewhere. But this isn’t ideal, as you’ll incur more latency in communicating with a separate server to retrieve this data.

There are many other drawbacks to using a serverless architecture. [Martin Fowler has gone much more in-depth about these drawbacks in his blog](https://martinfowler.com/articles/serverless.html#drawbacks).

If you’re interested in seeing whether serverless would be the right option for you, read along.

## Should you switch to a Serverless architecture?

The decision to adopt an architecture should not be based on a single article. However, the aim of this section is to provide you some of the questions you should be asking if you’re considering adopting a serverless architecture.

These questions can guide [your research](https://serverless.com/blog/when-why-not-use-serverless/) to enable you to make informed decisions that will lead to the best outcome for your particular use case.

- Do you already utilize most of your server hardware?
- Does your app require a lot of in-memory caching?
- How will frequent cold starts affect your UX?
- Do you require long-lived processes most of the time?
- Does your traffic profile play to the strengths of a serverless architecture?

Maybe have a chat with your CTO or your team lead to answer the questions above (this is by no means an exhaustive list). You should have a much better idea if serverless would be right for a project at the other end of the conversation.

I’ll leave you with a quote from Martin Fowler that bests summarizes the decision to switch to a serverless architecture:

“While there are riches — of scaling and saved deployment effort — to be plundered, there also be dragons — of debugging and monitoring — lurking right around the next corner.”


If the use case is right, serverless architectures can offer massive reductions in hosting costs and incredible modularity. But you need to be aware of the caveats.

Cloud computing

Benefits and tradeoffs of going Serverless

React has made building interactive applications a lot more manageable. We’re able to break up our app into components, each with their own encapsulated logic and styling. It’s great — it means we’re able to work on lots of smaller problems instead of one really large one.

This method of building applications works really well because of abstractions. A component in an application is just an abstraction of logic, data, and, in some cases, styling.

    const Button = () => (...)

The `Button` component above is an abstraction of the logic and styles required to make a button show up on a page. Now, every time we want a button, we simply use this abstraction — no need to reinvent the wheel.

When we build apps this way, a new challenge arises: sometimes we want to share logic or data between components. We also want to do this in a way that is clean and composable. Just as we’re able to abstract logic and data into components, we also want to be able to compose these components to form larger building blocks.

Four paragraphs in and we still haven’t gotten to [render props](https://reactjs.org/docs/render-props.html) yet.

**Put simply, a render prop is simply a function prop that is called in a render method**. But to truly understand what this means, we need to know why such a pattern exists in the first place.

## Why do we need render props?

Let’s take a legitimate problem we might face in the real world. Say we wanted to have a UI element that we could dismiss with an animation.

![Delete from table by Alex Lauderdale](https://static.dribbble.com/users/46425/screenshots/4823330/table_ux.gif)

What we want here is a component that can render anything, but we want to keep this dismissal animation. We could simply use the `children` prop and pass whatever we wanted to render as a child.

    const Dismiss = ({ children }) => {
      return (
        <Fragment>
          {children}
        </Fragment>
      )
    }

That would work, but it’s limited.

- How would we fire the dismiss event from within the component being rendered? If we decide to fire it from the `Dismiss` component, that means we’ll have to hardcode some HTML.
- What if we wanted to set up different actions to fire on the dismiss event?
- Is there any way to pass data as props to the children being rendered?

In situations like this, we need something a bit more flexible than the children prop method. What we really want is to encapsulate the dismissal functionality so that we can share it between components.

With render props, we could render anything we wanted, just like the children prop method. But we will also be able to pass props to whatever is being rendered.

**This is the main purpose of render props — being able to communicate with any rendered component without having to couple implementation details.** This is possible because the render function now comes in as a prop, and you can pass data to it as arguments when you call it.

This will become clearer when we take a look at a practical use case for render props (based on [Wave Free’s modal component](https://wave.free-now.com/components/Modal)). We’ll look at a possible solution to the problem we raised initially using the children prop method. Then, we’ll look at a more flexible solution with render props.

## Implementing render props
    const Dismiss = ({ children }) => {
      const dismiss = () => {
        ...code to implement dismissal animations etc
      }

      return (
        <div>
          {children}
          <button onClick={dismiss}>dismiss</button>
        </div>
      )
    }

    const DismissableContent = () => {
      return (
        <Dismiss>
          ...code
        </Dismiss>
      )
    }

Above, we have a `Dismiss` component that renders whatever is passed as the children prop but also contains code to implement the dismiss animation. Below it is how we’d use such a component. Notice that with this implementation:

- You can only fire the dismiss event from within the `Dismiss` component
- You can’t pass data to the `children` being rendered
- You have to account for the extra div in your layouts

You can see some of the limitations in sharing functionality this way. Now let’s look at the same solution, but with render props:

    const Dismiss = (props) => {
      const dismiss = () => {
        ...code to implement dismissal animations etc
      }

      return props.render(dismiss)
    }

    const DismissableContent = () => {
      return (
        <Dismiss render={
          dismiss => <Content dismiss={dismiss} />
        } />
      )
    }

Apart from the code being smaller, there are some more important advantages to this method.

We have moved the content of the render function from being hardcoded in the `Dismiss` component to accepting it from the props. By simply calling `props.render()`, the component is able to render whatever is returned from the render prop. This comes with some implications:

- Since the render prop is a function, we can pass data to it as arguments. This means that  `Dismiss` can communicate with the component being rendered and vice versa
- You don’t have to account for any extra divs from `Dismiss` because it can be pure and not return its own HTML (most times, though, you’d return some accompanying HTML and styling)

We can now see how this solves the issues we had using the children prop method. This is much cleaner and more flexible by every metric.

## Implementing other props

Another advantage of render props is that the prop doesn’t have to be called `render`. You could call it whatever you want as long as the prop is invoked in the render method. This leads to interesting implementations, like this:

    const Dismiss = ({ children }) => {
      const dismiss = () => {
        ...code to implement dismissal animations etc
      }

      return children(dismiss)
    }

    const DismissableContent = () => {
      return (
        <Dismiss>
          {(dismiss) => (
            <Content dismiss={dismiss} />
          )}
        </Dismiss>
      )
    }
## Implementing higher-order components (HOCs)

You may have noticed by now that render props also allow us to implement HOCs with minimal effort. Below, you can see a `withDismiss` HOC that takes in a component and enhances a component with the dismiss functionality.

    const withDismiss = (Component) =>
      (props) => (
        <Dismiss>
          {(dismiss) => (
            <Component dismiss={dismiss} {...props} />
          )}
        </Dismiss>
      )

This is so easy because of the compositional nature of components in React. Because we’ve been able to encapsulate the dismiss logic into a component with render props functionality, composing new components with the same functionality becomes effortless.

## Caveats

There’s an important edge case to keep in mind when using the render props pattern if you use `React.PureComponent`. For a quick refresher, `PureComponent` can provide small performance gains because it implements `shouldComponentUpdate` internally through a shallow props and state comparison.

The important thing to note here is the shallow props comparison. Most of the time, when you use render props, you’ll be passing an anonymous function to the render prop.

    class Dismiss extends React.PureComponent {
      dismiss = () => {
        ...code to implement dismissal animations etc
      }

      render() {
        return this.props.render(dismiss)
      }
    }

    const DismissableContent = () => {
      return (
        <Dismiss render={
          dismiss => <Content dismiss={dismiss} /> // will be different every render
        } />
      )
    }

In this example, every time `DismissableContent` renders, it generates a new value for the render prop, and this fails the shallow comparison done by `React.PureComponent`.

If it is important to you that this doesn’t happen — e.g., maybe `Dismiss` contains some intensive code — you could fix it by moving the render prop value into a named function, like this:

    class Dismiss extends React.PureComponent {
      ...same implementation as above
    }

    const DismissableContent = () => {
      const content = (dismiss) => <Content dismiss={dismiss} />

      return (
        <Dismiss render={content} />
      )
    }

This will ensure that the `content` value becomes an instance of the `DismissableContent` component and is not regenerated on every render.

## Conclusion

I hope by the end of this article you should have a solid understanding of the render props pattern in React. It is a very powerful and flexible pattern for solving some code sharing issues you might come across in your codebase.

If you want a playground to practice with render props, you can [fork this CodeSandbox](https://codesandbox.io/s/render-props-bd52r) and try to get a practical feel for working with the pattern.

Happy coding ❤️.

My all-in-one reference guide on render props in React, including how to implement render props, how to implement HOCs, and more.

react-logo-wide

All you need to know about React Render Props

So you want to publish a React component as a package to npm? This guide has all the information you need.

npm logo on red background

Publishing a React package to NPM

I’m writing this blog post on testing because it’s a topic I’m very comfortable with and I recently had a Eureka! moment and I want to document my growth in this area.

This is a question that has bugged me from the first time I wrote an integration test using Cypress. I had a vague understanding that integration and end to end tests interact with the app as a user would. But to what extent, I didn't know.

Cypress itself didn't really help matters with it being branded as an end to end testing tool but then using an `/integration` folder name in example tests. Is it an e2e or an integration test?

I think I can finally attempt to answer that question now 😄

## Integration tests

Integration tests are similar to end-to-end tests in one major way; they both test the app as a user would use it. Apart from that, they are pretty different from each other in what they assert and their overall scope with respect to the application.

Integration tests, in my opinion, should interact with the application from the perspective of a user but should not interact with the network layer, i.e, make a network request to fetch data.

Imagine a slider component built with React. Testing such a component using unit tests would probably result in very unreliable tests that don't say much about how it fits in with the app holistically.

Instead, you'd write a simple integration test that would interact with the slider just like a user would.

    Pause slider
    Click to next slide
    Swipe to next slide
    ...

You want to ensure that a user can perform the above actions in your applications and that they would see the correct thing every time and you probably don't need to make a network request to fetch content for the slider but you want to be able to assert that those actions are possible.

This is where a tool like Cypress then comes in. Because it has access to all layers of your application, it can stub out network requests and provide the data required for the slider component to function.

You can then interact with the slider component using mocked data. This allows the integration test to remain fast and lightweight while ensuring that your slider component works correctly in the context of your application.

To iterate, integration tests

- test small sections of the app at a time
- can bypass the network layer without losing integrity
- are usually faster

## End to end tests

Now imagine another scenario. You want to add search functionality to your blog.

When a user types in the search input box and hits enter they should see a list of results that match their query

Instead of testing an isolated section of your app, you're now testing for user flows and stories which may involve populating many smaller components with data and seeing if they can work together to complete the desired action.

Since your search functionality is probably a custom code, you also want to ensure that it meets business requirements. You should not stub this request because you really want to test your backend search API as well as your frontend rendering code. End. To. End.

Notice how we're involving multiple stacks and asserting that they can work together to satisfy the user story. Stubbing out the network layer would make it impossible to test a significant portion of the feature (the backend code that actually does the searching).

To iterate, end to end tests

- test user flows and whole features from end to end
- good e2e tests require the network layer to be useful
- are slower and expensive to run compared to integration tests

Can you now begin to see how integration and end to end tests operate at different scales? They are similar in a way but are concerned with proving different things.

## Conclusion

Both integration and e2e testing are essential in any significant application. Having one or the other may be sufficient in some cases but you can’t beat the robustness of having both in a project.

Having both classes of tests will enable you iterate much faster with little worry of breaking existing features and UX flows.


Learn how to differentiate between an integration test vs an end-to-end test. Inspired by real life eureka moments!

E2E vs Integration

Integration vs e2e testing

Hi and welcome to my little corner of the internet.

I believe the internet is the single greatest equaliser in the history of man so as you can imagine, I build stuff for it.

My work includes anything that can be accessed via the web like applications, marketing pages, or written content. Usability and efficiency are where I spend the most time when working.

Here are a few technologies I've been working with recently:

When I'm not working, I'm either walking my dog, listening to Yuval Harari, or just aimlessly browsing Reddit for funny photos.

I'm currently not looking for new opportunities but don't hesitate to get in touch about anything at all.

About me

If you want to reach out to me for consulting, technical writing, or just to chat about one of my articles, shoot me an email by clicking the big red button below

Want to reach me?

Where I've worked

I'm a frontend developer based in Utrecht, NL specialising in building (and occasionally breaking) highly dynamic websites, applications, and everything in between.

Hi, my name is

Ovie Okeh.

Your friendly neighbourhood developer

❖ About me

❖ Where I've worked

Product developer @ Sky UK

❖ You may be interested in this

Want to reach me?