Architecture proposal #13
Replies: 3 comments 1 reply
-
|
The tool seems good, and the architecture looks great, probably over time it may get more layers or more complociated along development but for now it is very good, thanks. |
Beta Was this translation helpful? Give feedback.
-
|
The model for diagrams looks interesting, and so does the tool. However, I think it's worth noting that our documentation supports the direct integration of PlantUML, and the C4 Model uses a different language (Structurizr DSL). The translation between PlantUML and C4 is pretty simple, as there is an already integrated C4-PlantUML notation system. The documentation for C4-PlantUML can be found here. I've also seen that the tool you shared has an option to directly translate from Structurizr to both PlantUML and C4-PlantUML, which is very useful. The resulting diagram is very similar:
Of course, this is if we want to insert the code for the diagrams directly into our .adoc files. We could simply use Structurizr DSL and add it as images to the documentation, if you prefer it that way. Regarding your third question, I think the architecture seems pretty solid, at least until we start developing and get a better idea of the needs of our design. |
Beta Was this translation helpful? Give feedback.
-
|
I didn't know we could embed PlantUML code in our files, thank you for mentioning it. I will try to do it that way, it makes further modifications of the schemas even easier. Regarding the C4 model, DSL is just a diagramming language, but we can perfectly follow it with PlantUML. The diagrams look like this when using PlantUML (basically the same).
|
Beta Was this translation helpful? Give feedback.
-
Regarding the C4 Model:I agree that the C4 model is a solid option for documenting the architecture. The levels you proposed (System Context and Container Diagrams) seem like a great starting point. As discussed, we could always expand to the Component Diagram (level 3) if the complexity of our system increases by the time we start implementing the application. Regarding the tool:Regarding the tool, I think it’s a great fit for our needs at the moment. As mentioned, the tool allows us to easily visualize both the System Context Diagram and Container Diagram in one view, which is convenient and efficient. Regarding the architecture:I think the architecture is well thought out and addresses the main components of the system. I agree with @carlosfernandezmartinez that it seems solid for now, but as development progresses, we might find the need to add more layers or make adjustments to certain components. It’s definitely something to keep in mind as we iterate. A couple of things to consider:
|
Beta Was this translation helpful? Give feedback.
-
Why?
I've been having a look at the building block view for the documentation of our project. I've been having a look a your work and I think that a bit more detailed architecture would be very beneficial for us all to follow the same path when documenting the project.
About diagrams
Our documentation will need quite a few diagrams. For the purpose of building block view, the C4 model seems to fit very well. It provides a clear way of representing the following levels of our architecture:
According to the documentation, the first two levels are enough for most of the projects. In this case, I suggest documenting these two levels.
QUESTION 1: What do you think about using C4 model for this part of the documentation? Would you increase the level of detail (up to level 3, for example)?
5 diagram.txt
This is the architecture I suggest for our application. You can see it with this tool, it includes system context diagram and container diagram all in one. That's nice because modifications are very very easy to be done. By the way, you have tutorials in their website, it's not difficult at all (at least the features I've used).
QUESTION 2: What do you think about the tool?
My idea of how this architecture would work
I will try to explain to you how I think this architecture could work. Of course, nothing of this is final, so please give me some feedback.
Web application: This serves as the primary interface for users to interact with Wichat, offering a seamless experience while abstracting backend complexities. It improves usability and accessibility but introduces potential frontend-related performance bottlenecks. Additionally, maintaining a responsive UI across different devices requires continuous optimization.
Gateway Service: Acts as a single entry point for API calls, enforcing security policies and load balancing. It simplifies communication between the frontend and backend while reducing direct exposure of microservices. However, it can become a single point of failure, requiring scaling and maybe redundancy mechanisms (even though it might be overkill for our system). It may also introduce latency if not optimized properly due to additional processing overhead, so we should be very careful not to include much logic in here.
Documentation System: Ensures users and developers have easy access to system guidelines, API references, and instructions, improving maintainability and onboarding. The downside is that keeping documentation up to date requires dedicated effort, and if not properly managed, outdated documentation can lead to confusion and inefficiencies.
LLM Service: Handles interactions with an external LLM, ensuring modularity and the ability to swap AI models if needed. This separation allows better resource allocation and security control. However, reliance on an external LLM introduces latency and potential availability issues. Additionally, managing API costs and data privacy when sending queries to a third-party AI system requires careful consideration.
User Gateway: Centralizes user-related API requests, improving security by isolating authentication and CRUD operations. This ensures better access control and prevents direct database exposure. However, it can create an additional layer of latency and complexity, especially if not optimized for high request loads.
User CRUD Service: Manages user-related data operations separately from authentication, improving maintainability and following the principle of least privilege. Using a dedicated service allows independent scaling and optimizations for data retrieval. However, it increases the number of service-to-service communications, which can lead to potential network latency and require efficient caching strategies.
User Authentication Service : Dedicated authentication handling enhances security by isolating access control from other user-related operations. It simplifies compliance with security standards. However, improper implementation may lead to vulnerabilities like session hijacking or token mismanagement. Additionally, any downtime in authentication service would block all user logins, requiring high availability strategies.
Game Service: Manages game-related logic, such as generating and validating question batches, ensuring the system remains interactive and engaging. It would be also in charge of caching question batches to reduce WikiData API call's overhead. Separating this logic improves modularity and allows better scalability. However, fetching and processing large datasets from external sources (like WikiData) can introduce latency.
MongoDB Database: Chosen for its flexible schema and ability to handle dynamic data structures, MongoDB allows efficient scaling and quick reads for user and game data. However, its lack of strict ACID compliance in distributed setups may introduce consistency challenges. Additionally, improper indexing or excessive document growth can impact query performance over time.
I will not mention the endpoints in here because I think that's the next step after deciding the architecture.
QUESTION 3: What would you change in the architecture? What's your opinion about it?
@pelayosl @DavidPedregal @franCimadevilla @sergio-riesco @HovanRojasIgnacio @adrianmfuentes
Beta Was this translation helpful? Give feedback.
All reactions