Is it good practice to call WEB API in Blazor server side App?-CodePudding

I am new to Blazor server side app. I am currently working on creating web app for my client using Blazor Server side app. I want to understand the good practice on using Web API in Blazor server side app. I can access the data directly in Blazor Server side app using Entity Framework, but at the same time, there are APIs already written to access the data.

I am wondering, why should I not use those APIs instead of connecting EF in Blazor server side app.

Will using the EF to pull data be much faster then API ?

Which approach should I use for good coding practice ?

Thanks

CodePudding user response：

I have worked with both Blazor server-side and web-assembly, although not an expert but glad to share what I know.

In Blazor web-assembly, the pages are rendered at the client-side which is at the browser. You don't have access to database. You will need a Web API to supply the application with the data it needs, authentication, uploads and so on. Therefore, in this case A Web API is required.
However, in Blazor server-side the pages are rendered at the server-side, you have access to database, you can authenticate directly. Thus, you have full access to the server as well as filesystem and so on. Therefore, Web API is not required in this scenario which makes developing Blazor server-side easier. You can still use WEB API but if you are beginning, no need to complicate your development.

I am wondering, why should I not use those APIs instead of connecting EF in Blazor server side app. Will using the EF to pull data be much faster then API ?

Yes using EF directly is faster than Web API. Furthermore, If you are starting blazor server-side development not using a Web API will make your development easier because you have full access of the server, an endpoint is not necessary.

CodePudding user response：

I am wondering, why should I not use those APIs instead of connecting EF in Blazor server side app.

Is the API modern? Does it abstract the controllers from the underlying data pipeline? Is it EF based? See discussion below.

Will using the EF to pull data be much faster then API ?

Certainly yes. You've removing a layer of complexity.

Which approach should I use for good coding practice ?

Who knows.

In an ideal design the controllers, the UI, or your test routines are all consumers of the same data pipeline. They talk to the data pipeline through interfaces that abstract the implementation. You can implement data pipelines specific to the storage without the UI or controller caring.

Consumer => interface => persistant storage
Consumer => interface => Test In Memory database
Consumer => interface => API Controller(Consumer) => interface => persistant storage
Consumer => interface => MS SQL DB
Consumer => interface => another DB provider

It's all in the design.

Here's an article (of mine) that demonstrates how to build a CQS data pipeline (based on the Blazor Weather Forecast) that you can plug into any consumer end point. I use it for my Blazor demos. In the implementation the consumer is a set of XUnit tests, and the persistent storage is an In-Memory EF database - https://www.codeproject.com/Articles/5340253/Building-a-Succinct-DotNetCore-CQS-Data-Pipeline

CodePudding user response：

I have just built a calendar app in Blazor Server, which is embedded in an existing MVC project.

For Blazor Server - you can use dbContext directly or create your own service layer - but make sure your dbContext is served either by dbContext factory or new one instantiated for each request.

You COULD use existing API, there is no problem with that technologically - that was my first approach as well, but since I already had a MVC service layer, I decided to not duplicate code and use the existing services. API could be a bit awkward for Blazor Server, you could run into some problems, like auth that you might have to write yourself - as you normally wouldn't use API for Blazor Server, since you can access DB directly. That said - you COULD use API instead of duplicating code, which will probably save some time. It's not a recommended way of using Blazor Server, but it can be done.

Depends on whether the "Don't Repeat Yourself" rule is more important to you.

CodePudding user response：

Granting database credentials to a Blazor app (or web app of any kind) is generally considered bad practice. It would be better practice to separate your concerns. Keep the Blazor app serving web pages and create a RESTful Web API to serve the data to that Blazor app.
Furthermore, creating a Web API will buy you flexibility down the road. For instance, someday you might want to convert your Blazor server-side app to a Blazor Web Assembly app. If so, no problem - You can just replumb the app to fetch data from the Web API via REST. Or better still - What if you have an entirely new application (web app or something else), (potentially) written with a different stack? Again - No problem whatsoever. You can always retrieve that data via REST.

Will using the EF to pull data be much faster then API?

Yes, but likely not noticeably faster. The advantages I stated above should trump this concern.

For more information about separation of concerns and best practices vis-à-vis Blazor and Blazor Server Apps, I encourage you to watch Gill Cleeren's Pluralsight course entitled 'Blazor: Getting Started'; specifically, Section 3: 'Working with Data'.