I’ve been working with @rosano from 0data.app to make the simplest possible Solid application. The literal rendition of that would have been an app showing the user’s profile, but we made something a bit more fleshed out to showcase common CRUD operations as well.
We’ve tried to make it using as little dependencies as possible, and we are only using Inrupt’s library for authentication and the n3 library to parse Turtle files. Everything else is just plain HTML, JavaScript and CSS. You can check it out here: Solid Hello World
We’re going to present it next week in a Zero Data Swap, and you’re all welcome to join:
I love it ! Exactly what I’ve been looking for for a long time ! I think this will help a lot of people understanding the core priciples and struggling with beginner hurdles without the hassle of an IDE.
if you still need a volunteer for Wednesday, you have found one. just ping me here or in the Gitter.
@ewingson If you mean volunteer to make a similar one for remoteStorage or Fission then yes that would be amazing. Do you know how to get started? Feel free to message me and we can also collaborate.
@rosano@NoelDeMartin no, I have not an idea how to get started. I find the hello world of Solid amazing and thought you need a partner on remote side to demonstrate. if you have a primer for me ? I will show up at the event as I learned it’s more a discussion and collective learning experience. any preliminary information is more than welcome.
I know it’s meant to be a hello world, not a best practice showcase, but it might be interesting to introduce/explore some of the subtleties in a follow-on example, e.g.
Dealing with token expiry, now that it’s relatively short (1h access token on CSS). I’m not sure how much should be directly communicated to the user, but code should at least listen for failure of the refresh token flow and resulting expiry of the access token.
Communicating with the user about what data will be saved and where?
Local first vs online design (especially given this is a strength of remotestorage.js)
Conflict detection - probably using Etags and only for supporting servers for the time being?
These are probably all generic issues across at least solid and remotestorage?
Lovely, and very important for onboarding new people to the tech.
I don’t know if this already exists, but what Solid Project might have is a dedicated solid-examples repo that demonstrates feature-by-feature how stuff is used and steadily grows as people PR more example code to it.
@josephguillaume I know you meant these for a follow-up example, but here’s why these haven’t been tackled here:
To be frank, I don’t even deal with this in my real apps Which is not an excuse, maybe I should. But I definitely don’t think this should be part of a hello world. I have been adding inline comments for this sort of thing, so I may mention it.
A proper implementation would either use the type index or the Solid App Interoperability, but I decided not to use any of them because that would complicate the code too much. But I did mention it in the inline comments because I think it is important.
About how to communicate with the user, I consider that part of UX and I’m not sure if these should be included here. It’s always good to mention UX best practices, but the goal of this is to get a developer to understand how Solid works easily, so if we keep adding things, it won’t stay as simple.
The remotestorage version hasn’t been created yet, but I’m not sure how feasible it would be to have this working with Solid without over-complicating the code.
This is something I’d be happy to add, but as far as I understand ETags are not part of the spec in Solid yet, and I don’t use them in my apps for that same reason. But yeah, I think this wouldn’t complicate the code excessively and it’s a good best practice.
The file (and folder) are publicly editable if anyone wants to make any edits or comments. (I might try a dokieli doc next time).
I don’t think I’ve seen this kind of data format disclosure anywhere in the Solid world yet, so it’s definitely an aspirational suggestion rather than a recognised best practice…
I think this is a topic where the best practice is not clear yet, so I’m not sure if we should include anything about it in a Hello World.
My opinion on this is that most people don’t even understand what folders in a POD are, much less shapes and vocabularies. At the same time, I understand the needs for people who are aware of these. But I’m not sure how to reconcile both positions.
I don’t think adding statements such as This app will store data in the /tasks/ folder using the Action vocabulary from schema.org is a good solution because it will be confusing and I wouldn’t want to add this type of friction. Instead, I think a better approach is to make it work seamlessly out of the box, and give power users the possibility of tweaking this, with an “advanced options” type of thing. But I haven’t fully explored this yet, so I’m not sure how to go about it.
These days, I’m leaning towards including a storage choice as part of the onboarding so that people understand where the data resides. I like how my apps all store locally and you add a personal data store later if desired, but someone pointed out to me that it makes the storage location non-obvious: some people might mistakenly think it’s in a server somewhere although it’s in a browser, some people may not be aware that there are options. Basically something like @noeldemartin’s approach in Media Kraken fulfills an important pedagogical aspect of onboarding.
It might be only the Solid library that doesn’t include local-first storage: both remoteStorage.js and Fission’s webnative have it built in. I don’t think it makes sense for each developer to implement that.
I think the big issue at the moment is that across Solid Focus, the issue-pane, and this Hello world app there’s already three vocabularies. Type and shape registration doesn’t tackle this problem at all, so unless the user is made aware of the difference they’re going to have a major friction moment where they wonder why their new Todo app can’t see their existing data or why it’s created yet another separate folder.
Waiting for a seamless technical solution (probably involving conversion, see my later examples) will inevitably come with greater developer complexity (e.g. how do I anticipate whether the different shapes are compatible across apps).
Working out a satisfactory UI/UX solution could fix this now, potentially even without type/shape registration.
I don’t think people need to be aware of shapes and vocabularies. I do think they’d be aware of what a folder is. So maybe talking about data formats and folders on your personal storage might be better language.
Remotestorage.js has much less flexibility so it seems it’s currently relying on reuse of JSON schema modules. I don’t know whether they’ve run into any problems with prima facie compatible apps using incompatible data modules? From what I’ve read fission isn’t even interested in this interoperability problem yet. (see below)
To be honest, I find that solution adds too much friction
In all my suggestions I’ve included a default so that the user can click through without thinking but will have been made aware they have a choice.
Yep, but local first is an explicit aim for the data browser GitHub - SolidOS/mashlib: Solid-compatible data mashup library and Data Browser, so it will come eventually.
One option would be to bake it into rdflib.js and other RDF libraries. Another is that each app will have slightly different local first patterns and a library of approaches will emerge.
The hello world here is very low level (probably using solid-client would simplify it?). It makes sense to have hello worlds using higher level libraries that people would actually use.
Does Soukai solid provide sufficient support for local first? Would it make sense to have another identical hello world using it instead of the hand-coded CRUD interface?
They have a whole sub-community called ToolsForThought.Rocks (formerily Tools For Thought Interchange, where ‘interchange’ hints at ‘not export’), which is about using that genre of apps as a practical starting ground for understanding interop principles that can be generalized. They’ve interviewed Geoffrey Litt from Project Cambria multiple times and I think some people from the Solid community attend their discussions.
You might be interested in the notes from Zero Data Swap #1 for Michiel de Jong’s reflections on the challenges of linked data, and the audio of Swap #2 for a ideas about files and portability.
I went back and found I’d misinterpreted this statement: “This is not a focus of Fission’s webnative, to type data. We see that as an app to app concern which will be widely different.” from Interoperable Serendipity - #2 by boris - Zero Data Chat
At the moment, it’s not seamless. The new app I’m working on is offline-first, and I’m using soukai, but it’s still a work in progress. Eventually I think the answer will be yes :). But not yet.
Although even when that happens, I don’t think we’ll update this hello world. Nor use solid-client, that’s actually the point of not using any library. I would avoid using Inrupt’s library and n3 as well, but it’s not feasible without over-complicating the code.
I agree it’s useful to have hello worlds that use existing libraries, but those already exist. Off the top of my head, I can think of 3: My own Ramen app (Vue + soukai), @Virginia’s tutorial (React + Inrupt SDK) and @wkokgit’s Hello Solid (JQuery + LDFlex). There are probably more.
I can’t imagine anyone using remotestorage or fission without the libraries either, so I’d be interested in seeing what kind of hello world you had in mind there.
For anyone curious about remoteStorage, I just made a pull request literally copying Noel’s entire structure to a new folder and replacing the Solid parts with remoteStorage, the commits might help visualize the difference between the two protocols:
I think using e.g. solid-client would have been a more direct comparison to remotestorage.js
Underneath the hood, both use REST, whereas here only the solid implementation actually calls fetch directly, while remotestorage uses the broader module abstraction.
While the solid implementation uses turtle, that’s not a requirement either - the implementation could have used json-ld or simply JSON.
The biggest difference in the two technologies is in discovery (webid vs webfinger), authentication and authorisation (both oauth but then DPoP+webid+TBC ACL vs bearer token+ scopes)?
Which is not an excuse, maybe I should. But I definitely don’t think this should be part of a hello world. I have been adding inline comments for this sort of thing, so I may mention it.