5 ms·

Your start is good but you add complexity on top of it. Install Golang on your VPS, clone the source code on it and compile it there instead of messing with cro

by dom96 8y ago

Your start is good but you add complexity on top of it. Install Golang on your VPS, clone the source code on it and compile it there instead of messing with cross compilation. Also use sqlite to avoid the pain of setting up a SQL server, there is no need for it. You can then easily get systemd to supervise your binary. This is how I host all my web apps, the main difference is that I don't use Go but Nim. If you want a great framework match up then check out Jester + Karax, see how I developed the Nim Forum using this combination.

BLanen 8y ago
Better would be to just use docker.
- marcus_holmes 8y ago
  Please explain. I still don't understand the use-case for docker... How is docker going to make my life easier in this example?
nicoburns 8y ago
> instead of messing with cross compilation. To be fair, cross-compilation in Go is as simple as setting and environment variable.
joobus 8y ago
Why put the source on the VPS? Go cross compilation is much easier then you make it sound. GOOS=linux GOARCH=amd64 go build Nim can't beat that.
- dom96 8y ago
  That's awesome, I didn't realise it was that easy with Go. Of course, I would say keeping the source on the VPS is just as easy.
ngrilly 8y ago
And what about zero downtime deploy (upgrading the app binary and updating the database schema)? It's difficult to do without some kind of reverse proxy and without a database server.
- dom96 8y ago
  How often is that really required? OP asked for a quick deploy, for most apps it's enough to put the db into read-only mode and then update the schema. Upgrading the app binary is as simple as replacing it on the file system and then restarting the service.
  - ngrilly 8y ago
    The more often we deploy with CI/CD, the more we need zero downtime deploy. Putting the DB in read-only mode is not that simple, because the app needs to be able to work in a degraded read-only mode.
    - marcus_holmes 8y ago
      Yeah DB migrations are a pain in the bum. I do them manually because I still haven't found a tool that handles them properly. But by the time there's significant data to migrate to the new schema, any schema change is usually due to a major version change or feature implementation, and the migration is part of a wider pain-in-the-bum situation.

by dom96 8y ago

BLanen 8y ago

Better would be to just use docker.

marcus_holmes 8y ago
Please explain. I still don't understand the use-case for docker... How is docker going to make my life easier in this example?

nicoburns 8y ago

> instead of messing with cross compilation. To be fair, cross-compilation in Go is as simple as setting and environment variable.

joobus 8y ago

Why put the source on the VPS? Go cross compilation is much easier then you make it sound. GOOS=linux GOARCH=amd64 go build Nim can't beat that.

dom96 8y ago
That's awesome, I didn't realise it was that easy with Go. Of course, I would say keeping the source on the VPS is just as easy.

ngrilly 8y ago

And what about zero downtime deploy (upgrading the app binary and updating the database schema)? It's difficult to do without some kind of reverse proxy and without a database server.

dom96 8y ago
How often is that really required? OP asked for a quick deploy, for most apps it's enough to put the db into read-only mode and then update the schema. Upgrading the app binary is as simple as replacing it on the file system and then restarting the service.
- ngrilly 8y ago
  The more often we deploy with CI/CD, the more we need zero downtime deploy. Putting the DB in read-only mode is not that simple, because the app needs to be able to work in a degraded read-only mode.
  - marcus_holmes 8y ago
    Yeah DB migrations are a pain in the bum. I do them manually because I still haven't found a tool that handles them properly. But by the time there's significant data to migrate to the new schema, any schema change is usually due to a major version change or feature implementation, and the migration is part of a wider pain-in-the-bum situation.