Ask HN: What is the most barebone back end solution?

You can generate your links with Cloudflare functions and save the links with Cloudflare KV. You can also serve the game with Cloudflare pages.

Cloudflare offers generous free tiers, so you shouldn't have to pay anything.

I find Cloudflare's ecosystem much, much easier than all of the alternatives for simple projects. It's fast, the UIs are nice, the docs are great, and everything is usually deployable straight through GitHub and simple configs.

Ah! That sounds very interesting. I am actually using Cloudflare Pages to host the current frontend-only version of the game. I'll have a look and see where it takes me. Thanks!

Consider that for your use-case the state is likely to be small enough that you could simply serialize the state and base64 encode it, and add it to the url.

Other than that, I'd self-host it, either on a cheap VPS or just a rasperry pi in the closet, this way you avoid thinking about all the cloud stuff and won't be surprised by some massive bill because something went wrong, writing a backend in nodejs will feel very familiar to you if you've already used javascript or typescript before. For storing the state, it depends how much data you expect.. I'd see how far I could go with just keeping an object in memory and serializing that to a text-file.. or you could use sqlite with nodejs, then you don't need to administer a separate piece of software, it can simply be a nodejs module.

I don't think you even need a backend. Just base64 encode the gamestate and include that in the url being shared. It will only work if the gamestate is small enough, but based on your description it sounds like that might be the case.

yeah you should have plenty of wiggle room as a query string parameter, which could be useful if you want to see how your game is played (time between turns etc) as it'll be logged on your web server.

If you don't care, you could always use a client side url fragment.

Unfortunately not possible, as the JSON is quite long. I've even gone the extra mile to calculate the average entropy of my game-state (its just numbers) to see how much I could save by compressing it, but to no avail. It would way too long, even compressed.

Thanks for the suggestion though!

Depending on the game you could precalculate every possible game state and assign each one an ID then load the game off of that.

Also impossible, unfortunately. But a fun idea, nontheless

I used to think this is how NES worked x)

how long is "way too long"? URLs (including query parameters) can be up to 4k. Does it have to be JSON? Can you use a binary format like protobuf, BSON, etc.? you're likely to get much better compression.

> how long is "way too long"?

How long would a link that you receive on iMessage/WhatsApp have to be before you would reply with a "?"

I'm quite open to testing out different ways to keep all of this frontend only (I would much prefer it tbh). The JSONs contain around 2000 integer data points, which could theoretically be compressed by removing redundant information, but seeing how there is little rhyme or reason to the datapoints, there will be sequences with little redundancies which will blow up the end result. I think?

With base64 you have around 6 bits per character. M$ edge max url length is shortest now at about 2038 characters. If you can drop support for edge, the next highest is Android browser at 8k. 8k characters gives you around 6000 bytes to encode into the URL. Unless your 2000 ints are utterly random and use the full spectrum of 4-8 byte integers, im sure you can find a way to compress them into 6000 bytes.

i think it's possible. this is an example: https://github.com/topaz/paste

in the big brain bucket, you could generate the url and use and url shortener

Many thanks for the input, but as I've said above, I roughly calculated the entropy of an average state and without some kind of magic there just is not enough wiggle room.

I've tried your example and it gave me a URL with ~24,000 characters (down from around 30,000)

Have you tried compressing your JSON before base64 encoding it.

https://github.com/KilledByAPixel/JSONCrush

Agreed with GP, it seems like you don't even need a backend.

Even when compressing thje JSON before encoding it, it's still way too long for a shareable link. As I've said below, I've roughly calculated the entropy and even had a quick look around if there was any cool research out there regarding compressing the type of data I have (just loads of integers) (and there is cool research out there, just no magic, unfortunately).

JSON might be the problem though?

The string representation of integers could easily take more space than storing them as ints

For sure, but how much impact does it actually have? Let's say I have around 2000 datapoints, all of them integers, little rhyme or reason to their sequence. I'm very open for ideas on how to squeeze that down to a link that wouldnt (a) deter you from sharing that link with family and friends and (b) deter your family and friends from clicking that link.

Why not use an url shortener?

I haven't used it before but Firebase/Supabase is probably the way to go if you just need to save and load data from the frontend. Fireship is an entertaining and instructive channel with some videos on it:

https://youtu.be/9kRgVxULbag

edit: to clarify, you don't need a server at all for what you're doing, just a database with an API, which (as I understand it) is what Firebase and Supabase offer. Firebase in 100 seconds by the Fireship channel: https://www.youtube.com/watch?v=vAoB4VbhRzM

I would choose option B and use a really cheap <5€/m VPS with a sqlite database. Alternatively you could also use managed web hosting where you just upload you CGI scripts. This will probably cost around 5€ and is a bit more limited but they usually give you access to a proper database like postgresql and you don't have to do as much server administration yourself.

The VPS option won’t be €50. I have a small vps for like $10/month.

Setup a VM. Install SQLite and caddy on it. Choose an async server framework Node or python quart or something.

Add a table to your SQLite, saved_games(id,json). Add two endpoints, save and load, save generates and Id saves json and returns a link, load returns the json. Make sure there’s an index on the id too.

Run your server, for example via Hypercorn if you’re using Quart or equivalent node prod setup.

Set up caddy to reverse proxy port 443 to your running instance. This gives you HTTPS

There you go. Quite simple and fast.

You could probably serve upwards of 1k QPS with this setup. That’s about 1/100th the qps of Google search.

You could try compressing the json before storing it too. Once you have some saves a dictionary compression would be really effective on a particular json format.

