Umai, an offline-first Recipes Manager

[NoelDeMartin]

Homepage | Source Code | Report Issues

License: GPLv3
Author: Noel De Martin

Umai is a simple Recipes Manager to collect all your precious recipes.

• Create your own cookbook.
• Import recipes from any website.
• Adjust ingredient quantities automatically.
• Share recipes with your friends.
• Use it completely offline (it’s an offline first PWA!).
• Keep data safe in your Solid POD.

Screenshots

[bourgeoa]

Impressive. Thanks

[renyuneyun]

It’s great to see it’s announced here. Very elegant interface. Though unfortunately it has some i18n issue (Doesn’t work with Chinese content.)

I noticed “offline-first” this time, which triggers my alarm about CRDTs (I see you mentioned this elsewhere) – I’m trying to understand how CRDTs work and how to work with Linked Data for a synchronization mechanism like CRDTs (thus enabling the possibility, though maybe not very useful, to use Solid Pod as a backend/peer).
How is offline-first implemented for Umai? Is it storing data inside browser storage, and send/sync that with the Solid Pod; or is it using CRDTs, with one peer storing to Solid Pod (thus having the ability to connect with more peers)?

[NoelDeMartin]

@renyuneyun

It’s great to see it’s announced here. Very elegant interface. Though unfortunately it has some i18n issue (Doesn’t work with Chinese content.)

That’s unfortunate Can you share more details about this opening an issue in GitHub? (and maybe share an example url as well, so that I can reproduce it).

Also, if you’re interested in seeing the app in Chinese this time I’ve prepared it so that it can be translated :D. Check out the translation guidelines.

@renyuneyun

How is offline-first implemented for Umai? Is it storing data inside browser storage, and send/sync that with the Solid Pod; or is it using CRDTs, with one peer storing to Solid Pod (thus having the ability to connect with more peers)?

I talked about this in this other thread: Request for Comments: CRDTish approach to Solid.

TLDR: The data is stored locally in IndexedDB, and when it’s synchronized with the POD other than the recipe data, a list of operations are sent. That way, when other devices get data from the POD they’ll get the operations and merge changes instead of overriding. But yeah, it’s CRDT mediated by the POD, not peer to peer (although technically the architecture allows it to work that way, but I haven’t implemented it).

[renyuneyun]

@NoelDeMartin

That’s unfortunate Can you share more details about this opening an issue in GitHub?

Sure. I’ll open one. Unfortunately I can’t share an example URL because… it didn’t allow me to save the recipe.

@NoelDeMartin

Check out the translation guidelines .

Good to know it’s there. Will take a look.

@NoelDeMartin

I talked about this in this other thread: Request for Comments: CRDTish approach to Solid.

Whoops. Missed that thread. I’ll check it out.

@NoelDeMartin

a list of operations are sent

Won’t that be a significant storage overhead if the CRDT operation history is very long?
(Maybe I should check out the other post first.)

[NoelDeMartin]

@renyuneyun

Sure. I’ll open one. Unfortunately I can’t share an example URL because… it didn’t allow me to save the recipe.

Ok, I was assuming you meant that it didn’t work using the “Import from the web” functionality. If it doesn’t work by creating a new recipe from scratch that’s even worse . I guess you can write the Chinese text in the GitHub issue (like recipe name, description, etc.) and I can reproduce the problem by copy-pasting the content.

@renyuneyun

Won’t that be a significant storage overhead if the CRDT operation history is very long?
(Maybe I should check out the other post first.)

Yes, that’s one of the concerns I raise in that thread :/. I don’t have any solution for now, so I’ll see how it goes and find some solutions when and if it becomes a real problem. Some ideas I have for example is squashing history and such, but I figured it’ll probably take a long time until I need to tackle that.