Netlify Blog



<p>It&rsquo;s been a busy March at Netlify! Read about what we&rsquo;ve been up to in this re-publishing of our monthly newsletter. Want to receive updates like this in your inbox? Sign up for our mailing list here ⬇️</p>

<aside class="blog-newsletter-signup card">
  <h2>Sign up to our newsletter</h2>
  
  
  <form
  name="resource-newsletter"
  method="POST"
  action="/thanks-for-signing-up/"
  class="newsletter floating-labels"
  data-hubspot-form
  netlify>
  <input type="hidden" name="hubspotformid" value='52611e5e-cc55-4960-bf4a-a2adb36291f6' />
  <input type="hidden" name="hubspotutk" value="" data-hubspot-cookie-field />
  <p>Subscribe to our newsletter to make sure you don’t miss anything.</p>
  <p class="form-field">
    <label>
      <span class="label">
        Email address
      </span>
      <input name="email" type="email" required />
    </label>
  </p>
  <p class="form-footer">
    <button type="submit" class="button ">Subscribe</button>
  </p>
</form>

</aside>

<h2 id="news-next-js-on-netlify-integration-now-available">🌶 News: Next.js on Netlify integration now available</h2>

<p><img src="/img/blog/next-is_on_netlify.png" alt="Next.js on Netlify " /></p>

<p>Are you a Next.js user? We have <a href="https://www.netlify.com/press/netlify-announces-next-js-integration-enabling-next-js-10-for-enterprise-teams">news</a> for you! Netlify now auto-detects and enables Next.js apps with zero-configuration required, supporting features like preview mode, internationalized routing and server-side rendering (with Netlify Functions!). <a href="https://docs.netlify.com/configure-builds/common-configurations/next-js/">Get started with the docs for the Essential Next.js plugin on Netlify today</a>!</p>

<p><strong><a href="https://www.netlify.com/blog/2021/03/16/try-the-new-essential-next.js-plugin-now-with-auto-install/">Learn more</a></strong></p>

<h2 id="jamstack-quick-bites">🍩 Jamstack quick bites</h2>

<p>Some Jamstack articles we&rsquo;ve been snacking on:</p>

<ul>
<li><a href="https://www.netlify.com/blog/2021/03/08/incremental-static-regeneration-its-benefits-and-its-flaws/">Incremental Static Regeneration: Its Benefits and Its Flaws</a></li>
<li><a href="https://explorers.netlify.com/learn/angular-dynamic-data-with-sanity-io">New Jamstack Explorers Mission: Angular Dynamic Data with Sanity.io</a></li>
<li><a href="https://explorers.netlify.com/learn/building-a-lyric-blog-with-nuxt-js-and-strapi">New Jamstack Explorers Mission: Building a Lyric Blog with Nuxt.js and Strapi</a></li>
<li><a href="https://devjourney.info/Guests/140-MattBiilmann.html">Dev Journey podcast on the Jamstack and more with Netlify co-founder Matt Biilmann</a></li>
</ul>

<h2 id="linkable-log-better-team-collab">🔗 Linkable log = better team collab</h2>

<p><img src="/img/blog/linkable-logs-newsletter.png" alt="Netlify Linkable Logs" /></p>

<p>You can now create a shareable URL for a single deploy log line or range of lines, making it super easy to reference and share with team members. This handy feature was created in our company-wide hack day, because we build Netlify on Netlify, and are passionate about developer experience. ✨ <a href="https://docs.netlify.com/site-deploys/overview/#share-log-content">Check out the docs</a>.</p>

<p>Bonus: you can now pause and play Functions logs, making for a better debugging experience all around!</p>

<p><strong><a href="https://www.netlify.com/blog/2021/03/04/linkable-log-lines-now-available/">Learn more</a></strong></p>

<h2 id="more-product-updates">More Product Updates</h2>

<ul>
<li><a href="https://www.netlify.com/blog/2021/03/01/learn-how-netlify-redirects-give-you-control-over-cdn-level-routing/">Learn how Netlify Redirects give you control over CDN-level routing</a></li>
<li><a href="https://www.netlify.com/blog/2021/03/01/netlify-build-plugin-of-the-week-gatsby-cache-plugin/">Build Plugin: Gatsby Cache</a></li>
<li><a href="https://www.netlify.com/blog/2021/03/11/netlify-build-plugin-of-the-week-cypress/">Build Plugin: Cypress + a webinar to learn more</a></li>
<li><a href="https://www.netlify.com/blog/2021/03/03/shipping-node.js-at-netlify/">Shipping Node.js at Netlify</a></li>
</ul>

<h2 id="how-spring-migrated-from-a-monolith-to-microservices">📘 How Spring Migrated from a Monolith to Microservices</h2>

<p><img src="/img/blog/spring_case_study.png" alt="" /></p>

<p>Spring (formerly Teespring) is a massive e-commerce platform with more than 1 million unique visitors each day. They migrated from a monolithic Rails app to a microservices-based web architecture, and achieved vastly better developer experience, site performance and conversion rates. They also cut build times from 90 minutes to 1 minute using Netlify High-Performance Build.</p>

<p><strong><a href="https://www.netlify.com/blog/2021/03/08/spring-uses-netlify-to-scale-social-commerce-and-boost-conversion-for-creators/">Read the Case Study</a></strong></p>

<h2 id="join-us-at-an-upcoming-event">📅 Join us at an upcoming event</h2>

<ul>
<li>March 31: <a href="https://www.netlify.com/events/migrating-to-the-modern-web/">Migrating to the modern web</a></li>
<li>April 14: <a href="https://us.vuejs.org/">Vueconf US</a></li>
<li>April 14-16: <a href="https://remote.reactsummit.com/">React Summit</a></li>
<li>May 26: <a href="https://headlesscommercesummit.com/">Headless Commerce Summit</a></li>
<li>October 6-7: <a href="https://jamstackconf.com/">Jamstack Conf</a></li>
</ul>

<h2 id="welcome-new-netlify-customers">🥳 Welcome New Netlify Customers!</h2>

<p><img src="/img/blog/march_logos.png" alt="" /></p>

<p>We&rsquo;d like to extend a warm welcome to the latest companies who trust Netlify with their web infrastructure! Learn more about <a href="https://www.netlify.com/enterprise/">Netlify&rsquo;s enterprise products</a>.</p>


It’s been a busy March at Netlify! Read about what we’ve been up to in this re-publishing of our monthly newsletter. Want to receive updates like this in your inbox? Sign up for our mailing list here ⬇️
Sign up to our newsletter
Subscribe to our newsletter to make sure you don’t miss anything.
Subscribe
  
🌶 News: Next.js on Netlify integration now available

Are you a Next.js user? We have news for you! Netlify now auto-detects and enables Next.js apps with zero-configuration required, supporting features like preview mode, internationalized routing and server-side rendering (with Netlify Functions!). Get started with the docs for the Essential Next.js plugin on Netlify today!
Learn more
🍩 Jamstack quick bites
Some Jamstack articles we’ve been snacking on:
Incremental Static Regeneration: Its Benefits and Its Flaws
New Jamstack Explorers Mission: Angular Dynamic Data with Sanity.io
New Jamstack Explorers Mission: Building a Lyric Blog with Nuxt.js and Strapi
Dev Journey podcast on the Jamstack and more with Netlify co-founder Matt Biilmann
🔗 Linkable log = better team collab

You can now create a shareable URL for a single deploy log line or range of lines, making it super easy to reference and share with team members. This handy feature was created in our company-wide hack day, because we build Netlify on Netlify, and are passionate about developer experience. ✨ Check out the docs.
Bonus: you can now pause and play Functions logs, making for a better debugging experience all around!
Learn more
More Product Updates
Learn how Netlify Redirects give you control over CDN-level routing
Build Plugin: Gatsby Cache
Build Plugin: Cypress + a webinar to learn more
Shipping Node.js at Netlify
📘 How Spring Migrated from a Monolith to Microservices

Spring (formerly Teespring) is a massive e-commerce platform with more than 1 million unique visitors each day. They migrated from a monolithic Rails app to a microservices-based web architecture, and achieved vastly better developer experience, site performance and conversion rates. They also cut build times from 90 minutes to 1 minute using Netlify High-Performance Build.
Read the Case Study
📅 Join us at an upcoming event
March 31: Migrating to the modern web
April 14: Vueconf US
April 14-16: React Summit
May 26: Headless Commerce Summit
October 6-7: Jamstack Conf
🥳 Welcome New Netlify Customers!

We’d like to extend a warm welcome to the latest companies who trust Netlify with their web infrastructure! Learn more about Netlify’s enterprise products.

March Netlify Newsletter: Next.js on Netlify, Linkable Logs and more 



<p>The <a href="/blog/2016/07/26/our-conversion-from-angular-to-react/">React codebase</a> that powers <a href="https://app.netlify.com">app.netlify.com</a> is about five years old. During these five years, the focus has mostly been on high-speed growth, as most start-ups do. For this reason, what started with organised PostCSS gradually grew to become a complex and entangled global CSS architecture with a lot of specificity and overrides. As you might expect, there&rsquo;s a point where the added tech debt it introduces makes it difficult to keep shipping fast without adding any regressions. Besides, as the number of frontend developers contributing to the codebase also grows, this kind of CSS architecture becomes even more difficult to work with.</p>

<p>For this reason, in 2021, we are taking on the challenge of refactoring the entire Netlify UI codebase to utility CSS, using Tailwind.</p>

<p>This blog post is the first of a series that will cover our decisions, implementation strategy, technical difficulties, and things we learn along the way.</p>

<h2 id="initial-state-of-the-codebase">Initial state of the codebase</h2>

<p>Currently, our codebase contains about 35 different CSS files. Some of them contain the styles dedicated to parts of the UI (e.g. <code>navigation.css</code>), others seem to be dedicated to particular components (e.g. <code>Banner.css</code>) and others to more general elements (e.g. <code>animation.css</code>, <code>images.css</code>).</p>

<p>Maybe this would be ok if styles were truly encapsulated, but it&rsquo;s very difficult to keep things separated when using global CSS. Hence, the CSS file that is supposed to be dedicated to the alerts components also has styles for buttons and links within these alerts, and the CSS file dedicated to the settings components also has styles related to our cards components&hellip; you get the idea.</p>

<p>Why is this a problem? Because as the company, team and codebase grows, it&rsquo;s very difficult to know where things are, what classes should be used where, and people end up writing overrides over overrides, hacking CSS until it works. In the long run, this creates a real blocker to being able to ship fast and with confidence.</p>

<p>We started conversations about refactoring our CSS last year and spent a lot of time brainstorming different CSS frameworks to find the one that would match what we were looking for the most.</p>

<h2 id="benchmark-of-different-css-solutions">Benchmark of different CSS solutions</h2>

<p>To find the best solution to our problem, we first had to define what we actually wanted out of the tool. We were looking for something that could fit most of the following criteria:</p>

<ul>
<li>Human readable</li>
<li>Low specificity by default</li>
<li>Handles variations</li>
<li>Modular/Composable</li>
<li>Performant</li>
<li>Doesn&rsquo;t make naming hard</li>
<li>Allows safe refactoring</li>
<li>Extensible</li>
<li>Does not enforce bad markup patterns</li>
<li>Positive impact on developer velocity/productivity</li>
<li>Reasonable learning curve</li>
</ul>

<p>We compared these criteria to the following CSS methodologies: BEM (OOCSS), CSS modules, CSS-in-JS, and utility-first CSS with Tailwind.</p>

<p>Without going through our benchmark of all these tools, we ended up deciding on Tailwind for the following reasons:</p>

<p>✅ <strong>Human readable</strong>: Tailwind classes are pretty self-explanatory. For example, <code>text-black</code> sets the color of the text&hellip; to black. 🎉</p>

<p>✅ <strong>Low specificity by default</strong>: Utility CSS encourages a single class per style with a consistent, low specificity score.</p>

<p>✅ <strong>Handles variations</strong>: We can use component props to enforce consistent styling, like an <code>&lt;Alert&gt;</code> component that has variants for error, warning, and success states.</p>

<p>✅ <strong>Modular/Composable</strong>: Tailwind makes CSS styling really modular as each class does exactly one thing.</p>

<p>✅ <strong>Performant</strong>: Utility CSS removes the need to continually add more CSS to your bundle as your featureset and patterns grow. Tailwind also has PurgeCSS built in, making it easy to shed unused utilities and shrink file size in production.</p>

<p>✅ <strong>Doesn&rsquo;t make naming hard</strong>: With Tailwind, naming is unnecessary!</p>

<p>✅ <strong>Allows safe refactoring</strong>: We don&rsquo;t know if refactoring CSS ever feels &ldquo;safe,&rdquo; but using Tailwind means that styles become completely encapsulated to the element the style is applied to, so there is less fear of introducing regressions somewhere else in the codebase.</p>

<p>✅ <strong>Extensible</strong>: Configuring Tailwind to match custom design tokens is easy, and once set up, helps enforce visual consistency (no more one-off hex values or &ldquo;magic numbers&rdquo;!). Writing custom plugins can extend functionality even further.</p>

<p>✅ <strong>Does not enforce bad markup patterns</strong>: Utility classes can be applied to any element as needed! No more using <code>&lt;h2&gt;</code> where an <code>&lt;h3&gt;</code> is more semantically appropriate just to get those sweet <code>&lt;h2&gt;</code> styles.</p>

<p>✅ <strong>Impact on developer velocity/productivity</strong>: There might be a small impact at first while people learn how to use Tailwind, but once people are used to how the classes work, styling components becomes much faster!</p>

<p>✅ <strong>Learning curve</strong>: Configuring Tailwind is pretty straight forward and after trying out a few classes, the concept is rather the same no matter what class you add. Some complexity can appear if you need to add variants and build custom plugins.</p>

<p>Of course, if Tailwind was absolutely perfect and was solving every problem, most people would be using it. During our research, we found the following potential downfalls of using this framework.</p>

<p>👎🏻 Writing these long class names inline still feels a little weird and can make your markup hard to read both when you&rsquo;re developing and debugging in the devtools.</p>

<p>👎🏻 HTML weight increases: Adding this many class names bloats the HTML and increases its download size, which can have some impact on performance. However, we&rsquo;re gaining on speed by not downloading multiple stylesheets, and class names being repeated, the compressed file size over the wire is only negligibly affected.</p>

<p>👎🏻 Conditional styling is more difficult.</p>

<p>After setting on Tailwind, we started working on defining an implementation strategy.</p>

<h2 id="implementation-strategy">Implementation strategy</h2>

<p>An important thing we did not mention is that this complete refactoring has to be done alongside normal product work and responsibilities. As a result, thinking in advance about setting an efficient implementation strategy is the best way to make sure we do reach this goal.</p>

<h3 id="setting-milestones">Setting milestones</h3>

<p>We&rsquo;ve decided to set up some milestones, starting with the conversion of our components under the <code>ui</code> folder. These components are usually small and encapsulated, for example <code>Button</code>, <code>Link</code>, <code>Alert</code>, etc.</p>

<p>Focusing on these components allows us to start at the very core of our codebase. The issue with our global CSS is with the overrides that are often implemented when UI components are used inside different layouts with styles passed down from parent components. Therefore, starting the conversion with a bottom-up approach seems the simplest.</p>

<p>Besides, our <code>ui</code> folder is made of about 40 components, some of them already previously converted to Tailwind, so scoping our first milestone to this level makes it feel more feasible and easier to track.</p>

<p>On top of focusing on types of components to convert, this milestone also has a temporal dimension. The aim is to have all these components converted in four weeks.</p>

<p>Considering that the frontend guild is made of 10 engineers and, at the time of starting this initiative, there are currently 24 issues, it would be on average six components converted per week, to spread between 10 engineers, taking into account that some people might have more or less availability.</p>

<p>Looking at it this way, this milestone seems pretty feasible.</p>

<p>To track our progress, all these issues are on a specific project board on GitHub and a milestone was created and added to each issue. Not only does it make it easier to filter down issues specific to this milestone, but it also gives a little visual feedback of the progress.</p>

<p><img src="/img/blog/tailwind-conversion/milestone.jpg" alt="1st milestone for the project" /></p>

<p>This way, we can see how we&rsquo;re driving towards the goal, check how many issues were merged per week, and if needed, bring it up as a topic in our weekly sync to understand why we might be getting behind.</p>

<p>As this is the first time we are undertaking such big refactoring, the time part of the milestone is flexible. It is set to four weeks for this particular one, but as the amount of product work fluctuates, this deadline needs to be flexible too.</p>

<h3 id="visual-regression-tests">Visual regression tests</h3>

<p>When refactoring the entire CSS of an app, the risk of introducing visual regression bugs is pretty high. To help us catch these bugs early and provide some support when reviewing Tailwind-related PRs, we have set up <a href="https://percy.io/">Percy</a>, and more specifically, <a href="https://github.com/percy/percy-storybook">Percy in Storybook</a>.</p>

<p>For our first milestone, we&rsquo;ve updated our UI component&rsquo;s stories to generate a base snapshot so, as we convert our styles to Tailwind, if we do miss something and introduce regressions, it will fail our Percy tests.</p>

<p>Adding Percy does not completely remove the need to check changes manually, but we are hoping it can provide some support and speed up reviews.</p>

<h2 id="technical-difficulties-and-their-solutions">Technical difficulties and their solutions</h2>

<p>Before kicking off the initiative, we had a lot of questions to answer. Converting our codebase to Tailwind is unfortunately not as straight forward as replacing a class with a set of Tailwind classes.</p>

<p>Over time, our global CSS got pretty untangled so we started by identifying our current blockers, and thinking about the different scenarios where we needed more robust solutions.</p>

<p>Here are some examples:</p>

<h3 id="readability">Readability</h3>

<p>Tailwind classes can end up pretty long and make your code a bit less readable:</p>

<pre><code class="language-javascript">&lt;div class=&quot;tw-sr-only focus:tw-not-sr-only tw-bg-teal-darker tw-text-white tw-block tw-rounded-sm tw-p-1 tw-mt-5&quot;&gt;&lt;/div&gt;
</code></pre>

<p>We agreed on having a &ldquo;five classes&rdquo; rule where, if we happen to chain more than five utility classes, we extract them into a variable, format them to be more readable, and use a custom utility <a href="https://www.npmjs.com/package/@netlify/classnames-template-literals"><code>ctl</code></a> to remove whitespaces and new lines when classes are appended into the DOM.</p>

<pre><code class="language-javascript">import ctl from &quot;@netlify/classnames-template-literals&quot;;

