Last post Mar 10, 2020 01:28 AM by Brando ZWZ
Mar 06, 2020 01:59 PM|jinzo7|LINK
Just few details to feel the concept and then dive into the problem.
We implement web app in asp.net core web api + angular. We have a lot of experience on building the client of browser based games and sockets. For year we learned nodejs, express, mongo but we don't like js so much so for few months we moved to asp,
ef, sql. I want to say we have solid experience in software development but we are not pros in web development.
The idea of the app is to be public and to be access only in our small country.
The simplest concept of the app - the user creates article(title, body). Other users can search articles and comment,like them.
Currently we have 1 server instance that cares about everything - authentication, authorization, resource and etc. For this we have only 1 database that contains identity elements and resource elements.
On the client side when someone get article we want to show not only the article but also its creator (username and photo). So when users and the articles are on the same database under only 1 server it is easy.
Next we to try to divide the server into 2 instances - authorization server and api server .Using IdentityServer4, works on OAuth.
The auth server has its own database(UsersDb) and there is another api server(ArticlesDb). Everything working properly but now we cannot establish relation between User entity and Article entity.
So when someone get article we cannot get information about the user.
How to gather related information between the users and articles If we have 2 servers and 2 databases (Users, Resources)? Is it microservice architecture?
Mar 10, 2020 01:28 AM|Brando ZWZ|LINK
According to your description, I suggest you could write another api to gather related information between the users and articles. Both of them will use http to communicate.
In my opinion, this is not a microservice now.
The microservice is not a layer within a monolithic application (example, the web controller, or the backend-for-frontend).
Rather it is a self-contained piece of business functionality with clear interfaces, and may, through its own internal components, implement a layered architecture.
It is like "Just do one things and do well". That means it will have its own server and other things will not affect it.