Readit News logoReadit News
Posted by u/asim 2 years ago
Ask HN: Who is still programming directly on a server?
So after a decade plus of doing it the right way inside companies, I felt the need for a break from all the processes and pipelines involved in shipping code. So now, on personal projects, I dump a github repo on a server, run a Go server and front it with nginx. Then I commit directly on the server. I will say that parts of me want to create a whole framework around doing it the right way, but the hacker in me is really happy to just write and ship code without all the stuff in between.

Anyone else doing this?

jryb · 2 years ago
You've misunderstood the "right" way's purpose. It's right because it solves a problem in a particular context, not because it's the best way in all contexts. You're not coordinating with other humans, so why have a mechanism to coordinate your efforts on a personal project? You're not risking people's incomes with minor downtime, so why build a resilient system? The right way comes at a cost of time and effort - why pay for things you don't want?
codegeek · 2 years ago
For my personal blog, I have a poor man's version of a CMS written in Go that builds a binary locally and then scp it to the server directly using a Makefile that also configures Caddy as a reverse proxy in front of the binary for other goodies like SSL etc and uses supervisor to run the binary. I don't even use Git for the personal blog (not yet :)). Here is the snippet from Makefile for deployment:

    .PHONY: deploy/web
    deploy/web:
     ssh -i ~/.ssh/id_rsa2 -t root@${production_host_ip} '\
     sudo supervisorctl stop ycblog\
  '
     scp ./build/ycblog-linux/ root@${production_host_ip}:/home/projects/ycblog
     scp ./remote/production/Caddyfile root@${production_host_ip}:/home/projects/ycblog
     ssh -t root@${production_host_ip} '\
      sudo mv /home/projects/ycblog/Caddyfile /etc/caddy/ \
      && sudo systemctl reload caddy \
      && sudo supervisorctl start ycblog \

Whenever I change the code, I just do:

    make deploy/web

gregjor · 2 years ago
I do and I know other developers who do it. On multiple projects I've worked on we had a dev server and production server, cloud instances on AWS or GCP. Developers work over ssh on the dev server (in their own copy of the web app), either with ssh+vim or VSCode over ssh. Deployment to production amounts to a git pull and maybe updating the database schema.

Advantages: Controlled dev environment. No more days-long getting the app to work on a new developer's laptop. Can change dev environment and tools in one place. All developers can see each other's work and collaborate at any time. Dev environment identical to production and easy to refresh as needed.

Disadvantages: Network latency, though less of a problem that I expected. Must have internet connection to work (at least to see the changes and test). A more subtle disadvantage is a lot of developers can't use the Linux command line at all, or not effectively, and some sulk about having to learn "the terminal."

If I know I'll be traveling or without internet I can git pull the source and work on my laptop with no internet connection, the rsync to my dev instance later.

theonething · 2 years ago
> disadvantage is a lot of developers can't use the Linux command line at all, or not effectively, and some sulk about having to learn "the terminal."

I'd say this can work out to be an advantage by filtering these out.

gregjor · 2 years ago
Agree. Proficiency with the command line and basic navigation and common tools, ssh, git and Github, at least one professional editor or IDE for each platform (e.g. VSCode and vim or nano) seem like table stakes for a professional developer. Bonus for screen/tmux, fuzzy finding, reading shell scripts, environment variables. Not everyone has to use all of these things, depends on the environment.

Then again I've had to work with "front-end developers" and even so-called "full-stack" developers who don't know HTML, CSS, and Javascript.

wojciii · 2 years ago
I told a junior developer (to me, as I'm in my 40ies) to try to use a console based debugger (gave him my scripts).. last time I met him he told me that he was grateful because it speeded up his work. He was just using VS code before.

So some people just need a nudge in the right direction.

afiori · 2 years ago
One of our clients handles non-trivial usage with a setup that is not much more complicated.

They use hosted db (like AWS RDS or MongoDB Atlas), an external service for some user data (sorta like Firebase to handle user accounts, paid/free entitelments, etc) and I believe also a server image on AWS to quickly be able to recreate a clean server if something goes wrong.

Deployment is done with a webhook on git push and a local script that does some folder swapping.

For the rest the application (500k+ active users) is a single machine with apache+php for prod and clones of it for testing.

Thanks to php request-response model there is little to no server-side state out of the db so if load where to become excessive they could slap a load balancer and manually spin up a second server.

If your business model is different from "must get a ton of views" or "let's monopolize this market" this should be quite enough.

xnx · 2 years ago
You can simplify even further and edit live PHP files right in your editor.
BayesianDice · 2 years ago
And then your text editor might leave a backup copy with filename "xyz.php~" which PHP won't interpret and Apache will happily serve to a curious user as plain text.

So I've heard :-)

toast0 · 2 years ago

   <Files "*~">
       Require all denied
   </Files>

   <Files "DEADJOE">
       Require all denied
   </Files>
(last one assuming you're using joe)

shermantanktop · 2 years ago
Sometimes you can edit someone else’s live PHP files right on their server.
kypro · 2 years ago
I miss the days when this was normal for production websites. I wrote delete query once but forgot the where clause so I nuked the prod DB.
Monotoko · 2 years ago
We've all been there
ActorNightly · 2 years ago
Enterprise stuff is designed around managing peoples mistakes.

For personal stuff, I go straight to most efficient way.

- Spin up a docker image from a base on my home server that has all the stuff setup (ssh server, python/node, open ports, e.t.c)

- Use VSCode with Remote SSH to develop directly in the docker container. Don't even bother with git. I just keep all code around in different files, never delete it.

- I have a cron job running on the docker host that snapshots containers every day, keeps snapshots for a week. Sometimes useful for backups.

- Once server is up and running and I want public access, I set up cloudfare tunnel to it with a subdomain.

donatj · 2 years ago
I'm kind of ashamed to admit this but I have multiple servers that are just Go binaries running in tmux...

I've meant to configure systemd but haven't not gotten around to it

chatmasta · 2 years ago
Don't be shy! Send the links so we can test their robustness ;)
donatj · 2 years ago
https://shielded.dev/ is the front-facing-est example lol

Entire app is a single Go binary I just replace and restart in tmux manually.

klyrs · 2 years ago
Back in the 90s, we did it a bit like that... only we didn't have git, most of us didn't even know about the VCS that did exist. Before doing something serious, I'd make a manual backup before just editing files directly on prod through SSH. Alarmed? At least I said SSH, and not telnet...
singlow · 2 years ago
Unencrypted FTP in our case, over a shared ISDN connection. Copy index.cfm to index.cfm.bak and take a swing. No dev, no staging, just production. We did have regular full backups though. And we took plain text credit cards and put 'em in the database so we could batch them up and send them over a modem to the clearinghouse overnight. Never really got bit bad though as far as we knew and we took hundreds of orders per day.
_nalply · 2 years ago
Wait, is ISDN still a thing?
noduerme · 2 years ago
I did this as recently as last week... when we were cleaning up our unused AWS resources, and accidentally jettisoned a reserved IP that an important script was still apparently connecting to for live updates. I got 8 phone calls in 3 minutes at 4:30am while I was sleeping, immediately guessed what had happened, and it was just faster to SSH in from my phone and change the script than get up and open an IDE.