const componentCN = ctl(`
  tw-sr-only
  focus:tw-not-sr-only
  tw-bg-teal-darker
  tw-text-white
  tw-block
  tw-rounded-sm
  tw-p-1
  tw-mt-5
`);

const Component = () =&gt; &lt;div className={componentCN}&gt;&lt;/div&gt;;

export default Component;
</code></pre>

<h3 id="dealing-with-visual-variants">Dealing with visual variants</h3>

<p>One of our concerns was around handling different variants of a component. For example, our Alert component has different styles based on the situation in which it is used. To combine standard styles and variants, we compose our class names using conditionals in template literals.</p>

<pre><code class="language-javascript">const AlertCN = ({ error, warning }) =&gt;
  ctl(`
	tw-relative
	tw-flex
	${error &amp;&amp;
    `
	  tw-bg-red-lightest
	  tw-text-red-darkest
	`}
	${warning &amp;&amp;
    `
	  tw-bg-red-lightest
	  tw-text-red-darkest
	`}
	...etc
`);

const Alert = props =&gt; {
  const { error, warning } = props;
  return &lt;div className={AlertCN({ error, warning })}&gt;...stuff&lt;/div&gt;;
};
</code></pre>

<p>Depending on the amount and complexity of the variants, we are also considering extracting them into their own separate components.</p>

<h3 id="overrides">Overrides</h3>

<p>As we are gradually converting our CSS, we will sometimes come across a situation where we cannot remove parts of our global CSS because it is used in different components, but we will need to override some properties inside the component we are currently converting. To handle this situation, we are going to use the <a href="https://github.com/chasegiunta/tailwindcss-important">tailwind-important utility</a>. It lets us prepend our classes with the <code>!</code> character to apply <code>!important</code>.</p>

<p>For example, in the code sample below, if we imagine that our global CSS sets the width of the <code>p</code> tag to <code>100%</code>, but in this particular case we need it to be <code>auto</code> for mobile, we would write it this way:</p>

<pre><code class="language-javascript">&lt;p className=&quot;!tw-w-auto md:tw-w-full&quot;&gt;Hello world&lt;/p&gt;
</code></pre>

<p>For this utility to work, you also need to add important in your <code>tailwind.config.js</code> file, for the property you want to target, here width.</p>

<pre><code class="language-javascript">alignItems: ['responsive', 'important'],
width: ['responsive', 'before', 'after', 'important']
</code></pre>

<p>Once we&rsquo;ve refactored to remove the highly-specific styles that made this approach necessary in the first place, we&rsquo;ll be able to remove the important utility altogether.</p>

<h3 id="layout-components">Layout components</h3>

<p>As we refactor our <code>ui</code> components to Tailwind, we have a unique opportunity to ensure our components are truly reusable in any context. Styles that impact layout outside of the component will be abstracted out so that we can encourage better component encapsulation.</p>

<p>To do this, we built a simple component called <code>&lt;Outset&gt;</code> to handle margins between <code>ui</code> components, so we can start removing those styles from the components themselves:</p>

<pre><code class="language-javascript">&lt;Outset top={4}&gt;
  &lt;Alert error /&gt;
&lt;/Outset&gt;
</code></pre>

<p>The <code>Outset</code> wrapper creates a dynamic Tailwind class based on the <code>top</code> value passed in (like <code>tw-mt-4</code>), and then adds that class name to any children inside it.</p>

<p>We decided to limit margin values in <code>Outset</code> to a consistent vertical direction (<code>top</code>) and consistent horizontal direction (<code>left</code>), in order to support consistent vertical rhythm without risk of collapsing margins. It also means we&rsquo;ll be able to safely remove components from the page without breaking any spacing in the layout!</p>

<h2 id="next-steps">Next steps</h2>

<p>Our next step will be creating layout components for common page-level patterns. This should empower us to build composable and consistent page layouts without copying and pasting fragile JSX patterns around the codebase.</p>

<p>Stay tuned!</p>


The React codebase that powers app.netlify.com is about five years old. During these five years, the focus has mostly been on high-speed growth, as most start-ups do. For this reason, what started with organised PostCSS gradually grew to become a complex and entangled global CSS architecture with a lot of specificity and overrides. As you might expect, there’s a point where the added tech debt it introduces makes it difficult to keep shipping fast without adding any regressions. Besides, as the number of frontend developers contributing to the codebase also grows, this kind of CSS architecture becomes even more difficult to work with.
For this reason, in 2021, we are taking on the challenge of refactoring the entire Netlify UI codebase to utility CSS, using Tailwind.
This blog post is the first of a series that will cover our decisions, implementation strategy, technical difficulties, and things we learn along the way.
Initial state of the codebase
Currently, our codebase contains about 35 different CSS files. Some of them contain the styles dedicated to parts of the UI (e.g. navigation.css), others seem to be dedicated to particular components (e.g. Banner.css) and others to more general elements (e.g. animation.css, images.css).
Maybe this would be ok if styles were truly encapsulated, but it’s very difficult to keep things separated when using global CSS. Hence, the CSS file that is supposed to be dedicated to the alerts components also has styles for buttons and links within these alerts, and the CSS file dedicated to the settings components also has styles related to our cards components… you get the idea.
Why is this a problem? Because as the company, team and codebase grows, it’s very difficult to know where things are, what classes should be used where, and people end up writing overrides over overrides, hacking CSS until it works. In the long run, this creates a real blocker to being able to ship fast and with confidence.
We started conversations about refactoring our CSS last year and spent a lot of time brainstorming different CSS frameworks to find the one that would match what we were looking for the most.
Benchmark of different CSS solutions
To find the best solution to our problem, we first had to define what we actually wanted out of the tool. We were looking for something that could fit most of the following criteria:
Human readable
Low specificity by default
Handles variations
Modular/Composable
Performant
Doesn’t make naming hard
Allows safe refactoring
Extensible
Does not enforce bad markup patterns
Positive impact on developer velocity/productivity
Reasonable learning curve
We compared these criteria to the following CSS methodologies: BEM (OOCSS), CSS modules, CSS-in-JS, and utility-first CSS with Tailwind.
Without going through our benchmark of all these tools, we ended up deciding on Tailwind for the following reasons:
✅ Human readable: Tailwind classes are pretty self-explanatory. For example, text-black sets the color of the text… to black. 🎉
✅ Low specificity by default: Utility CSS encourages a single class per style with a consistent, low specificity score.
✅ Handles variations: We can use component props to enforce consistent styling, like an <Alert> component that has variants for error, warning, and success states.
✅ Modular/Composable: Tailwind makes CSS styling really modular as each class does exactly one thing.
✅ Performant: Utility CSS removes the need to continually add more CSS to your bundle as your featureset and patterns grow. Tailwind also has PurgeCSS built in, making it easy to shed unused utilities and shrink file size in production.
✅ Doesn’t make naming hard: With Tailwind, naming is unnecessary!
✅ Allows safe refactoring: We don’t know if refactoring CSS ever feels “safe,” but using Tailwind means that styles become completely encapsulated to the element the style is applied to, so there is less fear of introducing regressions somewhere else in the codebase.
✅ Extensible: Configuring Tailwind to match custom design tokens is easy, and once set up, helps enforce visual consistency (no more one-off hex values or “magic numbers”!). Writing custom plugins can extend functionality even further.
✅ Does not enforce bad markup patterns: Utility classes can be applied to any element as needed! No more using <h2> where an <h3> is more semantically appropriate just to get those sweet <h2> styles.
✅ Impact on developer velocity/productivity: There might be a small impact at first while people learn how to use Tailwind, but once people are used to how the classes work, styling components becomes much faster!
✅ Learning curve: Configuring Tailwind is pretty straight forward and after trying out a few classes, the concept is rather the same no matter what class you add. Some complexity can appear if you need to add variants and build custom plugins.
Of course, if Tailwind was absolutely perfect and was solving every problem, most people would be using it. During our research, we found the following potential downfalls of using this framework.
👎🏻 Writing these long class names inline still feels a little weird and can make your markup hard to read both when you’re developing and debugging in the devtools.
👎🏻 HTML weight increases: Adding this many class names bloats the HTML and increases its download size, which can have some impact on performance. However, we’re gaining on speed by not downloading multiple stylesheets, and class names being repeated, the compressed file size over the wire is only negligibly affected.
👎🏻 Conditional styling is more difficult.
After setting on Tailwind, we started working on defining an implementation strategy.
Implementation strategy
An important thing we did not mention is that this complete refactoring has to be done alongside normal product work and responsibilities. As a result, thinking in advance about setting an efficient implementation strategy is the best way to make sure we do reach this goal.
Setting milestones
We’ve decided to set up some milestones, starting with the conversion of our components under the ui folder. These components are usually small and encapsulated, for example Button, Link, Alert, etc.
Focusing on these components allows us to start at the very core of our codebase. The issue with our global CSS is with the overrides that are often implemented when UI components are used inside different layouts with styles passed down from parent components. Therefore, starting the conversion with a bottom-up approach seems the simplest.
Besides, our ui folder is made of about 40 components, some of them already previously converted to Tailwind, so scoping our first milestone to this level makes it feel more feasible and easier to track.
On top of focusing on types of components to convert, this milestone also has a temporal dimension. The aim is to have all these components converted in four weeks.
Considering that the frontend guild is made of 10 engineers and, at the time of starting this initiative, there are currently 24 issues, it would be on average six components converted per week, to spread between 10 engineers, taking into account that some people might have more or less availability.
Looking at it this way, this milestone seems pretty feasible.
To track our progress, all these issues are on a specific project board on GitHub and a milestone was created and added to each issue. Not only does it make it easier to filter down issues specific to this milestone, but it also gives a little visual feedback of the progress.

This way, we can see how we’re driving towards the goal, check how many issues were merged per week, and if needed, bring it up as a topic in our weekly sync to understand why we might be getting behind.
As this is the first time we are undertaking such big refactoring, the time part of the milestone is flexible. It is set to four weeks for this particular one, but as the amount of product work fluctuates, this deadline needs to be flexible too.
Visual regression tests
When refactoring the entire CSS of an app, the risk of introducing visual regression bugs is pretty high. To help us catch these bugs early and provide some support when reviewing Tailwind-related PRs, we have set up Percy, and more specifically, Percy in Storybook.
For our first milestone, we’ve updated our UI component’s stories to generate a base snapshot so, as we convert our styles to Tailwind, if we do miss something and introduce regressions, it will fail our Percy tests.
Adding Percy does not completely remove the need to check changes manually, but we are hoping it can provide some support and speed up reviews.
Technical difficulties and their solutions
Before kicking off the initiative, we had a lot of questions to answer. Converting our codebase to Tailwind is unfortunately not as straight forward as replacing a class with a set of Tailwind classes.
Over time, our global CSS got pretty untangled so we started by identifying our current blockers, and thinking about the different scenarios where we needed more robust solutions.
Here are some examples:
Readability
Tailwind classes can end up pretty long and make your code a bit less readable:
<div class="tw-sr-only focus:tw-not-sr-only tw-bg-teal-darker tw-text-white tw-block tw-rounded-sm tw-p-1 tw-mt-5"></div>

We agreed on having a “five classes” rule where, if we happen to chain more than five utility classes, we extract them into a variable, format them to be more readable, and use a custom utility ctl to remove whitespaces and new lines when classes are appended into the DOM.
import ctl from "@netlify/classnames-template-literals";

const componentCN = ctl(`
  tw-sr-only
  focus:tw-not-sr-only
  tw-bg-teal-darker
  tw-text-white
  tw-block
  tw-rounded-sm
  tw-p-1
  tw-mt-5
`);

const Component = () => <div className={componentCN}></div>;

export default Component;

Dealing with visual variants
One of our concerns was around handling different variants of a component. For example, our Alert component has different styles based on the situation in which it is used. To combine standard styles and variants, we compose our class names using conditionals in template literals.
const AlertCN = ({ error, warning }) =>
  ctl(`
	tw-relative
	tw-flex
	${error &&
    `
	  tw-bg-red-lightest
	  tw-text-red-darkest
	`}
	${warning &&
    `
	  tw-bg-red-lightest
	  tw-text-red-darkest
	`}
	...etc
`);

const Alert = props => {
  const { error, warning } = props;
  return <div className={AlertCN({ error, warning })}>...stuff</div>;
};

Depending on the amount and complexity of the variants, we are also considering extracting them into their own separate components.
Overrides
As we are gradually converting our CSS, we will sometimes come across a situation where we cannot remove parts of our global CSS because it is used in different components, but we will need to override some properties inside the component we are currently converting. To handle this situation, we are going to use the tailwind-important utility. It lets us prepend our classes with the ! character to apply !important.
For example, in the code sample below, if we imagine that our global CSS sets the width of the p tag to 100%, but in this particular case we need it to be auto for mobile, we would write it this way:
<p className="!tw-w-auto md:tw-w-full">Hello world</p>

For this utility to work, you also need to add important in your tailwind.config.js file, for the property you want to target, here width.
alignItems: ['responsive', 'important'],
width: ['responsive', 'before', 'after', 'important']

Once we’ve refactored to remove the highly-specific styles that made this approach necessary in the first place, we’ll be able to remove the important utility altogether.
Layout components
As we refactor our ui components to Tailwind, we have a unique opportunity to ensure our components are truly reusable in any context. Styles that impact layout outside of the component will be abstracted out so that we can encourage better component encapsulation.
To do this, we built a simple component called <Outset> to handle margins between ui components, so we can start removing those styles from the components themselves:
<Outset top={4}>
  <Alert error />
</Outset>

The Outset wrapper creates a dynamic Tailwind class based on the top value passed in (like tw-mt-4), and then adds that class name to any children inside it.
We decided to limit margin values in Outset to a consistent vertical direction (top) and consistent horizontal direction (left), in order to support consistent vertical rhythm without risk of collapsing margins. It also means we’ll be able to safely remove components from the page without breaking any spacing in the layout!
Next steps
Our next step will be creating layout components for common page-level patterns. This should empower us to build composable and consistent page layouts without copying and pasting fragile JSX patterns around the codebase.
Stay tuned!

From semantic CSS to Tailwind - Refactoring the Netlify UI codebase

<p>Welcome to our series highlighting <a href="https://www.netlify.com/products/build/plugins/">Netlify Build Plugins</a>! Netlify Build Plugins are community-contributed scripts that can be used to perform all kinds of clever actions each time your site is built and deployed. They can automate workflows and tasks, manage notifications, and kick off events. This week, we’re highlighting the Inline Critical CSS plugin, contributed by Tom Bonnike, who is also an engineer at Shopify. The plugin extracts and inlines your critical above-the-fold CSS, and is built on top of the popular <a href="https://github.com/addyosmani/critical"><code>critical</code> package</a>.</p>

<p>If you’re using the Jamstack for <a href="https://www.netlify.com/products/edge/">speedy content delivery</a>, inlining critical CSS can make your content render even faster. Inlining the critical CSS directly into the HTML document eliminates additional requests and can be used to deliver a “one roundtrip” critical path where only the HTML is a blocking resource. You can use this plugin together with Bonnike’s <a href="http://app.netlify.com/plugins/netlify-plugin-inline-source/install">Inline Source plugin</a> to inline your other assets/sources such as small images, SVGs or render-blocking scripts.</p>

<p><img src="/img/blog/build-plugin-critical-css.png" alt="Netlify Build Plugin of the Week: Inline Critical CSS" /></p>

<p><strong>Plugin: Inline Critical CSS Netlify Build plugin</strong> <br>
Automatically extract and inline the critical CSS of your pages in order to render content to the user as fast as possible. <br>
<strong>By <a href="https://www.npmjs.com/package/netlify-plugin-inline-critical-css">Tom Bonnike</a></strong> <br>
<strong><a href="https://app.netlify.com/plugins/netlify-plugin-inline-critical-css/install">Install now</a></strong></p>

<p>And if you’re interested in learning more about <a href="https://www.netlify.com/products/build/plugins/">Netlify Build Plugins</a>, check out our <a href="https://app.netlify.com/plugins">directory of community plugins</a>, or learn how to <a href="https://docs.netlify.com/configure-builds/build-plugins/create-plugins/">create your own</a>.</p>


Welcome to our series highlighting Netlify Build Plugins! Netlify Build Plugins are community-contributed scripts that can be used to perform all kinds of clever actions each time your site is built and deployed. They can automate workflows and tasks, manage notifications, and kick off events. This week, we’re highlighting the Inline Critical CSS plugin, contributed by Tom Bonnike, who is also an engineer at Shopify. The plugin extracts and inlines your critical above-the-fold CSS, and is built on top of the popular critical package.
If you’re using the Jamstack for speedy content delivery, inlining critical CSS can make your content render even faster. Inlining the critical CSS directly into the HTML document eliminates additional requests and can be used to deliver a “one roundtrip” critical path where only the HTML is a blocking resource. You can use this plugin together with Bonnike’s Inline Source plugin to inline your other assets/sources such as small images, SVGs or render-blocking scripts.

Plugin: Inline Critical CSS Netlify Build plugin 
By Tom Bonnike 
Install now
And if you’re interested in learning more about Netlify Build Plugins, check out our directory of community plugins, or learn how to create your own.

Netlify Build Plugin of the Week: Inline Critical CSS



<p>At Netlify we’ve been expanding our adoption of Go-based services for the backend infrastructure that powers our core services. In this article, we explore a fault we encountered in a production service as we were scaling it to handle new traffic patterns. In particular, we uncovered some of the difficulties and concerns with using a CGO binding to a C++ implementation, but discovered better means to debug these failures more efficiently in the future.</p>

<h2 id="history-of-the-origin">History of the origin</h2>

<p>When a customer loads a Netlify site, their browser contacts one of many edge nodes in the <a href="https://www.netlify.com/products/edge/">Netlify Edge network</a>. If that node does not have a cached version of the content they are requesting, the edge node must make a request to the origin to serve it. Unlike a traditional CDN, Netlify maintains the origin for all site content.</p>

<p>To provide some context for the service we were working on, we need to take a short overview of how this origin service has evolved at Netlify.</p>

<p>The first version of Netlify was built as a Ruby on Rails application. Rails provided the ability to iterate quickly on early features as the Jamstack space was evolving. The team could focus on easing the friction for early Jamstack developers to ship sites quickly on the platform and less on complicated infrastructure.</p>

<p>One of the earlier features of Netlify was the <a href="https://docs.netlify.com/routing/redirects/">redirect and proxy</a> support. Redirects provide a number of features that can help when building sites, including:</p>

<ul>
<li>serving regional content based on different locales</li>
<li>easing the import/migration of sites by remapping content URLs to their new homes</li>
<li>facilitating fast iteration micro-site development models, where many smaller sites are stitched together under a single domain.</li>
</ul>

