Cover image for Alternative Backend Approaches

Alternative Backend Approaches

johannesjo profile image Johannes Millan ・3 min read

Working on my favorite to do list & time tracker app Super Productivity I have spent quite some researching alternative approaches on how to share, synchronize and persist user data on the web. Beyond hosting your own REST or GraphQL backend API on your own server or using a cloud solution like firebase there are other less known avenues one can take. Let's explore some of them!


Claim: "Re-decentralizing the web"
Description: "Solid (derived from "social linked data") is a proposed set of conventions and tools for building decentralized social applications based on Linked Data principles. Solid is modular and extensible and it relies as much as possible on existing W3C standards and protocols."


Aspects I like

  • project led by Prof. Tim Berners-Lee, inventor of the World Wide Web
  • own your own data
  • allows sharing data between different apps

Aspects I don't like

  • feels a bit overengineered and complicated
  • not really clear what the status of the project is
  • the information for developers could be much better and much better organized

First things I'd like to evaluate

  • can I get this running now?
  • if so, is this half stable?
  • how complicated will using this be for my users?

Remote Storage

Claim: "An open protocol for per-user storage on the Web"
Description: "remoteStorage is the first open protocol to enable truly unhosted web apps. That means users are in full control of their precious data and where it is stored, while app developers are freed of the burden of hosting, maintaining and protecting a central database."


Disclaimer: I recently became a member of the organization on Github to help with the Typescript migration.

Aspects I like

  • own your own data
  • seems to be pretty stable
  • Dropbox or Google Drive as backend (how cool is that?)
  • (theoretically) allows sharing data between apps
  • supports file upload as well

Aspects I don't like

  • syntax feels a bit dated
  • I were unable to get the real world apps that I tested to work

First things I'd like to evaluate

  • speed
  • how does it fare with larger datasets
  • syncing and conflict resolution
  • how to do user to user interaction (is this even possible?)


Claim: "A realtime, decentralized, offline-first, graph protocol to sync the web."
Description: "GUN is a small, easy, and fast data sync and storage system that runs everywhere JavaScript does. The aim of GUN is to let you focus on the data that needs to be stored, loaded, and shared in your app without worrying about servers, network calls, databases, or tracking offline changes or concurrency conflicts."


Aspects I like

  • fancy & somehow sexy
  • pretty fast
  • cool community & super nice lead dev
  • real time user to user interaction build in

Aspects I don't like

  • might not be the best fit for non- social apps?

First things I'd like to evaluate

  • can I get this running with my existing non GraphQL, offline first, single user first model?
  • why does it appear to be so sexy? Is it just good marketing or what tickles my fancy? :)


Well, of course there is none yet (sorry) and this is a mere teaser and encouragement to experiment. I am pretty curious myself how well using those options will work out. I'll try to keep you posted on the details during the next weeks!

To be continued...

Posted on by:


markdown guide

Just checked blockstack. I have to say it looks pretty promising.


Do you have experience with these technologies? If so, please let us hear them!


I worked a bit with gun.js, it needs a bit of different app state / mindset of using pure objects instead of lists, but once you figured it out, it works great

Also there are some obstacles getting gunjs events as an rxjs observable (because of angular)


Thanks for sharing! Could you describe how one would approach handling a list in gun (possibly this even a good subject for a short and easily digestible article)?