In version two I wanted to create the backend as agnostic as possible. The kind of data that flows through the system is somewhat irrelevant, similar to a database or Solid. LightNet core would be a box which would handle authentication, CRUD actions, access control and media storage to an S3 compatible storage.
On top of this core a generic channel viewer would be made. This would replace https://library.mediaworks.global. It would display the data via server driven UI.
Server driven UI has a couple of ideas:
- It does not matter if there is data that the app does not understands, it only displays data that it has definitions for
- How something is displayed is defined in the back-end and this is shown in the front-end
Building this generic front end took some time but I had a working code base that showcased exactly this.
Lessons learned:
- Comunica in the front end increases the bundle size with 1.5 MB
- It was very helpful to have a folder on disk with content. In the future I wanted to write this to the database and solve the challenge of staging content. I mean if you do a config change, that is saved in the database how will you take this from DEV to PROD? Flatty, the database wrapper that I have made helped with that. (we have a similar but smaller structure in version 2 of LightNet)
- RDF everywhere made it harder for new people to join. This was one of the criticism of Simon Faber. One counter argument is that it can be fixed with a good SDK, however Simon Faber did not want to serve RDF from the API. This is one of the disagreements that made me consider starting over and going through each problem a second time but then together with Simon Faber.
- The component based way of working enabled Emanuel to work on the project.