I am going to build something like this but I hesitate with choice of technologies stack. I’m not sure if such stack is really good for my project (especially database and backend) so I would like to get your opinion about it. I don’t really know will it be OK to use ASP.NET Core with MongoDB or I should focus on some kind of RDMS?
Why not? I mean id choose whatever technology fits best for my needs.
The problem is that I’m not sure if it’s a good solution to use MongoDB for such project.
Unless you deem the scope of your project to be fairly basic (I have looked at the example but I don’t know the extent of it) I suggest to strongly separate your backend from your frontend. Too many times devs “architect” apis after frontend pages/components introducing a coupling that makes fairies sad. This becomes even more of an issue if you want to write a mobile app or other ways to interface to your apis and will thus need a “slightly different” series of endpoints for each case (and many other subtle issues).
Don’t worry, I’m going to stop the boring digression there, with the above the answer to your question, from my point of view, (unless the project is too simple to require you to be bothered by all of this) is the choice of the backend stack should not be affected by your choice of the frontend one, provided the api is written well, your React.js frontend will talk well to an Asp.Net Core backend (personally strongly suggested for many situations), a node js one, a python, hell even an erlang one if you have real time use cases.
This separation also applies to the service <-> database. Tier your backend, separate the concerns between the part of your application that queries the database and the part that deals with your business logic and you will not need to care what database you are using in a large chunk of your application.
Tl;dr: Separate the concerns on as many levels as you can and, if you do, your question won’t need any answer other than “use the right tool for the right job”.
Source: I architect and lead the backend for a large and complex product in which we use Mongodb stretched to its extreme for the dB, asp.net core for various api appications and .Net for background tasks processing (all of which using a tiered engine for maintenability and consistency) , Xamarin for mobile apps and Vue.js for a crazily large single page application. Including many more technologies under the hood and for the infrastructure
There is a .NET MongoDB driver (client library), so you’re good.
Yeah, I know. The reason I’m hesitating is that in my mind ASP.NET is always about SQL and Node.js, Python is about MongoDB.
It’s perfectly valid to use MongoDB with ASP.NET Core and React.
See here for the MongoDB .NET driver: https://docs.mongodb.com/drivers/csharp
The real question should be, is MongoDB right for the type of data you’re storing? The way I see it, if you have a well defined data structure with clear relationships between types, then you should go for something SQL like SQL Server. If the data structure is more fluid/dynamic then go for MongoDB.
Yes, maybe I’ve asked not accurate question. I know that there is no problem with using MongoBD with ASP.NET Core and React, but the real issue is if MongoDB is right for the data I’m going to store.
I mean, it is developing, you learn after time. If the database doesn’t work, change it. It is not set in stone. Mongodb or SQL is perfectly fine for this application. Your code will look different yes, but will it work? Yes.
C# devs
null reference exceptions