<p>Some sites make heavy use of redirects, upwards up 10k+ redirect rules for single sites. When content is requested for the first time from the origin we can evaluate thousands or more rules in a single request. The initial version of redirects was implemented in Ruby as part of the early Rails stack. As the site scaled, it proved too expensive and generated a lot of garbage that took overhead to collect in the Ruby VM. The team decided to move the most costly portions of the redirect rule matching engine into a C++ library, internally known as libredirect, and incorporate it into the app using the Ruby extensions API.</p>

<p>As the Jamstack model grew in popularity and the Netlify platform continued to scale, more processing was pushed to the edge. This included the need to process redirect rules at the edge, where most edge services were implemented as Go services. A <a href="https://golang.org/cmd/cgo/">CGO</a> binding to the same library was built so that redirect rules could be evaluated at the edge and maintain the same compatibility as those executed at the origin.</p>

<p>This brings us to the project we are working on today which will extract the remaining origin request path from our Rails application and move it to a set of Go service tiers. This work includes architecture changes to the storage systems backing origin, including moving to systems with better availability and scalability stories. We plan to cover this work in more depth in future articles here. A requirement for this work is handling the redirects processing still done at the origin and moving it to the new origin Go services. We took the same approach of adopting the CGO bindings that we use at the edge to ensure compatibility.</p>

<h2 id="testing-a-new-service">Testing a new service</h2>

<p>A goal we set for our new service was to build it out incrementally and handle delivering content for Netlify sites of increasing feature complexity. The <a href="https://launchdarkly.com/">LaunchDarkly</a> service has been an important part of our iterative approach as it has allowed us to dark launch new code paths and slowly increase the traffic exposed to them. Additionally, we execute requests against the original origin service alongside our new implementation. We verify in real-time if there are any differences in behavior and fallback to the original implementation. This provides us the necessary guardrails to ensure we don’t change the behavior for content requests.</p>

<p>During our rollout of the redirect parsing, we had scaled up to 60% of our target traffic when our monitoring systems notified us of high request latency. The log monitoring identified that our service pods were exiting with a segmentation fault and getting restarted. We used the <code>kubectl logs</code> command’s <code>--previous</code> flag to dump the full log data from the exited pods which neatly gave us a fault backtrace that resembled the following:</p>

<pre><code>fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x7f5a402cc2e0 pc=0x7f58b2677b16]

runtime stack:
runtime.throw(0x1501c59, 0x2a)
	/usr/local/go/src/runtime/panic.go:1116 +0x72
runtime.sigpanic()
	/usr/local/go/src/runtime/signal_unix.go:726 +0x4ac

goroutine 12655254 [syscall]:
runtime.cgocall(0x118b6d0, 0xc0007cddb0, 0xc000729000)
	/usr/local/go/src/runtime/cgocall.go:133 +0x5b fp=0xc0007cdd80 sp=0xc0007cdd48 pc=0x463cbb
github.com/netlify/libredirect/go._Cfunc_MatcherMatch(0x7f58402c2910, 0x7f5864cff240, 0x7f5864c69c90, 0x7f582ccceb30, 0x7f5864d08e00, 0x178ce000178cd, 0x0)
	_cgo_gotypes.go:387 +0x4e fp=0xc0007cddb0 sp=0xc0007cdd80 pc=0xf3cbee
github.com/netlify/libredirect/go.(*Matcher).Match.func4(0xc0007ce080, 0x7f5864cff240, 0x7f5864c69c90, 0x7f582ccceb30, 0x7f5864d08e00, 0x178cd, 0x178ce, 0x7f58882c32a0)
	/root/go/pkg/mod/github.com/netlify/libredirect@v1.1.5/go/redirector.go:204 +0x96 fp=0xc0007cde00 sp=0xc0007cddb0 pc=0xf3f856
github.com/netlify/libredirect/go.(*Matcher).Match(0xc0007ce080, 0x1784dc0, 0xc0009cc008, 0x0)
	/root/go/pkg/mod/github.com/netlify/libredirect@v1.1.5/go/redirector.go:204 +0x305 fp=0xc0007cded8 sp=0xc0007cde00 pc=0xf3dd05

</code></pre>

<p><em>1. Segfault crash backtrace</em></p>

<p>It was clear that the faults were coming from the libredirect library that we were invoking via the CGO bindings. At the report of high request latency, we disabled the feature flag and request latency returned to normal, and the pods stopped restarting. This clearly identified that the new code path we were testing was leading to the new segfault behavior.</p>

<h2 id="go-race-detector">Go race detector</h2>

<p>As part of this project, we had developed an exhaustive integration testing framework that modeled the multiple service tiers for serving origin content. After hitting the segfault in production, we adapted the framework to add a stress test that specifically exercised the request path we expected to be problematic in production. After tweaking some of the test parameters we were able to reproduce the same segfault we hit in production.</p>

<p>We initially suspected a race condition that impacted the data objects that the libredirect CGO bindings were accessing could be at fault here. Go tooling provides a <a href="https://blog.golang.org/race-detector">race detector</a> that can identify data races at runtime if you rebuild your code with the <code>-race</code> flag. We first checked if rerunning our unit test suite with the <code>-race</code> flag set would trigger any detected race conditions, but it came up empty. However, many of the tests used mocked interfaces, so we rebuilt the service with the <code>-race</code> flag and ran it through our stress test integration environment again. This confirmed the hypothesis that there was a race condition triggered in the redirects code path we were running in production. There&rsquo;s a difficult balance to strike when testing complex systems, swinging too far towards abstractions and mocked interfaces can mask race conditions that only present themselves under realistic workloads.</p>

<p>The team was able to quickly patch the conditions detected by the race detector, primarily by cloning the objects shared across the concurrent goroutine boundaries. A quick test showed that the changes did in fact fix the race conditions detected by the race detector during our stress test run. Unfortunately, continued stress testing of the service demonstrated we had not completely resolved the segfault.</p>

<h2 id="shared-pointers-and-go-finalizers">Shared pointers and Go finalizers</h2>

<p>Our attention then turned to the actual libredirect code and the CGO binding implementation. Something that stuck out to us was the use of the C++ <code>shared_ptr&lt;&gt;</code> or “<a href="https://docs.microsoft.com/en-us/cpp/cpp/smart-pointers-modern-cpp?view=msvc-160">smart pointers</a>”. The <code>shared_ptr</code> class maintains a reference counted pointer to an object and only when all references pass out of scope will the pointer be deallocated. In the case of this code, the pointer was pulled out of the shared_ptr and passed around externally, which can be dangerous as that can maintain a non-counted reference to the object. While we could not prove that the use, in this case, had the potential to crash, we thought it best to fix it to avoid future misuse.</p>

<p>To our surprise, when we reran our stress test with the shared_ptr change in place we found it difficult to hit the segfault again. In our initial stress tests, we would trip a segfault within 2-3 minutes, but now we were running the stress test much longer without an issue. However, after running the stress test for a much longer duration we were still able to periodically trip the segfault.</p>

<p>We next turned our focus to the use of the Go runtime package function <a href="https://golang.org/pkg/runtime/#SetFinalizer">SetFinalizer</a>. We were using this function to deallocate internal data structures of the C++ libredirect library when the reference in our CGO bindings was garbage collected. Without the use of a finalizer function, our libredirect data structures would be lost and lead to memory leaks. A closer look at how the finalizers had been setup provided a clue to the problem:</p>

<pre><code class="language-go">// (redirects.)Matcher (defined externally in libredirect)
type Matcher struct {
	b builder
}

func Parse(file string) redirects.Matcher {
	m := redirects.New()
	m.Parse(file)

	runtime.SetFinalizer(&amp;m, func(p *redirects.Matcher) {
		m.Free()
	})

	return m
}

func main() {
	m := Parse(&quot;/tmp/test.json&quot;)

	req := http.NewRequest(&quot;GET&quot;, &quot;/test&quot;, nil)
	m.Match(req)
}

</code></pre>

<p><em>2. Example code that segfaulted</em></p>

<p>To test our hypothesis, we added several repeated calls to <code>runtime.GC()</code> right after the return of the <code>Parse()</code> function and before the call to <code>Match</code>. When we rebuilt and reran our stress test against this change, the service crashed immediately.</p>

<p>The problem was that our libredirect library was returning a struct by copy and then we were returning another copy from our <code>Parse</code> routine. However, in the <code>Parse</code> routine, we were setting up a finalizer to run when the struct, allocated in <code>Parse</code>, left scope and was garbage collected. Since the struct was returned by copy, that struct was lost following the completion of the <code>Parse</code> routine. If we got unlucky and a GC cycle ran before we could call Match, or our stress test forced calls to <code>runtime.GC()</code>, the parsed redirect rules returned from libredirect would be deallocated before we had the chance to invoke the <code>Match()</code> method. If we made the simple change to simply return a reference from <code>Parse</code>, as seen below, it was enough to prevent the early deallocation of the libredirect object.</p>

<pre><code class="language-go">// (redirects.)Matcher (defined externally in libredirect)
type Matcher struct {
	b builder
}

func Parse(file string) *redirects.Matcher {
	m := redirects.New()
	m.Parse(file)

	runtime.SetFinalizer(&amp;m, func(p *redirects.Matcher) {
		m.Free()
	})

	return &amp;m
}

func main() {
	m := Parse(&quot;/tmp/test.json&quot;)

	req := http.NewRequest(&quot;GET&quot;, &quot;/test&quot;, nil)
	m.Match(req)
}

</code></pre>

<p><em>3. Same code with the fixed pointer return</em></p>

<p>We rebuilt and reran our test suites with this change applied. After extensive runs, we were unable to reproduce the original crash and deemed it safe to return to production. Since the final change was shipped to production and the feature flag was increased to 100%, we have not seen another segfault.</p>

<h2 id="gdb-backtrace-debugging">GDB backtrace debugging</h2>

<p>We were somewhat lucky in this scenario to be able to identify potentially problematic code and confirm it quickly in our test environment. The default backtrace stacks that Go prints on a segfault can make it difficult to debug particular issues, especially when using externally compiled code linked with CGO. We can see a call stack leading into CGO code, but not much past that point.</p>

<p>Had we been unable to reproduce this in our test environment or unable to stumble upon a fix, we would have used <a href="https://golang.org/doc/gdb">gdb</a> to debug a full crash dump. To enable Go to write a core dump instead of printing a backtrace, you can set <code>GOTRACEBACK=crash</code> at runtime. You can then open this core dump with gdb for better debugging.</p>

<h2 id="conclusion">Conclusion</h2>

<p>This production crash provided an opportunity to dive deeper into our CGO integration with the redirect library we use in several projects. During the debugging analysis, we identified several code improvements to the redirect library that will make it safer to use across projects. For example, all memory structures returned from the library now use pointer references to make it more difficult to set up a finalizer on an object that leaves scope before it is referenced. This change will be shipped to our Go services that run at the edge.</p>

<p>Finally, as part of our work to build <a href="https://www.netlify.com/products/edge/edge-handlers/">Netlify Edge Handlers</a>, we have built a Rust implementation of our redirect handling that we will incorporate into our Rust-based edge handler framework. This work will allow us to execute redirect rule parsing at the edge and eventually remove the need to process redirects closer to origin, thereby deprecating our C++ implementation.</p>

<p>If you found this article interesting and would like to help us build better systems, come <a href="https://www.netlify.com/careers/">join us</a>!</p>


At Netlify we’ve been expanding our adoption of Go-based services for the backend infrastructure that powers our core services. In this article, we explore a fault we encountered in a production service as we were scaling it to handle new traffic patterns. In particular, we uncovered some of the difficulties and concerns with using a CGO binding to a C++ implementation, but discovered better means to debug these failures more efficiently in the future.
History of the origin
When a customer loads a Netlify site, their browser contacts one of many edge nodes in the Netlify Edge network. If that node does not have a cached version of the content they are requesting, the edge node must make a request to the origin to serve it. Unlike a traditional CDN, Netlify maintains the origin for all site content.
To provide some context for the service we were working on, we need to take a short overview of how this origin service has evolved at Netlify.
The first version of Netlify was built as a Ruby on Rails application. Rails provided the ability to iterate quickly on early features as the Jamstack space was evolving. The team could focus on easing the friction for early Jamstack developers to ship sites quickly on the platform and less on complicated infrastructure.
One of the earlier features of Netlify was the redirect and proxy support. Redirects provide a number of features that can help when building sites, including:
serving regional content based on different locales
easing the import/migration of sites by remapping content URLs to their new homes
facilitating fast iteration micro-site development models, where many smaller sites are stitched together under a single domain.
Some sites make heavy use of redirects, upwards up 10k+ redirect rules for single sites. When content is requested for the first time from the origin we can evaluate thousands or more rules in a single request. The initial version of redirects was implemented in Ruby as part of the early Rails stack. As the site scaled, it proved too expensive and generated a lot of garbage that took overhead to collect in the Ruby VM. The team decided to move the most costly portions of the redirect rule matching engine into a C++ library, internally known as libredirect, and incorporate it into the app using the Ruby extensions API.
As the Jamstack model grew in popularity and the Netlify platform continued to scale, more processing was pushed to the edge. This included the need to process redirect rules at the edge, where most edge services were implemented as Go services. A CGO binding to the same library was built so that redirect rules could be evaluated at the edge and maintain the same compatibility as those executed at the origin.
This brings us to the project we are working on today which will extract the remaining origin request path from our Rails application and move it to a set of Go service tiers. This work includes architecture changes to the storage systems backing origin, including moving to systems with better availability and scalability stories. We plan to cover this work in more depth in future articles here. A requirement for this work is handling the redirects processing still done at the origin and moving it to the new origin Go services. We took the same approach of adopting the CGO bindings that we use at the edge to ensure compatibility.
Testing a new service
A goal we set for our new service was to build it out incrementally and handle delivering content for Netlify sites of increasing feature complexity. The LaunchDarkly service has been an important part of our iterative approach as it has allowed us to dark launch new code paths and slowly increase the traffic exposed to them. Additionally, we execute requests against the original origin service alongside our new implementation. We verify in real-time if there are any differences in behavior and fallback to the original implementation. This provides us the necessary guardrails to ensure we don’t change the behavior for content requests.
During our rollout of the redirect parsing, we had scaled up to 60% of our target traffic when our monitoring systems notified us of high request latency. The log monitoring identified that our service pods were exiting with a segmentation fault and getting restarted. We used the kubectl logs command’s --previous flag to dump the full log data from the exited pods which neatly gave us a fault backtrace that resembled the following:
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x7f5a402cc2e0 pc=0x7f58b2677b16]

runtime stack:
runtime.throw(0x1501c59, 0x2a)
	/usr/local/go/src/runtime/panic.go:1116 +0x72
runtime.sigpanic()
	/usr/local/go/src/runtime/signal_unix.go:726 +0x4ac

goroutine 12655254 [syscall]:
runtime.cgocall(0x118b6d0, 0xc0007cddb0, 0xc000729000)
	/usr/local/go/src/runtime/cgocall.go:133 +0x5b fp=0xc0007cdd80 sp=0xc0007cdd48 pc=0x463cbb
github.com/netlify/libredirect/go._Cfunc_MatcherMatch(0x7f58402c2910, 0x7f5864cff240, 0x7f5864c69c90, 0x7f582ccceb30, 0x7f5864d08e00, 0x178ce000178cd, 0x0)
	_cgo_gotypes.go:387 +0x4e fp=0xc0007cddb0 sp=0xc0007cdd80 pc=0xf3cbee
github.com/netlify/libredirect/go.(*Matcher).Match.func4(0xc0007ce080, 0x7f5864cff240, 0x7f5864c69c90, 0x7f582ccceb30, 0x7f5864d08e00, 0x178cd, 0x178ce, 0x7f58882c32a0)
	/root/go/pkg/mod/github.com/netlify/libredirect@v1.1.5/go/redirector.go:204 +0x96 fp=0xc0007cde00 sp=0xc0007cddb0 pc=0xf3f856
github.com/netlify/libredirect/go.(*Matcher).Match(0xc0007ce080, 0x1784dc0, 0xc0009cc008, 0x0)
	/root/go/pkg/mod/github.com/netlify/libredirect@v1.1.5/go/redirector.go:204 +0x305 fp=0xc0007cded8 sp=0xc0007cde00 pc=0xf3dd05


1. Segfault crash backtrace
It was clear that the faults were coming from the libredirect library that we were invoking via the CGO bindings. At the report of high request latency, we disabled the feature flag and request latency returned to normal, and the pods stopped restarting. This clearly identified that the new code path we were testing was leading to the new segfault behavior.
Go race detector
As part of this project, we had developed an exhaustive integration testing framework that modeled the multiple service tiers for serving origin content. After hitting the segfault in production, we adapted the framework to add a stress test that specifically exercised the request path we expected to be problematic in production. After tweaking some of the test parameters we were able to reproduce the same segfault we hit in production.
We initially suspected a race condition that impacted the data objects that the libredirect CGO bindings were accessing could be at fault here. Go tooling provides a race detector that can identify data races at runtime if you rebuild your code with the -race flag. We first checked if rerunning our unit test suite with the -race flag set would trigger any detected race conditions, but it came up empty. However, many of the tests used mocked interfaces, so we rebuilt the service with the -race flag and ran it through our stress test integration environment again. This confirmed the hypothesis that there was a race condition triggered in the redirects code path we were running in production. There’s a difficult balance to strike when testing complex systems, swinging too far towards abstractions and mocked interfaces can mask race conditions that only present themselves under realistic workloads.
The team was able to quickly patch the conditions detected by the race detector, primarily by cloning the objects shared across the concurrent goroutine boundaries. A quick test showed that the changes did in fact fix the race conditions detected by the race detector during our stress test run. Unfortunately, continued stress testing of the service demonstrated we had not completely resolved the segfault.
Shared pointers and Go finalizers
Our attention then turned to the actual libredirect code and the CGO binding implementation. Something that stuck out to us was the use of the C++ shared_ptr<> or “smart pointers”. The shared_ptr class maintains a reference counted pointer to an object and only when all references pass out of scope will the pointer be deallocated. In the case of this code, the pointer was pulled out of the shared_ptr and passed around externally, which can be dangerous as that can maintain a non-counted reference to the object. While we could not prove that the use, in this case, had the potential to crash, we thought it best to fix it to avoid future misuse.
To our surprise, when we reran our stress test with the shared_ptr change in place we found it difficult to hit the segfault again. In our initial stress tests, we would trip a segfault within 2-3 minutes, but now we were running the stress test much longer without an issue. However, after running the stress test for a much longer duration we were still able to periodically trip the segfault.
We next turned our focus to the use of the Go runtime package function SetFinalizer. We were using this function to deallocate internal data structures of the C++ libredirect library when the reference in our CGO bindings was garbage collected. Without the use of a finalizer function, our libredirect data structures would be lost and lead to memory leaks. A closer look at how the finalizers had been setup provided a clue to the problem:
// (redirects.)Matcher (defined externally in libredirect)
type Matcher struct {
	b builder
}

