The post looks at some options moving forward for developing applications using React/Angular/Vue with ASP.NET Core. Each option has it’s own advantage and short comings depending on the application requirements.
SpaServices & NodeServices going away
SpaServices and NodeServices become deprecated, starting at .NET Core 3.1. And they will be removed when .NET 5 arrives. .NET 5 is Microsoft’s effort in merging .NET Core & original .NET framework as one. There’s no .NET Core 4. .NET 5 is what comes after .NET Core 3 and it’s coming soon.
What does that mean? Especially to those who develop Javascript based front end application such as React & Angular together with .NET framework.
The Catch
You can still develop Javascript based front end application with ASP.NET framework. But server side rendering would not be possible without SpaServices/NodeServices support. If server side rendering is important for your application (e.g. Search Engine Optimization), then it’s important to identify the migration path for your application moving forward.
Migration Options
- Staying as is
- Moving forward without server side rendering
- Split up front-end and back-end
Staying as is
Continue to use SpaServices and/or NodeServices by not upgrading to .NET 5. This works best only when you anticipate the application lifespan is ending in next 2 or 3 years. Or the application would continue to work and in service with minimal changes.
Moving forward without server side rendering
Basically if your application can go without server side rendering, you can continue to develop React application together with ASP.NET without problem.
When Google and other search engines can fully fetch your React/Angular application, SEO may not be a problem anymore without server side rendering. Tool such as Google’s Fetch as Google would be good to assess how Google sees your website.
Split up front-end and back-end
Separate front-end and back-end. Build front-end using framework such as Next.js. Use ASP.NET & .NET Core for API services and back-end server. While there is quite a bit of work involved to restructure the application architecture, it does provides a few potential benefits for the project.
Decouple bigger application into more smaller components
Separating front-end and back-end probably is a good starting point in decoupling big application. This could also be good path in moving toward microservices architecture.
Next.js framework
Next.js is one great framework worth consideration. It allows you to continue React application with server side rendering. And actually, server side rendering is done much easier than using SpaServices in ASP.NET.
Another great feature is that Next.js has an option to generate your front-end application into static files with data pre-rendered to the files at build time. This option may not work for all use cases, but when it does, the performance is top notch.
I have successfully migrated React ASP.NET projects using Next.js and it’s an awesome experience.
Gatsby framework
Worth noting is another great React framework: Gatsby. It’s a open source framework to help generate static web files using GraphQL to render pages with data during build time.
In my opinion, both Next.js and Gatsby can give you the best performance with SEO support if serving React application using static web pages work in your use cases.
Serverless
Start decoupling the application also brings in another benefits, the possibility of going serverless, or partial serverless.
For example, ability to generate static files using Next.js allows you to host front-end application using serverless cloud service such as AWS S3 Website hosting with/without CloudFront.
For Next.js, you can also deploy it serverless using Lambda@edge / Cloudfront distribution.
Cloud Migration (Serverless infrastructure)
Additional opportunities I see while doing this migration is the further decoupling of API and back-end services support. And some decoupled components can be migrated to some cloud serverless infrastructure. Below shows some possibilities:
- Identity management: from ASP.NET identity to AWS Cognito.
- API Services: from ASP.NET API controllers to AWS API Gateway + Lambda
- Database: from standalone RDBMS to AWS RDS, Aurora serverless or DynamoDB
This does not have to be done all at once. When we can start decouple components, we can do it one by one gradually, for whatever make sense to the application.
