Created: February 2018
Description
The Databaseless Digital Photo Album is an idea to design a digital media album similar to Google Photos but which avoids vendor lock-in by organizing photos and videos in folders instead of albums, and uses native JPEG EXIF metadata to store things like title, camera information, location, persons, etc.
Motivation
The motivation to create such an application stems from not being satisfied with current photo organization solutions on the market and the inherent difficulty of moving your memories from one service to another.
A lot of different services like Google Photos, Flickr, iCloud Photos etc purposefully make it difficult for you to leave the platform once you’ve uploaded your photos and videos. For example, the export tool for Google Photos returns all of the modifications and edits you’ve made to your photos and albums as a json file that you’ll have to parse manually via the use of a third party service, some of which can be costly.
By storing modifications made to a photo or video via built in protocols like EXIF or XMP, and using file and folder based storage mechanisms present in all operating systems, a databaseless photo album application could allow for a portable way to store and organize our media collections.
Technical Design
One of the main challenges of the databaseless approach is performant loading of thumbnails and searching. One approach is to use a database as a caching layer which is updated whenever new files are added/removed/modified from the file system, or when modifications are made to photo/video metadata. This way, loading a page of 100 files will require a quick lookup in a database rather than parsing each original file at several megabytes.
Potential Issues
Keeping this “caching database” in sync could pose a challenge. If a photo metadata is modified but the caching layer isn’t updated, there is incongruency in the system. Best-effor modification of the caching layer wouldn’t suffice, the system would need to have a guarantee that the caching layer has been updated.
Tech Stack
Any backend framework could be used either as an API only server or with built-in front-end layer. An ideal scenario would be a frontend microservice running a highly optimzed web app in a modern JS framework like React or Ember.js, with a backend using a framework designed for performance. A database capable of storing image thumbnails and supporting arbitrary relationships would be necessary to support mirroring the file and folder architecture of an operating system, since this doesn’t follow a strict schema.
Unfinished Implementations
- Photr (Newer incarnation using Rails v5 + Ember.js and JSON API Resources): https://github.com/kcarmonamurphy/photr ⎘
- Photonest (Backend for Photon using Neo4j as storage engine): https://github.com/kcarmonamurphy/photonest ⎘
- Photon (Ember frontend for Photonest): https://github.com/kcarmonamurphy/photon ⎘
