Hacker News Reader

Comment by sph | Hacker News Reader

Go out with a bang. Release it, enjoy your 15 minutes in the spotlight, and when the lawyers come a-knocking, shut it down. Or make it open source and let the community take the wheel and the responsibility.

You never know what opportunities this adventure might bring, but certainly more than just keeping it on your hard drive. Go for it mate.

View on HN

I may indeed do this. There is an outstanding issue I have to address that I've never quite worked up the motivation to deal with:

Heroku restarts their servers once every 24 hours with only thirty seconds' warning. Since the games are in-memory, this of course kicks everyone out of whatever games they may be in the middle of.

I guess the solution is to have the games be on Redis instead of in-memory? I'm a bit more front-end oriented so I was bewildered to learn this was how it worked in the first place and I'm not 100% confident in my solution.

Is using a host that doesn't do this not a possibility?

It seems they all do, though. Digital ocean was the same.

Any decent VPS provider (including DigitalOcean, unless they’ve changed anything) definitely doesn’t do this.

Maybe you're right, I may be mistaken. Perhaps I should migrate to DO.

Actually, I should qualify this.

If you use a PaaS (platform as a service, e.g. Heroku, DO App Platform, AWS EB), they might assume your app to be stateless and do things like restart it at will.

If you use a VPS (virtual private server, e.g. DO Droplet, AWS EC2), this certainly shouldn’t happen, but of course it requires some Linux skills to maintain your VPS.

So it’s basically a trade-off between engineering your app to fit a PaaS or hand-managing your VMs (though the latter is usually the cheaper option).

Yeah, indeed. I can try using a Droplet but I'm just new to managing a VM by hand. I've always used a PaaS for my projects so ensuring uptime and whatever other responsibilities there may be is new for me.

If that’s the case I’d suggest you probably have a bug in your code somewhere that depends on a timer that resets at midnight. So when it spans midnight everything resets, but this isn’t the server resetting.

Data persistence is a solved problem. “Server that never fails or reboots” is not.

The quickest win would to move off of Heroku. Either rent your own server that you can control (to a reasonable degree), or find an alternative that doesn't suffer that issue.

Redis would work but I'd be afraid of race conditions. There probably wouldn't be any, but it's something to be aware of.

If you wanted to test the waters with at least the relative public, I'd consider doing step 1 of renting a server, but then hiding it behind a Tor hidden service. Inconvenient to connect to? Yeah. (Probably) safe from the Hasbro demons? Also yeah.

Linode is super cheap. I pay 6 or 7 bucks a month for a bottom tier VM.

I guess I just haven't done anything outside of a PaaS before and I'm a bit worried about unknown unknowns. I'm sure I'm probably up to the task but managing my own server is just new ground for me. I'll have to research how to ensure that the server is always up or recovers from an unexpected failure and restarts immediately.

You can also split the difference and run Dokku[0] on a vps and basically host your own instance of “Heroku”. It can even use the same build packs and procfiles.

Feel free to message me and I’d be happy to help with server stuff.

[0] https://dokku.com/

Fly.io would probably work for your use case. Doesn't have the restart limit of Heroku and still has a solid enough free tier to run your app!

I'd be happy to help if you need anything! Whether hosting or just backend related questions!

Also depending on how hard coded your architecture is, maybe you can separate out the Magic specific data from the app itself? So the MTG specific data could just be loaded as a datapack?

Render (render.com; I'm the founder) doesn't restart your server every 24 hours like Heroku; it does restart it automatically if it crashes.

Architect a redundant cluster and let a peer server take over as master?

I would second the recommendation to move off Heroku. They're essentially the smallest scale version of vendor lock-in out there nowadays, especially considering they're no longer free.

An open-sourced codedump will survive best if people (which effectively means "average technically-minded MTG player" in this case) can run it wherever they're most comfortable - which will almost certainly be something that smells like a VPS. Mayyybe a container.

On restart warning, take server state (sign/encrypt if you want to) and dump it to each players' clients.

If both players are still connected once the server comes up and client reconnects, both players can send state to server and if both players' global states match then the game resumes, if not then error out. If only one player reconnects cause the other couldn't wait & closed tab, then you gotta error out anyways.

Then you don't need Redis or any other additional dep at least.

Reply on news.ycombinator.com