My Face

Implementing a Media Tracker using Solid

(Ongoing)

I've recently started using my Solid Task Manager in production. While I don't consider it finished, it's at a point where I can use it without adding more features. One of the things I want to do in my Path is to build the tools to have control in my digital life. I got tired of being at the mercy of others, so I don't want to use anything that doesn't embrace Autonomous Data. And the next step is to implement a Media Tracker.

At the moment, I am using TViso for tracking TV Shows and Movies, MyAnimeList for Manga and nothing for Books. I am not happy with either of those services, but given the vendor lock-in I can't easily switch to alternatives. This makes a great opportunity to continue expanding my toolbox.

My appetite for this task is of 40 hours with 5 weeks in real-time. Keeping this in mind, I'll scope this first version only to tracking Movies.

Activity

Task started

I've started working on this and you can find the code here. I tried to find a good name for this app but nothing came to mind, for now I am calling it media-tracker. I'm not happy with it, so it'll probably change before I'm done with the task.

Other than naming, something I've come across that I'd like to improve is the scaffolding. I'm starting to duplicate a lot of code across projects, so I'll probably release some packages with utilities. One will be plain javascript utilities, for example I have a wrapper for localStorage, Array utilities, Object utilities, etc. Many of these are inspired by Laravel helpers. And another package will contain application scaffolding for Autonomous Data apps using Vue and Soukai.

But of course, not everything was useless. Every time that I create a project from scratch, it's a good opportunity to see if I can improve something in my setup. This time, I learned more about how I am using service workers in my PWAs. Vue cli comes with Workbox installed out of the box, but I've been having some issues pushing updates to clients. I suspect that this has something to do with the default strategy. It seems that apps use precaching with the default configuration, which acts similar to the CacheFirst strategy. The problem with this would be that new code won't reach the clients until the cache is invalidated. So in my new configuration I am using StaleWhileRevalidate for index.html and all other assets can keep using CacheFirst because they are versioned. The truth is that I still have to learn more about this, but for now I'd say it's good enough (and it's not the main goal of this task).

Finally, other than all the house keeping, I've also started working on application specifics. When it comes to Solid, something that continues being a problem for me is finding fitting RDF definitions. But this time, I was lucky because schema.org already supports Movies. It also supports watch actions, so it doesn't seem like modeling will be a problem this time. But there is something new in this app that I'll need to investigate. In solid-focus, I am using one document per resource. But for this app, I think it's a better approach to keep actions in the same document as the movie they are referencing. Actually my initial idea was to have a simple date attribute to indicate when a movie had been watched, but after looking into schema.org I decided to use their approach. This also makes me ponder if actions should be resources at all, which doesn't make a lot of sense to me. So I'll have to investigate more on this.

It's taken me a long time to post this update because I've been busy attending FOSDEM, preparing a talk on Solid and as I'll explain later, solving some technical challenges. On the flip side I've implemented an RSS feed for these updates, maybe that's where you are reading this :).

As I mentioned on my last update, I've been pondering how to model watch actions in this application. Given that I needed to solve a new use-case, I decided to revisit the Solid docs and I'm glad to say they've improved. I also noticed I am neglecting setting up the Type Registry in my applications, that's something I'll have to fix at some point. The conclusion I reached after learning how others are handling similar use-cases is that I should create a new relationship in soukai-solid. As I suspected, watch actions should not be LDP Resources, although they'll be RDF Resources (because all rdf entities are). I hope this doesn't get confusing, basically LDP Resources are documents (they have their own url), and any other entities that don't map to a document will be plain RDF Resources. In modeling this I've called this non-document entities Embedded Resources, and the new relationship can declared using embeds and isEmbeddedBy. Since they are within an existing document they can't have their own url. I've solved this by using the url fragment (which I think is a standard practice in Solid). For example, if I have a movie with uuid 12345 at https://my-pod.com/movies/12345 the identifier for a watch action with uuid abc on that movie would be https://my-pod.com/movies/12345#abc.

Other than the reasons I've mentioned at the beginning, this has also taken me a couple of weeks in real-time because library development and app development are completely different. When I'm developing library code (soukai and soukai-solid), I have to be careful not to break existing functionality. I also need to make sure that every new feature is congruent with the library. But I think it's a worthy effort because that will allow me to make applications faster (and I plan to make many :D). This may cause this task to go beyond my initial appetite, but I consider that this library work is outside the scope of the task anyways.