The Micro-Frontend Revolution at Amex

Rate this content

How do you scale a web application to be developed thousands of engineers and upgrade it to use the latest Javascript technologies (Nodejs + React)? The answer is, using Micro-Frontends!

American Express is a pioneer in the usage of this architecture using it in production since 2016 and transforming the face of a website used millions of users worldwide.

28 min
24 Jun, 2021

Video Summary and Transcription

This Talk discusses the micro front-end revolution at American Express, highlighting the challenges of independent delivery and the solution of micro frontends. The architecture involves a Node.js server for server-side rendering and module composition, with Holocron modules deployed to a CDN. The development workflow includes local development environments and CI pipelines. Microfrontends are a pattern, not a set of tools, and should be implemented based on the specific use case. The adoption challenges include reworking the architecture and implementing features like Webpack and Module Federation. Communication between modules should be kept independent, and migration to micro frontends is simplified with existing microservices and Kubernetes. Server-side rendering is optional, and bundle size is limited to 250K.

Available in Español

1. Introduction to Micro Front-end Revolution

Short description:

Hello, everybody. My name is Ruben and I am a software engineer at American Express. Today I'm going to talk about the micro front-end revolution that took place at American Express. Let's start with a story. Imagine you are just being hired as the new CTO for a large corporation, responsible for digital transformation and scaling. You decide to add more developers and create smaller autonomous teams. However, applying these methods to the frontend presents challenges due to a large monolithic application with legacy code. Communication issues, friction, and difficulty in adding new features arise. A complete rewrite seems daunting, but let's pause for a moment.

Hello, everybody. My name is Ruben and I am a software engineer at American Express. And today I'm going to talk about the micro front-end revolution that took place at American Express.

So, first of all, let's start with a story. Let's imagine that you are just being hired as the new CTO for this very, very large corporation. So, you are responsible for the digital transformation of the company, as well as fixing issues with scaling. And you're in charge of fixing these issues.

So, the first decision that you make is, right, so, we need more developers. We need to add more people, and that's what you do. So, you also are a fan of the two-pizza rule, and you think, right, we need to create smaller teams and add those developers to those teams. So, we create smaller autonomous teams, and because in the past, you were part of this previous company and you had some previous experience, you think, oh, I think we should do microservices architecture here. It's a good idea. It's been proven. There are a lot of resources out there, and it's widely adopted.

So, let's make the most of the microservice architecture, and let's make the most of horizontal scaling, because we know that vertical scaling is not enough at some point, so we want to start doing horizontal scaling. And that is great. That is working very well. Until, well, until we try to apply these methods to the frontend. And what happens with the frontend? Well, the frontend, let's imagine this frontend is a really large monolithic application. It has a lot of legacy code. All the engineers are working on the same codebase. And if we want to add more engineers, obviously this is a bad idea, because they are working on the same codebase. So, the more engineers you add, the worse it becomes, because it will be just a nightmare to manage so many people working out of the same codebase.

So, the frontend has a lot of challenges. And these challenges are communication issues, friction, it takes longer and longer to add new features, fixing and finding bugs becomes a challenge, very hard to keep production and development environments in sync. And at some point of our careers, we all have had this question. We all were, like, what about a complete rewrite? And you think, oh, is that even possible? It seems like a very, very difficult task. Seems like an impossible task. But you're considering, right, we need to do a complete rewrite. Now, but hold on a second.

2. Challenges of Independent Delivery

Short description:

I think we have seen these problems before. We had this when we were adopting microservices. Independent delivery could be a turning point for large organizations to allow teams to deliver faster and collaborate more effectively. However, dividing the frontend into subdomains and allowing independent delivery can cause more challenges than solutions. Building applications in silos leads to fragmentary user experiences and the need to duplicate functionality. Upgrading and managing becomes difficult, resulting in authentication issues. Scaling a web application to be developed by thousands of engineers and adopting the latest technologies is a loaded question.

I think we have seen these problems before. We have seen all these communication issues, all this stuff. We had this when we were adopting microservices. So we think, hmm, what do we need to do to apply the microservices to the front end to solve these issues?

So the first thing you try is, well, I have seen this quote somewhere. Independent delivery could be a really turning point for large organizations to allow their teams to deliver faster and freely and to collaborate more effectively. And you think, well, that's it. I need to allow them to deploy independently. I want to allow them to deliver independently so they don't work on the same code base and they can deliver independently. And that's our first approach. And we try to divide the frontend and let's say that we are going to divide it into subdomains.

