P/S: the app currently lives at https://slemmy.libdb.so.

Thank you for the reply, I really appreciate it! Currently, my app has been migrated to the WS API so development can continue for now until the WS is removed completely in a later release or Lemmy addresses the CORS issue upstream.

As for the security concerns, I believe that most of them are addressed in this comment that is in the particular issue that I linked above.

It’s worth noting that CORS really only applies in the browser and that the WS API currently bypasses this protection (hence me being able to continue with the development).

No plans for a Docker image atm but you should be able to easily host this using any web server! It just needs to be built, and I might make a Github Action to automate that.

For now, the site is fully static and doesn’t require any server so you can just use the one hosted on Netlify.

I don’t really have a choice here, see https://github.com/LemmyNet/lemmy/issues/3109

Yup! Each profile will eventually be its own (possibly anonymous) account that belongs to an instance, something like this:

Whoops! I forgot to update it.

The websocket needs the right URL or it won’t work, you can’t always assume the websocket endpoint is at the root of the domain.

Right. I was reading a code snippet from somewhere else where they called into the root path, but the library that they were using probably did the appending in the background which I didn’t know.

That’s annoying, though, because setting up the right CORS headers to allow arbitrary online clients is a pain and I suspect many instance admins won’t do it.

There is an issue upstream tracking this. For now, I only mostly use Beehaw, so that’s fine.

As a side note, are you implementing the API from scratch? Because there’s a Javascript (Typescript) API that gets auto generated from the Lemmy sources that’s ready to use (supports both REST and WS).

Nope, I’m using lemmy-js-client. The WS part of it doesn’t do much, so I didn’t bother using it. The LemmyWebsocket type wasn’t also in the main import for some reason, but that wasn’t much of an issue.

Huh, interesting. It seems that a WS connection to wss://beehaw.org/api/v3/ws works, but not wss://beehaw.org. I remember reading somewhere that the WS API will eventually be removed, though.

I’ll continue development w/ the REST API until I feel like it’s in a mostly-working state, and then I’ll probably subject myself to the WS API after. Working with the REST API does feel a lot easier.

Here’s what I have planned at the moment: https://hachyderm.io/@diamond/110564684274449852

I don’t plan on making it feature-complete, just enough to be a Lemmy reader with some reply capabilities.

Websocket handshakes are done over HTTP. The endpoint for Beehaw’s WS API would be wss://beehaw.org/, so it’s still going to use the same CORS policies as accessing the / (root) path.

People comment a lot on performance, but I think Caddy can (and should) hold up perfectly fine. It might be worth it to experiment with running servers half on Caddy and half on NGINX, then see how the traffic is being handled by both to compare.

I do think the much cleaner config makes up for the maybe slight performance loss, though. It’s just so much less work to set up and maintain compared to NGINX. The last time I’ve used NGINX was years ago, when I decided to drop it entirely in favor of Caddy. I do think NGINX is only “standard” because it came before Caddy, and that most applications should not prefer it over Caddy.