Elvith Ma'for

Former Reddfugee, found a new home on feddit.de. Server errors made me switch to discuss.tchncs.de. Now finally @ home on feddit.org.

Likes music, tech, programming, board games and video games. Oh… and coffee, lots of coffee!

I � Unicode!

  • 0 Posts
  • 70 Comments
Joined 2 years ago
cake
Cake day: June 21st, 2024

help-circle







  • No, that’s just another hypothetical app that you’re using a reverse proxy for. I just included it to show how you can also set settings for a single subdomain/reverse proxy entry that isn’t used globally on all domains that get served. I used a hypothetical REST API that needs a CORS Header that other apps don’t need (or maybe serve themselves).

    admin off disables Caddy’s admin interface (which shouldn’t be public and if you’re using config files this usually isn’t needed. So just a bit of gardening)

    servers sets some general server options.

    and then I just inserted several blocks that each define a reverse proxy to a different app / backend to show that you can just dump them all in a single Caddyfile. And the last example to show that you can set specific settings only for a specific subdomain instead of globally. As I set headers mostly used by REST APIs, I just called that api.example.com instead of app3.example.com.



  • If you like, I can send you an example of the Caddyfiles, that I’m using (I used the import directive to split every service into its own Caddyfiles, you could just copy and paste everything in the same file). It will take a few hours until I get home, though.

    But basically you can just put every subdomain and it’s target in a separate block and the add some things globally (e.g. passing the original IP, switching off the admin API of Caddy,…)

    Something like this should work:

    
    admin off 
    
    servers {
    		client_ip_headers X-Forwarded-For X-Real-IP
    }
    
    app.example.com {
        reverse_proxy 127.0.0.1:8080
    }
    
    app2.example.com {
        reverse_proxy 127.0.0.1:8081
    }
    
    api.example.com {
        reverse_proxy 127.0.0.1:8082
        header {
            Access-Control-Allow-Methods "GET, OPTIONS"
            Access-Control-Allow-Origin "*"
        }
    }
    







  • I have a Copilot license at work. We also have an in house „ChatGPT clone“ - basically a private deployment of that model so that (hopefully) no input data gets used to train the models.

    There are some usecases that are neat. E.g. we’re a multilingual team, so having it transcribe, translate (and summarize) a meeting so that it’s easier to finalize and check a protocol. Coming back from a vacation and just ask it summarize everything you missed for a specific area of your work (to get on track before just checking everything chronologically) can be nice, too.

    Also we finetuned a model to assist us in writing and explaining code from a domain specific language with many strange quirks that we use for a tool and that has poor support from off the shelf LLMs.

    But all of these cases have one thing in common: They do not replace the actual work and are things that will be checked anyways (even the code one, as we know there are still many flaws, but it’s usually great at explaining the code now - not so at writing it). It’s just a convenient method to check your own work - and LLM hallucinations will usually be caught anyway.