setup nginx to server blobs

[rabble]

Setup so that the blobs are served from nginx to a docker image which mounts the blob directory from the planetary-graphql docker container.

[cooldracula]

I worked with @mixmix to make sure the routes were right for the blobs, and updated our nginx config to route blobs properly from the graphql server. This solves the issue of blobs not showing up on planetary.pro and future instances.

This pair resulted in updated ansible scripts, and a resulting PR in ps/ansible-scripts and PR in ps/planetary-graphql

It is a bit more complex to have the blobs served directly from nginx, as the blobs folder is not a flat listing. Would we still want to pursue this, @rabble ?

[mplorentz]

@cooldracula do you think the current performance problems we are seeing on Planetary.name would be helped by this? Or is loading images from graphql not the bottleneck anymore?

[cooldracula]

@mplorentz , I think it is more related to the size of the images we are bringing over, rather than where they are being served from. My initial thought is that the slowness is coming from two places. The response from the graphql server could be sped up, but we are still bringing over large files for small profile images. For example, when I visit planetary.name now I see a post from Irina, with an avatar that is 37px x 37px; but the image used for this avatar is 750px x 1001px. Even if we switch where the file is being served from, it's still a 108kb file that we are trying to send over.

It might be good to look into how the blob server is set up, and whether we can have different sizes of these images. We only send a 50px x 50px version of the avatar image when on the homepage, and bring over the larger one when looking at their profile page, for example. This, combined with tuning the graphql server on both the application level and the droplet level, will likely speed up the performance.

[mplorentz]

@mixmix @chereseeriepa have you all done this sort of image compression for Āhau?

[cooldracula]

I paired with @mixmix for a bit to look more into the feasibility of adjusting the nginx config to serve the blobs directly. If it was a quick 3-line fix, then I wanted to do that fix and help with the speed issue.

Summary

It would not be a 3-line fix and would likely require changes in the graphql server's code, the room frontend's code, and the nginx config. It is feasible, but may not be worth the development time. If we do not want to do additional development, I recommend we close this ticket.

More Detail

The blobs are stored as flat files in the /db dir created by our graphql server. This directory is organized around the hex encoding of a blob, and basically as db/blobs/algorithm/first_two_chars_of_hex/remaining_chars_of_hex

So an example blob in the server has the path :

db/blobs/sha256/12/b39b735b36f7f08d183785c74e44fb0afb94775565d6271a4f6cd34b7e3bb0

This above blob, specifically, is this image on planetary.name which has the uri:

https://planetary.name/blob/%26ErObc1s29%2FCNGDeFx05E%2Bwr7lHdVZdYnGk9s00t%2BO7A%3D.sha256?

In other words, the uri given in the graphql response differs from its actual location in our server. So simply taking the blob route and using regex to match it to the correct file would not work.

The difference between the blob uri and it's file path is that the uri is base64 encoded and the filepath is hex encoded. So if we wanted to do it entirely in nginx, we would want a pipeline of url-encoded->base64 -> hex -> filepath. This encoding pipeline is not a part of the core functionality of nginx, but is possible through extending nginx with njs, which is basically a subset of javascript embedded into nginx.

Additionally, we wouldn't want to fully replace the blob server with this string matching, as the server is not just serving the files, but grabbing them from the room peers. In short, if there is a blob in a text message, then there is a step in the process where the blob server checks if the blob exists locally and, if not, explicitly requests it using some ssb-blob methods. If we switched over to just nginx, we would lose this step( or we could try to rewrite ssb-blob methods in njs).

What would likely be a cleaner solution would be to extend the response in our graphql server to include a hexURI and a base64 uri. Then, we would update the rooms-frontend to display the hexURI instead. We would then add a route to our nginx config at /blob/hex that does our pattern-matching and serves the file straight from nginx.

At this point, though, we were designing new functionality in multiple areas of our code. I did not want to go further down this path, yet, as it would be a time investment and we are trying to reduce the time spent on the web viewer. It is s a task I could take on, though, if we decide it is worth it.

[mplorentz]

Thanks for the investigation. We discussed and agreed to close this as a won't fix given the effort required.