In the rapidly evolving landscape of web development, new frameworks, languages, and tools constantly emerge to fade into obscurity as quickly as they arise.
Find 5 minutes to read this
Nevertheless, there are other times when seemingly insignificant forum (and Google+, 🪦) discussions come out years later from the drawer of your subconscious ready to solve an annoying problem from your last project.
Filesystem APIs are one of those epiphany. One day, while working on our internal tool to manage the generation of internal documentation (quotations, contracts, etc.), I faced a dilemma: Where should I save this documentation?
Initially, I toyed with the idea of building an isolated database to store the generated documents for each project. However, the thought of not saving everything within the same filesystem, thus further fragmenting our already precarious folder organization, caused me a severe headache that triggered the retrieval of a feature I had heard about years before and had completely forgotten. I opened MDN, typed in "Filesystem," and there it was: Filesystem API, 90% fully supported by almost all browsers (damn you, Firefox), ready to be used.
Filesystem APIs are a feature that allows browsers to access and manipulate (as the name suggests) the filesystem on the user's computer. Of course, this is only possible with the user's authorization, similar to webcam or GPS location access. However, this feature enables the development of peculiar projects: projects that do not require a database as they directly interact with and write local files to disk, a sort of editor, you could say.
In the case of the project I was working on, this is how our studio filesystem works: At the base, there is a list of folders representing clients, each containing folders for individual projects.
AA-FirstClient/
├─ Project/
├─ Project/
AB-SecondClient/
├─ Project/
AC-ThirdClient/
├─ Project/
Using the Filesystem API, I can write a web app that, through a file picker, allows me to open a client's folder and create a new quotation, contract, or other documentation. This leads to another side effect: since the studio's filesystem automatically uploads to Dropbox and files are saved directly in the folders, they will sync online being available to the other team members who can access them using the online web app.
To quickly list the problems solved:
- Filesystem API allows, for example, working with very large or heavy files without worrying about online storage as they will only live on the user's computer.
- Filesystem API adds better security as files not being transferred over the network have much lower chances of being leaked.
- Making the filesystem available through a cloud service (and clouds like Dropbox have rollback capabilities enabling a file history feature).
Another example
Once I understood the mechanism and functioning, I had fun finding other applications I had developed earlier to convert using the Filesystem API, and one in particular worked very well. For some months, I have been working on a tool (a collection of tools to manage music, combat, quick notes, etc) to help me master the role-playing game sessions I play with my friends. Before the introduction of Filesystem API, everything was handled from a local Node server to read and write files. Now I can quickly open a different folder for each played adventure, keeping everything separate and organized.
Conclusions
In conclusion, this article doesn't have a particular lesson or moral, and it will also need to be revised as I'm writing it very late at night. However, I hope it has sparked an idea in you, just as it did in me.
Top comments (0)