So, we give every single team a subdomain and they're going to build the application on that subdomain and everyone should be happy with that and we will solve a lot of issues. Well, actually, having that just independent delivery could more problems and more challenges than actual solutions. And let me expand on that.

Why this will cause more challenges. Well, if we give people their own subdomain or their own place on the website, teams will tend to start building applications in silos. And what is a silo? Well, it's a way of building software that is very difficult to communicate with another piece of software. So, the application and the features are built in siloes, and we start seeing people doing their own thing. Now, that also causes fragmentary user experiences. Because they're using their own tools and they're following their own thing, and they just don't care about communicating with other teams. We end up with a very disjointed user experience where the website might look very different if you go to one subdomain or if you go to a different subdomain of the website, when you're transferring, hold on a minute, the website doesn't look the same, and it starts looking very different.

Now, if we start also building the same functionality over and over, for example, if we want to build a different variation or if you want to translate that page to a different language or launch a different market in a different place, we end up building the same functionality again and again just because it has some variations in language or different regulation in different parts of the planet. So, we start building the same thing over and over again. There is no reuse. Also, because it's really difficult to upgrade and manage, things are everywhere and it's very difficult to have somewhere to update something in one place that will propagate throughout the website. This one is really annoying to me when you have authentication issues and you're on a website and it's asking you to log in again. But hold on, I just logged in on this part of the website and it's asking me to log in again. So, we end up with a lot of authentication issues and persistent authentication. Now, this is the big question. This is a big question on this presentation. How do we scale a web application to be developed not just by hundreds, but by thousands of engineers and upgrade it to use the latest technologies? It's a very loaded question.

3. Micro Frontend Solution

Short description:

Applying micro frontends is a solution to fix the challenges and problems faced in implementing independent delivery. American Express has been a pioneer in this approach since 2016, using a framework that allows the creation of server-side rendered micro frontends. This framework enables modular design, independent deployments, server-side rendering, enterprise security, and easy internationalization. The key advantage is the ability for each team to deploy their own changes without restarting the server.

And this is what we want to try and solve. This is what we want to achieve. So, let me just tell you, just drumroll, what is the solution? Well, this is one solution. Applying micro frontends. A micro frontend is just a way to apply the microservices architecture pattern to the frontend. And it's a set of tools that will allow us to do that and fix all those challenges and problems that we are facing.

So, how do we do it? A bit of history. American Express is actually a pioneer in the implementation of micro frontends. And since 2016, we have implemented this framework that allows us to create server side rendered micro frontends and compose them on the page. So, this framework solves a lot of these problems. And I'm going to talk a little bit about how this framework and how the concept behind the framework has helped American Express solve the scaling issues. So, let's have a look.

First of all, what we have solved and what features have helped us solve some of the problems? Okay. Let's start by the modular design by default. What do I mean by modular design? Well, we are building instead of entire pages or entire applications, we are building modules. And these modules allow us to deploy them independently but also we can give parts of the website, not just the subdomain, just very granular parts of the website to independent teams. An example of this would be there is a team that handles the header and the footer and the overall navigation. That overall navigation, the team will be in charge of making sure that it's translated to all languages, they will make sure that it has the latest version, latest colors, latest links and everything. And also we probably have another team handling the authentication. If I'm one of the teams developing a page, I know that I don't have to worry about the header or the footer or the newest links that have to be added, because I can just drag and drop that module onto my page and then just get on with my development. The same with authentication authorization. I don't have to worry about implementing authentication many times because I know there is a module that allows you to do authentication. This also provides server-side rendering and this application allows us to do not just client-side interactive experiences, but also server-side render our applications, which is important for SEO. It also provides us with enterprise security. It's very important that you manage that from a centralized place and make sure that everyone is compliant with security. Implement things like the content security policy, which is an industry standard, just ensuring that every single module provides the security required. If you remember before, I mentioned when you try to do different markets or internationalization, the app provides that option to translate those modules and just reuse them in different contexts. The main feature of all, as we discussed before, is allowing independent deployments. Every single team will have their own capability to deploy to production without having to deploy the entire website, entire application. And the most important of all, there is no server restart.

4. Micro Frontend Architecture

Short description:

