Sync and Share (Under the hood)

This article is part of our "Tiger Bridge - Under the hood" series, where we uncover technical details about our product, dive deep into the solutions it offers, and explain which decisions we had to make while designing it.

Definition/Background

The problem with syncing and sharing is not the same as data replication in its basic understanding. A typical sync is between two machines. Here, we are focusing on a subset of the data.

If you have one file and want it sent to someone, this used to be done via mail or FTP. The main problem with them is that you can only work with the finalized object – it is not possible for collaboration (syncing) or iteration – another version of the same file (sharing) – to happen. It is even harder when more than just a few files are involved.

Problem

               

When User A wants to send something to User B, there are several possible scenarios, each of which presents a sharing problem:

    • single file – this can be accomplished through different methods, mail included; it does not introduce such a big problem on its own
    • multiple files – mail can work for about 10 files, for example; for more, it gets difficult to manage and introduces a problem
    • multiple recipients – it gets tricky to keep track of responses and proposed changes, so the workflows at hand face a huge problem

What we would really want, as end users, is to have some folders with certain files on our PCs, and the ability to share them with our colleagues so they can see them the way we do, with the most up-to-date information on newly created or deleted files.

Existing Solutions

Popular solutions currently being used are Mail, FTPs, sharing platforms like WeTransfer, a shared storage on a file server, and some cloud solutions like Dropbox and Google Drive.

Cons

Mail still works for a low number of relatively small-sized files. Collaboration is still hard to achieve – if you send a file to be reviewed by multiple people, it gets difficult to keep track of every proposed change for your document.

The procedure looks like this:

 Create a .docx -> Attach to mail -> Send -> Receive -> Save As -> Modify -> Attach -> Send -> Receive -> Save As

When we you click “Save As”, you face the question “Shall I save a new version of my file or override the previous one?”. It might be easier to opt for the second option and keep only one version, but what if you didn’t like something in it?

We almost never use FTPs anymore as they are complicated to setup and maintain, and there is no peer-to-peer collaboration or shared storage. One party has to upload the content and another has to download it, which is very time-consuming and also a blocking operation. Furthermore, if the transfer gets interrupted in the middle because of a networking problem, you will need to start over.

Solutions like WeTransfer are also unusable as there is no connection between what is sent and what is received. When creating a new version of a document, the fact that you have a previous one copied over won’t help, but actually hinder you. Collaboration over the same doc is even harder to accomplish.

File servers solve some of the problems the previous solutions present: you can work with the same file, share it with a colleague by providing its path, let your colleague edit the file, save a new version of it which you can pick up, and so forth. This works well for the use-case we are presenting, but it is constrained within a local network where everybody has access to the shared storage on the file server. If we divide potential consumers of such a solution into categories, these would be individuals, small and medium businesses (SMEs), and large enterprises. The file server approach would work for SMEs but not for the others. This is because different users are not connected to the same network, and large enterprises require VPNs to be set up to keep physically distant locations reachable.

The cloud comes to solve that problem. Google Drive, Dropbox and other similar solutions operate like FTPs with central (cloud-based) storage. Although they do help in certain cases, they do not fully solve the main problem with syncing and sharing. Some applications like Word and Excel can really benefit from these solutions, but that is not the case for other types of files – AutoCAD, for instance. For such files, the solution works like an FTP – you upload the file, somebody downloads and uses it with an application on their machine, then a new version is uploaded so someone else can access it and continue making changes. This is how collaboration looks with such a solution.

Our Solution

Considering the limitations of all existing solutions, we implemented something different. We replicate the local information to the cloud and then let anyone who needs access to it reach it through the same cloud location.

Tiger Bridge has some built-in logic which allows files to continue their download or upload even if there are network drops while the transfer is happening.