Blazor Server App or React for Interactive Web UI - asp.net-core

Please I have an ASP.NET Core Web API project that I need to develop a front-end UI to consume it, taking advantage of the Single Page Application (SPA) and component model of Blazor, I am thinking of using Blazor Server app, but my application is going to be an enterprise app with at least 20,000 concurrent users or more in the future and my concern is obviously the SignalR connection.
I know React also uses the SPA and component model approach.
Am at a fix as to which one to choose and whether it can be scalable in the future.
Thank you for your kind response.

Related

Can I co-host both Blazor Server and Blazor WASM Client as 2 deployment instances for the same app on production?

Blazor WASM has its advantages like speed on client side (after initial pre-load), offline support and can be served via CDNs.
But, Blazor WASM isn't suitable for SEO, pre-rendering doesn't really solve the issue because then the app essentially becomes Blazor Server which always has an open SignalR connection and needs a server round trip for each button click.
Can I host both versions of the app, and do some URL/DNS Routing magic so that the search crawlers use Blazor Server, but humans interact with Blazor WASM Client. I am looking for best of both worlds from a user experience standpoint.
Both Speed and SEO are critical in our project.
References: https://learn.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-5.0
Thanks in advance!

Next.js API is back-end?

I know Next.js is front-end but when i used API of next.js it can response and can manage route or anything about back-end can do.
Then i want to know "Next.js api is back-end ?"
Yes. Next.js is a pre-rendered React app in the client-side that users can view and interact with and can be considered as front-end. At the same time, it also does server-side rendering and API routes which can perform server-side code and access data in the database and can be considered as back-end.
Next.js > v13 uses two folders app or api for Dynamic Routing. Store React components in app for client-side or server rendered components. The backend functions or server-side of Next.js is with the api folder. The api JavaScript code is not executed in the browser but with Node.js so this is not safe for static page generation. When Next.js is hosted in the cloud with Vercel then your server-side or serverless JS will render, but on Netlify or other static hosts the api folder will be ignored or throw errors. It's like running Express.js code in the browser the JIT rendered will fail
Next.js v13 transitioned React folders from pages to app and currently supports both folders. Before v13 the React client code was stored in pages only.
Next.js api provides REST API. We are sending requests internally to our next.api routes. With this you can add business logic in your next.js project without writing any additional custom server code and without configuring any api routes. In node.js app, we need to separete api code into controllers and routes, then register each route in express app, then you need to make sure that you registered the routes in correct order.
The only drawback as of now, vercel does not support websocket connections. So you cannot have realtime services. But you can kinda make it almost realtime with SWR. More on SWR Basically, with swr, you tell next.js to fetch data periodically, keep the response in cache and serve it.
With this feature, Next.js provides everything to build a full-stack application. So next.js also simplifies the backend for us.
Yes. Next js is framework of React js. you can use it both like- frontend and backend. Thanks.
I come from the asp.net world and am slowly, enjoying, learning javascript development. It does clash with me though when people describe something like Next.js, which I'm enjoying learning, as a backend.
To me it is more conceptually like an asp.net server-side frontend (Webforms, MVC, Razor Pages) etc. It seems its main concern is producing reactive frontend UI. Just because some of the frontend functionality runs/processed on server does NOT make it a backend AT ALL.
What about the fact it has api endpoints?
Well to me, a web api is only a means of enabling a frontend to talk to a backend across a network, the internet in this case. For me an api handles only very limited concerns; provides the endpoints, handles de/serialisation, talks http to the caller and that's kind of it, thin and dumb.
The backend doesn't really start till you get to your App layer and then the architectural fun can start, Application orchestration, Domain logic, dependency inverted data access layer etc. etc. all the things that talk to the complexity of designing robust software.
So much talk seems to be focused on where bits sit, is it on the client, is it on the server and less about the concern of what goes where.
I thing Next.js is an excellent server-side, frontend framework but whatever your onward stack into the backend, it's not a backend!
Your Question: "Then i want to know "Next.js api is back-end ?""
Simple Answer: It depends
For any technology to be a backend it must fulfill its minimum criteria to identify itself as a backend.
If you don't use NextJS features and use it as a frontend, it behaves as a frontend.
But you can use it as a backend if you want to use that way.

Frequent logouts in ASP.NET Core app hosted on Google Cloud Run

I have developed an application using ASP.Net Core Razor Pages and I have pretty big problem with frequent user logouts. The application is using default ASP Core Identity service. Logouts occur from time to time when navigating between random pages. Until I hosted this app on App Engine Flex everything was all right but however, for various reasons I had to change the hosting environment.
Maybe anyone has any idea how to solve this problem?

Recommendation needed for cross platform authentication .net core MVC and Xamarin

I need to create an application (Mobile) and a Web application. It needs to use the same database so the same user authentication is required.
Can anyone give me such a demo or an idea where to begin.
I have looked into identity but I see that it is not compatible with Xamarin.
Expected result would be a cross platform login provider
my recommendation is to create one web service that can connect to the db and your mobile app and web app make http get/post calls to the web service. This also means you get to keep db logic in one place instead of duplicated across the applications.
The web app and mobile app should get some kind of authorization token (such as bearer) from the webservice to ensure no ones else is hitting the api.

How can I expose my ASP.NET Core web api to be used without http?

I know this sound strange, but please bear with me. We have a legacy desktop app (DataFlex), and we are developing a new web app. Both apps share the same business logic. We are in the process of moving the business logic to a centralized project that is exposed as an asp.net-core web api, to be used both by the desktop app and the web app.
So far, we have been able to access the new business logic project from the legacy desktop app via COM, but because maintaining interfaces and DataFlex wrapper classes is a pain, we are hoping to find an easier way.
We could access the business logic using the web api via http. But many users are still only using the desktop app, and setting up web servers for all of them is not something that can be done anytime soon. So we want to call the asp.net-core project in a way that resembles the way a web app does it, passing method calls as strings (JSON?)
Is this feasible? If so, how?