App Technical Architecture
Last updated
Last updated
The App considers using a typical front-end and back-end separation architecture, and there are already plenty of open-source projects available as references for such community Apps. Here, I will describe its general technical architecture for future development and implementation.
Notably, since we lack extensive experience in deployment and operations, we plan to host all components on the cloud and aim to reduce costs as much as possible. For example, we may introduce cloud functions to replace cloud servers and mount CFS to replace the file system. This approach can minimize considerations for scaling, load balancing, and cost-effectiveness. In low-traffic scenarios, pay-as-you-go pricing based on resources might be a more reliable solution compared to using cloud servers and deploying components using containerization technology. Additionally, in cases of limited technical expertise, this design can better ensure program robustness, as cloud providers can guarantee certain disaster recovery and high availability capabilities. Even if this architecture leads to cost increases or implementation difficulties, we can quickly adopt more typical cloud server deployment strategies.
Of course, our primary goal is to quickly implement image protection and processing technologies and promptly open interfaces for service provision after validation of their effectiveness. Ideally, the image processing part should efficiently and effectively utilize perturbative adversarial, noise injection, digital watermarking, and other methods to process images and return results. In this scenario, cloud functions might indeed be an excellent choice.
I do not have a comprehensive understanding of frontend development. However, after conducting research, I have chosen uni-app as the development framework for my frontend application. In theory, uni-app can compile to multiple platforms such as iOS, Android, Web, and various mini-programs, which can save the cost of Native development. It also has a strong community and plugin support. Of course, there may be various issues to consider, such as platform compatibility, etc., which may require guidance and corrections from experienced developers. The choice here does not need to be too rigid; if there are suitable open-source projects, I will follow the technology stack of the open-source project. Regardless of the technology stack used, the general preview and logic of frontend interactions are as follows:
The backend service uses the Flask framework, whose lightweight and easy scalability allow us to iterate quickly during development. It also enables us to deploy the services on Serverless Cloud Functions. Additionally, we considered Python's comprehensive image processing libraries. Under the architecture of cloud functions, we can achieve microservice separation between the backend business and image processing modules through methods like cloud pipelines and function composition. In cases where image processing requires significant resources and time, we can treat it as an asynchronous task by using a message queue. Logs and other systems can be stored in mounted CFS (Controlled File System). The backend business interacts with the database, object storage, and Elasticsearch to complete the cycle of functions like image publishing and searching. The following is an illustration of the backend business tree:
The data storage strategy includes two parts: one part is a MySQL database for storing user information, and the other part is an object storage service for storing user images. Typically, the database is used to save user information, while object storage is used to store user-posted images and so on. At the same time, tags, storage paths, and other information should be synchronized to Elasticsearch to provide search services.
The Anti-AI module for images protects image copyrights and prevents unauthorized AI learning by adding digital watermarks, adversarial perturbations, injecting noise, and other methods to the images. This module should be designed as an independent microservice module and should be able to provide services independently as soon as possible in the early stages. The deployment pattern can be referenced from the serverless cloud function deployment. However, for this specific technology, further research and effectiveness testing are still necessary before implementation.
Considering the current requirements for low cost and low concurrency usage scenarios, the decision is to design the project based on the basic deployment method of SCF (Serverless Cloud Function) with CFS (Cloud File Storage) mounting to reduce performance waste. Currently, SCF technology covers low cost, concurrency control, smooth scaling, and the ability to interact with databases and object storage, which should be sufficient for the basic operation of the service. If necessary in the future, migration to Kubernetes or other platforms can be considered.
