[DOCS-13727] [Server] Distribute the Tools as a software service provided in the cloud Created: 23/Jun/20 Updated: 30/Oct/23 Resolved: 22/Feb/21 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | tools |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Task | Priority: | Blocker - P1 |
| Reporter: | Anonymous | Assignee: | Andrew Feierabend (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Days since reply: | 3 years, 33 weeks, 1 day ago | ||||||||||||
| Epic Link: | DOCSP-1769 | ||||||||||||
| Description |
DescriptionYes - it would be a new component of software to document Engineering Description The Tools are currently distributed as Golang executables in mongo-tools and MTC. First of all, it’s generally difficult to “deploy” and test CLI tools in isolation; CLIs intrinsically have to support all platforms across all dependencies. In addition, it’s not very easy to embed the underlying executables into other products, e.g. Compass and Atlas web UI. Core Concept - Tools as a Service The Tools Server is a proposed system, which executes a subset of the Tools’ functionality in the cloud over an HTTP/s service. We could expose all of the Tools in this fashion, but the most salient use cases are in import/export and dump/restore. The endpoints of the prototype might look something like this:
This design gives rise to the following possible features:
A possible prototype of the system would be a generic implementation of dump/restore and import/export in Realm and/or AWS Lambda. Short-Term Benefits **In the past, we've considered the following Epics:
These give rise to higher-level problems in the Tools and the ecosystem, i.e. “What would a stable and succinct interface over the Tools look like? How do we implement that?” This problem in particular is solved much more easily by versioning and distributing a HTTP/s-based Tools API and leaving the functionality embeddable to various interfaces. We could trivially support the CLI, i.e. by using the HTTP/s endpoints, for compatibility, if we wanted. Fundamentally, decoupling the Tools’ functionality as an API would result in better testing and reproducibility, i.e. using various Cloud services. Long-Term Benefits If we support a stable implementation of the Tools as a service, we could enjoy the following:
Scope of changesImpact to Other DocsMVP (Work and Date)Resources (Scope or Design Docs, Invision, etc.) |