Distributed Communication: Choosing the Right Protocol
In our research on the communication between the distributed system backend and the front-end, we explored three options: REST, GraphQL, and tRPC. Let's delve into our findings and determine the most suitable protocol for MindSpaces.
Research methodology
We conducted an Available product analysis to determine the most suitable communication protocol for MindSpaces. We first went online and searched for available products that could be used for communication between the backend and the front-end. Then we defined criteria to evaluate the products and compared them based on the criteria. Finally, we chose the most suitable protocol for MindSpaces.
Criteria
We evaluated the three options based on the following criteria: Maintainability, Complexity, Performance, Flexibility, Schema validation, and Security.
We came to the criteria by analyzing the project requirements and the communication protocols' features. We then assigned a score to each criterion based on how well the protocol met the requirement. The criteria are graded on a scale of good (+), neutral (o), and bad (-).
Maintainability: The protocol should be easily extensible and changeable. Complexity: The protocol should be easy to understand and implement. Performance: The protocol should be fast and efficient. Flexibility: The protocol should be flexible and adaptable to different use cases. Schema validation: The protocol should support schema validation. Security: The protocol should be as secure as possible.
Why tRPC is not an option
After examining tRPC as a potential communication protocol, we concluded that it is not viable for MindSpaces. Since our backend is built using Golang, and tRPC lacks support for this language, using tRPC would require migrating to TypeScript as our backend language. Given our current technical stack and preferences, this was not a feasible choice.
REST vs. GraphQL: A Comparative Analysis
We compared REST and GraphQL, evaluating their features and assessing their compatibility with the project requirements. The table below provides a summary of our analysis. For a more detailed comparison, both the REST and GraphQL pages contain a more in-depth analysis of the protocols.
| Feature | REST | GraphQL |
|---|---|---|
| Maintainability | o | + |
| Complexity | + | - |
| Performance | + | - |
| Flexibility | - | + |
| Schema validation | - | + |
| Security | + | - |
Conclusion: Choosing REST for MindSpaces
Selecting the appropriate communication protocol is crucial for an efficient and robust distributed system. In the case of MindSpaces, both REST and GraphQL were considered viable options.
REST demonstrates satisfactory maintainability and offers well-established industry practices. Despite being slightly more complex than GraphQL, REST aligns well with the project's existing knowledge base and expertise. Its proven performance capabilities and wide adoption make it a reliable choice for efficient communication between the backend and frontend.
While GraphQL boasts flexibility and schema validation, these advantages were outweighed by REST's maturity and the existing resources and tools available for its implementation. Furthermore, REST's stronger security tooling ecosystem provides confidence in the protection of sensitive data.
Ultimately, I was a very close call between REST and GraphQL and the decision to use REST was more out of comfort and familiarity than any other factor. We have experience with REST and have used it in previous projects. As we already have multiple factors that are new to us in this project we decided to go with a protocol we are familiar with.