Editing the database directly from Joplin Server DB

I have a quick question, If I edit the data of the Postgres or SQLite DB that stores all the sync notes in the Joplin Server, does this change my local data after the next sync?

Only if you change update_time, I think

If I can change the data directly from the server, So Technically we can make a Web app on top of the Joplin server which can use the Server Auth(as we can use the user details directly from the server DB) and view and edit directly from the browser.

I know there are many websites to access data from Joplin but I guess they use the clipper service and so work on the localhost, making a web app on top of the Joplin server will make many things easy, users can access it from anywhere from ( though they have to set up the VPS and sync with Joplin server).

In short 3 docker containers running on a VPS
Joplin server, Postgres, and the web app where the web app will use the Postgres data for auth, showing, and editing the notes.

I'm not sure, but weren't there server APIs that were also used in the collaboration plugin from last year's GSOC?

Because when editing directly in the DB also all entrys from other tables of Joplin (resources, ...) must always be edited or updated or otherwise it could come to inconsistencies and e.g. resources are deleted because they are no longer tracked correctly ...

That's why I didn't experiment with this on my server.

I will check the codes for the collaboration plugin.

It will be great if can somehow make a web app on top of the Joplin server. Most of the things are already working with the Server, Adding an Edit thing will make it perfect.

I don't think so. If I recall correctly it used a separate server for coordination, not the joplin server.

You don't need to limit it to only use the Joplin server though. You might as well use the sync code from Joplin and make the web app just another Joplin client syncing with any supported sync target type.

That seems cool, It will take some time but if everything works out well it can be very useful to everyone, I will start the project in a few days after some research on the working of the web app and stuff we can add to it.

Also check out Joplin-vieweb: a simple web viewer for Joplin notes

Thanks, I will try it out

FYI, I'm about (I still need a few days) to release Joplin-vieweb in a docker way, far far simpler than this way of doing.

I'll post in this post when it's ready.

In two words, the setup will be one command line (docker-compose up, change admin password (which is admin, logical ;-), setup cloud sync, and you're done).

A schema of the containers here.

Nice, you've even integrated Certbot in the config. Does it support multiple users?

A bit offtopic but why does it require 3 docker containers just to run a relatively simple web app? Also 3 instances of nginx...

Looked again, it's not 3 but 4 containers.

no. It's for me only, I dont share :wink:
Seriously, it relies on joplin terminal which does the main job. Only one joplin termial => only one user.
I may run one container per user... but it was not initially my main concern, which was: I'd like to access and edit my notes through a web browser.

About certbot: yes. It was not easy! I'll have to wait for the first certificate expiration to check if the auto renewal works.
But before, I must finish to install the whole stuff on my raspberry (I'm afraid when I'll do docker will complain: "hey, I don't have image for your arm architecture" :wink: . Wait and see

Hi. 4 containers :wink: EDIT: I saw your edit: indeed 4.

  • Container 1 (joplin-vieweb-nginx) if to provide the https mechanism. The nginx with certificates.
  • Container 2 (joplin-vieweb-certbot) is to deal with the certificates (create one, renew). It should not be on the same container, for security.
    Those 2 containers must be beside the 2 next, because some users will have their own server, certifictaes and so on (serving other apps on the same server). And indeed, one guy asked me how to not use them: he already has his web server and certificates.

Finally, 2 last containers:

  • Container 3 (joplin-terminal-xapi): it brings joplin terminal, with its API (on port 41184, there's a mistake on the schema). And the xapi (extended api) which provides synch endpoints: a node express server that receives those kinds of commands: get synch config, set synch config, get synch progres... and this server interacts with joplin terminal CLI)
    I need a nginx on this container because joplin terminal server (data API) only accepts requests from localhost.
  • And finally Container 4 the GUI (django-joplin-vieweb). He also need a nginx to serve the statics assets (at least that the way I know how to do).

We could simplify by merging container 3 and 4. That was my initial work, but I ended to split them up. I admit I don't really remember the rational behind. Separate the topics...
I was adviced to split the containers: usually on "standard" applications, we have one conatiner for db, one container for server, one container for serving logs... I try to do like that: on container based on node-alpine for joplin, and one based on python-alpine for django. Also to save the work to build a node-python image and keep them small. But I realize after that I would need an extra nginx on the joplin terminal container.

If I had only one test, I could argue for decoupling, but... :wink: Before I'll write one test, I would prefer write the front part in something like VueJS, and get rid off all the jquery stuff.

That's the story.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.