So you can deploy independently. The Node.js server provides server-side rendering and module composition. Holocron modules, built on React, handle business logic and user experience. The Node.js server is just the orchestrator. In production, Holocron modules are deployed to a CDN with static assets, server code, and client code. The module map JSON file determines which modules are active. The 1Up server checks the module map for changes and loads modules into memory. When a user types the URL, the modules are composed on the page.

So you can deploy independently. You don't have to restart any servers when you deploy. The server will just carry on running. And this is probably when you start asking, okay, show me the architecture, show me the code, show me what is behind the scenes of this framework. Okay. So, we are going to see the technology behind this. And the technology is basically we have a Node.js server in the background that is just a long running server. That server provides the server side rendering, it provides the composition of different modules.

And on the right hand side, we have the Holocron modules which are basically micro frontends built on top of React. Yes, Star Wars reference. We like Star Wars and Holocron modules is the name we have given to the modules and the micro frontends. And these modules are in charge of the business logic. Are in charge of the user experience. So, there is no business logic or nothing is built on the Node.js server. The Node.js server is just the orchestrator. It's just the container that is in charge of the server side rendering and decomposition. But all the logic and all the applications are built as independent Holocron modules. And we are using React to allow this composition model.

Now let's take a look at the diagram and what happens when we are in production. So, in production, we have, again, the Node.js server is the long running process. And we have our Holocron modules deployed to a CDN. Those modules on the CDN are deployed and they have the static assets, the server code, as well as the client code. And the way that we know what modules are deployed to the particular application that we're working on is by using something that we call the module map. The module map is just a JSON file that is very similar. You can think about the module map to something like the package to JSON file where we have a reference, a list of modules and their versions and what modules should be active on this application. So, what the 1Up server does is keep checking this JSON file regularly for changes and it will find out if a module has been updated, if it has been removed or it has been added. And those modules are added into memory. Those modules in memory are ready to be rendered and to take requests. So, after the modules are loaded into memory, when the user types the URL, the request will come to the one app server and then we will have the modules composed on the page. So, if you look at the diagram below, we have the root module, which is basically the module where we configure the application and we contain the other modules and then we have individual modules on the same page.

5. Development Workflow and Conclusion

Short description:

You can load different modules on different URLs and compose them as per your requirements. In development, each module has its own repository and CI pipeline. A local development environment pulls the 1-up server and modules from Docker. Changes can be made to specific modules, composed locally, and tested before deployment. The CICD pipeline handles unit and integration tests, publishing to the production CDN, and updating the module map at runtime. Microfrontends have solved scaling and deployment issues, but there isn't a single approach.

You can also load different modules on different URLs and compose them it's up to the developer and up to their requirements how to compose those modules on the page. Right. So, this is more or less what happens in the production.

Now, we most of us are developers. Let's see. How do you manage this in development? Because the first question that we might have is, right, we have let's say 300 modules in production. How am I meant to use all this code? How am I meant to download this code and make a change? Well, every single module has their own repository. They have their own CI pipeline and they are they have isolated.

So, they have their own code base. So, the way we do this is we have a local development environment that will pull the 1-up server from a Docker image. We also have a CDN locally. So, what happens is if I want to make a change to one of the modules, I just clone the repository into my local machine, make the change, and the 1-up server locally from Docker will load all the rest of the modules that are in production and it will compose them for my application. So, I don't have to download all the code. I can just download the module I want to change, compose it locally, test it, and then it will be ready for deployment.

So, this is what happens in development. It's a very easy way just to manage separate codebases. And, again, the CICD pipeline and everything is individually for every single module. So, after I have made the changes to my module, I will do independent unit tests. I will also perform some integration tests to make sure that the module behaves as expected when running in the environment with the other modules, and then I will push it. After I push it to production, the CICD pipeline will publish it to the production CDN, and then the production one observer will pull that module from the module map and a new version will be installed. Everything happens at runtime. The one observer does not need to restart when a new module is added into memory. It will just find a new module, put it into memory, and then you have something in production. So, this is very powerful because it means that you don't have to worry about deploying things and restarting servers and downtime, because the server is always running and modules can be just added and removed at runtime.

Okay. So, this is just a conclusion. And the conclusion is, well, this is great. This has worked very well for us. Microfrontends has been an architecture that has solved a lot of problems with scaling, making sure that we can have thousands of developers working on the same application without having a lot of problems with single codebases and a lot of problems with deployments. But the conclusion is, there isn't a single approach.


Microfrontend Patterns

