Backend Architecture for Backoffice

# Backend Architecture for Backoffice  ## Version control | Version | Date | Author | Reviewer | Description | |--|--|--|--|--| |1.0|20210511|Sergio Ñ|Jed Horne|Emision| ## 1 Introduction  This document aims to define the backend that it should be used for the new Backoffice frontend created with Flutter. ## 2 Motivation  We started the Backoffice development suddenly and we weren't ready to start the development of the backend elements. In the previous version of the backoffice a.k.a "Saas Project", we created a new backend called "Saas Api", however, with the new developments ahead, and the new vision It's important define the way we must follow. ## 2.1 Brainstorming 1. Use SaaS API * Pros: * We currently have this implemented with some minor endpoints, including the authentication ones * We are using Nest framework using Node.js and Javascript behind. * Don't loose the time spent on this * Cons: * It uses the same database of orders API, syncing the migrations is a headache (we need to do this first on orders api, in some environment, and then come to here and update the entities, it's a nightmare) * At first sight is not compatible with the vision of microservices. 2. Use Orders API * Pros: * Fast development * We have more trained developers to acomplish this * Cons: * This sould be a temporal solution (this work would be deprecated on mid term). But it's compatible with the vision of microservices * We are growing this monolithic 3. Create a new backend * Cons: * Really if we did want to create a new backend we should use the SaaS API. ## 3 Implementation Proposal  ### 3.1 Microservices Vision Before talking about the proposal, it's necessary to plan what's the vision about microservices we have which enables the future decisions, in this case the backend for the new backoffice. The vision of microservices presents the motivation of spliting our current monolithic Orders API service in different microservices in charge of different aspects of the business, known as bounded contexts in the Domain Driven Concept [[link](https://www.thoughtworks.com/insights/blog/domain-driven-design-services-architecture)] DDD allow us to achieve that our microservices be small, independent, and base of business context. Every microservice using their own database, using the best set of technologies that fits the goal of itself (e.g: python for machine learning, rust for performance, golang by default, NoSQL or redis for faster readings or SQL databases for more transactional, etc), also interacting among them. Given that statement it's considering to use the following domains to split our monolithic in microservices: - Authentication (users, permissions, tokens, roles) - Orders (orders and their statuses) - Routes (handling different providers and slots) - Catalog (products, categories, rich information) - Stock (products stocks) - Payments [[Definition Available](/VuG5bo1iSca-9pla8VKq7Q)] - Searcher - CMS - Promos - Notifications (email, sms) - Logistic (country, cities, coverage areas) - Address The communication amoung these services could be via GRPC or REST API for sync calls, or via a message bus with Rabbit MQ or SQS or Kafka for async calls. ### 3.2 The proposal Given that vision of microservices for the backend, as temporal solutions it's proposed to use **Orders API** as backend for the new backoffice, based on the following arguments: - The implementation of microservices it's going to be ready on a mid term but we can't delay the new backoffice product. - We have team available for work on django right now, and use the SaaS API or another backend it's out the microservices vision. - This doesn't add more load to django, and even it could be reduce it, because this services are going to be a replacement for the slow django admin, and the server side rendering consumes a lot of CPU. - **How can we use microservices and when?**: - How: every frontend should have its own backend that consumes the different microservices prepared. [[link](https://samnewman.io/patterns/architectural/bff/)] - How mobile: in this case mobile technically they could call the services directly avoiding some latency, this sould be discussed later, having in account security concerns. - When: we need to wait this mid term when the microservices be developed - The microservices should replicate the responses created by Orders API, to easily change from monolithic to service - **Plan** - **Orders API** (from Sprint 3 to ~august ): - We should create a new django app, for handling only backoffice endpoints - Avoid to implement authentication services right now, this is because the authentication service it's the foundation that enable us to use microservices, it handles the permissions of users and applications for accesing certain microservices. - Directly to implement the services of the dashboard itself (e.g: Orders, Products, etc) - When the authentication layer be ready, then to integrate it. - **Microservices** (from ~august to next year) - Killing celery for some tasks, and pass this to the message bus. - OrdersAPI is the integrator, so all the rest of services should be decoupled one by one, starting by authentication, followed by payments that is planned, the paralell ones (like notifications, promos, searcher, CMS, etc) and then the core ones (routes, stock, catalog, logistic, orders) - Due we are going to handle a lot of services with a lot of containers with different resources and scalability plans, we should reconsider to use Kubernetes to acomplish this. - Every time a new microservice be released implies to be integrated in the ecommerce frontend, and in the new backoffice. ## 4 Metrics (N/A)  ## 5 Risks or inconvenients - A potential client knocking the door, and don't be ready with the new backoffice  ## 6 Alternatives (N/A)  ## 7 Potential impact and dependencies  The impact it's minor, even if we fail in the vision or we change for another, it's ok that changing the Admin Django for the new backoffice we use the same service. ## 8 Unsolved questions (N/A)  ## 9 Future ideas - Define the architecture for the Backend for frontend - Consume directly the services  ## 10 Conclusion - This document defined how we must deal the backend for the new backoffice having in account the vision we have. - This solution is temporal but necessary to go for the microservices approach