Hi everyone, how do you think of Joplin in the Web. I know there’s a web-app before but that run based on DATA API which require Joplin to run on Desktop.
I’m aiming to create a web client that connects directly to Cloud sync storage. I know Joplin prioritizes offline-first, but we all backup (synchronize) to the cloud I guess, I think it’s just convenient to have a web view that we can check anywhere with little setup (authentication only).
Image below is React with connection to WebDAV
A bit of update: I checked out personalizedrefrigerator's Joplin web version, and I believed it's the most proper way to approach Web version Joplin. React-native-web + sqlite-wasm.
I guess my web version, will be more online-based (again, a bit against Joplin philosophy, but it more of a convenient tool that a full fledged app)
Having a quick way to view and edit small changes quickly, browser-based.
My web aim to render whole notebook without full syncing. And for editing, I will have single note editing only and click submit/save to perform sync on that one, similar to Github editing online (no full syncing or scan).
Hope it helps someone, if not, I guess I'll make it for personal use only.
That's definitely something that would interest a lot of people. I haven't looked into this for many years but I remember last time my conclusion was that it would make more sense to somehow run the server as a regular Joplin client because it would handle all the edge cases including conflict resolution, etc. but maybe there's a better way. E2EE is definitely going to be challenge but maybe that can be ignored initally.
it would make more sense to somehow run the server as a regular Joplin client
This is the conclusion I came to as well, for a separate purpose. I wanted to manipulate joplin notes over an API (just like the data API) in a headless fashion. I struggled with the server API for while until I realized: the joplin server is a SYNC server only. It’s not made for note manipulation (like a client).
I was expecting basically the data-API as a server. So instead, I use terminal client in API mode, which feels funny since now there is:
your app → joplin terminal API in headless mode → joplin server.
Which also means your app basically has to duplicate state (in the terminal app) and will lag behind the server (unless you spam the sync frequency). Not a huge deal, just a little weird.
Ideally it’d be nice if the joplin server itself duplicated the data API, so you could basically use it directly from your app.
your app → joplin server with data API
A small nice-to-have would be some clear docs and a simpler way to run terminal client in headless mode. The only thing I think it was missing was ability to listen to non localhost IPs, but otherwise was 99% there last I checked. I’d be willing to help with this if it would be useful for others.
Now, I’m coming into an issue that, I cannot parse the tree of Joplin notebooks and notes ahead of time (I’ll need to read file content for parent id and name for that), which will requires mass files read.
I’m testing it with OneDrive and hitting a rate limiting.
If mass files read initially (through batching or whatever mechanisms) is the solution, then maybe I’ll need to load them to a browser database (like sqlite-wasm) for fast rendering.
Well, I don’t think it would be any faster than the already available web-app.
Hi, you can take a look at: GitHub - khuongduy354/joplin-sync-lib at read-only-api
This aims to create a unify interface for items read/write to cloud storage.
Currently: create/read operations works well on WebDAV, I haven’t updated the docs yet for the new syntax.
I’m able to run it in a pure React app with a few stubs (no Node.js required), is this what you need?