func Parse(file string) redirects.Matcher {
	m := redirects.New()
	m.Parse(file)

	runtime.SetFinalizer(&m, func(p *redirects.Matcher) {
		m.Free()
	})

	return m
}

func main() {
	m := Parse("/tmp/test.json")

	req := http.NewRequest("GET", "/test", nil)
	m.Match(req)
}


2. Example code that segfaulted
To test our hypothesis, we added several repeated calls to runtime.GC() right after the return of the Parse() function and before the call to Match. When we rebuilt and reran our stress test against this change, the service crashed immediately.
The problem was that our libredirect library was returning a struct by copy and then we were returning another copy from our Parse routine. However, in the Parse routine, we were setting up a finalizer to run when the struct, allocated in Parse, left scope and was garbage collected. Since the struct was returned by copy, that struct was lost following the completion of the Parse routine. If we got unlucky and a GC cycle ran before we could call Match, or our stress test forced calls to runtime.GC(), the parsed redirect rules returned from libredirect would be deallocated before we had the chance to invoke the Match() method. If we made the simple change to simply return a reference from Parse, as seen below, it was enough to prevent the early deallocation of the libredirect object.
// (redirects.)Matcher (defined externally in libredirect)
type Matcher struct {
	b builder
}

func Parse(file string) *redirects.Matcher {
	m := redirects.New()
	m.Parse(file)

	runtime.SetFinalizer(&m, func(p *redirects.Matcher) {
		m.Free()
	})

	return &m
}

func main() {
	m := Parse("/tmp/test.json")

	req := http.NewRequest("GET", "/test", nil)
	m.Match(req)
}


3. Same code with the fixed pointer return
We rebuilt and reran our test suites with this change applied. After extensive runs, we were unable to reproduce the original crash and deemed it safe to return to production. Since the final change was shipped to production and the feature flag was increased to 100%, we have not seen another segfault.
GDB backtrace debugging
We were somewhat lucky in this scenario to be able to identify potentially problematic code and confirm it quickly in our test environment. The default backtrace stacks that Go prints on a segfault can make it difficult to debug particular issues, especially when using externally compiled code linked with CGO. We can see a call stack leading into CGO code, but not much past that point.
Had we been unable to reproduce this in our test environment or unable to stumble upon a fix, we would have used gdb to debug a full crash dump. To enable Go to write a core dump instead of printing a backtrace, you can set GOTRACEBACK=crash at runtime. You can then open this core dump with gdb for better debugging.
Conclusion
This production crash provided an opportunity to dive deeper into our CGO integration with the redirect library we use in several projects. During the debugging analysis, we identified several code improvements to the redirect library that will make it safer to use across projects. For example, all memory structures returned from the library now use pointer references to make it more difficult to set up a finalizer on an object that leaves scope before it is referenced. This change will be shipped to our Go services that run at the edge.
Finally, as part of our work to build Netlify Edge Handlers, we have built a Rust implementation of our redirect handling that we will incorporate into our Rust-based edge handler framework. This work will allow us to execute redirect rule parsing at the edge and eventually remove the need to process redirects closer to origin, thereby deprecating our C++ implementation.
If you found this article interesting and would like to help us build better systems, come join us!

Tracking down a CGO crash in production



<p>When working with Vue 3&rsquo;s Composition API, a common question that often comes up when working with reactive data is: &ldquo;Should I use ref or reactive?&rdquo;</p>

<h2 id="quick-overview-of-ref">Quick Overview of <code>ref</code></h2>

<p><code>ref</code> is the fundamental building block for reactive data in Vue. As a result, it&rsquo;s the prerequisite for understanding what&rsquo;s going on and how things work.</p>

<p>At its simplest, when we want to define data that is reactive and will be watched by Vue, we can do it by importing the helper method and wrapping the desired value in it.</p>

<pre><code class="language-js">import { ref } from 'vue'

const firstName = ref('Ben')
const currentCount = ref(10)

return {
  firstName,
  currentCount
}
</code></pre>

<p>While this is a clean way to declare whether or not a variable contains reactive data or not, it comes with a few downsides:</p>

<ol>
<li>Requires people to learn the basics of JavaScript proxies</li>
<li>Requires you to unpack the value in some cases but not in others</li>
<li>Adds additional bulk to the code</li>
</ol>

<h3 id="the-need-to-understand-a-little-bit-about-javascript-proxies">The need to understand a little bit about JavaScript Proxies</h3>

<p>The thing about <code>ref</code> is that whenever you want to refer to the value of the reactive data, you need to be aware of the fact that it will utilize JavaScript Proxies to facilitate the reactivity.</p>

<p>In other words, it has some special properties you must be aware of. Specifically, when you want to refer to the value of a <code>ref</code>, you must unpack it by calling <code>.value</code>.</p>

<pre><code class="language-js">// Will not give the expected result
const wrongHeroName = computed(() =&gt; {
 return firstName + ' ' + currentCount
})

// Need to access values in order to use them properly
const heroName = computed(() =&gt; {
  return firstName.value + ' ' + currentCount.value
})
</code></pre>

<h3 id="you-need-to-unpack-the-value-in-some-cases-but-not-others">You need to unpack the value in some cases, but not others</h3>

<p>This may not seem like a massive inconvenience at first, but it can introduce friction as a learning concept since it&rsquo;s not always clear when it should be used.</p>

<p>For example, while you need to unpack values manually inside of the script block, once it is returned to the template, you no longer need to unwrap it because Vue will do this for you.</p>

<pre><code class="language-html">&lt;script&gt;
import { ref } from 'vue'

export default {
  setup() {
    const heroName = ref('Taco Launcher')

    return {
      heroName
    }
  }
}
&lt;/script&gt;

&lt;template&gt;
  &lt;p&gt;Wrong: {{ heroName.value }}&lt;/p&gt;
  &lt;p&gt;Correct: {{ heroName }}&lt;/p&gt;
&lt;/template&gt;
</code></pre>

<h3 id="it-can-add-more-bulk-to-the-code">It can add more bulk to the code</h3>

<p>Also, for each additional <code>ref</code> that you need to expose to the template, you need to manually specify it inside the returned object at the end of your setup function.</p>

<pre><code class="language-js">import { ref } from 'vue'

const firstName = ref('Ben')
const currentCount = ref(10)
const isTransformed = ref(false)
const powers = ref([])

return {
  firstName,
  currentCount,
  isTransformed,
  powers
}
</code></pre>

<h2 id="quick-overview-of-reactive">Quick Overview of <code>reactive</code></h2>

<p>On the other hand, <code>reactive</code> as a helper method is much closer to what many Vue developers are already familiar with: the <code>data</code> option.</p>

<p>In Options API, we would define our code as the following:</p>

<pre><code class="language-js">&lt;script&gt;
export default {
  data: () =&gt; ({
    firstName: 'Ben',
    currentCount: 10,
  }),
  computed: {
    heroName() {
      return this.firstName + ' ' + this.currentCount
    }
  }
}
&lt;/script&gt;
</code></pre>

<p>With the <code>reactive</code> helper method, we can refactor the <code>data</code> option into:</p>

<pre><code class="language-js">&lt;script&gt;
import { ref } from 'vue'

export default {
  setup() {
    const state = reactive({
      firstName: 'Ben',
      currentCount: 10
    })

    return {
      state
    }
  },
  computed: {
    heroName() {
      return this.firstName + ' ' + this.currentCount
    }
  }
}
&lt;/script&gt;
</code></pre>

<pre><code class="language-html">&lt;template&gt;
  &lt;h1&gt;{{ heroName }}&lt;/h1&gt;
  &lt;p&gt;First Name: {{ state.firstName }}&lt;/p&gt;
  &lt;p&gt;Current Count: {{ state.currentCount }}&lt;/p&gt;
&lt;/template&gt;
</code></pre>

<p>And then, unlike <code>ref</code>, we don&rsquo;t have to worry about unpacking any values! You refer to the property as you would expect, without the need to call <code>.value</code>. So we can refactor the computed property into the following:</p>

<pre><code class="language-js">&lt;script&gt;
import { computed, ref } from 'vue'

export default {
  setup() {
    const state = reactive({
      firstName: 'Ben',
      currentCount: 10
    })

    const heroName = computed(() =&gt; {
      return state.firstName + ' ' + state.currentCount
    })

    return {
      state,
      heroName
    }
  }
}
&lt;/script&gt;
</code></pre>

<p>And then to top it off, we can utilize a helper method called <code>toRefs</code> to minimize the amount of boilerplate code we would ordinarily write with <code>ref</code>, while also removing the prefix of <code>state</code>!</p>

<pre><code class="language-js">&lt;script&gt;
import { computed, ref, toRefs } from 'vue'

export default {
  setup() {
    const state = reactive({
      firstName: 'Ben',
      currentCount: 10
    })

    const heroName = computed(() =&gt; {
      return state.firstName + ' ' + state.currentCount
    })

    return {
      ...toRefs(state),
      heroName
    }
  }
}
&lt;/script&gt;
</code></pre>

<pre><code class="language-html">&lt;template&gt;
  &lt;h1&gt;{{ heroName }}&lt;/h1&gt;
  &lt;p&gt;First Name: {{ firstName }}&lt;/p&gt;
  &lt;p&gt;Current Count: {{ currentCount }}&lt;/p&gt;
&lt;/template&gt;
</code></pre>

<p>But like any solution, <code>reactive</code> is not without its downside. Because <code>reactive</code> is built upon the concept of <code>ref</code>, there is a little bit of a circular dependency in that you need to understand <code>ref</code> to leverage <code>reactive</code> without being too confused.</p>

<h2 id="verdict-use-reactive">Verdict: Use <code>reactive</code></h2>

<p>At the end of the day, I recommend using <code>reactive</code> as the primary way to manage reactive data in Vue 3&rsquo;s Composition API. By doing so, it allows us to leverage what developers are already familiar with. And to top it off, it also has the benefit of being more intuitive than <code>ref</code>, which requires more in-depth JavaScript knowledge to use.</p>

<p>That said, are there still use cases for using <code>ref</code>? Absolutely! It&rsquo;s just that when it comes to choosing one to primarily stick to, <code>reactive</code> is the way to go.</p>

<p>For additional resources on Vue 3&rsquo;s Composition API, be sure to check out these resources:</p>

<ul>
<li><a href="https://explorers.netlify.com/learn/launching-with-composition-api/composition-api-reactive-data?utm_campaign=devex-bh&amp;utm_source=twitter&amp;utm_medium=social&amp;utm_content=exploreres-comp-api-reactive-data">Free lesson on reactive data with Composition API Jamstack Explorers</a></li>
<li><a href="https://explorers.netlify.com/learn/launching-with-composition-api?utm_campaign=devex-bh&amp;utm_source=twitter&amp;utm_medium=social&amp;utm_content=explorers-comp-api-mission">Free course on Vue 3&rsquo;s Composition API</a></li>
</ul>


When working with Vue 3’s Composition API, a common question that often comes up when working with reactive data is: “Should I use ref or reactive?”
Quick Overview of ref
ref is the fundamental building block for reactive data in Vue. As a result, it’s the prerequisite for understanding what’s going on and how things work.
At its simplest, when we want to define data that is reactive and will be watched by Vue, we can do it by importing the helper method and wrapping the desired value in it.
import { ref } from 'vue'

const firstName = ref('Ben')
const currentCount = ref(10)

return {
  firstName,
  currentCount
}

While this is a clean way to declare whether or not a variable contains reactive data or not, it comes with a few downsides:
Requires people to learn the basics of JavaScript proxies
Requires you to unpack the value in some cases but not in others
Adds additional bulk to the code
The need to understand a little bit about JavaScript Proxies
The thing about ref is that whenever you want to refer to the value of the reactive data, you need to be aware of the fact that it will utilize JavaScript Proxies to facilitate the reactivity.
In other words, it has some special properties you must be aware of. Specifically, when you want to refer to the value of a ref, you must unpack it by calling .value.
// Will not give the expected result
const wrongHeroName = computed(() => {
 return firstName + ' ' + currentCount
})

// Need to access values in order to use them properly
const heroName = computed(() => {
  return firstName.value + ' ' + currentCount.value
})

You need to unpack the value in some cases, but not others
This may not seem like a massive inconvenience at first, but it can introduce friction as a learning concept since it’s not always clear when it should be used.
For example, while you need to unpack values manually inside of the script block, once it is returned to the template, you no longer need to unwrap it because Vue will do this for you.
<script>
import { ref } from 'vue'

export default {
  setup() {
    const heroName = ref('Taco Launcher')

    return {
      heroName
    }
  }
}
</script>

<template>
  <p>Wrong: {{ heroName.value }}</p>
  <p>Correct: {{ heroName }}</p>
</template>

It can add more bulk to the code
Also, for each additional ref that you need to expose to the template, you need to manually specify it inside the returned object at the end of your setup function.
import { ref } from 'vue'

const firstName = ref('Ben')
const currentCount = ref(10)
const isTransformed = ref(false)
const powers = ref([])

return {
  firstName,
  currentCount,
  isTransformed,
  powers
}

Quick Overview of reactive
On the other hand, reactive as a helper method is much closer to what many Vue developers are already familiar with: the data option.
In Options API, we would define our code as the following:
<script>
export default {
  data: () => ({
    firstName: 'Ben',
    currentCount: 10,
  }),
  computed: {
    heroName() {
      return this.firstName + ' ' + this.currentCount
    }
  }
}
</script>

With the reactive helper method, we can refactor the data option into:
<script>
import { ref } from 'vue'

export default {
  setup() {
    const state = reactive({
      firstName: 'Ben',
      currentCount: 10
    })

    return {
      state
    }
  },
  computed: {
    heroName() {
      return this.firstName + ' ' + this.currentCount
    }
  }
}
</script>

<template>
  <h1>{{ heroName }}</h1>
  <p>First Name: {{ state.firstName }}</p>
  <p>Current Count: {{ state.currentCount }}</p>
</template>

And then, unlike ref, we don’t have to worry about unpacking any values! You refer to the property as you would expect, without the need to call .value. So we can refactor the computed property into the following:
<script>
import { computed, ref } from 'vue'

export default {
  setup() {
    const state = reactive({
      firstName: 'Ben',
      currentCount: 10
    })

    const heroName = computed(() => {
      return state.firstName + ' ' + state.currentCount
    })

    return {
      state,
      heroName
    }
  }
}
</script>

And then to top it off, we can utilize a helper method called toRefs to minimize the amount of boilerplate code we would ordinarily write with ref, while also removing the prefix of state!
<script>
import { computed, ref, toRefs } from 'vue'

export default {
  setup() {
    const state = reactive({
      firstName: 'Ben',
      currentCount: 10
    })

    const heroName = computed(() => {
      return state.firstName + ' ' + state.currentCount
    })

    return {
      ...toRefs(state),
      heroName
    }
  }
}
</script>

<template>
  <h1>{{ heroName }}</h1>
  <p>First Name: {{ firstName }}</p>
  <p>Current Count: {{ currentCount }}</p>
</template>

But like any solution, reactive is not without its downside. Because reactive is built upon the concept of ref, there is a little bit of a circular dependency in that you need to understand ref to leverage reactive without being too confused.
Verdict: Use reactive
At the end of the day, I recommend using reactive as the primary way to manage reactive data in Vue 3’s Composition API. By doing so, it allows us to leverage what developers are already familiar with. And to top it off, it also has the benefit of being more intuitive than ref, which requires more in-depth JavaScript knowledge to use.
That said, are there still use cases for using ref? Absolutely! It’s just that when it comes to choosing one to primarily stick to, reactive is the way to go.
For additional resources on Vue 3’s Composition API, be sure to check out these resources:
Free lesson on reactive data with Composition API Jamstack Explorers
Free course on Vue 3’s Composition API

Choosing Between Ref and Reactive with Vue 3's Composition API



<p>Chances are, if you&rsquo;ve used Next.js on Netlify, you&rsquo;ve encountered either the <code>next-on-netlify</code> npm package, or the Next.js Build Plugin to enable some of its Node-driven features.</p>

<p>Today, we&rsquo;re happy to announce that the two have become one, to form the <strong>Essential Next.js Plugin</strong>!</p>

<p>With this plugin, you enable features like:</p>

<ul>
<li>Support for <code>getServerSideProps</code> and <code>getStaticProps</code> with fallbacks (via <a href="https://www.netlify.com/products/functions/?utm_source=blog&amp;utm_medium=functionsnext-cs&amp;utm_campaign=devex-cs">Netlify Functions</a>)</li>
<li>Preview Mode</li>
<li>Internationalized Routing</li>
<li><a href="https://www.netlify.com/blog/2021/03/08/incremental-static-regeneration-its-benefits-and-its-flaws/?utm_source=blog&amp;utm_medium=isrnext-cs&amp;utm_campaign=devex-cs">Incremental Static Regeneration</a></li>
<li>and more!</li>
</ul>

<p>And, that&rsquo;s not all, we now <em>auto-detect</em> when you use Next.js on Netlify, so <strong>you don&rsquo;t have to manually install anything</strong> to get all of the features you love in Next.js working on the platform.</p>

<h2 id="what-do-i-do-next">What do I do next?</h2>

<p>Ha! That&rsquo;s a pun.
What does this mean for you if you already use the old version of the plugin, or the <code>next-on-netlify</code> package? Technically, you don&rsquo;t have to do anything, this won&rsquo;t break your current projects. But, if you want to use the latest and greatest changes:</p>

<ul>
<li>You can go ahead and uninstall the package, and remove it from your netlify.toml.</li>
<li>If you have a <code>next.config.json</code>, make sure to set <code>target: &quot;serverless&quot;</code>, but if you don&rsquo;t have anything else in that file, you can remove it.</li>
<li>Install the new plugin either in the UI or <a href="https://github.com/netlify/netlify-plugin-nextjs#installation-and-configuration">manually in your netlify.toml</a>:</li>
</ul>

<p><img src="/img/blog/essentialnext.png" alt="Install the Essential Next.js plugin" title="Install the Essential Next.js plugin" /></p>

<p>For a new site deployed with Next.js, Netlify will automatically install this plugin.</p>

