System architecture
Drop System Diagram
Link to the diagram: https://drive.google.com/file/d/1fX3acchddzHSExsnm4uplsiB_nd8TM5s/view?usp=sharing
Location of AWS Instances
First, make sure that you have access to the "external-sandbox" account
Then, click on "Power user access", this will land you on the main console page. From here, you can choose to dive into either the S3 or the EC2 instance that's hosting Drop
DTO
Each JSON response object from backend APIs is deserialized in DTO. This Deserialized Response Master Sheet includes all the responses and their specific fieldnames, sub-fieldnames and its data.
If you notice the any UPDATES to the Response JSON object, please update the Master Sheet, so that people join in future can quickly comprehend the exact data returned from the Frontend / Backend.
Package Install
In general, once the Explore tab is clicked, the codebase would search all package repos(currently, there are DiskRepo, UrlRepo), and grab all the package information JSONs and deserialize them to IPackage / IPackageVersion. The interfaces would then be used to create downloaded JSON files for each package and version as well as the asset zip files; the JSON files are stored in .core-drop folder under %USERPROFILE% directory. For each package, the package.versions attribute would be updated from null to all of its available IPackageVersion that can be downloaded and installed by users.
PackageId and VersionId both attributes are used collectively to filter all the packages and find the particular package version that users intend to install. Once the package is found, the package.downloadedVersions will be updated with the particular package version (IPackageVersion), and the previous installed version will be deleted and replaced by the newly installed package version.
Once the package version that user intends to download is confirmed, recursively find its dependency packages (including the children dependency packages of the dependency pacakges, if there is any) and convert them into a PackageDependencyDetailsDTO, this DTO should provide each dependency package name, version id, and the version number. Use this information to find the corresponding IPackages to download along with the user-intended package. In the case of downloading a package that has dependency packages, the user should see multiple packages are installed on their target location. Currently, there is no special attributes made for packages to differentiate whether the package is a dependency package or an regular package.
NOTE: Package.versions is the information of all available versions of a package, which is displayed in the desktop app package view card - dropdown menu of "Versions" where users select which version to install. package.downlaodedVersions is the information displayed at the "installed" where users would see the version of the package they previously installed.
Package Uninstall
The current steps to uninstall packages are presented as following:
Once the version to uninstall is chosen, the .core-drop directory will be searched. The entire installed packages and versions are created into IPackages and IPackageVersions types based on the corresponding Package.JSON and Version.JSON respectively found in each installed package directory.
Find the selected package version to uninstall from the group of all installed IPackages and IPackageVersion.
Apply the same recursive method that used for installation to find all of the dependency packages of the particular package to uninstall.
Find the particular package version and its asset single file / zip file. If it is a single file, parse the file name and the target location to find the asset files that installed on the target location directory, and delete the asset files.
If it is a zip file, go though each zip archive(file contained in the zip) and parse each archive name with the target location directory, find and delete the asset files that were installed on the target location directory.
If the dependency package is implemented in the installed / uninstalled process, the uninstallation will check whether the package has any dependency to any other packages, if there is, delete the dependency packages that are not also required for other packages or purposes.
Application vs. Dependency
Application package: This is the main package that was selected by users to install to their local drive. The Application package may or may not contain dependency packages. Once the Application package is deleted, its dependency packages are also to be deleted automatically unless they are also shared by other packages.
Dependency package: This is the supporting packages required to run the main package users installed. When the Appliction package installed, its dependency packages are automatically installed along with it. The Application package also may or may not contain dependency packages. They follow the footsteps of their Application package - they are to be deleted if the Application package they support is no longer existed.
Automatic Background Update
Not everyone likes to manually update their packages, especially for those who need their working environment to be always up-to-date and hassleless from endless clicks. Therefore, Drop provides users the ability to enable the automatic update process running in the background to ensure their packages always fresh.
Last updated
