I have a toy web application that accepts a very, very low rate of writes. It's almost all reads.

It is implemented like this:

- The front end uses react to draw a UI.

- It fetches data from a JSON file stored on S3.

- When we get a write request, a lamdba function reads the JSON file, parses it, adds new data, and writes back to S3.

The main selling point for me is that almost all of it is static assets, which are cheap and simple to host, and the tiny bit of "back end" logic is just one nodejs function.

The previous implementation used SQLite and a golang back end, but I eventually got tired of having to maintain a virtual machine to host it.

▲

sergsoares 5 days ago | parent | next [-]

Easy and useful, usually the basic is better.

I ever plan do it with sqlite, loading it at memory during app start and flush data to s3 during runtime but it create more corner cases and logic to handle.

▲

ayende 5 days ago | parent | prev [-]

Even with very small number of requests - what happens when you have two concurrent ones?

▲

fiskfiskfisk 5 days ago | parent [-]

You can set concurrency limits per function on AWS, so you can apply a hard limit on your function to only have a single invocation running at the same time. That should give you a guarantee that data isn't lost without the producer noticing.

	▲	frou_dh 4 days ago \| parent [-]
		I wonder whether that kind of thing is actually bulletproof and doesn't end up having 2 running concurrently in some scenario.