<p>This means that <strong>you don&rsquo;t have to do anything</strong> — just build and deploy your site to Netlify as usual and we&rsquo;ll handle the rest.</p>

<p>If you&rsquo;d like to learn more or get involved:</p>

<ul>
<li><a href="https://docs.netlify.com/configure-builds/common-configurations/next-js/">Check out the docs</a> if you need more guidance.</li>
<li><a href="https://github.com/netlify/netlify-plugin-nextjs">File any issues you see on the plugin repo</a>, or make a PR if you see improvements that can be made!</li>
<li>Got a business using Next.js? <a href="https://www.netlify.com/press/netlify-announces-next-js-integration-enabling-next-js-10-for-enterprise-teams/?utm_source=blog&amp;utm_medium=press-cs&amp;utm_campaign=devex-cs">Check out our press release</a> for more information about how our collaboration and security tools can make your apps even better.</li>
</ul>

<p>You can get started with a new Next.js project here!</p>

<p><a href="https://app.netlify.com/start/deploy?repository=https://github.com/cassidoo/next-netlify-starter&amp;utm_source=blog&amp;utm_medium=nextstarter-cs&amp;utm_campaign=devex-cs"><img src="https://www.netlify.com/img/deploy/button.svg" alt="Deploy to Netlify" /></a></p>

<p>(Clicking this button will clone a starter repo to your Git provider of choice, and deploy it instantly to Netlify)</p>


Chances are, if you’ve used Next.js on Netlify, you’ve encountered either the next-on-netlify npm package, or the Next.js Build Plugin to enable some of its Node-driven features.
Today, we’re happy to announce that the two have become one, to form the Essential Next.js Plugin!
With this plugin, you enable features like:
Support for getServerSideProps and getStaticProps with fallbacks (via Netlify Functions)
Preview Mode
Internationalized Routing
Incremental Static Regeneration
and more!
And, that’s not all, we now auto-detect when you use Next.js on Netlify, so you don’t have to manually install anything to get all of the features you love in Next.js working on the platform.
What do I do next?
Ha! That’s a pun.
What does this mean for you if you already use the old version of the plugin, or the next-on-netlify package? Technically, you don’t have to do anything, this won’t break your current projects. But, if you want to use the latest and greatest changes:
You can go ahead and uninstall the package, and remove it from your netlify.toml.
If you have a next.config.json, make sure to set target: "serverless", but if you don’t have anything else in that file, you can remove it.
Install the new plugin either in the UI or manually in your netlify.toml:

For a new site deployed with Next.js, Netlify will automatically install this plugin.
This means that you don’t have to do anything — just build and deploy your site to Netlify as usual and we’ll handle the rest.
If you’d like to learn more or get involved:
Check out the docs if you need more guidance.
File any issues you see on the plugin repo, or make a PR if you see improvements that can be made!
Got a business using Next.js? Check out our press release for more information about how our collaboration and security tools can make your apps even better.
You can get started with a new Next.js project here!

(Clicking this button will clone a starter repo to your Git provider of choice, and deploy it instantly to Netlify)

Try the new Essential Next.js plugin, now with auto-install!

<p>Welcome to our series highlighting <a href="https://www.netlify.com/products/build/plugins/">Netlify Build Plugins</a>! This week, we’re featuring a Build Plugin created by one of our partners: <a href="https://www.cypress.io/">Cypress</a>. Cypress is an end-to-end testing tool for any frontend framework or website. It makes setting up, writing, running, and debugging tests easy. We love that it’s an all-in-one tool, which means there’s no need to install 10 or more separate tools and libraries to get your test suite setup.</p>

<p>And with the Cypress Netlify Build Plugin, you can streamline your workflow even <em>further</em>. With a one-click install in Netlify’s UI, the plugin runs an end-to-end Cypress test with each Netlify build, so you can ship with confidence without sacrificing efficiency.</p>

<p><img src="/img/blog/cypress-netlify-inline.png" alt="cypress-netlify-plugin" /></p>

<p><strong>Plugin</strong>: Cypress Netlify Build plugin <br>Runs Cypress end-to-end tests after Netlify builds the site <br>
<strong>By <a href="https://github.com/bahmutov">Gleb Bahmutov</a></strong> <br>
<strong><a href="http://app.netlify.com/plugins/netlify-plugin-cypress/install">Install now</a></strong></p>

<blockquote>
<p>“Developers love how simple and powerful Netlify is for Continuous Delivery (CD) and hosting. Netlify Build Plugins make that workflow even more powerful. We created a plugin that runs an end-to-end Cypress test at every build. Now anyone can enable this plugin with a click in Netlify’s UI, ensuring quality and confidence with each deploy.”</p>

<p>- <a href="https://www.netlify.com/press/netlify-opens-build-layer-to-powerful-community-plugins-that-automate-developer-workflows-and-optimize-site-performance/">Gleb Bahmutov, Cypress.io</a>.</p>
</blockquote>

<p>Got questions about the Cypress plugin? Netlify’s own Jason Lengstorf is chatting with the author of the plugin, Cypress engineer Gleb Bahmutov, on Thursday, March 18. <strong><a href="https://go.cypress.io/netlify-webcast-registration?utm_source=Netlify&amp;utm_medium=web&amp;utm_campaign=Netlify_Webcast">Register for the webinar</a></strong> to ask your questions live. And if you’re interested in learning more about <a href="https://www.netlify.com/products/build/plugins/">Netlify Build Plugins</a>, check out our <a href="https://app.netlify.com/plugins">directory of community plugins</a>, or learn how to <a href="https://docs.netlify.com/configure-builds/build-plugins/create-plugins/">create your own</a>.</p>


Welcome to our series highlighting Netlify Build Plugins! This week, we’re featuring a Build Plugin created by one of our partners: Cypress. Cypress is an end-to-end testing tool for any frontend framework or website. It makes setting up, writing, running, and debugging tests easy. We love that it’s an all-in-one tool, which means there’s no need to install 10 or more separate tools and libraries to get your test suite setup.
And with the Cypress Netlify Build Plugin, you can streamline your workflow even further. With a one-click install in Netlify’s UI, the plugin runs an end-to-end Cypress test with each Netlify build, so you can ship with confidence without sacrificing efficiency.

Plugin: Cypress Netlify Build plugin 
Runs Cypress end-to-end tests after Netlify builds the site 
By Gleb Bahmutov 
Install now
“Developers love how simple and powerful Netlify is for Continuous Delivery (CD) and hosting. Netlify Build Plugins make that workflow even more powerful. We created a plugin that runs an end-to-end Cypress test at every build. Now anyone can enable this plugin with a click in Netlify’s UI, ensuring quality and confidence with each deploy.”
- Gleb Bahmutov, Cypress.io.
Got questions about the Cypress plugin? Netlify’s own Jason Lengstorf is chatting with the author of the plugin, Cypress engineer Gleb Bahmutov, on Thursday, March 18. Register for the webinar to ask your questions live. And if you’re interested in learning more about Netlify Build Plugins, check out our directory of community plugins, or learn how to create your own.

Netlify Build Plugin of the Week: Cypress



<p>Right now there are a lot of hot takes out there about how to improve and scale sites &ldquo;beyond Jamstack&rdquo; by adding in features that use a Node server. One of those features is called Incremental Static Regeneration.</p>

<p>Some people call it &ldquo;hybrid web development&rdquo; (or &ldquo;hybrid serverless + static&rdquo;) but let&rsquo;s talk a bit more about what that means.</p>

<h2 id="what-happens-when-you-deploy-a-jamstack-project">What happens when you deploy a Jamstack project</h2>

<p>First of all, we should talk about what happens when you build Jamstack sites, and how atomic and immutable deploys work. These are fundamental principles to understand for this style of web development.</p>

<p><strong>Atomic deployment</strong> means all of the code, assets, and configuration of a site are updated together at the same time. This means that a website cannot be served in a partially updated state.
<strong>Immutable deployment</strong> insulates deploys from future actions, guaranteeing their integrity. This means there is always a stable copy of this deploy that can be referenced or re-deployed at any state in the future.</p>

<p>(You can read more about these terms in <a href="https://www.netlify.com/blog/2021/02/23/terminology-explained-atomic-and-immutable-deploys/?utm_campaign=devex-cs&amp;utm_source=blog&amp;utm_content=isratomic">this blog post</a>)</p>

<p>You can almost think of this as state-driven development. Every single deploy is a new state of your application or site.</p>

<p><img src="/img/blog/atomic-star.gif" alt="Atomic deploys, the latest deploy is the live deploy" title="Atomic deploys, the latest deploy is the live deploy" /></p>

<p>If you were to make a mistake on your site, let&rsquo;s say you broke prod, you deployed the wrong brand colors, or you mixed up some copy, you can <a href="https://docs.netlify.com/site-deploys/manage-deploys/#rollbacks">instantly rollback</a> to a previous deploy without having to wait for a new build, because that version of your site exists in space. It&rsquo;s why it works so well with Git, it&rsquo;s similar to reverting a commit.</p>

<p><img src="/img/blog/rollback-star.gif" alt="Instant rollbacks mean you can choose any built deploy to go live at any time" title="Instant rollbacks mean you can choose any built deploy to go live at any time" /></p>

<p>I won&rsquo;t get into the details of the perks of pre-rendering all of your pages, but if you&rsquo;d like to read more about that, you can check out more information on <a href="https://jamstack.org/what-is-jamstack/">Jamstack.org</a>.</p>

<h2 id="incremental-static-regeneration">Incremental Static Regeneration</h2>

<p>Incremental Static Regeneration, or ISR, seeks to extend the power of static sites by adding some server-side rendering (SSR) goodies on top.</p>

<h3 id="how-it-works-and-why-it-s-cool">How it works and why it&rsquo;s cool</h3>

<p>When you deploy a site with ISR enabled, you deploy a (mostly) static site. You have your pre-defined static pages that were built, and you have routes on your application that aren&rsquo;t built until your users hit those pages.</p>

<p>Typically when you have a server-side rendered (SSR) page that is one of these unbuilt pages, your users have to wait for the page to be built and served all at once. But in the case of ISR, if your users hit that route, they get a <em>fallback page</em>. A fallback page is a placeholder for the actual content that will be on that page, and you can have skeleton components in place until data is built and loaded. Once that data has been resolved, that page is cached, added to the rest of the site&rsquo;s bundle, and the next user of your page will see the built page. If the data needs to update, the user will see that cached version instead of the fallback, and the site can set a <em>revalidate timeline</em> so that it can revalidate and update data regularly when your users hit the page.</p>

<p><img src="/img/blog/isr-star.gif" alt="Incremental static regeneration adds new pages to the latest deploy and caches them separately" title="Incremental static regeneration adds new pages to the latest deploy and caches them separately" /></p>

<p>Each of the new blocks in this diagram is a new page that is built at runtime and added to the &ldquo;stack.&rdquo;</p>

<p>This method of serving pages is using the <a href="https://web.dev/stale-while-revalidate/">stale-while-revalidate</a> caching strategy. It&rsquo;s pretty dang performant, because you can (nearly) get the performance benefits of a pure static page, with the power of new dynamic data like you would in SSR. That&rsquo;s why this strategy is very often called &ldquo;hybrid&rdquo; development, because it combines the best of both worlds!</p>

<h3 id="why-it-s-not-great">Why it&rsquo;s not great</h3>

<p>There&rsquo;s a few flaws in ISR that you might want to consider before going all-in on the concept.</p>

<p>When you have a user come to your page, you want them to see the most up-to-date version, immediately. With ISR the first visitor to a page will not see that. They will always see a fallback first. And then later, if the data gets stale, the first visitor to see that cached page will see the out-of-date data first before it revalidates. Once again, this inconsistent experience can be pretty difficult to debug if your users experience negative side-effects as a result of old/unbuilt pages.</p>

<p><img src="/img/blog/stale-star.gif" alt="Pages can get stale, but they'll stay deployed" title="Pages can get stale, but they'll stay deployed" /></p>

<p>Remember the whole section up there of atomic and immutable deployment? ISR, unfortunately, breaks that model. By adding extra pages to your bundle, rollbacks can no longer be instant, and you no longer have that single new version of your site when you update your content.</p>

<p>Let&rsquo;s say you build a site that has a bunch of products for sale, and each of those products are on ISRed pages. In an ideal scenario, your users can navigate to a products&rsquo; page, see a product for sale, and buy it. The next users who go to the page will see it, and the page might update to show that the product is out of stock.</p>

<p>If you rollback your site to a different deploy, because your page is cached separately from the bundle, it could exist in a different state for your user than expected. It could be the old version of the site, the new version, or some funky in-between cached version trying to revalidate itself. And unfortunately, debugging this is difficult, because different users (and the dev team!) would see different pages, and it might be difficult to duplicate.</p>

<p><img src="/img/blog/rollbackisr-star.gif" alt="ISR means that you can rollback, but the stale/separately cached pages will stay live" title="ISR means that you can rollback, but the stale/separately cached pages will stay live" /></p>

<p>Notice how in this graphic, the pages that are cached separately stick around with their nice big checkmarks, while the rolled-back page is no longer the shipped deploy. If the users navigate to those cached routes, they might see out-of-date data.</p>

<p>The stale-while-revalidate caching that powers ISR is the reason behind these gotchas. When ISR is based on serving stale content like this, we end up with a pretty big footgun that ultimately is confusing for users, and frustrating for developers.</p>

<h2 id="how-does-netlify-handle-it">How does Netlify handle it?</h2>

<p>Currently, ISR is built in to Next.js, and we serve those unbuilt pages via <a href="https://functions.netlify.com/?utm_campaign=devex-cs&amp;utm_source=blog&amp;utm_content=functions">Netlify Functions</a>, rendering them new every time, to avoid that caching problem. This isn&rsquo;t the spirit of ISR, yes, but we are strongly in favor of atomic and immutable deploys. There are better ways to approach your sites than with this type of caching.</p>

<p>We have solutions coming in the future to serve these kinds of unbuilt pages in a better way, keep an eye on this space!</p>

<h2 id="what-should-i-do-for-my-projects">What should I do for my projects?</h2>

<p>✨ It Depends ✨</p>

<p>Clearly there are benefits to ISR, but it does come with caveats! Weigh the pros and the cons and decide for yourself if it&rsquo;s right for you.</p>


Right now there are a lot of hot takes out there about how to improve and scale sites “beyond Jamstack” by adding in features that use a Node server. One of those features is called Incremental Static Regeneration.
Some people call it “hybrid web development” (or “hybrid serverless + static”) but let’s talk a bit more about what that means.
What happens when you deploy a Jamstack project
First of all, we should talk about what happens when you build Jamstack sites, and how atomic and immutable deploys work. These are fundamental principles to understand for this style of web development.
Atomic deployment means all of the code, assets, and configuration of a site are updated together at the same time. This means that a website cannot be served in a partially updated state.
Immutable deployment insulates deploys from future actions, guaranteeing their integrity. This means there is always a stable copy of this deploy that can be referenced or re-deployed at any state in the future.
(You can read more about these terms in this blog post)
You can almost think of this as state-driven development. Every single deploy is a new state of your application or site.

If you were to make a mistake on your site, let’s say you broke prod, you deployed the wrong brand colors, or you mixed up some copy, you can instantly rollback to a previous deploy without having to wait for a new build, because that version of your site exists in space. It’s why it works so well with Git, it’s similar to reverting a commit.

I won’t get into the details of the perks of pre-rendering all of your pages, but if you’d like to read more about that, you can check out more information on Jamstack.org.
Incremental Static Regeneration
Incremental Static Regeneration, or ISR, seeks to extend the power of static sites by adding some server-side rendering (SSR) goodies on top.
How it works and why it’s cool
When you deploy a site with ISR enabled, you deploy a (mostly) static site. You have your pre-defined static pages that were built, and you have routes on your application that aren’t built until your users hit those pages.
Typically when you have a server-side rendered (SSR) page that is one of these unbuilt pages, your users have to wait for the page to be built and served all at once. But in the case of ISR, if your users hit that route, they get a fallback page. A fallback page is a placeholder for the actual content that will be on that page, and you can have skeleton components in place until data is built and loaded. Once that data has been resolved, that page is cached, added to the rest of the site’s bundle, and the next user of your page will see the built page. If the data needs to update, the user will see that cached version instead of the fallback, and the site can set a revalidate timeline so that it can revalidate and update data regularly when your users hit the page.

Each of the new blocks in this diagram is a new page that is built at runtime and added to the “stack.”
This method of serving pages is using the stale-while-revalidate caching strategy. It’s pretty dang performant, because you can (nearly) get the performance benefits of a pure static page, with the power of new dynamic data like you would in SSR. That’s why this strategy is very often called “hybrid” development, because it combines the best of both worlds!
Why it’s not great
There’s a few flaws in ISR that you might want to consider before going all-in on the concept.
When you have a user come to your page, you want them to see the most up-to-date version, immediately. With ISR the first visitor to a page will not see that. They will always see a fallback first. And then later, if the data gets stale, the first visitor to see that cached page will see the out-of-date data first before it revalidates. Once again, this inconsistent experience can be pretty difficult to debug if your users experience negative side-effects as a result of old/unbuilt pages.

Remember the whole section up there of atomic and immutable deployment? ISR, unfortunately, breaks that model. By adding extra pages to your bundle, rollbacks can no longer be instant, and you no longer have that single new version of your site when you update your content.
Let’s say you build a site that has a bunch of products for sale, and each of those products are on ISRed pages. In an ideal scenario, your users can navigate to a products’ page, see a product for sale, and buy it. The next users who go to the page will see it, and the page might update to show that the product is out of stock.
If you rollback your site to a different deploy, because your page is cached separately from the bundle, it could exist in a different state for your user than expected. It could be the old version of the site, the new version, or some funky in-between cached version trying to revalidate itself. And unfortunately, debugging this is difficult, because different users (and the dev team!) would see different pages, and it might be difficult to duplicate.

Notice how in this graphic, the pages that are cached separately stick around with their nice big checkmarks, while the rolled-back page is no longer the shipped deploy. If the users navigate to those cached routes, they might see out-of-date data.
The stale-while-revalidate caching that powers ISR is the reason behind these gotchas. When ISR is based on serving stale content like this, we end up with a pretty big footgun that ultimately is confusing for users, and frustrating for developers.
How does Netlify handle it?
Currently, ISR is built in to Next.js, and we serve those unbuilt pages via Netlify Functions, rendering them new every time, to avoid that caching problem. This isn’t the spirit of ISR, yes, but we are strongly in favor of atomic and immutable deploys. There are better ways to approach your sites than with this type of caching.
We have solutions coming in the future to serve these kinds of unbuilt pages in a better way, keep an eye on this space!
What should I do for my projects?
✨ It Depends ✨
Clearly there are benefits to ISR, but it does come with caveats! Weigh the pros and the cons and decide for yourself if it’s right for you.