Short description:

There isn't a single solution for this problem. Microfrontends are a pattern. They are not a set of tools or a framework they can just plug and play. It depends on your use case. Different companies will have different issues and you will have different things that you can solve. Should micro front ends use a single framework language or have multiple? It looks like the majority think a single one. The thing with micro contents is that people think they are all about mixing frameworks. And that is completely that's not true. You should use one. I mean, you can use multiple frameworks. But at the end, I don't think it's recommended for performance issues. You also have to think about the team cost, you know. It costs a lot more to have a developer that knows all of these frameworks than to have one that maybe is just specific to one.

There isn't a single solution for this problem. Microfrontends are a pattern. They are not a set of tools or a framework they can just plug and play. It depends on your use case. And your specific use case will likely drive the requirements and the architecture that you need to use to solve the scaling problems.

So, different companies will have different issues and you will have different things that you can solve. So, just to conclude, the one up framework is open source if you want to take a look at it and just let us know what you think.

So, yeah, thank you very much. And I hope that you enjoyed your presentation. Now I just hope that you have some questions. What do you think? Should micro front ends use a single framework language or have multiple? It looks like the majority think a single one. What do you think of that?

Well, that was a great question. Because the thing with micro contents is that people think they are all about mixing frameworks. And that is completely that's not true. That's not what micro frontends are about. You should use one. I mean, you can use multiple frameworks. And there is a valid use case. Let's say the application is built on Angular JS and you want to upgrade it to react. Then you could use micro frontends to do the upgrade, like the straggler pattern, which is upgrading the application incrementally. But at the end, I don't think it's recommended for performance issues. I mean, you could. And I have heard people saying we gave the developers the flexibility to use the framework that they wanted to use. And at the end, they ended up using just one framework because it's the one they are more comfortable with. So, yeah. Yeah, yeah, yeah. You also have to think about like the... I would think that you'd have to think of the team cost, you know. It costs a lot more to have a developer that knows all of these frameworks than to have one that maybe is just specific to one. Yeah.

Microfrontend Adoption Challenges

Short description:

Adopting a Microfrontend pattern onto an existing framework is a challenge because it requires reworking the architecture to allow independent deployments. The key feature of Microfrontends is the ability to deploy parts of the application independently without restarting the entire application. This can be achieved with any framework by implementing features like Webpack and Module Federation.

That's a point. We have some questions from our audience, our lovely audience. Dr. Jessie Pye asked, does NestJs fit for my current front ends? NestJs. Well, probably we need to talk to them about this topic. Nest, sorry. Yeah. I'm sorry. I missed the question. Well, the thing is, adopting a Microfontend pattern onto an existing framework is a challenge because it's completely a way of building architecture. And the key feature of Microfontend to allow any framework to use this pattern is allowing independent delivery so that you can deploy parts of the application independently without having to restart the entire application. So possible is with any framework, the question is, you know, it has to be reworked to allow independent deployments. And features like Webpack, Modifederation could help with that. Gotcha.

Module Communication in Micro Frontends

Short description:

Modules in micro frontends should remain as independent as possible, avoiding tight coupling. While it's crucial to keep them independent and load the data they need, there are cases where communication is necessary. You can choose mechanisms like sending events or using state management tools like Redux. However, it's important to avoid tightly coupling the micro frontends.

That actually kind of leans into our next question from Maxim Leont. How do you solve problems with modules' communications? And Danji also asked how do modules communicate with each other? Okay. So communication is you can choose what communication mechanisms you want to use but the main thing that you need to bear in mind is that modules should remain as independent as possible. So it's not a traditional application development where you just pass data down cascading or using props. With microphone 10s it's very important to keep them independent so they load the data they need and they are not depending on other microphone 10s and they are not tightly coupled to each other. That is very important with microphone 10s. Now there are obvious cases where that's not possible and you need to send communication and you need to update other microphone 10s depending on the state of other microphone 10s. So at that point you can choose your mechanism. You can use just sending events, that's one solution. Other people prefer to use a state management like global state management like Redux for example but sharing a state is also a bit difficult. It's very important that you don't tightly couple those microphone 10s so it depends on your implementation. But again, very important, do not couple them.

Micro Frontend Migration and Infrastructure

Short description:

