Skip to content

Implementing a Task Manager using Solid

–

Some months ago I started working on a protocol to build applications that decouple storage from service providers. You can read about that here: https://noeldemartin.github.io/autonomous-data.

Well, one month ago Tim Berners-Lee (inventor of the World Wide Web) announced he's been working on a project called Solid, which is very similar to what I had in mind.

So I'll start working on a simple task manager using Solid to get my feet wet, and I'll decide whether to focus my efforts on Solid or continue developing my protocol.

Activity

Task started

Since I started looking into Solid, I realized it's built on top of many existing technologies I didn't know much about. These are some basic concepts I'd recommend getting familiar with before learning Solid:

And using this website you can find vocabularies to define your data models: https://lov.linkeddata.es

Today I finished the first version that stores tasks in a Solid POD (including a hierarchy of lists and workspaces). The code for this project can be found on this github repo: github.com/NoelDeMartin/solid-focus.

I still have many things to complete before I can consider this MVP "done". For example, making more efficient requests (I didn't succeed on querying with SPARQL yet), validating my use of Solid standards with community members, adding more RDF attributes, etc.

After some more digging, I found that SPARQL is not supported yet! Which makes performance a problem for applications with a lot of data (like a Task Manager). Instead, they suggest to use Globbing for the short term.

I guess this was to be expected, since Solid hasn't been declared as "production-ready", as far as I know. And this is the kind of thing I wanted to learn doing this project. So, good, let's see how this evolves and what I have when I complete this MVP.

I have been chatting with the guys working on Solid using gitter, and they are quite responsive :D. I opened an issue in the GitHub repo to keep track of this: https://github.com/solid/node-solid-server/issues/962

Today I've been working in something that lead me stray from the path to complete this task, but I think it was worth it to explore possibilities.

The first thing I did when I started working on this task manager is storing user data in local storage, in order to have the skeleton of the app before getting into anything Solid specific. I did it in such a way that everything was behind an interface, so I just had to reimplement the interfaces using Solid.

And what I realized today, is that it wouldn't be too difficult to maintain both implementations, and let users decide whether to use local storage or Solid (or potentially other backends in the future). This is obviously not something to take lightly, but since this is only an exploratory task, to learn Solid and alternative architectures, I thought it'd be a good idea to do it and see how it goes.

I have completed a first version were both offline and Solid storages are working locally, but the application is throwing an error when logging with my solid.community account. So I'll have to see what's different from my local Solid server for development.

I have also deployed a version to github pages, so if you are curious to see how it looks you can visit this page: noeldemartin.github.io/solid-focus. But keep in mind that you'll just be able to use the offline option at the moment. I'll post an update when I get it working correctly!

And it's done! The app is working both locally and using my solid.community account. You can head to the github repo if you want to check it out.

I'm still not closing this task because there are still some things to improve (globbing for better performance, UI tweaks, RDF types, etc.). But I would say the most important part has been finished.

Once I've completed what's left I'll close this and head to gitter and my socials to ask for feedback.

You know when sometimes you get wrapped up in something completely irrelevant to the project at hand? Well this happened today, not that it's a problem or that it took long.

I was using an SVG loader I got from this repository. And it worked fine, but I noticed how sometimes the animation would be stuck and I suspected that it had something to do with Javascript loading. Which is counterproductive, given the job of that loader was to show until the app was ready.

Turns out the problem was with SVG SMIL animations. They were deprecated, then they weren't, and now I don't even know what's the status. So I decided to move the animation to CSS. It wasn't straightforward because they don't share the same syntax nor the same operations. You can see how I did it in this commit.

Today I fixed a bug and set up some tests using my favorite CD/CI tool: Semaphore CI. I had seen they'd released a new version of their platform and was excited to try it out... Until I found out the new version only works installing a CLI :/.

Unfortunatelly, that's a no go for me. I'll continue using the old version for a while and let's see where it goes. It isn't that I can't install anything, it's just that I don't want any intrusive code running in my machine when the old version is working perfectly fine (actually they only need to access github, so I'm not sure why this new requirement...).

Finally I went around improving the network usage. I used two strategies:

  • Globbing: As I explained previously, this is currently the best way to get a bunch of records in one request from a solid POD. At some point SPARQL should be supported and replace this for most scenarios. Something new I found that I wasn't expecting is that globbing only works for resources, not containers (meaning you can get a list of all the resources within a container, excluding containers, so it isn't recursive).
  • Lazy Loading: In order to improve the requests overall, regardless of batching or not, sections are only loaded after being visited. Instead of loading everything at once as I was doing until now.

I just completed the last thing I needed to consider this task done: A logo!

Yeah, I know.

Anyways, at this point I consider this finished and I'll use the PWA for a while to see if it works as expected "in production". You can find it here. I'll probably continue adding some features here and there.

As per my conclusions regarding Solid. I can't say I've reached any definitive conclusion yet, but I have learned quite a bit. I now have a better feel for how working with Solid's like. It's clear that it's still a very early stage for the project, a lot of essential pieces are still in development and I haven't seen a lot of activity outside of the core community. But the goals are aligned with what I wanted to achieve when I was developing my protocol, so I'll continue working on Solid for a while.

There are a couple of things that worry me and I'll have to continue digging into:

  • Finding RDF Schemas and ontologies was more difficult than I expected, and I'm not entirely happy with the current definitions I am using. This worries me because I consider a "task manager" to be a use case common enough that I expected definitions for this to be established. Of course I can always create my own definitions or mix and match from different schemas, but that kills the idea I had of interoperability.
  • The learning curve and the community are not great at the moment. This can be attributed to being at an early stage, but if this doesn't change some years from now I can't see Solid becoming something that anyone else besides enthusiasts use. And that would be a bad sign. If this doesn't happen with Solid given the exposure and people behind it, it won't happen with anything else that tackles data ownership.

Task completed