Incremental Static Regeneration: Its Benefits and Its Flaws



<div class="toc">
  <h2>In this post</h2>
  
</div>


<h2 id="how-jamstack-is-enabling-spring-to-move-iteratively-from-monolith-to-microservices">How Jamstack is enabling Spring to move iteratively from monolith to microservices</h2>

<p><img src="/img/blog/spring-logo-alpha-04.png" alt="Spring logo Teespring" title="Spring logo Teespring" /></p>

<p>As a leading social commerce platform for creating and selling custom products online, <a href="https://www.spri.ng/">Spring</a>’s web experience matters a lot. The magic of customizing physical and digital products on demand is made possible with a dynamic web experience powered by Netlify using a modern <a href="https://www.netlify.com/jamstack/">Jamstack</a> architecture.</p>

<p>With Netlify, Spring (formerly Teespring) was able to migrate from a monolithic to a microservices-based web architecture, gradually. This reduced the risk of the architectural shift, improved site speed even as traffic was skyrocketing, and allowed them to ship changes to their web app much faster, directly improving conversion rates.</p>

<h2 id="background">Background</h2>

<p>“We want people to focus on the design and marketing of their products, rather than all of the logistics around it,” said Rick Takes, Spring’s director of engineering.</p>

<p>Spring, which started life as a Y Combinator project nine years ago, now has <strong>more than one million visitors to its site per day</strong> and has hit more than three years of profitability. This massive growth is thanks to the web app experience they offer, seamlessly combining custom branding of merchandise with a storefront, with social presence and flawless order handling and logistics.</p>

<p>But maintaining this level of innovation at scale was becoming more time-consuming, and the infrastructure was becoming more slow and brittle because it was built as a monolith in a monorepo. Netlify enabled Spring to take advantage of the modern Jamstack web architecture, one step at a time, to rapidly scale the e-commerce web experience and boost conversion for merchants.</p>

<h3 id="from-monolith-to-microservices">From Monolith to Microservices</h3>

<p>Modernization started with a close look at their tech stack.</p>

<p>“We started with a Ruby on Rails monolith in a <a href="https://www.netlify.com/blog/2019/10/09/launching-monorepo-support-for-netlify-sites/">monorepo</a>,” said Takes.</p>

<p>However, as the company expanded, this model&ndash;with its multiple frameworks and apps&ndash;did not scale well.</p>

<figure>
  <center>
    <img src="/img/blog/spring-original-tech-stack-rails.png" alt="Spring’s original tech stack.">
  </center>
  <figcaption>Spring’s original tech stack.</figcaption>
</figure>

<p>“We have a lot of different domains crossing paths here,” said Takes. “We have storefronts, checkout, shopping cart, fulfillment, all intertwined in a single repo in a single app, which makes it difficult to iterate quickly and also brings up unforeseen bugs. Making a change to one part of the code base affects something else. For example, we might make a change to storefronts and that change affects fulfillment, which just isn&rsquo;t great, so we decided to pull things apart.”</p>

<h3 id="starting-hybrid-and-gradually-moving-to-the-jamstack-approach">Starting Hybrid and Gradually Moving to the Jamstack Approach</h3>

<p>Takes and his team decided to start with a domain-driven-design approach, rolled out in phases with the goal of creating a more service based architecture. For example, Spring wanted to be able to pull out a product area, such as a “shopping cart,” from its monolith and present it as a fully stand-alone service.</p>

<p>“We knew roughly what we wanted to do—we needed to break apart the monolith because it just wasn’t scaling well at all,” said Takes. “But we wanted to be really deliberate in how we approached it and not just jump into the latest and greatest technology that a year from now we might regret.”</p>

<p>“We wanted a solution that would enable us to pull apart our monolith without having to completely tear it down,” said Takes.</p>

<p>This is where the Jamstack&ndash;an architecture that leverages the principles of pre-rendering and decoupling to make the web faster, more secure and more resilient&ndash; and Netlify comes in. The Jamstack’s flexible architecture along with a great developer experience delivered by Netlify allowed the Spring team to take a phased approach to break away pieces of their legacy monolith.</p>

<p>Spring has a culture of iterating and experimenting. Once something is proven out, it gets added to the Spring roadmap in a safe, scalable manner. Takes and his team came to Netlify early in 2020 with the challenge of enabling sellers to create their own branded storefronts, and began working through some proofs of concept.</p>

<p>“It ended up working really well,” said Takes. “We started scaling it up, and now here we are, about a year later, ready to release this out to a much larger audience.”</p>

<p>Now his team has set a goal of one million storefronts on the Netlify platform by June 2021.</p>

<h3 id="a-huge-timesaver-moving-from-a-rails-monolith-to-frontend-apps-living-in-netlify">A Huge Timesaver: Moving from a Rails Monolith to Frontend Apps Living in Netlify</h3>

<p>One thing that helped Takes and his team focus their journey was to imagine the ideal API. Every step of the way they asked themselves, “If we were to open this up publicly, what would be sensible, what could people build meaningful products on top of, and what would make sense to those not familiar with our internal terms and concepts?” These questions, said Takes, served as a “gut check” throughout the process.</p>

<p>Takes and his team decided to take an adapter pattern approach to an ideal, documented and versioned API.</p>

<p>“We proxy all the API responses from our Rails code base through the AWS API gateway,” he said. “It then takes that legacy shape and passes it through what we call an adapter&ndash;really just a function that converts that legacy shape to a more modern, ideal state and then surfaces it to whatever is requesting data.”</p>

<p>Takes said this process provided the organization with the flexibility to go back and refactor some of these concepts in its Rails app. They could be pulled out without worrying that every time an API change was made all the apps that consume the API would have to be updated, as well.</p>

<p>“Now we only have to update that function, that adapter,” said Takes. So, if we make a change on the Rails side to remove something, like a campaign (an internal term for a buyable product), we edit the adapter and everything else just keeps on working as long as we keep that handshake the same. And because we now have this versioned API, if we were to make a change we can call it V2 and, at our leisure, update the apps to start consuming it.”</p>

<p>Spring is building a pluggable architecture that allows partners to onboard extremely quickly. Connections to partners are now built in days by a few engineers, where they used to take months for an entire team. Without having to rebuild everything from the ground up and taking this approach they are more flexible, can focus better on their core product and can reduce technical debt moving forward.</p>

<p>Spring also takes advantage of <strong><a href="https://www.netlify.com/blog/2020/10/29/announcing-background-functions/">Netlify Background Functions</a></strong>, for longer running tasks, or asynchronous jobs.</p>

<p>At this point in time, said Takes, many of Spring’s microservices don’t even touch the Rails app: “We can have frontend apps living in Netlify and going through the API and then hitting a microservice, and that can return out to the frontend app without ever having to hit our Rails code base. That’s been a huge timesaver for us in building new applications.”</p>

<figure>
  <img src="/img/blog/spring-current-architecture-1.png" alt="Spring’s current architecture that runs on Netlify">
  <figcaption>Spring’s current architecture that runs on Netlify.</figcaption>
</figure>

<blockquote>
<p>“We can have frontend apps living in Netlify and going through the API and then hitting a microservice, and that can return out to the frontend app without ever having to hit our Rails code base. That’s been a huge timesaver for us in building new applications.”</p>
</blockquote>

<h3 id="high-converting-branded-storefronts">High converting branded storefronts</h3>

<p>By eschewing an “all-in” approach to microservices, Spring can be purposeful in terms of what it converts to the Jamstack approach and what it doesn’t (for now or forever, depending on the apps and services).</p>

<p>The most recent project focused on developing a branded storefront experience powered by Netlify.</p>

<p>Branded storefronts allow creators to have a fully customizable experience: They can adjust their logo, fonts, colors, text&ndash;even customize their own domains&ndash;so the storefronts really become owned by the creators. All of this runs on <strong><a href="https://www.netlify.com/enterprise/">Netlify’s High-Performance Edge network</a></strong>.</p>

<p>“Branded storefronts are fully utilizing our new commerce API,” said Takes. “These sites are dynamically deployed to Netlify, and they’re living on the high-performance edge network there. We’ve seen huge performance increases from doing it in this way, and, as a result of the performance increases, we’re seeing an uptick in conversion rates and a decreased bounce rate—specifically in mobile, because people can load the sites much faster than they could with legacy sites.”</p>

<blockquote>
<p>&rdquo;&hellip;We’ve seen huge performance increases from doing it in this way, and, as a result of the performance increases, we’re seeing an uptick in conversion rates and a decreased bounce rate—specifically in mobile, because people can load the sites much faster than they could with legacy sites.&rdquo;</p>
</blockquote>

<p>Spring’s branded storefronts are just leaving beta. The company is currently rolling out branded storefronts to all of its users.</p>

<h2 id="results-and-future-proofing-with-netlify">Results and Future-Proofing with Netlify</h2>

<p>One of the biggest benefits that Spring has gained from using Jamstack and Netlify has been improved developer experience via live <strong><a href="https://www.netlify.com/products/">deploy previews and faster build times</a></strong>, allowing them to ship updates to their customers more efficiently. <strong>They went from 90-minute build times to 1 minute, thanks to adopting Netlify <a href="https://www.netlify.com/enterprise/">High Performance Build</a>.</strong></p>

<p>“In the monolith, our CI deployment times could be up to an hour and a half,” said Takes. “Those have come down significantly as we’ve pulled things out. Our build times on our branded stores, backed by our serverless architecture, are about a minute.”</p>

<p>Spring plans to evolve its use of Netlify and the Jamstack moving forward, especially when it comes to <a href="https://www.netlify.com/products/edge/">capabilities on the edge</a>. Spring is a global company, so being able to put sites as close to creators as possible will provide a host of benefits, including improved localization.</p>

<p>“As a global offering we’re excited to work with <a href="https://www.netlify.com/products/edge/edge-handlers/">Netlify Edge Handlers</a> to add better localization and to continue to improve site performance.”</p>

<p>Spring is also in the process of moving to <strong><a href="https://www.netlify.com/with/nextjs/">Next.js on Netlify</a></strong> and taking advantage of <a href="https://www.netlify.com/blog/2020/10/27/preview-mode-for-next.js-now-fully-supported-on-netlify/">preview mode support</a>, which Takes said can offer a better developer experience.</p>

<p>Takes and his team are working to expand their use of Netlify as the company expands&ndash;and to continue to reduce the size of its monolith over time and as it makes sense.</p>

<p>“We’re scaling as a company and bringing in more and more engineers, and that allows us to do more of this work,” he said. “We eventually want to move fully away from our monolith and completely toward this modern architecture, but we are going to do that safely and in bite-sized pieces. Whenever we’re about to do some new work, we look and see if we are going to have to touch the legacy code base. We front-load modernizing that piece by pulling it out or making a microservice out of it. Then we do our new work. And, just kind of bite by bite, that’s pulling apart our monolith.”</p>

<blockquote>
<p>“We eventually want to move fully away from our monolith and completely toward this modern architecture, but we are going to do that safely and in bite-sized pieces.&rdquo;</p>
</blockquote>

<p>The Spring team had a vision for their next-generation commerce platform and by partnering with Netlify and adopting Jamstack, they are well on their path to realizing it.</p>

<h2 id="learn-more">Learn more</h2>

<ul>
<li><a href="https://www.netlify.com/resources/webinars/teesprings-journey-to-the-jamstack">Watch a <strong>webinar</strong> with Spring to dive deeper into their architecture</a></li>
<li>Have a project in mind? One of our experts would love to <strong><a href="https://www.netlify.com/enterprise/contact/">talk with you</a></strong> about the use-case and requirements.</li>
<li><a href="https://youtu.be/5xkDnOemjLk?list=PL58Wk5g77lF94tg-F3y5zRyDeLVhTDnTg">View a replay of a talk from Jamstack Conf on Spring’s move to the Jamstack</a></li>
</ul>

<iframe width="986" height="555" src="https://www.youtube.com/embed/5xkDnOemjLk?list=PL58Wk5g77lF94tg-F3y5zRyDeLVhTDnTg" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>


In this post
How Jamstack is enabling Spring to move iteratively from monolith to microservices

As a leading social commerce platform for creating and selling custom products online, Spring’s web experience matters a lot. The magic of customizing physical and digital products on demand is made possible with a dynamic web experience powered by Netlify using a modern Jamstack architecture.
With Netlify, Spring (formerly Teespring) was able to migrate from a monolithic to a microservices-based web architecture, gradually. This reduced the risk of the architectural shift, improved site speed even as traffic was skyrocketing, and allowed them to ship changes to their web app much faster, directly improving conversion rates.
Background
“We want people to focus on the design and marketing of their products, rather than all of the logistics around it,” said Rick Takes, Spring’s director of engineering.
Spring, which started life as a Y Combinator project nine years ago, now has more than one million visitors to its site per day and has hit more than three years of profitability. This massive growth is thanks to the web app experience they offer, seamlessly combining custom branding of merchandise with a storefront, with social presence and flawless order handling and logistics.
But maintaining this level of innovation at scale was becoming more time-consuming, and the infrastructure was becoming more slow and brittle because it was built as a monolith in a monorepo. Netlify enabled Spring to take advantage of the modern Jamstack web architecture, one step at a time, to rapidly scale the e-commerce web experience and boost conversion for merchants.
From Monolith to Microservices
Modernization started with a close look at their tech stack.
“We started with a Ruby on Rails monolith in a monorepo,” said Takes.
However, as the company expanded, this model–with its multiple frameworks and apps–did not scale well.
Spring’s original tech stack.


“We have a lot of different domains crossing paths here,” said Takes. “We have storefronts, checkout, shopping cart, fulfillment, all intertwined in a single repo in a single app, which makes it difficult to iterate quickly and also brings up unforeseen bugs. Making a change to one part of the code base affects something else. For example, we might make a change to storefronts and that change affects fulfillment, which just isn’t great, so we decided to pull things apart.”
Starting Hybrid and Gradually Moving to the Jamstack Approach
Takes and his team decided to start with a domain-driven-design approach, rolled out in phases with the goal of creating a more service based architecture. For example, Spring wanted to be able to pull out a product area, such as a “shopping cart,” from its monolith and present it as a fully stand-alone service.
“We knew roughly what we wanted to do—we needed to break apart the monolith because it just wasn’t scaling well at all,” said Takes. “But we wanted to be really deliberate in how we approached it and not just jump into the latest and greatest technology that a year from now we might regret.”
“We wanted a solution that would enable us to pull apart our monolith without having to completely tear it down,” said Takes.
This is where the Jamstack–an architecture that leverages the principles of pre-rendering and decoupling to make the web faster, more secure and more resilient– and Netlify comes in. The Jamstack’s flexible architecture along with a great developer experience delivered by Netlify allowed the Spring team to take a phased approach to break away pieces of their legacy monolith.
Spring has a culture of iterating and experimenting. Once something is proven out, it gets added to the Spring roadmap in a safe, scalable manner. Takes and his team came to Netlify early in 2020 with the challenge of enabling sellers to create their own branded storefronts, and began working through some proofs of concept.
“It ended up working really well,” said Takes. “We started scaling it up, and now here we are, about a year later, ready to release this out to a much larger audience.”
Now his team has set a goal of one million storefronts on the Netlify platform by June 2021.
A Huge Timesaver: Moving from a Rails Monolith to Frontend Apps Living in Netlify
One thing that helped Takes and his team focus their journey was to imagine the ideal API. Every step of the way they asked themselves, “If we were to open this up publicly, what would be sensible, what could people build meaningful products on top of, and what would make sense to those not familiar with our internal terms and concepts?” These questions, said Takes, served as a “gut check” throughout the process.
Takes and his team decided to take an adapter pattern approach to an ideal, documented and versioned API.
“We proxy all the API responses from our Rails code base through the AWS API gateway,” he said. “It then takes that legacy shape and passes it through what we call an adapter–really just a function that converts that legacy shape to a more modern, ideal state and then surfaces it to whatever is requesting data.”
Takes said this process provided the organization with the flexibility to go back and refactor some of these concepts in its Rails app. They could be pulled out without worrying that every time an API change was made all the apps that consume the API would have to be updated, as well.
“Now we only have to update that function, that adapter,” said Takes. So, if we make a change on the Rails side to remove something, like a campaign (an internal term for a buyable product), we edit the adapter and everything else just keeps on working as long as we keep that handshake the same. And because we now have this versioned API, if we were to make a change we can call it V2 and, at our leisure, update the apps to start consuming it.”
Spring is building a pluggable architecture that allows partners to onboard extremely quickly. Connections to partners are now built in days by a few engineers, where they used to take months for an entire team. Without having to rebuild everything from the ground up and taking this approach they are more flexible, can focus better on their core product and can reduce technical debt moving forward.
Spring also takes advantage of Netlify Background Functions, for longer running tasks, or asynchronous jobs.
At this point in time, said Takes, many of Spring’s microservices don’t even touch the Rails app: “We can have frontend apps living in Netlify and going through the API and then hitting a microservice, and that can return out to the frontend app without ever having to hit our Rails code base. That’s been a huge timesaver for us in building new applications.”
Spring’s current architecture that runs on Netlify.