Rent a $5 cloud server, clone this repo here (https://github.com/void4/lazyweb/) and use json.dumps/loads(data) to (de)serialize the JSON data into a text field in the database

Edit: I've adapted my code example to your usecase here: https://github.com/void4/jsonserver/

You should probably set data size limits

Let me know if you need to know more, sounds like a fun project!

How extremely nice of you! Thank you very much for the time you've spent on a random internet stranger, it is very much appreciated!

Encrypted pastebin:

You encrypt and dump the JSON object to a site like https://hushfile.it/ — the download link has the decryption key as part of the URL:

https://hushfile.it/2f5998db28974#5KQPcgUzQdrQmjPHoXYcwxeiW3...

Now you don’t leak game state, and anyone with the link can access the game state and send a new game state back.

That is a very interesting idea. Oddly enough, isnt that pretty much what I want to build myself? A link to a JSON file that's much shorter than the JSON file. It might make sense to use a site that offers that anyways as a middleman. Thank you for the suggestion!

I think you know best what you want to build yourself. :-)

If you separate the abstract interface for sending/receiving game states and its implementation, you can rely on an external service like hushfile to get started, and then switch to running a similar service yourself afterwards. Saves you from having to deploy and maintain the server initially.

Running a VPS wouldn't cost more than $5/mo.

Since nobody mentioned it, you may want to consider:

https://boardgame.io/

It is a service specifically for managing JSON game state.

But it comes with its own ideas, so your mileage may vary.

I’d do it all in the AWS console with Lambda and DynamoDB. Ask ChatGPT for some boilerplate with the v3 AWS SDK API.

There’s a few AWS-sponsored workshops. It’s pretty cheap for low/medium usage.

Amplify is a nice wrapper and will give you some level of authorization if you’d like (using AWS cognito underneath).

Like you say everyone will be biased towards what they know.

^ my tendency is to take detailed steps using the console so that it’s possible to reproduce. And avoid infrastructure as code until you really need it.

Take a look at firebase storage, very easy to use: https://firebase.google.com/docs/storage/web/upload-files#we...

You can leave the bucket fully redable / writable by anyone, or limit who can do what.

Player A would upload the JSON to it and get the shareable URL: ================================================================== import { getStorage, ref, uploadString } from "firebase/storage"; const storage = getStorage(); const storageRef = ref(storage, 'some-child');

And Player B would simply HTTP GET the shared URL.

If you ask barebones, that's going to get so many different answers here because everyone will have their own definition and bias. If I inherited a small game that needs a backend, I'd pick any of those backend-as-a-service options. Supabase and Firebase comes to mind.

If you pick Supabase, it's Postgres with a web api and sdk on top. Then, sure you can serialize all the game state as a jsonb record. You don't even need to deal with authentication if you don't care about isolating games.

Free tier until you make money somehow and then pay the 25/mo.

You can always use google sheets, apparently: https://news.ycombinator.com/item?id=34865717

This sounds like the perfect use case for Firebase. You can achieve your goals with just a few lines of code in your Typescript app and it will be free unless your game gets really popular.

I would agree with dusted about encoding the state of the game, but if you don't want that you don't need to pay 50 bucks a month for something that simple.

6-12 bucks will get you a more than powerful VPS, and Amazon S3 will be pretty cheap for this and allow you to set a policy that all storage expires after n-days, which will prevent this for exploding too much.

S3 is expensive for storage, but you are dealing with data at the kilobyte level, where it does not matter.

Everything in Golang and get a $5 Digital Ocean VPS.

You could probably build on Cloudflare Workers + R2 to an extreme scale before you start being charged more than $5/mo

B doesn't cost you 50$, you can get a VPS for <10$ a month. If you wrote it in typescript just read a tutorial for express and host it on a VPS, shouldn't take you more than a day or two. Now if it blows up that's a harder question to answer but that's a good problem to have

I don't know how people feel about others referencing themselves, but... I posted this in a reply chain ~9 months ago going over the (then-current) VPS solutions that were being discussed:

https://news.ycombinator.com/item?id=31400500

I know the OVH "starter" VPS has gone up to a bit over $4 USD, but it's still a great deal and it's what I'm using for multiple small projects where I wanted to experiment with backend and frontend dev.

Just use express server and session storage and voila. You can write prototype on repl.it

I would take a look at y.js if you are building shared state - https://github.com/yjs/yjs

Lots of VPS companies will offer you a server for doing option B for less than 5€/month. That should be plenty for getting started and testing your idea. From there you can easily scale up if/when you need to.

lambda + s3. add ec2 spot if you need it.

just make sure you understand how billing works. mostly it’s just egress bandwidth expensive, alarms and monitoring good. also 2fa is non optional.

do something like this:

https://github.com/nathants/aws-gocljs

or with less opinions:

https://github.com/nathants/libaws/tree/master/examples/simp...

welcome to cloud, glhf!

Just generate client-side a state.json for user A to download, then user A sends the file to user B and user B goes to your game and uploads the json

Just an S3 bucket. See http://rubeosity.com

I'd try a ~$5 Hetzner cloud server with SurrealDB. SurrealDB offers GraphQL and REST endpoints, also SDKs.

Containers are always the answer, except I don't know if you can even get orchestration for cheaper than a t2.micro, and if your service and audience are small enough, might as well just run it on a micro.

Google Sheets (no sarcasm)

use the browser local storage for it like any other web game. done.

Rust + linode vps

index.php