StreetOfThings enables its users to share, rent or gift items they do not need with / to their neighbors through the application, As most homes have things that they need at certain limited times, and most of the time they are left unused to wear out over time. The importance of implementing the Street of Things app stems from the fact that it strengthens social relations at the level of the people of the neighborhood and saves the residents of the neighborhood who do not have the price of the item they need the ability to borrow it from their neighbors or perhaps obtain it for free, Also, the owner of the object can achieve profit by offering the object for rent for a specified period, thus making use of the shelf life of things as much as possible. In the end, we can only say that mobile applications have become one of the most important technologies that contribute to facilitating people's lives, which is changing the nature of our relationship with the things we own so we do not cling to things much, and also change our relationship with the people around us for the better.
This repository is only the back-end for StreetOfThings.
microservices architecture is an approach to building a server application as a set of small services. That means a microservices architecture is mainly oriented to the back-end, Each service runs in its own process and communicates with other processes using protocols such as HTTP/HTTPS, WebSockets, or AMQP. Each microservice implements a specific end-to-end domain or business capability within a certain context boundary, and each must be developed autonomously and be deployable independently. Finally, each microservice should own its related domain data model and domain logic (sovereignty and decentralized data management) and could be based on different data storage technologies (SQL, NoSQL) and different programming languages.
- Independent components.
- Easier understanding.
- Better scalability.
- Flexibility in choosing the technology.
- The higher level of agility: Any fault in a microservices application affects only a particular service and not the whole solution
- Extra complexity.
- System distribution.
- Cross-cutting concerns.
- Testing.
- Microservices Are Often More Expensive Than Monoliths:
although all those disadvantages listed above, plus our application did not require the urge to scale so vigorously we could have just built our back-end as a huge monolith server and upgrade it as our application grows, but we choose to architect the back-end as microservices just for the sake of learning it, architect small parts of software to solve huge problems. The .NET core was the best candidate for embracing a microservices-oriented system that is based on containers because .NET Core is lightweight. In addition, its related container images, either the Linux image or the Windows Nano image, are lean and small making containers light and fast to start.
Containerization is an approach to software development in which an application or service, its dependencies, and its configuration (abstracted as deployment manifest files) are packaged together as a container image. The containerized application can be tested as a unit and deployed as a container image instance to the host operating system (OS). All of our microservices and there databases are containerized with docker.
Authorization service DockerFile
When designing and building large or complex microservice-based applications with multiple client apps, a good approach to consider can be an API Gateway. This is a service that provides a single entry point for certain groups of microservices. It’s similar to the Facade pattern from object-oriented design, but in this case, it’s part of a distributed system. The API Gateway pattern is also sometimes known as the “backend for frontend” (BFF) because you build it while thinking about the needs of the client app. Therefore, the API gateway sits between the client apps and the microservices. It acts as a reverse proxy, routing requests from clients to services. also provide additional cross-cutting features such as authentication, and cache.
- Reverse proxy or gateway routing. The MobileGateway, AdminGateway offers a reverse proxy to redirect or route requests (layer 7 routings, usually HTTP requests) to the endpoints of the internal microservices.
- Requests aggregation. As part of the gateway pattern, you can aggregate multiple client requests (usually HTTP requests) targeting multiple internal microservices into a single client request.
*. gRPC
*. RabbitMQ
*. REST.
Databases should be treated as private to each microservice. No other microservice can directly modify data stored inside the database in another microservice. and accessible only via its API, And for that in the back-end, we have three independent databases. Authorization database, Catalog database, Transaction database. there is a container named SQL.data defined in the docker-compose.yml file that runs SQL Server for Linux with all the SQL Server databases needed for the microservices. (You could also have one SQL Server container for each database, but that would require more memory assigned to Docker.) The important point in microservices is that each microservice owns its related data, therefore its related SQL database in this case. But the databases can be anywhere. We also are using the Local SQL server Database for development.
For that we used Entity framework core
In our StreetOfThings app, We used something similar to Domain Oriented N-Layered Architecture V2.0 Published first ALPHA version of Domain Oriented N-Layered Architecture V2.0 | Cesar de la Torre as an internal design for our services