Standards in Architecture across backend microservices, front-end and mobile apps has a lot of benefits in Programming, software development and beyond. In purely coding perspective – it is crucial for ensuring consistency, scalability, and maintainability in a software ecosystem. It allows new members to enter and be productive fast. New applications may be produced in no time. New feature may be implemented in days, not weeks. By organizing properly the code – software tools may be created that – generate code, test, check for best practices, etc.
Here are some key aspects to consider and several examples from my experience.
Backend Microservices
I’ve recently watched a webinar of dev.bg, and the lector told in his own words – what I’ve exprienced in other places and spaces. Every single company has their own systems – of software and more importantly – of operations and hiring, their own approaches, thier own best practices, thier own tools. From development perspective – these are just architecture standards for approaching code.
Layered Architecture
Organize code into layers such as controllers, services, repositories, and models, following a clear separation of concerns. This comes identical on all fronts – apps, front-ends, backend microservices.
Dependency Injection
Dependency injection frameworks is something you will not escape – no matter what you code. Maybe if you code at startup you will. It is generally not required. But – if you reach any level of enterprise – you will.
- It is in the Core of Spring
- Quarkus has it their own way: https://quarkus.io/guides/cdi
- Similarly to Micronout: https://guides.micronaut.io/latest/micronaut-dependency-injection-types-maven-java.html
- Privider is the equivalent in Flutter
- Some time ago I’ve also used Dagger
- If you’ve dive deep, you will find DI in React and Angular
It is the same thing – capsulating layers, minimizing logic spread in multiple modules, the software being testable….
Modularization
In last 6 months – I’ve dived into java and backend – docker & docker-compose, kafka & rabbitmq, spring boot, Vaadin, researched on different ways that Micro Services are created and handled. There is a ton of stuff that I still need to learn – I’m totally sure of that. But the core from a broader perspective remains the same:
- Divide functionality into separate modules or packages based on their responsibilities.
- This is the essense of organizing a mobile Flutter app in features_. It is only a naming different that
- Prime Holding Flutter – has chosen rx_bloc to be controller.
- They use Streams – the same as Spring Boot Reactive/Flux/,
- They try to enforce more logic into the service layer (the same as the backend in whatever tech) – so the actual business logic may be tested with minimal effort and runtime resources.
- Integrate cross-feature communication. In rx_bloc ecosystem – it is done with coordinator bloc. In the backend side there are options.
API and inter feature Contracts
Define clear interfaces and contracts for communication between microservices, adhering to standards like OpenAPI (formerly Swagger). This is a must for communicating between front-end and back-end. Between backend nodes – there are more options.
- Micro Services may communicate over standard synchronious HTTP requests.
- But – Features may use Messaging Systems (kafka, RabitMQ)
- Event based systems
- Database System feature – that integrate event listeners – when changes on some data occurs
- Noawadays Web sockets exist for all kinds of platforms and apis. There are also Server Side Events (that take advantage of life socket) – that broadcast events to the clients
- The option of Long Pooling seem to me as a no-go.
Frontend/Mobile Apps
Feature or Component-Based Architecture
Structure code into reusable components representing UI elements or logical units of functionality. This seem to me as common in Flutter, React, Server Side Components like Vaadin (and probably NextJS). For max reusability – get more parameters as optional. For max reusability and security – use minimal external dependencies – on libraries, services and platforms – as possible.
Folder Structure & Code Standards and Conventions
Organize code files and assets into meaningful directories based on feature or functionality, following conventions like MVC or MVVM or BloC. This is standard for Spring and for Flutter Development. Strict folder structure allows development of tools that speed up new apps, features, tests and more.
Establish coding standards and conventions for naming conventions, file structure, and code formatting across all projects. This allows use of linting tools (e.g., ESLint, TSLint) to enforce coding standards automatically and maintain code consistency and integration of code analysis that find vulnerability in dependencies.
Routing
Part of the Feature development also includes how the user (or the external service) gets into them. Implement a consistent routing mechanism to manage navigation between different views or screens within the application. Having strict mehanisms allows implementing guards, protection and permission logic.
State Management
In Flutter State Management is a hot topic. The most corporate is bloc (I have more exprience with rx_bloc). But – there are others. Utilize state management libraries like Redux (for React) or Vuex (for Vue.js) to manage application state in a predictable and centralized manner. This separates logic from the Framework. This is the essense of the external state management.
I have some collegues that find this a little bit of over-work. There are tools that execute live tests on the UI – that translates to the controller, service and logic. These are
My only problem with these solutions is – when a problem occurs, one (developer) needs to search in multiple layers – where is the problem.
Documentation
Documenting is one of the hardest things to archive in long term. It covers code structure, module dependencies, and API contracts. This is not urgent work, bit important – as it may aid understanding and collaboration among team members.
Utilize tools like JSDoc or Swagger for generating API documentation automatically.
Testing
Integrate unit tests, integration tests, and end-to-end tests into the codebase to ensure its reliability and robustness. Follow test-driven development (TDD) or behavior-driven development (BDD) practices to drive code structure and design. This is hard to archive in a startup, but it has great return of value for long term projects.
Continuous Integration and Deployment (CI/CD)
If you have any tests written – they may be meaningless – if you don’t Implement CI/CD pipelines to automate the build, test, and deployment processes, ensuring consistent code quality and deployment practices across all projects. This increases visibility of the code beyond the developers. CI/CD systems may give reports to the Project Managers and even – Clients.
At the end this kind of thinking produce systems that minimize the bus factor of companies. This kind of systems make work repeatable, scalable and optimal in performance. This is what business is about.