Yet another Solid Hello World

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:

9 Likes

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.

1 Like

@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.

sure it will be a learning experience for everyone i think. be welcome.

1 Like

Looking good!

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?

3 Likes

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.

Various technologies and frameworks have this. Off the top of my head Vert.x has such a repo: GitHub - vert-x3/vertx-examples: Vert.x examples.

An alternative might also be that example repo’s add a solid-example topic label to it by default, making example easily findable on Github.

4 Likes

@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 :sweat_smile: 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.

3 Likes

Yep, not yet sure where in a hello world + follow-up all these should go, but thanks for continuing the conversation anyway.

Since I posted I had a go at thinking about the data storage communication question, so I’ll respond to that one now.

I think it’s a fundamental part of what we want Solid to be, so it’s worth including in a minimal form in a hello world.

I think the minimal form is a statement of the form:

This app will store data in the /tasks/ folder using the Action vocabulary from schema.org .

In the hello world it could be a footer statement or a placeholder statement in an empty task list, i.e. hello-world-solid/index.html at f6e55591ae1ef81f7acbaed2d79be79daaff481e · 0dataapp/hello-world-solid · GitHub

I’ve elaborated on my thinking here:
https://josephguillaume.solidcommunity.net/solid/data%20storage%20statement%20latest.md

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…

1 Like

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.

4 Likes

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.

1 Like

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 :slight_smile:
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 - solid/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?

Edit: I moved my discussion document to https://josephguillaume.solidcommunity.net/solid/data%20storage%20statement%20latest.md and added some thoughts on alternative language options.

1 Like

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.

2 Likes

Thanks!

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

1 Like

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.

3 Likes

Sounds good.

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.

I’ve created also a very small Hello World example in Svelte using Inrupt authentication client. Here: GitHub - MellonScholarlyCommunication/Svelte-Solid-Authn: A Hello World in Svelte with Solid Authentication

3 Likes

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:

2 Likes

Ditto for Fission

2 Likes

What do you mean by protocol in this context?

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)?

1 Like