In this episode of Semaphore Uncut, we talk to Guillermo Rauch. Guillermo is CEO and co-founder of Vercel. We talk about how React has emerged as a de-facto standard for the front-end. Guillermo describes Vercel’s Next.js framework that is built around React. And we also discuss front-end testing and microservices engineering trends.
Key takeaways:
- Next.js improves React development and deployment
- Next.js is a powerful framework around de-facto standard React
- Front-ends are globally distributed – Next.js supports CDN from the start
- Front-end engineers need short feedback loops
- Fast feedback drives front-end quality
- Adopt new front-end tech one page at a time
- Test in production-like preview builds
- Use headless, visual regression tests for GUI components
- Testing benefits from React being functional and declarative
- The risks and rewards of microservices
- Emerging patterns and systems mitigate microservices risk
Listen to our entire conversation above, and check out my favorite parts in the episode highlights!
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Edited transcript
Darko (00:02): Hello, and welcome to Semaphore Uncut, a podcast for developers about building great products. Today I’m excited to welcome Guillermo Rauch. Guillermo, thank you so much for joining us. Please just go ahead and introduce yourself.
Guillermo: I’m the CEO and co-founder of Vercel, the company behind Next.js. It’s one of the most popular ways of developing modern front-end applications and websites. And I have a career in open source and developer tools. That’s always been my passion. I am happy to have the opportunity to help many teams with their front-end infrastructure, tooling, and edge platform requirements.
Next.js improves React development and deployment
Darko (00:42): Can you give us a brief pitch about what your company does and what Next.js is for?
Guillermo: Over the past decade, we’ve seen a ton of investment into great ways of creating back ends. And great ways of, funny enough, not creating back ends. We’ve seen the emergence of Stripe, Twilio, Auth0, all these amazing back ends as a service.
One of the emergent opportunities where the most difference can be made with your product and your company today is with the front-end. Because that’s where every visitor comes through to meet your brand, to try your product, and even use your backend. Every backend needs a great interface.
We decided to create an open-source framework called Next.js, which brings all the benefits of React to the table. React is the open-source UI library that Facebook open-sourced and has now become the most popular way of creating front-ends. But on top of that, we built an entire ecosystem of tools, workflows, and a global CDN, such that you can not only create your front-end but deploy it in such a way that is as fast as possible to the end-user. Today, front-end teams at companies like Washington Post, Airbnb, TripAdvisor have now standardized on Next.js and Vercel to build, develop, preview and ship their front-end experiences.
Next.js is a powerful framework around de-facto standard React
Darko (03:30): How we can understand better what Next.js is bringing to the table in the front-end area?
Guillermo: At the end of the day, none of the things we use to build back-ends and infrastructure today are real standards. They’re de facto standards that the industry has come up with. And from my observation, I would say that a similar thing has started to happen in front-end, where the de facto standard building block of the front-end universe has become the React component. Teams are now able to create design systems, brand systems, styling guidelines, and even behavior, and basically create the standards for their teams in the form of React components. And then they can reuse those building blocks.
Front-end teams and teams worldwide have now seen the light, so to speak, with this emergence of the React component. But the problem that remained was companies don’t build their websites and applications with just components. They need more powerful frameworks around that primitive, right?
They need routing systems and styling systems and state management systems, and different ways of composing applications together and building them. And that’s where Next.js emerged. Our fundamental primitive in Next.js is the page. You start by creating a page. That page can use, and export React components.
Front-ends are globally distributed – Next.js supports CDN from the start
And then we make it super easy for teams to build and push those pages that they create to a global edge network. The other big distinction between the back-end world and this nascent front-end world is it’s not that your application lives in a particular cluster in a particular region. Your front-end is globally distributed. And that gives you the ability to collocate the assets, the content, the pages, the data right next to where your visitors are.
A lot of our customers are moving from, let’s say the famous breaking down the monolith, right? So they have a technology like Ruby on Rails that has some front-end support, but it’s limited, right? The tasteful way of using systems like PHP, WordPress, Ruby on Rails, Drupal, it never involved a lot of front-end sophistication through component systems and React being a first-class citizen rather than an add-on that comes later.
What we’re seeing is a lot of companies breaking down the monolith. They’re retaining their back-end API, that talks HTTP, GRPC, GraphQL, JSON-RPC, what have you. And then they spin up a front-end stack. And then instead of then creating an ingress inside their cluster and then maintaining an nginx pod, and then juggling with bringing on a CDN and configuring caching and purging the caches when they deploy, they just give control of that front-end repository or that front-end entry point.
Front-end engineers need short feedback loops
An exciting feature is that we preview every change. When the front-end team pushes to Git, they get back at the deploy preview automatically, so they can test their changes and collaborate with the rest of the team. In terms of the persona, what’s been interesting has been to see that the front-end engineer is very motivated to hop on technologies like Next.js and platforms like Vercel out of self-interest. Because they have a shorter feedback loop. They push, and they get their URL. A lot of web APIs are best tested in production nowadays. Many features are not even enabled on the web browser today if you don’t have SSL.
The persona is not really just the front-end developer, but it’s also this intense, real-time collaboration with the rest of the organization, whether it’s because they’re sharing deploy previews and different stakeholders within the company can comment early on in the development process about what the product feels like and what it looks like.
Fast feedback drives front-end quality
And I want to emphasize that because the world of the front-end is a lot about the experience. When I work on thinking about back-end systems, frankly, I don’t want to oversimplify things, but I think a lot about just throughput and latency. I think about, okay, this message queue can push through this number of messages in this amount of time. They then think about things like availability and reliability and the best ways to expose my data to more teams and more people.
But when I’m a front-end person, it’s even hard to come up with one metric for performance because one super interesting thing is that a front end is almost never done rendering, especially a modern front end. When I think about an API, I think about the P99 response, okay. This API responds in 200 milliseconds. But what is the equivalent of that for a front-end?
The frontend is all about experience. Anything that closes to having metrics, which is the web vitals that Google has created, they still rely on a lot of heuristics. With this kind of deploy preview primitive that we’re helping popularize, the team happens to collaborate on the product, and they get to experience and feel the product earlier on in the software life cycle.
Adopt new front-end tech one page at a time
I think that’s where a lot of misconceptions have existed in this world of revolutionizing developer experience because they think an approach many years ago was, “Okay, you have to reinvent everything. You have to switch to this entire new stack. You have to change everything completely.”
Whereas what we’ve seen being a lot more successful is “Okay, start it with just one page, build it on Next.js, then use the Next.js router, for example, to say, okay, this page is served by Next.js, and then, the rest of the system is served to the legacy front-end system, which is usually your Rails monolith.” And our teams actually can get to compare side by side everything, from raw performance, they’ve got web vitals, meaning how fast is the front end to render, then the developers get to experience, okay, what is it like to evolve each system and work with it?
The whole company gets a taste for whether this is a system that they should invest further in or not. It’s a nice way of testing the waters and adopting these technologies. And increasingly, every one of these systems has evolved over the past few years to support API as a first-class citizen. The world is also standardizing into these semi-standard inputs and outputs systems. And that’s also fueling a lot of this momentum.
Test in production-like preview builds
Darko (21:22): You mentioned testing and you know how you can obviously test something on a production. How to solve testing the front-end and DOIs in a stable way? What are some of the tools and strategies to writing some automated tests that can test these components?
Guillermo: That’s a great point because what you’re touching on is that front-end and back-end have fundamentally different testing requirements and methodologies and tooling that has become available for ages. And that’s another further incentive to split the monolith such that you can leverage the best testing solutions for each side of the equation.
On the front end side, first, as you mentioned through deploy previews, we’ve seen an emergence of testing methodologies that test the actual product, the actual result. You get your deploy preview URL, which runs in the same production environment as the rest of your production website because it’s full CDN/SSL enabled, broadly compression, all the bells and whistles that you required for production. They’re also applied to your preview environment. So that means that, for example, if you do end-to-end testing, you’re now testing the actual thing on a realistic URL before it gets rolled out to production.
Use headless, visual regression tests for GUI components
Another thing we’re seeing along the same lines is visual testing tools. What’s nice is it’s almost like you can buy a hedge or a protection or insurance for that investment because you can use visual testing tools to take screenshots and, again, using realistic headless web browsers in a completely serverless manner, so you don’t have to operate any of this testing infrastructure, which is a huge relief. You can now take photographs, so to speak, of those components, and then no regressions can easily be introduced. Visual testing is an incredible asset to greatly benefit from this new basically world of constantly previewing and making your work accessible to a real web browser.
And then there’s obviously the more traditional ways of doing integration, testing, and unit testing. And I also think that React and Next.js there provide some advantages from a testing standpoint because every time that you control your effects and you model your effects, you’ll have a better testing story. With jQuery, it was hard to write tests because everything is dependent on arbitrary side effects, and it requires tons and tons and tons of mocking.
Testing benefits from React being functional and declarative
But now React has this other benefit. Again, to me, it all relates to moving toward this declarative and more functional world. You’ll get some testing benefits with that fundamental plumbing as well. So for those that are not so familiar with modern React, modern React is basically a combination of functions and hooks. And the fundamental constraint is that this render function has to be pure. So the way that you attach behavior to the rendering of your UI is through hooks. This is a very clean way of organizing the world.
React components have this idea of also modeling reproducible behavior that I think is quite fascinating. And as a result, you can be a lot more ambitious with your front end. You can make it a lot more real-time. Instead of having to press refresh to get the latest data, you can subscribe to data changes. And I think opens up realistically, a new world of possibility for your product itself. How ambitious can you be with what it does?
The risks and rewards of microservices
Darko (27:45): One of the things we touched upon before our call is that you also mentioned how you can swap different components and play together. Yes, you can keep maybe 90% of Rails APIs that you developed over the years, but then moving forward, you can rely on some new headless APIs, as you mentioned, headless CMS and so on. You are in the first line of this. What’s your perspective on the services that are providing these APIs? What’s the state of things right now? Are you happy with what the offering is, and what do you see in the future?
Guillermo: The trend is very clear because we said, “Okay, split the monolith between back-end and front-end.” But then another step from it splitting into back-end is splitting into multiple back ends. That’s where the microservices world emerged.
But what happens is when you have all these distributed systems, all these, network calls all this state in multiple places, I see two things that are very important moving forward. One of them is that you have to understand state very deeply to make really good decisions.
The flip side of that, too, is that when you perform mutations on your back end and those mutations have a series of chained side-effects that relate to those other microservices, the problem of transactional consistency and availability rears its ugly head. What happens if one of those systems is temporarily down? Who reconciles the data later and who retries and for how long and who gets paged?
Emerging patterns and systems mitigate microservices risk
What I’m seeing in the future now is a response to this because I think the benefits of microservices outweigh this risk, which is the emergence of patterns and systems that will mitigate this risk. And not only will they mitigate the risk, they’ll actually make it easier for the developer to write this complex logic that touches hundreds of systems. They might write them even in ways that make the systems not look asynchronous at all. I always refer to syntax and imagine if async and await, the keywords in JavaScript or C-sharp or whatever disappeared. You’re just enunciating what all the effects are and what are all the business rules. That compiles down to a complex infrastructure system that keeps track of the evolution of this state machine and the retrying between the synchronization of the pieces and so on.
Long rant, but I think microservices are an incredible thing. I think you always have to be aware of the risks and the benefits. I think that’s true for any system you take a dependency on, but I think the future is very bright.
Darko (37:33): As you wrapped up nicely, the future looks bright and I’m happy to hear about all these systems, how they are emerging. And they are certainly going to help solve a lot of our engineering issues. Good luck with Vercel and Next.js, and hopefully we’ll see you again in the future.
Guillermo: Thank you so much. I had a lot of fun. Thank you.