“We can have frontend apps living in Netlify and going through the API and then hitting a microservice, and that can return out to the frontend app without ever having to hit our Rails code base. That’s been a huge timesaver for us in building new applications.”
High converting branded storefronts
By eschewing an “all-in” approach to microservices, Spring can be purposeful in terms of what it converts to the Jamstack approach and what it doesn’t (for now or forever, depending on the apps and services).
The most recent project focused on developing a branded storefront experience powered by Netlify.
Branded storefronts allow creators to have a fully customizable experience: They can adjust their logo, fonts, colors, text–even customize their own domains–so the storefronts really become owned by the creators. All of this runs on Netlify’s High-Performance Edge network.
“Branded storefronts are fully utilizing our new commerce API,” said Takes. “These sites are dynamically deployed to Netlify, and they’re living on the high-performance edge network there. We’ve seen huge performance increases from doing it in this way, and, as a result of the performance increases, we’re seeing an uptick in conversion rates and a decreased bounce rate—specifically in mobile, because people can load the sites much faster than they could with legacy sites.”
”…We’ve seen huge performance increases from doing it in this way, and, as a result of the performance increases, we’re seeing an uptick in conversion rates and a decreased bounce rate—specifically in mobile, because people can load the sites much faster than they could with legacy sites.”
Spring’s branded storefronts are just leaving beta. The company is currently rolling out branded storefronts to all of its users.
Results and Future-Proofing with Netlify
One of the biggest benefits that Spring has gained from using Jamstack and Netlify has been improved developer experience via live deploy previews and faster build times, allowing them to ship updates to their customers more efficiently. They went from 90-minute build times to 1 minute, thanks to adopting Netlify High Performance Build.
“In the monolith, our CI deployment times could be up to an hour and a half,” said Takes. “Those have come down significantly as we’ve pulled things out. Our build times on our branded stores, backed by our serverless architecture, are about a minute.”
Spring plans to evolve its use of Netlify and the Jamstack moving forward, especially when it comes to capabilities on the edge. Spring is a global company, so being able to put sites as close to creators as possible will provide a host of benefits, including improved localization.
“As a global offering we’re excited to work with Netlify Edge Handlers to add better localization and to continue to improve site performance.”
Spring is also in the process of moving to Next.js on Netlify and taking advantage of preview mode support, which Takes said can offer a better developer experience.
Takes and his team are working to expand their use of Netlify as the company expands–and to continue to reduce the size of its monolith over time and as it makes sense.
“We’re scaling as a company and bringing in more and more engineers, and that allows us to do more of this work,” he said. “We eventually want to move fully away from our monolith and completely toward this modern architecture, but we are going to do that safely and in bite-sized pieces. Whenever we’re about to do some new work, we look and see if we are going to have to touch the legacy code base. We front-load modernizing that piece by pulling it out or making a microservice out of it. Then we do our new work. And, just kind of bite by bite, that’s pulling apart our monolith.”
“We eventually want to move fully away from our monolith and completely toward this modern architecture, but we are going to do that safely and in bite-sized pieces.”
The Spring team had a vision for their next-generation commerce platform and by partnering with Netlify and adopting Jamstack, they are well on their path to realizing it.
Learn more
Watch a webinar with Spring to dive deeper into their architecture
Have a project in mind? One of our experts would love to talk with you about the use-case and requirements.
View a replay of a talk from Jamstack Conf on Spring’s move to the Jamstack

Spring uses Netlify to Scale Social Commerce and Boost Conversion for Creators

<p>Wow! I loved <a href="https://www.basicfun.com/lincoln-logs.html">Lincoln Logs</a> when I was a kid! It was so fun to be able to build houses, or even castles, and get so creative with them, and the— wait, there&rsquo;s a typo in my notes&hellip; ohhhhh, not <strong>Lincoln Logs</strong>, it&rsquo;s <strong>linking logs</strong>!</p>

<p>Well, you know, this is just as fun. We have some very cool changes just released in your deploy logs at Netlify!</p>

<p>Your deploy logs include all kinds of important info, like details about your site&rsquo;s build image, the Netlify build process, dependency caching, build plugins, and details about if your deploy succeeded or not. And sometimes, you&rsquo;re going to want to share some of that information, just like you might share your Lincoln Logs with your friends!</p>

<p><img src="/img/blog/loglines.png" alt="Linkable log lines!" title="Linkable log lines!" /></p>

<p>When you go to your logs, you can now select the line number to highlight the line, or hit Shift and select a range of lines, and you can share the resulting URL with your teammates. Wow, that was so easy, almost as easy as&hellip; Lincoln Logs. 👀</p>

<p>If you&rsquo;d like to read more about how to use this feature, <a href="https://docs.netlify.com/site-deploys/overview/?utm_campaign=devex-cs&amp;utm_source=blog&amp;utm_content=loglines#share-log-content">check out the docs</a> and get to it!</p>

<p>Not on Netlify? Want to be? <a href="https://app.netlify.com/signup?utm_campaign=devex-cs&amp;utm_source=blog&amp;utm_content=signup">Sign up here</a>!</p>


Wow! I loved Lincoln Logs when I was a kid! It was so fun to be able to build houses, or even castles, and get so creative with them, and the— wait, there’s a typo in my notes… ohhhhh, not Lincoln Logs, it’s linking logs!
Well, you know, this is just as fun. We have some very cool changes just released in your deploy logs at Netlify!
Your deploy logs include all kinds of important info, like details about your site’s build image, the Netlify build process, dependency caching, build plugins, and details about if your deploy succeeded or not. And sometimes, you’re going to want to share some of that information, just like you might share your Lincoln Logs with your friends!

When you go to your logs, you can now select the line number to highlight the line, or hit Shift and select a range of lines, and you can share the resulting URL with your teammates. Wow, that was so easy, almost as easy as… Lincoln Logs. 👀
If you’d like to read more about how to use this feature, check out the docs and get to it!
Not on Netlify? Want to be? Sign up here!

Linkable log lines now available!



<p>At Netlify, we use a diverse set of technologies, languages and paradigms to build our product. Along with Ruby, Go, Rust and others, we write quite a bit of JavaScript. All flavors of it.</p>

<p>My team is responsible for several mission-critical Node.js services: the <a href="https://github.com/netlify/cli">Netlify CLI</a>, the <a href="https://github.com/netlify/build">build system</a> and the <a href="https://github.com/netlify/zip-it-and-ship-it">serverless function bundler</a> are just a few examples. Despite the sheer number of repositories we maintain, and especially considering that some of them are open-source projects with daily contributions from the community, you might be surprised to learn that our team is relatively small.</p>

<p>I&rsquo;m convinced that one of the reasons why we&rsquo;re able to cover so much surface area is the rigorous set of tools and processes that we put in place. These are built on three key principles:</p>

<ul>
<li><p><strong>Automation</strong>: By automating recurring tasks whenever possible, we reduce the margin for human error and free up our engineers to focus on the right things.</p></li>

<li><p><strong>Confidence</strong>: We ship fast and often. To do this effectively, we need a culture of confidence around the code that we take to production.</p></li>

<li><p><strong>Consistency</strong>: All our repositories share the same basic structure, conventions and tools. This reduces the amount of context switching required when changing projects, which is important for our focus and productivity.</p></li>
</ul>

<p>In this article, I&rsquo;ll do a deep dive on some of these processes and tools, how we use them and why they help us.</p>

<h2 id="project-templates">Project templates</h2>

<p>As exciting as it is to lay the foundations for something new, starting a new Node.js project from a blank canvas is actually not a straightforward process. From scaffolding the application and the test suite, to installing all the dependencies and configuring the repository, you can find yourself spending precious time and energy before you even get to the point where you can start writing code.</p>

<p>We automate a lot of this with a tool called <a href="https://cookiecutter.readthedocs.io/en/1.7.2/index.html">Cookiecutter</a>. Every time we want to start a new project, we run <code>cookiecutter gh:netlify/node-template</code> (which points to our <a href="https://github.com/netlify/node-template">project template</a> on GitHub) and fill in some details about what we&rsquo;re building.</p>

<p>Cookiecutter takes care of creating a new repository with a fully-working Node.js application, including things like:</p>

<ul>
<li>a <code>package.json</code> file with information about the project and references to the basic dependencies;</li>
<li>a working test suite, integrated with code coverage reports;</li>
<li>configuration files for code formatting and linting;</li>
<li>contributing guidelines, a license and a code of conduct;</li>
<li>GitHub-specific settings, like issue and pull request templates and GitHub Actions workflows.</li>
</ul>

<p>By automating all of this grunt work, we can get off the ground much faster and start creating value straight away.</p>

<p>Using a template also provides the consistency of having the same tools and structure across every project, with the added benefit of promoting good practices from day one, regardless of the nature of the project — for example, the cost of adding a test to a proof-of-concept is much lower if all the infrastructure is already in place.</p>

<h2 id="issue-and-pull-request-templates">Issue and pull request templates</h2>

<p>All the communication around any one of our projects takes place in GitHub, be it a bug report or a feature request in an issue, or a contribution via a pull request. In any of these cases, there&rsquo;s a certain amount of information that is essential to get upfront, before any meaningful discussion or review can begin.</p>

<p>If it&rsquo;s a bug report, it&rsquo;s crucial to get an accurate description of any errors being shown, the steps needed to reproduce the problem, and information about the user&rsquo;s environment (e.g. operating system and Node/npm versions). If it&rsquo;s a code contribution, it&rsquo;s important to get an understanding of the solution chosen and any caveats or limitations that it brings.</p>

<p>To make sure we capture this information, we use <a href="https://docs.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates">issue and pull request templates</a> in all our repositories, so that we ask users for these essential bits of information right from the GitHub interface.</p>

<p>You can have different templates for different use cases: our <a href="https://github.com/netlify/node-template/blob/master/%7B%7Bcookiecutter.project_slug%7D%7D/.github/ISSUE_TEMPLATE/bug_report.md">bug report template</a> asks users to perform specific commands to obtain information about their system that might help with troubleshooting, whereas the <a href="https://github.com/netlify/node-template/blob/master/%7B%7Bcookiecutter.project_slug%7D%7D/.github/ISSUE_TEMPLATE/feature_request.md">feature request template</a> asks broader questions about the solution that the user is after.</p>

<p>Oh! More importantly, our pull request template encourages contributors to add a picture of a cute animal.</p>

<p><img src="/img/blog/node-pr1.jpg" alt="A pull request with a cute baby elephant" /></p>

<h2 id="labels">Labels</h2>

<p>We make extensive use of GitHub labels in our issues and pull requests.</p>

<p>For one, this help us triage and prioritize all the open issues across our projects (which, in the case of our public repositories, can be in the hundreds). We use labels like <code>status: need-info</code> to flag issues that require additional information, <code>status: blocked</code> for issues that are blocked by another initiative, or <code>status: wontfix</code> to mark something that we&rsquo;ve decided not to fix or implement. When a new issue is created, we do our best to address it as quickly as possible — even if we don&rsquo;t have the bandwidth to work on it straight away, it&rsquo;s crucial to do a triage and ask for any additional context or missing information while it&rsquo;s still <em>fresh</em>.</p>

<p>At the same time, labelling our issues and pull requests provides invaluable insights into how we&rsquo;re delivering our work, which is paramount for a <a href="/blog/2020/09/22/metrics-driven-engineering-leadership-how-to-elevate-the-visibility-of-your-distributed-team/">metrics-driven engineering organization</a> like ours. This materializes in labels that describe the type of work being carried out, like <code>type: feature</code> for new functionality or <code>type: bug</code> for a bug fix. To ensure that our work is always appropriately tagged, we have a CI workflow that automatically blocks a pull request from being merged if it doesn&rsquo;t have a <code>type:</code> label.</p>

<h2 id="formatting-and-linting">Formatting and linting</h2>

<p>In our team, engineers must have their pull requests reviewed and approved by at least one colleague before they can be merged, which is enforced in our <a href="https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews#required-reviews">repository settings</a>. But code reviews are difficult and time-consuming, so we want to ensure that we focus on the right things. We want our reviews to be about the soundness of the implementation and whether the solution covers all edge cases, not about finding a missing semicolon or pointing out that a function has too many lines. It&rsquo;s not that these things are not important — they absolutely are. But asking humans to enforce them is not optimal.</p>

<p>The solution? Automation, of course! To do this, we use a code formatter (<a href="https://prettier.io/">Prettier</a>) and a linter (<a href="https://eslint.org/">ESLint</a>).</p>

<p>You can think of Prettier as a typewriter that replaces the handwriting of different authors, producing a standardized and objective output that is easily understood by everyone. By using an opinionated and quite prescriptive tool, we completely stop thinking about formatting the code and just focus on the problem it needs to solve.</p>

<p>ESLint, on the other hand, is responsible for ensuring that the sentences that come out of the typewriter are syntactically correct. Using a linter helps us catch syntax errors earlier in the development cycle, reducing the likelihood of them making it to production.</p>

<p>For consistency, our Prettier and ESLint configurations are published as an <a href="https://github.com/netlify/eslint-config-node">npm module</a> and imported into all our repositories. This ensures that all projects share the same rules and conventions and centralizes any modifications in one place, while making it easier to propagate updates across all projects.</p>

<h2 id="automated-tests">Automated tests</h2>

<p>All of our projects have a suite of automated tests. They are a fundamental piece in our engineering culture, since they give us the confidence we need to ship to production often with a lower risk of introducing regressions. A good test suite is also important when onboarding new engineers to a project, or when accepting external contributions from the open-source community.</p>

<p><a href="https://github.com/avajs/ava">Ava</a> is our test runner of choice. We make use of <a href="https://github.com/avajs/ava/blob/main/docs/04-snapshot-testing.md">snapshot testing</a> in some projects (like <a href="https://github.com/netlify/build/blob/master/packages/build/tests/commands/snapshots/tests.js.md">Build</a>), but we tend to prefer traditional assertion-based testing.</p>

<p>Our test suite includes an integration with <a href="https://about.codecov.io/">Codecov</a> to keep track of test coverage. It&rsquo;s an important metric and we do keep an eye on its trajectory, but we don&rsquo;t live by it. More than focusing on an arbitrary number, we measure the robustness of our test suites based on how often bugs make their way to production. Whenever that happens, we always ensure that a fix is <a href="https://github.com/netlify/zip-it-and-ship-it/pull/350">accompanied by one or more tests</a> to prevent that issue — or similar ones — from creeping back in.</p>

<h2 id="ci-cd">CI/CD</h2>

<p>We currently use GitHub Actions as our CI/CD platform. All our workflows are automatically populated by our project template, so there&rsquo;s no additional configuration necessary after creating a new project.</p>

<p>The main job of the CI/CD pipeline is to run our test suite across <a href="https://github.com/netlify/cli/blob/master/.github/workflows/main.yml#L14-L16">different operating systems and Node versions</a>. This is a great way to discover issues that are specific to a setup different from the one we&rsquo;ve used while developing the feature. When this happens, we reach to tools like <a href="https://github.com/nvm-sh/nvm">Node version managers</a> and <a href="https://www.virtualbox.org/">virtual machines</a> to reproduce the exact conditions where the problem occurs.</p>

<h2 id="dependency-management">Dependency management</h2>

<p>Keeping dependencies up-to-date is another one of those repetitive, time-consuming tasks that we can offload to machines. We do this with <a href="https://github.com/marketplace/renovate">Renovate</a>, a GitHub App that periodically checks for newer versions of any dependencies our apps are using. When it finds an update, it offers to update them by sending <a href="https://github.com/netlify/build/pull/2312">a pull request</a> with a change to your <code>package.json</code> and lock files, which we can decide to merge or close depending on whether we&rsquo;re interested in the update.</p>

<p>Renovate is <a href="https://docs.renovatebot.com/configuration-options/">highly configurable</a>. You can choose a schedule for the update events, define different settings for certain modules, or even define a group of users that will be automatically added as reviewers for any pull requests.</p>

<p>We have a <a href="https://github.com/netlify/renovate-config">global configuration file</a> that is used across all projects, which we then augment on a per-project basis. For example, in <a href="https://github.com/netlify/zip-it-and-ship-it/blob/master/renovate.json5#L9-L25">our functions bundler</a> we&rsquo;re defining a list of modules that can&rsquo;t be upgraded because that would introduce compatibility issues with a legacy version of Node.js that we have to support.</p>

<p>It also includes a nifty <a href="https://github.com/netlify/build/issues/1653">dependency dashboard</a> right on the repository, in the form of a GitHub issue. From there, you can see which modules are scheduled for an update or trigger a re-evaluation of the dependency graph, which speeds up the creation of a pull request — I use this a lot when I&rsquo;m anxiously waiting for a dependency update to cut a release!</p>

<p><img src="/img/blog/node-pr2.jpg" alt="Renovate dependency dashboard" /></p>

<h2 id="automated-releases">Automated releases</h2>

<p>Our development cycle typically culminates in releasing a new version of a module and publishing it to <a href="https://www.npmjs.com/org/netlify">npm</a>. This, too, is something that we automate.</p>

<p>Every commit we make follows the <a href="https://www.conventionalcommits.org/en/v1.0.0/">Conventional Commits</a> specification, which consists of adding a prefix to the commit message according to the type of change we&rsquo;re making: <code>fix:</code> for patch increments, <code>feat:</code> for minor and <code>feat!:</code> for major/breaking changes, all following <a href="https://semver.org/">semantic versioning</a>.</p>

<p>We then use <a href="https://github.com/googleapis/release-please">Release Please</a> to take this data and, on every release, automatically populate the <code>CHANGELOG</code> file and create the appropriate tags. It also computes the upcoming version number according to the changes being released and creates <a href="https://github.com/netlify/zip-it-and-ship-it/pull/351">a pull request</a> to update <code>package.json</code> and any lock files accordingly. After this, all we have to do is run <code>npm publish</code> — which we&rsquo;re also looking to automate, once we find a good way to handle two-factor authentication with npm.</p>

<hr />

<p>This list is an eternal work in progress, as we&rsquo;re constantly evaluating our workflows and looking for other ways to optimize our time and improve the quality of our deliverables.</p>

<p>It&rsquo;s worth noting that these processes and automations don&rsquo;t come for free — they require time themselves for an initial investigation, the setup, and ongoing maintenance. However, we generally find that time we spend on automating our workflows is an investment that pays for itself many times over, very quickly.</p>

<p>I hope that some of these tools and processes can help you and your team as much as they help us. Happy builds!</p>


At Netlify, we use a diverse set of technologies, languages and paradigms to build our product. Along with Ruby, Go, Rust and others, we write quite a bit of JavaScript. All flavors of it.
My team is responsible for several mission-critical Node.js services: the Netlify CLI, the build system and the serverless function bundler are just a few examples. Despite the sheer number of repositories we maintain, and especially considering that some of them are open-source projects with daily contributions from the community, you might be surprised to learn that our team is relatively small.
I’m convinced that one of the reasons why we’re able to cover so much surface area is the rigorous set of tools and processes that we put in place. These are built on three key principles:
Automation: By automating recurring tasks whenever possible, we reduce the margin for human error and free up our engineers to focus on the right things.



Confidence: We ship fast and often. To do this effectively, we need a culture of confidence around the code that we take to production.



Consistency: All our repositories share the same basic structure, conventions and tools. This reduces the amount of context switching required when changing projects, which is important for our focus and productivity.



