Design questions about asp.net core website and asp.net core webapi
-
hi all, I am going to build an asp.net core website and an asp.net core webapi. My question is that from design perspective, should I just call into the webapi to get data for my website? or just call into the database to get data directly? It looks like calling the webapi would promote separation of concerns and I don't have to expose my database connection strings in multiple places, but I am afraid there is a performance hit that will impact the performance of the load time of the website. Any insight is greatly appreciated.
-
hi all, I am going to build an asp.net core website and an asp.net core webapi. My question is that from design perspective, should I just call into the webapi to get data for my website? or just call into the database to get data directly? It looks like calling the webapi would promote separation of concerns and I don't have to expose my database connection strings in multiple places, but I am afraid there is a performance hit that will impact the performance of the load time of the website. Any insight is greatly appreciated.
Quote:
My question is that from design perspective, should I just call into the webapi to get data for my website? or just call into the database to get data directly?
This is a preference-based and a scenario-based question. In my own application that I have, I am redirecting all the database related stuff through API, and this has decreased the attack surface a lot (I can secure the database requests at one place). Also, if you route all the database traffic to ASP.NET Core Web API, you can develop the frontend independently—in future you can replace ASP.NET Core MVC with something like a React or Angular framework for frontend, and you can easily integrate the application in a mobile application; native, Xamarin or Flutter.
Quote:
It looks like calling the webapi would promote separation of concerns
Correct, like I said earlier.
Quote:
I don't have to expose my database connection strings in multiple places
Yes, and no. You still can prevent exposing the database connection string by using variables on your hosting environment and then reuse that value in all your processes. This part depends entirely on where you are hosting your application.
Quote:
but I am afraid there is a performance hit that will impact the performance of the load time of the website.
No, do not worry about this part. If you create two applications, you are going to launch them separately and that can add 3-5 seconds of load time, but it would be much easier to scale the applications in the future. This will help you in handling the load like a pro. Also, load time depends on how many users are you expecting to get? If there will be a lot of users (like thousands of active users) then try caching your website and the queries, so you do not send duplicate queries to the database for at least an hour. Here are a few more ideas to improve the performance: 1. Deploy your application as a stateless instance (try to move all the memory and state, e.g. session information to a database) 1. Add a caching layer to your service 1. Try to add scaling to your website (depends on the host environment) - If you scale a stateless website, you can utilize caching and database to handle more requests and provide service to more users 1. Keep separating the different domains ins
-
Quote:
My question is that from design perspective, should I just call into the webapi to get data for my website? or just call into the database to get data directly?
This is a preference-based and a scenario-based question. In my own application that I have, I am redirecting all the database related stuff through API, and this has decreased the attack surface a lot (I can secure the database requests at one place). Also, if you route all the database traffic to ASP.NET Core Web API, you can develop the frontend independently—in future you can replace ASP.NET Core MVC with something like a React or Angular framework for frontend, and you can easily integrate the application in a mobile application; native, Xamarin or Flutter.
Quote:
It looks like calling the webapi would promote separation of concerns
Correct, like I said earlier.
Quote:
I don't have to expose my database connection strings in multiple places
Yes, and no. You still can prevent exposing the database connection string by using variables on your hosting environment and then reuse that value in all your processes. This part depends entirely on where you are hosting your application.
Quote:
but I am afraid there is a performance hit that will impact the performance of the load time of the website.
No, do not worry about this part. If you create two applications, you are going to launch them separately and that can add 3-5 seconds of load time, but it would be much easier to scale the applications in the future. This will help you in handling the load like a pro. Also, load time depends on how many users are you expecting to get? If there will be a lot of users (like thousands of active users) then try caching your website and the queries, so you do not send duplicate queries to the database for at least an hour. Here are a few more ideas to improve the performance: 1. Deploy your application as a stateless instance (try to move all the memory and state, e.g. session information to a database) 1. Add a caching layer to your service 1. Try to add scaling to your website (depends on the host environment) - If you scale a stateless website, you can utilize caching and database to handle more requests and provide service to more users 1. Keep separating the different domains ins
Thanks Afzaal, this is very insightful and answer most of my concerns. your ideas to improve performance aligned with what we had in mind except for number 1 that I am not sure if I understand. Did you mean that I will need to make database calls through the webapi to get the session state, like if I have a survey engine, I will have to post every question that the user answer so he or she can come back to it later? if not, Can you give a brief example what you have in mind? Thanks and greatly appreciate your help.
-
Thanks Afzaal, this is very insightful and answer most of my concerns. your ideas to improve performance aligned with what we had in mind except for number 1 that I am not sure if I understand. Did you mean that I will need to make database calls through the webapi to get the session state, like if I have a survey engine, I will have to post every question that the user answer so he or she can come back to it later? if not, Can you give a brief example what you have in mind? Thanks and greatly appreciate your help.
Quote:
Did you mean that I will need to make database calls through the webapi to get the session state,
Not specifically, but just outproc the session and other "state" information. Take a look at this for inspiration: [ASP NET Core MVC - How to configure Out of Process Session State? - Stack Overflow](https://stackoverflow.com/questions/38536012/asp-net-core-mvc-how-to-configure-out-of-process-session-state)
Quote:
if I have a survey engine, I will have to post every question that the user answer so he or she can come back to it later?
Correct, so that none of the information is stored only in the ASP.NET Core process. This can help you scale the application as well, since your users are not stuck with using a specific process and load balancer can easily balance the traffic regardless of the survey state.
The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
-
Quote:
Did you mean that I will need to make database calls through the webapi to get the session state,
Not specifically, but just outproc the session and other "state" information. Take a look at this for inspiration: [ASP NET Core MVC - How to configure Out of Process Session State? - Stack Overflow](https://stackoverflow.com/questions/38536012/asp-net-core-mvc-how-to-configure-out-of-process-session-state)
Quote:
if I have a survey engine, I will have to post every question that the user answer so he or she can come back to it later?
Correct, so that none of the information is stored only in the ASP.NET Core process. This can help you scale the application as well, since your users are not stuck with using a specific process and load balancer can easily balance the traffic regardless of the survey state.
The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
the post about out of process session state is interesting. still need time to digust the topic as I am not familar with it at all. I believe I have a basic idea how to go about doing this now. thanks again for the help!
-
hi all, I am going to build an asp.net core website and an asp.net core webapi. My question is that from design perspective, should I just call into the webapi to get data for my website? or just call into the database to get data directly? It looks like calling the webapi would promote separation of concerns and I don't have to expose my database connection strings in multiple places, but I am afraid there is a performance hit that will impact the performance of the load time of the website. Any insight is greatly appreciated.
You should separate the database code from the controllers and views. I created a database class implementing an interface that is passed to the controllers, providing methods to obtain the required data from the database. Thus there is a minimal common interface between the web site and the database code, and the web site knows nothing about the database. This allows testing of the database code with a desktop test harness. It also allows easy replacement of the database code if for example I change database provider. I used Dapper for database access, but PetaPoco is better IMO.
-
You should separate the database code from the controllers and views. I created a database class implementing an interface that is passed to the controllers, providing methods to obtain the required data from the database. Thus there is a minimal common interface between the web site and the database code, and the web site knows nothing about the database. This allows testing of the database code with a desktop test harness. It also allows easy replacement of the database code if for example I change database provider. I used Dapper for database access, but PetaPoco is better IMO.
hi Leif Simon Goodwin, Yes, I believe that calling into an webapi is better in terms of separation of concern, and I have started doing that for my project. I've never heard of petapoco before and it looks interesting. I am just using good old ADO.NET using queries and loading data to POCOs.
-
hi Leif Simon Goodwin, Yes, I believe that calling into an webapi is better in terms of separation of concern, and I have started doing that for my project. I've never heard of petapoco before and it looks interesting. I am just using good old ADO.NET using queries and loading data to POCOs.
You really should use an ORM such as PetaPoco or Dapper, it will make life much easier and less tedious. I found the former better as it worked well with four different SQL providers with minimal work, I couldn’t get Dapper working with them all. Here is an example application: Example WPF SQL Database Application using PetaPoco ORM with SQLServer, SQLIte, MySQL and ProgreSQL[^] There are other examples online too.
-
You really should use an ORM such as PetaPoco or Dapper, it will make life much easier and less tedious. I found the former better as it worked well with four different SQL providers with minimal work, I couldn’t get Dapper working with them all. Here is an example application: Example WPF SQL Database Application using PetaPoco ORM with SQLServer, SQLIte, MySQL and ProgreSQL[^] There are other examples online too.
I used to use Entity Framework. Everything seemed to work well enough to get me hooked, until there are more complicated examples, such as pull fields from different tables using a stored procedure and try to update the fields in the object afterwards, that will get me all the time ...