My current project uses the Ext JS framework and I am not familiar with how to update it to use the new backend which is ASP.Net Core. Where do I start from here?
I believe Ext.NET (https://ext.net/) would help you out.
Combining the leading client and server-side web technologies, including Ext JS and ASP.NET, Ext.NET brings a rock-solid component framework for web application development. Focus on creating your critical business logic while Ext.NET handles the web components for your applications. Its unparalleled cross-browser compatibility and advanced MVC architecture empower devs to create structured and scalable enterprise-grade applications.
My main concern is the utilize the concept of Server-Side Rendering (SSR) with the Asp.Net Core API project and NextJs. I have been trying for a while to run the NextJs with Asp.Net Core API as SPA just like we do with the available templates (React or Angular) on Visual studio. But ended up with some unfamiliar issues.
In the first place, I would like to know, is it possible to use NextJs with Asp.NetCore Web API as SPA for SSR without using external dependencies? I have found some articles mentioning about razzlejs and ReactJs.Net, Is it worth using them?
I will really appreciate your guidance.
Thank you.
I want to build a REST API for use with an Angular SPA.
My database is hosted on a SQL server through Azure.
A lot of online material I see when I search is for other types of databases or technologies.
I already have the database created.
How can I do this?
EDIT: I want to use ASP.Net Core for the API
but will use Angular to consume it.
I would recommend the following:
Architecture:
If your Angular SPA is Angular 2+ ( Typescript ): Setup a new .NET Core 3+ Web API project with entity framework (since it is a relational database). I would expose all the endpoints using swagger for .net and I would map all those methods on the SPA with a swagger client generator for Typescript.
If your angular SPA is not based on typescript, then I would not install swagger since the frontend is not strongly typed.
Hosting:
If you have an Azure account I would host both on Azure then you wouldn't have to expose your SQL Server to the web or create a VPN for that. Azure has also nice hosting for .NET Core projects.
If you need to make it really scalable
In this case, I would recommend you to publish this ASP.NET Core App building a container and have it running on Kubernetes or other container management server and have a load balancer to have the backend promoted with no downtime.
I'm confused whats different between Razor components and Blazor and which is better and in the last release .NET Core 3.0 Preview 3 the add those to Razor Components
Razor Components improvements:
Single project template
New .razor extension
Endpoint routing integration
Prerendering
Razor Components in Razor Class Libraries
Improved event handling
Forms & validation
Essentially there are 3 parts to understand.
Razor Components
This is the name for the core, out of process, component model which was created back in July 2018, for the first release of Server-side Blazor.
Razor Components is the core of the framework and contains all the following things.
Parameters
Event handling
Data binding
Routing
Dependency injection
Layouts
Templating
Cascading values
Server-side Blazor
This is the server-side hosting model, running on ASP.NET Core, for Razor Components. This version hosts the Razor Components model on the server. It uses a small runtime to send UI events from the browser to the server. Once processed by Razor Components, any UI updates get sent back from the server to the browser and the runtime handles updating the DOM. All this communication is handled via a SignalR connection. Even JS interop calls are handled this way.
Client-side Blazor
This is the client-side hosting model for Razor Components.
In this model, everything is hosted in the browser. Mono, compiled to WebAssembly, is the .NET runtime. On top of this sits Razor Components and then finally the application.
The great thing about this architecture is that any feature added to Razor Components should, in theory, be available to both hosting models. Although in reality, this is not always the case.
What's better?
That very much depends on what you want to do.
Client-side Blazors biggest drawback is its download size. This alone could rule it out for many developers. Downloads are easily into multiple MBs which if someone is trying to view your app on a mobile with a slow connection, they are not going to have a great experience. However, it's worth noting that after the first download a lot of the content is cached so subsequent loads can be a few 100kb.
Client-side Blazors debugging experience is very primitive right now as well. Which means working on it as a developer can be challenging at times.
Server-side Blazor has a much nicer developer experience in terms of debugging. The app is much faster to download and only has a size of a few 100kb before any caching takes place.
The downside is potentially scalability. But this will very much depend on the number of concurrent users you are expecting. Because this model uses SignalR your app will have a top limit on concurrent connections. But, you can manage this by plugging into Azure SignalR to allow a far greater number of connections to your app.
Ultimately, both hosting models of Razor Components have a long way to go. The authentication stories for both are in very early days, although client-side Blazor is arguably in a better place. The routing engine is still limited, forms and validation have only just had it's first release and there is still work to do.
Another thing to keep in mind is that it is possible to swap between the models pretty easily. So whatever decision you make you're not tied into it. There will even be a way of doing this built into the framework at some point so nothing you do now will be wasted.
Any questions, please ask. But I hope this helps.
Razor Components is a framework with which you can create SPA web applications. It is divided into two mode of execution. When the web app is hosted and executed on the browser, it is called Blazor. Blazor applications are written in C# and compiled into .NET assemblies. They are executed and run on the browser as .NET assemblies by the Mono run time, which itself is compiled to Web Assembly.
The second mode of execution is server-side. That is, your web app is executed on the server, not on the browser. Note that here the runtime environment is not Mono Web Assembly but the Asp.net Core run time. This is called server-side Blazor, but the term Razor Components is used as well, so that the confused get perplexed. The reason for this is historic: At the beginning, there was only Blazor running on the browser. But then came the idea that a web app can run on the server, and only the diffs can be send to the browser by means of SignalR. Running the web app on the server is much easier than running on the browser, and the developer can use many elements he can't use on the browser, such as debugging, etc. As a result of this possibility, the Asp.Net renamed the Blazor framework as Razor Components, which you can treat as a super structure on which Blazor is built. This is why the confusion. Let's emphasize this division as follows:
Razor Components --> Blazor (front end; browser)
Razor Components --> Razor Components (server-side Blazor )
I know this is a source of confusion, but this is it...
As to the question which is better, I may only say that it depends exclusively on your requirements. Each of these mode of executions has its benefits and drawbacks. Blazor applications are more suitable for running on the internet as public web sites, whereas server-side Blazor application are best used on the Intranet as enterprise web sites.
The list you displayed is related to Razor Components framework. Some improvements, for the time being, may only be relevant to Blazor, others to server-side Blazor. There is only one way to know which is which: To learn Razor Components. It takes time to learn it, less than Angular, especially if you are a .Net developer, but it is still something which requires some investment.
Hope this helps...
I'll improve on it later on, but if you have specific question don't hesitate to ask...
You have every right to be confused, the naming has changed a lot and when you wrote the original question the Blazor team had recently renamed 'Server Side Blazor' as 'Razor Components'. That has thankfully since been abandoned, see the timeline below for more on that.
To anyone finding that the naming conventions in the answers here don't seem to marry up with what they are reading in older blog posts it's worth knowing that the meaning of 'Razor Components' has changed repeatedly over time.
This may also help anyone like me who has been using Blazor since near the beginning and feels sure that the names have changed!
TL; DR
The naming has evolved a lot during the pre-release period. Kudos to the Microsoft and the Blazor team for trying to come up with clear names and being willing to change back when needed. However, this has left a legacy of mixed naming conventions in older articles and some Blazor veterans sometimes use older naming conventions.
At the time of writing in September 2020, with Blazor at version 3.2, the official naming convention is:
Blazor Components (formally called 'Razor Components') can be used in...
Blazor Server apps, or ..
Blazor WebAssembly apps
The exciting history of Blazor naming
October 2018: 'Razor Components' becomes the new name for 'Blazor Server Side'
When Blazor 0.6.0 was released it was decided to officially name server side Blazor as 'Razor Components'.
Dan Roth discusses that in his Blazor 0.6.0 experimental release now available blog post in October 2018:
We announced last month at .NET Conf that we've decided to move
forward with shipping the Blazor server-side model as part of ASP.NET
Core in .NET Core 3.0. About half of Blazor users have indicated they
would use the Blazor server-side model, and shipping it in .NET Core
3.0 will make it available for production use. As part of integrating the Blazor component model into the ASP.NET Core we've decided to give
it a new name to differentiate it from the ability to run .NET in the
browser: Razor Components.
It's also discussed more in the ASP.NET Core updates in .NET Core 3.0 Preview 2 blog post.
Feb 19: Naming is hard...
Probably due to confusion that was arising, the Razor Components name for Server Side Blazor was expanded to 'ASP.NET Core Razor Components'. This is mentioned in the Blazor 0.8.0 release notes:
Server-side Blazor is now ASP.NET Core Razor Components in .NET Core
3.0 As was recently announced, server-side Blazor is now shipping as ASP.NET Core Razor Components in .NET Core 3.0. We've integrated the
Blazor component model into ASP.NET Core 3.0 and renamed it to Razor
Components. Blazor 0.8.0 is now built on Razor Components and enables
you to host Razor Components in the browser on WebAssembly.
April 2019: Switching back to Server-side Blazor
In April 2019 Blazor server side went into official preview and as part of that the naming for server side Blazor was switched back:
Simplifying the naming and versioning
For a while, we’ve used the terminology Razor Components in some cases, and Blazor in other
cases. This has proven to be confusing, so following a lot of
community feedback, we’ve decided to drop the name ASP.NET Core Razor
Components, and return to the name Server-side Blazor instead.
This emphasizes that Blazor is a single client app model with multiple
hosting models:
Server-side Blazor runs on the server via SignalR
Client-side Blazor runs client-side on WebAssembly
… but either way, it’s the same programming model. The same Blazor
components can be hosted in both environments.
Note that in the above description there is no mention of Razor Components at all, now we have two different Blazor hosting models (Client-side and server-side) as ways of delivering Blazor Components to the browser.
Sept 2019 The return of 'Razor Components'
Dan Roth's Blazor and .NET Core release notes for the next few versions no longer mention the term 'Razor Components' at all until .NET Core 3.0 Preview 9 when the term emerges again in the name of the 'Razor component unit test framework prototype'.
May 2020 'Razor Components' = 'Blazor Components'. Introducing 'Blazor Server' and 'Blazor WebAssembly'
By the time we get to May 2020 Razor Components and Blazor Components are now being used as synonyms for each other and the naming for the two hosting models has evolved.
The Blazor WebAssembly 3.2.0 now available blog describes that as follows (my emphasis):
Blazor components can then be hosted in different ways to create your web app. The first supported way is called Blazor Server. In
a Blazor Server app, the components run on the server using .NET Core.
And...
Blazor WebAssembly is now the second supported way to host your Blazor components: client-side in the browser using a WebAssembly-based .NET
runtime.
So.. the term 'Razor Components' is officially dead, right?
It would be so much easier if it was.. it does seem like 'Blazor Component' would be a more natural fit. But no, from the Components section of the official documentation:
Components in Blazor are formally referred to as Razor components.
When one creates a new server-side Blazor project, you actually get two projects within a solution. Why is this? I suppose it has something to do with the architecture as shown in this diagram from the docs? So in other words, a .NET core process must be used to host the Blazor app. Is that the basic idea? In other words, IIS would serve up the .NET core app, which in turn "serves" up the Blazor app, or something to that effect?
According to "ASP.NET Core updates in .NET Core 3.0 Preview 2" blog article...
https://blogs.msdn.microsoft.com/webdev/2019/01/29/aspnet-core-3-preview-2/
Why two projects? In part it's to separate the UI logic from the rest of the application. There is also a technical limitation in this preview that we are using the same Razor file extension (.cshtml) for Razor Components that we also use for Razor Pages and Views, but they have different compilation models, so they need to kept separate. In a future preview we plan to introduce a new file extension for Razor Components (.razor) so that you can easily host your components, pages, and views all in the same project.