Opinions on running a server with Golang?

[candycanearter07]

I've been considering switching off of using PHP for my site for a bit, and use a backend thats more progmatic to make it easier to reuse elements between pages and stuff. I've been on the fence with Sinatra bc it doesn't seem as well supported and recently found Golang's web server library and I think it looks cool, but wanted to see if anyone else had opinions on it since it would take a while to convert my old php pages to this

[futurearcana]

To be honest, while I'm not much of a go person myself, I know that who uses it is pretty happy with it. I've seen it described as "boring", which is quite a good thing in the context of a tool, so it's likely gonna be a good fit. Plus there's plenty of backends in go so I think you should be well supported for the foreseeable future

I made a couple of backends myself in rust with axum, and I can certainly tell you that it's nice, and you get all the usual rust niceness of "if it builds there's a good chance it's also correct". Then again as usual with rust it also takes a bit of effort to set things up just right. Then again, I don't know how go compares.

I'm not sure what your use case is, but a static site generator (SSG) could also be an option you might want to look at. Most SSGs are tailored towards blogs, which I find very annoying, that's why I made my own that tries to be a lot more generalist. You can look at my website's source code for an example of what a fully built site would look like.

[Dan Q]

Firstly, I'll disagree with Sinatra not being well-supported; it's doing well IMHO!

PHP's fine too, of course, and reusability between pages is not a problem at all! You either need to patch your own thing together with e.g. require_once(...) etc. commands, or consider using a framework like Symfony or Laravel.

But Golang is great too. I wouldn't say it's any better for either support or composability than either of Ruby+Sinatra or PHP(+an optional framework)... but it's good for performance and - if these are things you care about - strict typing and thread-safety.

I've implemented both personal/fun and commercial projects in all three of the things you've listed, and would do so in all three again. For me, assuming there are no other considerations (e.g. working with other developers, building atop an existing system, etc.) the decision is based mostly on:

- Size: for a smaller or "bittier" project or one that has to "deploy (nearly) anywhere", I favour PHP
- Performance: if I'm looking for bleeding-edge performance, I reach for Go.
- Joy: if I want to feel my happiest when I'm working, I choose Ruby, because it's my favourite programming language!

Those are the deciding factors for me. Personally, I don't think it makes much difference, so use whatever pleases you! They're all great choices!

[candycanearter07]

I'm not sure what your use case is, but a static site generator (SSG) could also be an option you might want to look at. Most SSGs are tailored towards blogs, which I find very annoying, that's why I made my own that tries to be a lot more generalist. You can look at my website's source code for an example of what a fully built site would look like.

I REALLY don't want to use a SSG, I found them very frustrating when I was on neocities and don't want to mess with one again

Firstly, I'll disagree with Sinatra not being well-supported; it's doing well IMHO!

PHP's fine too, of course, and reusability between pages is not a problem at all! You either need to patch your own thing together with e.g. require_once(...) etc. commands, or consider using a framework like Symfony or Laravel.

But Golang is great too. I wouldn't say it's any better for either support or composability than either of Ruby+Sinatra or PHP(+an optional framework)... but it's good for performance and - if these are things you care about - strict typing and thread-safety.

I've implemented both personal/fun and commercial projects in all three of the things you've listed, and would do so in all three again. For me, assuming there are no other considerations (e.g. working with other developers, building atop an existing system, etc.) the decision is based mostly on:

- Size: for a smaller or "bittier" project or one that has to "deploy (nearly) anywhere", I favour PHP
- Performance: if I'm looking for bleeding-edge performance, I reach for Go.
- Joy: if I want to feel my happiest when I'm working, I choose Ruby, because it's my favourite programming language!

Those are the deciding factors for me. Personally, I don't think it makes much difference, so use whatever pleases you! They're all great choices!

TBH, I kinda want to move away from each page being one PHP file, and also I think having everything handled from a script file would make it easier to organize everything?

[Dan Q]

TBH, I kinda want to move away from each page being one PHP file, and also I think having everything handled from a script file would make it easier to organize everything?

Gotcha. That's a good goal... but achieving it isn't anything to do with your choice of programming language! Neither Go, Ruby, nor PHP do that by default. Go and Ruby usually do it by providing their own webserver that sits "behind" your actual webserver, which reverse-proxies to it... but that's not the only way to achieve this goal: the other way is through your webserver itself!

The right answer depends on what webserver software you're using, but here are a few options. In every case below, the request will be handled by /index.php. Use the variable $_SERVER['REQUEST_URI'] to see what path was actually requested; e.g. if the user goes to https://yourdomainname.example.com/some/page then it'll run index.php with $_SERVER['REQUEST_URI'] set to "/some/page"; your PHP code can then decide what content to show (or whether to respond with a 404 error, for example).

(This is, incidentally, how virtually every PHP-powered CMS works.)

If you're using Apache HTTPd

The following configuration says "unless the URL exactly matches a real directory or a file, use /index.php":

Code

<VirtualHost *:80>
  ServerName yourdomainname.example.com

  # (any of your usual DocumentRoot/DirectoryIndex/logging etc. configuration is here)

  <Location />
    RewriteEngine on
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule . /index.php [L]
  </Location>
</VirtualHost>

If you're using Nginx

This configuration says that for every incoming request, first try to find it as a file, failing that try to find it as a directory, failing that use /index.php.

Code

server {
  server_name yourdomainname.example.com;
 
  # (any of your usual root/index/logging/PHP etc. configuration is here)

  location / {
    try_files $uri $uri/ /index.php?$args;
  }
}

If you're using Caddy

My personal favourite. Like Nginx, this says "first try what they asked for; failing that use index.php"

Code

yourdomainname.example.com {
  try_files {path} /index.php

  # (any of your usual root/logging/PHP etc. configuration is here)

  file_server
}

Shout if you need a hand with any of that.