David Liam asks about migrating a microservices team with UI for each service to micro frontends. The best place to start is when your company already uses microservices, has large-scale applications, and uses Kubernetes. Implementing micro frontends allows for domain splitting and ownership of specific parts by teams. The trend of backends for front ends simplifies the process, as the backend microservice provides information to a single front end. The infrastructure is managed by other teams, but new micro front ends come with their own repository and automated infrastructure setup. This eliminates the need to start from scratch and ensures easy management and deployment to different environments. Micro frontends can be implemented without server-side rendering if it's not necessary for the application.

Yeah, that sounds like it's bound to get messy if they're coupled too much. David Liam asks do you have any recommendation on how a micro services team with UI for each service would migrate to microphone 10s?

Actually, that is the best place to start consider on a microphone 10 architecture. So if your company is already using micro services, you have large scale applications and you're using kubernetes, and you have a lot of distributor teams who own their own part of the product, it's a very good place to start implementing microphone 10s because at that point, you can start a domain split of your application, where you can just give the team the responsibility for that part. And they will be responsible for the backend and the front end. And also there is a new trend, which is backends for front ends, where the backend micro service will be in charge to provide the information just to one front end. And if you follow the micro front end pattern, then that will be easier, because it means that the team can own the entirety of that product or experience.

That's really interesting. It ties into Andre Calisson's question. You've mentioned that the team can own the front end, the backend. Andre's curious about the infrastructure. So they ask, what does the composition of teams at Amex look like? You said each model has its own CI-CD pipeline. Are they also responsible for maintaining these infrastructures? How does it look like when a new team is formed? How do they get started with their own module?

Right. So the infrastructure is something that is managed by other teams, but we get everything set up by default. So when you start a new micro front end, you'll get your own repository and there is some automation to create infrastructure for it. So you could create some automation to add all the jobs that are required for the deployment of those micro front ends. So it's part of the infrastructure onboarding and with some nice automation, it's something that is very easy to manage, so you don't have to worry about starting from scratch. Every time that you create a new micro front end, everything will just come out of the box.

That's awesome and probably helps with team velocity so that it's less overhead cost when you start, right?

Yeah, that's correct. So you don't need to worry about the infrastructure, you just need to create your micro front end, deploy it and then everything will just be deployed to the different environments. That's so nice. I want that.

Yeah. We have another question. We actually have tons of questions. People love this talk, way to go. House of Alejandro asked, he says, awesome presentation. Agree. And they also ask, what do you think about micro front ends without server side rendering? Would it be as good as a solution as a server side rendering approach? Well, server side rendering is something that we added to our micro front ends, but it doesn't mean that you have to. And you will find the answer to that question is, do you need server side rendering on your application at all? So if you have a client side rendered application that does the job and you don't have to worry about SEO or anything like that, again, the rules that apply when you are choosing server side rendering or client side rendering apply in the same case. The only difference is that those applications are deployed independently.

Server-side Rendering and Bundle Size

Short description:

In our framework, we have server-side rendering, but client-side only applications with micro frontends are also easier. If it's a single-page application, client-side only, that would work too. We limit the micro frontend bundle size to 250K, achieved through webpack externals and dynamic import. Thanks to everyone for the great questions!

So it's nice that we, in our framework have server side rendering, but also client side only applications with micro front ends will definitely be easier. That's that's something to bear in mind. Server side rendering does add some complexity as well. So if it's just a SPA, like a single page application, client side only, that would also work. Nice. Yeah.

So William asked and we have this is a very short last question. So no pressure. Did you see a big increase in download size when adopting micro front ends? I can imagine all those modules bring all kinds of dependencies. How did you solve it? This is a great question. So we have a limit. So 250K for micro front end as a baseline. And the way that you achieve that, so the bundle size is not bloated is by using a combination of webpack externals and combination of dynamic import. So you can achieve a smaller bundle size. But that is the main thing that we want to make sure they're not too big. That's a good rule. What a great question.

Thanks so much to all of the folks who asked questions. Ruben, there's a couple of questions left if you want to hop into Discord and give them an answer. And let's all give a big round of virtual applause to Ruben.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
JSNation Live 2021JSNation Live 2021
113 min
Micro Frontends with Module Federation and React
Did you ever work in a monolithic Next.js app? I did and scaling a large React app so that many teams can work simultaneously is not easy. With micro frontends you can break up a frontend monolith into smaller pieces so that each team can build and deploy independently. In this workshop you'll learn how to build large React apps that scale using micro frontends.
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js ( Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow ( 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.