In this article, I’ll do a deep dive on some of these processes and tools, how we use them and why they help us.
Project templates
As exciting as it is to lay the foundations for something new, starting a new Node.js project from a blank canvas is actually not a straightforward process. From scaffolding the application and the test suite, to installing all the dependencies and configuring the repository, you can find yourself spending precious time and energy before you even get to the point where you can start writing code.
We automate a lot of this with a tool called Cookiecutter. Every time we want to start a new project, we run cookiecutter gh:netlify/node-template (which points to our project template on GitHub) and fill in some details about what we’re building.
Cookiecutter takes care of creating a new repository with a fully-working Node.js application, including things like:
a package.json file with information about the project and references to the basic dependencies;
a working test suite, integrated with code coverage reports;
configuration files for code formatting and linting;
contributing guidelines, a license and a code of conduct;
GitHub-specific settings, like issue and pull request templates and GitHub Actions workflows.
By automating all of this grunt work, we can get off the ground much faster and start creating value straight away.
Using a template also provides the consistency of having the same tools and structure across every project, with the added benefit of promoting good practices from day one, regardless of the nature of the project — for example, the cost of adding a test to a proof-of-concept is much lower if all the infrastructure is already in place.
Issue and pull request templates
All the communication around any one of our projects takes place in GitHub, be it a bug report or a feature request in an issue, or a contribution via a pull request. In any of these cases, there’s a certain amount of information that is essential to get upfront, before any meaningful discussion or review can begin.
If it’s a bug report, it’s crucial to get an accurate description of any errors being shown, the steps needed to reproduce the problem, and information about the user’s environment (e.g. operating system and Node/npm versions). If it’s a code contribution, it’s important to get an understanding of the solution chosen and any caveats or limitations that it brings.
To make sure we capture this information, we use issue and pull request templates in all our repositories, so that we ask users for these essential bits of information right from the GitHub interface.
You can have different templates for different use cases: our bug report template asks users to perform specific commands to obtain information about their system that might help with troubleshooting, whereas the feature request template asks broader questions about the solution that the user is after.
Oh! More importantly, our pull request template encourages contributors to add a picture of a cute animal.

Labels
We make extensive use of GitHub labels in our issues and pull requests.
For one, this help us triage and prioritize all the open issues across our projects (which, in the case of our public repositories, can be in the hundreds). We use labels like status: need-info to flag issues that require additional information, status: blocked for issues that are blocked by another initiative, or status: wontfix to mark something that we’ve decided not to fix or implement. When a new issue is created, we do our best to address it as quickly as possible — even if we don’t have the bandwidth to work on it straight away, it’s crucial to do a triage and ask for any additional context or missing information while it’s still fresh.
At the same time, labelling our issues and pull requests provides invaluable insights into how we’re delivering our work, which is paramount for a metrics-driven engineering organization like ours. This materializes in labels that describe the type of work being carried out, like type: feature for new functionality or type: bug for a bug fix. To ensure that our work is always appropriately tagged, we have a CI workflow that automatically blocks a pull request from being merged if it doesn’t have a type: label.
Formatting and linting
In our team, engineers must have their pull requests reviewed and approved by at least one colleague before they can be merged, which is enforced in our repository settings. But code reviews are difficult and time-consuming, so we want to ensure that we focus on the right things. We want our reviews to be about the soundness of the implementation and whether the solution covers all edge cases, not about finding a missing semicolon or pointing out that a function has too many lines. It’s not that these things are not important — they absolutely are. But asking humans to enforce them is not optimal.
The solution? Automation, of course! To do this, we use a code formatter (Prettier) and a linter (ESLint).
You can think of Prettier as a typewriter that replaces the handwriting of different authors, producing a standardized and objective output that is easily understood by everyone. By using an opinionated and quite prescriptive tool, we completely stop thinking about formatting the code and just focus on the problem it needs to solve.
ESLint, on the other hand, is responsible for ensuring that the sentences that come out of the typewriter are syntactically correct. Using a linter helps us catch syntax errors earlier in the development cycle, reducing the likelihood of them making it to production.
For consistency, our Prettier and ESLint configurations are published as an npm module and imported into all our repositories. This ensures that all projects share the same rules and conventions and centralizes any modifications in one place, while making it easier to propagate updates across all projects.
Automated tests
All of our projects have a suite of automated tests. They are a fundamental piece in our engineering culture, since they give us the confidence we need to ship to production often with a lower risk of introducing regressions. A good test suite is also important when onboarding new engineers to a project, or when accepting external contributions from the open-source community.
Ava is our test runner of choice. We make use of snapshot testing in some projects (like Build), but we tend to prefer traditional assertion-based testing.
Our test suite includes an integration with Codecov to keep track of test coverage. It’s an important metric and we do keep an eye on its trajectory, but we don’t live by it. More than focusing on an arbitrary number, we measure the robustness of our test suites based on how often bugs make their way to production. Whenever that happens, we always ensure that a fix is accompanied by one or more tests to prevent that issue — or similar ones — from creeping back in.
CI/CD
We currently use GitHub Actions as our CI/CD platform. All our workflows are automatically populated by our project template, so there’s no additional configuration necessary after creating a new project.
The main job of the CI/CD pipeline is to run our test suite across different operating systems and Node versions. This is a great way to discover issues that are specific to a setup different from the one we’ve used while developing the feature. When this happens, we reach to tools like Node version managers and virtual machines to reproduce the exact conditions where the problem occurs.
Dependency management
Keeping dependencies up-to-date is another one of those repetitive, time-consuming tasks that we can offload to machines. We do this with Renovate, a GitHub App that periodically checks for newer versions of any dependencies our apps are using. When it finds an update, it offers to update them by sending a pull request with a change to your package.json and lock files, which we can decide to merge or close depending on whether we’re interested in the update.
Renovate is highly configurable. You can choose a schedule for the update events, define different settings for certain modules, or even define a group of users that will be automatically added as reviewers for any pull requests.
We have a global configuration file that is used across all projects, which we then augment on a per-project basis. For example, in our functions bundler we’re defining a list of modules that can’t be upgraded because that would introduce compatibility issues with a legacy version of Node.js that we have to support.
It also includes a nifty dependency dashboard right on the repository, in the form of a GitHub issue. From there, you can see which modules are scheduled for an update or trigger a re-evaluation of the dependency graph, which speeds up the creation of a pull request — I use this a lot when I’m anxiously waiting for a dependency update to cut a release!

Automated releases
Our development cycle typically culminates in releasing a new version of a module and publishing it to npm. This, too, is something that we automate.
Every commit we make follows the Conventional Commits specification, which consists of adding a prefix to the commit message according to the type of change we’re making: fix: for patch increments, feat: for minor and feat!: for major/breaking changes, all following semantic versioning.
We then use Release Please to take this data and, on every release, automatically populate the CHANGELOG file and create the appropriate tags. It also computes the upcoming version number according to the changes being released and creates a pull request to update package.json and any lock files accordingly. After this, all we have to do is run npm publish — which we’re also looking to automate, once we find a good way to handle two-factor authentication with npm.
This list is an eternal work in progress, as we’re constantly evaluating our workflows and looking for other ways to optimize our time and improve the quality of our deliverables.
It’s worth noting that these processes and automations don’t come for free — they require time themselves for an initial investigation, the setup, and ongoing maintenance. However, we generally find that time we spend on automating our workflows is an investment that pays for itself many times over, very quickly.
I hope that some of these tools and processes can help you and your team as much as they help us. Happy builds!

Shipping Node.js at Netlify

If you’re just joining us, this is part two of the series where we build out an Angular site that grabs data from Sanity.io, a headless CMS, using Netlify Functions and Build Hooks.
Part 1 of this series covered:
Starting with a pre-rendered Angular site template
Setting up a headless CMS with Sanity.io
Grabbing the data from the CMS using Netlify Functions
Here, in Part 2 we are going to:
Add an Angular Service to handle the incoming data
Create and update Angular components to display the data
Setup a build hook to update the page when new data is added
This is what the page will look like:

⏩ Want to skip the reading and just “make it work”? Here’s is the project repo, or you can click the button below to deploy the site now!

Making the Angular Service
In the first part of the series we added a Netlify Function to grab the data we needed from Sanity.io. Now, we will use an Angular service to access that data.
Adding the Product Model
One thing that we’ll need before anything else is an interface of the product data we’re receiving from Sanity.io. An interface is a TypeScript syntactical contract defining types so they can be checked. The Product interface is very complicated…everything is type string 🙃. Rest assured you can assign other types in interfaces.
src/app/models/Product.ts
export interface Product {
  id: string;
  name: string;
  price: string;
  url: string;
  image: string;
  description: string;
}

HTTP For You and Me
Another thing we’ll need for the service is the HTTP Client. This is an injectable class with methods to perform HTTP requests. We’ll import that in the app’s main module file.
src/app/app.module.ts
import { BrowserModule } from '@angular/platform-browser';
+ import { HttpClientModule } from '@angular/common/http';
import { NgModule } from '@angular/core';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';
import { NavigationComponent } from './navigation/navigation.component';

@NgModule({
  declarations: [AppComponent, NavigationComponent],
  imports: [
    BrowserModule.withServerTransition({ appId: 'serverApp' }),
    AppRoutingModule,
+    HttpClientModule,
  ],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}

On To the Actual Service
To make the service we can use the handy generate command from the Angular CLI to create the files we need.
ng generate service services/Products
💡 We’re using the full command here but we could also use the shortened version ng g s services/Product.
Once we have the generated files (product.service.ts & product.service.spec.ts), we can import the HTTP client and the Product interface. We’ll also import Observable from the RxJS library since the products will be coming through as an observable sequence.
Inside the ProductService class we’ll use dependency injection to use the HTTP client in the service. Finally, we’ll make a function, getProduct that will be returning Observable<Product[]> from its HTTP GET call to where the Netlify Function lives on the live site: /.netlify/functions/getProducts. The last thing we’ll add to the function is an object that passes the GET call a headers object that sets the Content-Type to application/json.
Put it all together and what we get:
src/app/services/products.service.ts
import { Injectable } from '@angular/core';
+ import { HttpClient } from '@angular/common/http';
+ import { Observable } from 'rxjs';

+ import { Product } from '../models/Product';

@Injectable({
  providedIn: 'root',
})
export class ProductsService {
+ constructor(private http: HttpClient) {}

+ getProducts(): Observable<Product[]> {
+   return this.http.get<Product[]>('/.netlify/functions/getProducts', {
+     headers: {
+       'Content-Type': 'application/json',
+     },
+   });
+ }
}

Adding & Updating the Components
Now it’s time to really see the work we’ve done, literally. We’ll make a new component to hold the product information. Then we’ll update the existing Product component with the newly created component.
Product List Component
To make a component that lists the product, we’ll use the Angular CLI generate command again. This time we’ll use it to make a component as so:
ng g component components/ProductList --module products.module
We want to pass it the products.module module (using --module) so that it becomes a child component of the main products component and they can share data.
The TypeScript Part
Inside the ProductList component’s TypeScript file we will:
import the Input directive in order to share data from parent to child component
import the Product interface we made in the first step
inside the ProductListComponent declare and instantiate the product data we’re sharing from the parent Products component: @Input() product: Product.
All of that looks like this:
src/app/components/product-list/product-list.component.ts
+import { Component, OnInit, Input } from '@angular/core';
+import { Product } from 'src/app/models/Product';

@Component({
  selector: 'app-product-list',
  templateUrl: './product-list.component.html',
  styleUrls: ['./product-list.component.css'],
})
+export class ProductListComponent implements OnInit {
+  @Input() product: Product = {
+    name: 'test',
+    id: '1',
+    price: '1.23',
+    url: 'https://netlify.com',
+    image: 'https://bit.ly/20o7MGL',
+    description: 'test',
+  };

  constructor() {}

  ngOnInit(): void {}
}

💡 We instantiate the product data with default data because TypeScript is set to strict mode and will throw an error if it doesn’t have matching types for the Interface, Product. I will show a work around for this further into the post in case this is too cumbersome.
The HTML Template Part
Now we get to the actual showing of stuff! To do this we’re going to use the product data we’re passing in and use dot notation to grab the parts of the product data we want to use.
Like so:
src/app/components/product-list/product-list.component.html
-<p>product-list works!</p>
+<div class="product-item">
+  <img [src]="product.image" />
+  <div class="product-item-details">
+    <h3 class="product-name">{{ product.name }}</h3>
+  </div>
+</div>

The CSS Styling Part
Finally, the super complicated CSS goes into the component’s CSS file. I’m kidding, we’re just going to center-align the text.
src/app/components/product-list/product-list.component.css
+.product-item-details {
+  text-align: center;
+}

Phew, we’ve got the component that shows all the products! BUT it’s still not being rendered because we haven’t passed this component to the Product template. Guess what we’re going to do next!
Updating the Product Component
From the template project we have a Products component to list all of the products. This is where we’ll make the changes to insert all the components for each product.
The Module Part
We’ve actually already changed one of its files without even opening it! When we used the generate command to make the Product List component we referenced this Products’ module. Doing so imported the Product List component in the Products’ module TypeScript file.
src/app/products/products.module.ts
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';

import { ProductsRoutingModule } from './products-routing.module';
import { ProductsComponent } from './products.component';
+import { ProductListComponent } from '../components/product-list/product-list.component';

@NgModule({
+  declarations: [ProductsComponent, ProductListComponent],
  imports: [CommonModule, ProductsRoutingModule],
})
export class ProductsModule {}

The TypeScript Part
The Product component is the parent component that will be sending the product data to the Product List component. Like with the Product List component, we’ll need to import Observable and the Product interface. We also need to import ProductsService, the service we created earlier that calls the getProducts Netlify Function.
Inside of the class is where we do all the work:
assign products to an observable array of the interface we made, Product
inside the constructor we use data injection to use the service, ProductsService and assign it to productsService
when the lifecycle ngOnInit is called (after Angular has initialized all data-bound properties of a directive), we assign products to what is returned from getProducts inside the service productsService
src/app/products/products.component.ts
import { Component, OnInit } from '@angular/core';
+import { Observable } from 'rxjs';

+import { ProductsService } from 'src/app/services/products.service';
+import { Product } from 'src/app/models/Product';

@Component({
  selector: 'app-products',
  templateUrl: './products.component.html',
  styleUrls: ['./products.component.css'],
})
export class ProductsComponent implements OnInit {
+  products!: Observable<Product[]>;

+  constructor(private productsService: ProductsService) {}

  ngOnInit(): void {
+    this.products = this.productsService.getProducts();
  }
}

💡 When products is declared at the beginning of the ProductsComponent class I use the !, the TypeScript non-null assertion operator. This is the workaround I mentioned earlier that can be used instead of initializing with default data as we did in the Product List component. I don’t recommend this but thought it was a good alternative to show instead of turning TypeScript’s strict mode off.
Okay, we have the data! Let’s get going.
The HTML Template Part
We’re going to change a few things inside of the Products HTML template:
add a section for the Product List component
apply an *ngIf conditional directive to say if we have the products data use an async pipe assigning the data to products, else displaying a loading block Angular template
then we pass in the Product List component (app-product-list)
we also pass a few parameters to the Product list component including an *ngFor to loop through the products and assign each one to product
inside the component we’ll use Angular’s text interpolation to display the product’s name ({{ product.name }})
finally, we take the existing ‘loading’ text and place it inside the conditional ng-template named #loadingBlock
That was a lot of words but let’s take a look below to see what the code actually looks like.
src/app/products/products.component.html
<div class="products">
+  <main
+    class="products-list"
+    *ngIf="products | async as products; else loadingBlock"
+  >
+    <app-product-list
+      class="product-item"
+      *ngFor="let product of products"
+      [product]="product"
+    >
+      {{ product.name }}
+    </app-product-list>
+  </main>
+  <ng-template #loadingBlock>
+    <p>Loading products...</p>
+  </ng-template>
</div>

The CSS Styling Part
Let’s make sure the products look good on the page. We’ll use inline-flex for the display, use wrap for the flex-wrap, and set the justify-content to space-evenly. We’re just going to focus on how this looks on the desktop for now. With that in mind, we’ll set margin to 15px, min-width to 350px, and the width of each product div to 20%.
src/app/products/products.component.css
.products {
  margin: 0 auto;
  width: 80%;
}

.products p {
  font-family: 'Poiret One', sans-serif;
  font-size: 40px;
  margin: 50px;
  text-align: center;
}

+.product-item {
+  display: inline-flex;
+  flex-wrap: wrap;
+  justify-content: space-evenly;
+  margin: 15px;
+  min-width: 350px;
+  width: 20%;
+}

Eye on the Product
Get excited, we can finally see how this looks! To do so locally, we can run ntl dev in the root directory of the project. Then we’ll head to localhost:8888/products.

Now if we’ve either already hooked this project up to Netlify using the CLI ntl init command, or followed the steps in part 1 of this series, we have CI/CD set up. That means we can Git commit the code changes we made and it will trigger a new build of the project. Then we can head to the project dashboard or run the command ntl open to have Netlify take us right to the dashboard. Once, the new build is published we should see the same products we saw locally.
Hook it Up
The data from Sanity.io will be added to the site whenever it is built. To make sure we grab data right when it’s entered into the CMS, we can set up some hooks.
Adding a Netlify Build Hook
Netlify provides an easy interface for setting up Build Hooks through the project’s dashboard. We’ll head to Site settings > Build & deploy > Continuous deployment > Build hooks and click the ‘Add build hook’ button. Today we’ll just set the name to ‘angular-sanity’, for identification, and use the ‘main’ branch.

Once we have the build hook information saved, we’ll get a unique URL to copy for the next step. To trigger this hook, we need to send a POST request to that URL. Thankfully, Sanity.io has a quick process to set up that POST request.

Creating a Sanity Hook
In the terminal, we need to make sure we’re in the backend directory where our Sanity.io instance lives. We can then use the Sanity.io CLI to create a hook with just one command.
sanity hook create
Through the prompts, we’ll name the hook netlify, set the dataset to production, and paste the link we just received from Netlify when we made the Build Hook.

Hook Test
Does this work? Well, let’s add a new product and see about that. We can head back to our deployed Sanity.io instance. The address for this can be found at the top of the project dashboard beside ‘Studio’. Check out the section on Sanity deploying in the first part of this series to see where this link lives.

After hitting ‘Publish’ on the new data, we can look at the Netlify Production deploy logs (on the project’s main dashboard) and see that a build has been triggered by the Build Hook.

Once that deploy is published we just head back to our site and, voila, a new product!

C’est Fini!
We’ve accomplished what we’ve come here to do. We now have a pre-rendered Angular site, deployed to a CDN, that is grabbing information from a headless CMS (Sanity.io) using a Netlify Function, and updating with a build hook for dynamic data. Congrats! I hope this helps you on your Jamstack “Jamgular” future. Happy coding 👩🏻‍💻!
Resources for the Road
Part 1 of this series
Project Repo
Sanity.io Documentation
Netlify Functions
Netlify Build Hooks
Pre-rendering with Angular Universal