IronOxidizer / lemmy-lite

A static, JSless, touch-friendly Lemmy frontend built for legacy web clients and maximum performance
https://lemmylite.crabdance.com
GNU Affero General Public License v3.0
79 stars 5 forks source link

Could other web servers be supported? #3

Closed EchedelleLR closed 3 years ago

EchedelleLR commented 4 years ago

I would suggest Apache HTTP Server at first.

IronOxidizer commented 4 years ago

I'd be willing to make it compatible with Apache, but this is pretty low on my priority list. If someone wants to create an Apache config, I'd accept the PR.

gatewaynode commented 4 years ago

My 2 cents. A Rust native web server would be preferred as the only requirement. When you need reverse proxies you really should be getting a fully managed CDN, no need to risk running your own proxy when CloudFlare or CloudFront are so easy and cheap. I'm fine with NginX for now.

EchedelleLR commented 4 years ago

@gatewaynode

What's about https://libreho.st projects run by being self-hosted and taking advantage from their own network or VPS/Dedicated server protections (which not include CDN) or even without it for privacy, non-free services, etc?

EchedelleLR commented 4 years ago

I would like to start a pull request but I don't understand NGINX config so well to make a translation. Also I need to know the equivalent things in Apache HTTP Server when I understand it.

For example:

server {
    listen 80;
    server_name lemmylite.crabdance.com;

    rewrite ^/(.*)/$ /$1 permanent;
    include mime.types;
    root /etc/nginx/lemmy-lite;
    access_log off;

    # Gzip html on the fly
    # Everything else should be pre-gzipped to reduce runtime load
    gzip on;
    gzip_vary on;
    gzip_static on;
    gzip_comp_level 9; # Use 7 or 5 if cpu limited

This part can be partially understood. Gzip compression is implemented through mod_deflate which is loaded separately commonly (Debian style) and not in the same file config but also I read gzip_vary and gzip_static which I don't know for what they are. I could replace partially that part by a suggestion to enable the deflate module in such case or look for the way to load it correctly inside a site config.

    location = / {
        if ( $is_args != "" ) {
           proxy_pass http://0.0.0.0:1131;
        }
    }

I don't know how to make a similar function in Apache HTTP Server exactly. No idea if it is equivalent to something else there or I must investigate for a way to define one.

Here the most complex part:

    location / {
        expires max;
        try_files $uri @lemmylite;
    }

    location @lemmylite {
        expires off;
        proxy_pass http://0.0.0.0:1131;
    }

First, what is the difference between "location = /" and "location /"?. The second part implies what does the "try_files" sentence which seems to get the url and call the other location in the config which I understand pretty well in this case. That is not taking in account how to manage requests expiration.

IronOxidizer commented 4 years ago

gzip_vary on; If the user has a non-gzipped version that is locally cached, it won't request for the gzipped version.

gzip_static on; Allows nginx to looked for static files that have the .gz suffix, essentially allowing for gzipped static files.

what is the difference between "location = /" and "location /"?

location = / is for when the user is specifically on the root, location / is for literally every path (except for root since it's already being handled above).

try_files Tells nginx to try to serve static files that match the URL request relative to the root which was set with root /etc/nginx/lemmy-lite.

expires Tells the client how long to keep the static content cached for. We disable it for the HTML since it's constantly changing but everything else should rarely change (when the project becomes stable).

IronOxidizer commented 4 years ago

@gatewaynode

A Rust native web server would be preferred as the only requirement.

I agree, I love the idea of only having a single binary to worry about, but leveraging NginX provides so many benefits:

  1. Built in gziping
  2. Impossibly fast static file serving (can be mitigated and improved by using a CDN but isn't free or FOSS)
  3. Easy integration with Lemmy and Docker
  4. Simple HTTPS setup with certbot

Until I have a better alternatives for the aforementioned benefits, I think NginX is the way to go.

IronOxidizer commented 3 years ago

This is no longer relevant as we no longer use NGINX and serve files using actix-web-static-files

EchedelleLR commented 3 years ago

Thank you for closing. I also almost forgot about this because I got busy with current studies.

I am glad to see that in the end it came with a neutral solution.