Joplin Web API for Nextcloud

Apps
81

I am thinking, if joplin naturally supports note sharing, then do I need to develop a tool for joplin-hexo to export blogs. . .

82

Well, I mean for simple "stupid" (mainly windows) users like me, an easy install would be a package like offered from https://synocommunity.com/ for my NAS. QNAP and other home use NAS-server producers might have similar free package repositorys. Nextcloud is not there, but installation was compfortable for me because I found a step-by-step manual for my Synology diskstation plattform. So install of a Joplin server should be possible in some way for me, just important to have my personal private server off from google. evernote & co. The workaround with saving my notes on Nextcloud is not a bad option for now. If you are targeting a large user community for Joplin with a server, I have no good ideas for lack of experience with linux, sorry!

83

Thanks for clarifying. I don't plan to specifically support Synology packages, but if it's anything like the main Joplin apps, some users might decide to take the released files and distribute them in other formats, perhaps including as Synology packages.

85

I found Gogs to be very easy to install (natively and via docker).

All go-based apps are usually very easy to handle (e.g. fzf, gh, terraform, vault, ...). I wish there was a way to automatically translate node js apps to go and just use go instead.... :wink:

86

The first Joplin client was actually done in Go :slight_smile: But turns out Go mobile support wasn't that great at that time (not sure how it is now), which is why it ended up being JavaScript.

87

So what it does is that it starts a local server running on port 3000, is that correct? Then it's up to you how you expose that server to the internet?

88

Cool, now imagine mobile support would have been great. Then we probably would have all the joplin clients in Go. And you could write the server in Go too. But now you already have all the code in js, so it makes more sense to stick with it for the server as well.

Yes, any port actually. 3000 is just the default.

Yes, there are examples how to setup a reverse proxy with different web servers in the FAQ.

Gogs supports TLS natively or you can terminate TLS on the reverse proxy. The choice is yours.

89

Yes, JavaScript got much better thanks to TypeScript, but I would still prefer Go if there was a choice.

Ok I see that's more or less what I intend to do with the Docker image. Ideally it would take care of everything, and expose the server to the internet without the need to setup a reverse proxy, but that seems a lot trickier (especially with Let's Encrypt integration) and perhaps not always wanted for users who already have a server running.

90

I don't think that's necessary. As long as there's documentation how to setup a reverse proxy, all should be good. Setting up TLS really depends on the cert provider and there are also plugins available for web servers.
You could always provide 2 docker images, if you really wanted to.
But maintaining a docker image that really takes care of everything is another project altogether.

I will set it up natively (without docker) and reverse proxy it.

91

When docker comes into play think should not all be contained in one container/image.
One for the Joplin Server, one for an externeal DB and on for reverseproxy when nessesary.
If all this is then put together in a docker-compose.yml it is extremely easy to start the service or use other images for proxy and co.

What base image in docker will be used for the Joplin service?

92

The docker-compose is there: https://github.com/laurent22/joplin/blob/server/docker-compose.server.yml

And some draft of the doc: https://github.com/laurent22/joplin/tree/server/packages/server

One thing I’m wondering is whether the db needs a secure password or not, considering it won’t be exposed to the internet.

93

Is there a reason to build the postgres image instead of using the ready made one (image: postgres:13.1-alpine) ?

Since the database is only needed in the backend there is really no reason. But I would split the container into frontend and backend, so that the postgress port is not reachable.

app:
    networks:
      - front
      - back
... 
db:
    networks:
      - back
... 

networks:
  front:
    driver: bridge
  back:
    external: false
94

Yes if you check Dockerfile.db you'll see I'm using the ready made image.

Thanks for the network tips, I'll give that a try. Although one benefit of the current setup is that you can ssh to the server then use psql to connect to the db. I guess if I move it to this "back" network, it will be only accessible from the app?

95

Yes i have seen the Dockerfile.db, I thought maybe this will be extended, since the same effect can also be achieved via the image specification.

Yes this is one downside but i think when the port is exposed, then a secure password should also be used. Because when someone runs the conatiners on a public server the DB is exposed with a default password :frowning:

96

will this implement the current Joplin Data API? In current server code I see it is file-based only, not note-based.

I would suggest to implement the same DATA API so current third party software using the Data API can be simply pointed to Joplin Server with minimal or no code-changes.

97

Joplin Web API for Nextcloud is now discontinued in favour of Joplin Server