Hosting React Apps on .NET Stack
How to make Asp.NET 5.0 host and serve your React Apps anywhere.
Build and Serve React Apps with Asp.NET 5.0
There are a few ways to build, deploy and run React Apps on Azure App Service, one of them being through running that in .NET stack through an Asp.NET shell. The others could be through Node stack.
In this post, I will show you how to configure your .NET web server to server your React bundles.
This guide is pre-requisite to App/API deployment, which I have covered in How to auto-deploy Asp.NET 5.0 APIs & React Apps using codified pipelines and Azure DevOps.
By the way, this topic belongs to the series to set up a Single Page Application using React, Redux and Asp.NET 5.0.
- Styling and Theme Management
- Global Navigation
- Responsive Layout
- Forms and Input Validation
- Routing
- Configuration Management
- API Call and Activity Indicator (Spinner)
- Monitoring, Logging and Instrumentation
- Toast Notification
- Redux and Store Setup
- Google Maps with Polygons
- SEO — Search Engine Optimisation
- Running React App on .NET Stack
- Deploy React App to Azure App Service
What We Touch
The changes I need to apply to my app are across the below areas:
- React App: Configuration changes to make my app production ready
- Asp.NET Shell: to build and prepare artefacts and make them ready for deployment
1. Make React App Prod-Ready
We have talked about configuring our react apps before when we touched on Configuration Management for React. Now what we need to do, is to revisit our env.production file, and make sure the values there are not for test environment.
White Screen of Death
It could happen that after your first deployment, when you type in your app URL in production, you only see a white screen. Most probably it is due to the fact that PUBLIC_URL has not been set property. It should point to your domain name.
Also, if you are using your own domain name, you should define that as a custom domain and use the same value in env.production file.
2. Asp.NET Shell
This is the shell that sits between your React app and your host, be it Azure Win/Linux, LocalHost, etc. It acts as a web server to manage the traffic to your React app, and can take care of things like:
- Building and Packaging
- Serving Static Files
- Response Caching
2.1 Building and Packaging
If you have built your app using create-react-app, WebPack will do all the work for you, however you need to initiate the process, to make sure Node is installed, npm is installed, and artefacts are produced and properly located.
For those purposes, I have relied on my Asp.NET project file to run those command when the project is being built. Here is my whole project file:
Step 1: is to make sure Node and NPM are there, which I am doing that by running DebugEnsureNodeEnv check before the Build begins. If they don’t I fail the process with a relevant error message.
Step 2: Publish and run WebPack, which is being done by PublishRunWebpack.
As you noticed I have also defined a variable called SpaRoot that refers to the folder which will contain the UI artefacts, and it will be used for deployment as well. I will use this path (UI), when I want to refer to these artefact to server app traffic.
Note
Configuration, plumbing and troubleshooting your software foundation take a considerable amount of time in your product development. Consider using Pellerex which is a complete foundation for your enterprise software products, providing source-included Identity and Payment functions across UI (React), API (.NET), Pipeline (Azure DevOps) and Infrastructure (Kubernetes).
2.2. Serving React Files
Now we are in a position to route the traffic to our packaged bundles. The way I do it is through the middleware pipeline in the Startup file, and once again, make sure the order is followed as order does matter like in any other middleware pipeline.
As you see, I am doing a few tasks here:
- Serving: the package I produced in the last step.
- Compressing: to ensure the client receives the files as fast as possible
- Caching: for 1 day to ensure the pages are served with minimum required processing
Pellerex Foundation: For Your Next Enterprise Software
How are you building your current software today? Build everything from scratch or use a foundation to save on development time, budget and resources? For an enterprise software MVP, which might take 8–12 months with a small team, you might indeed spend 6 months on your foundation. Things like Identity, Payment, Infrastructure, DevOps, etc. they all take time, while contributing not much to your actual product. These features are needed, but they are not your differentiators.
Pellerex does just that. It provides a foundation that save you a lot development time and effort at a fraction of the cost. It gives you source-included Identity, Payment, Infrastructure, and DevOps to build Web, Api and Mobile apps all-integrated and ready-to-go on day 1.
Check out Pellerex and talk to our team today to start building your next enterprise software fast.