Hacker News Reader

I'm really not sure why you wouldn't just store the current sale value in the database and build a simple UI to manage it. Why don't you want to store it in the main database? This "side database" will grow and grow and soon you won't know whether to put new features in the main database or the side database and now you have two different databases to maintain with two different tech stacks ... why are you doing this to yourself?

Maybe some sort of JSON document database?

CouchDB is quite easy to maintain and it has a built-in admin UI you can use to easily edit your documents. To retrieve your JSON documents on the client side you'd use the http api, eg GET /database_name/document_id.

Or, you know, just use json/plain text file(s) on your server and be done with it..

If your application already has a database, just make another table for the stuff you want. Relying on another SaaS for these small bits of data is just asking for trouble and downtime. There are tons of hosted databases available (e.g. redis.com) and Cloudflare Workers could be another approach, but I wouldn't bother with any of them.

Also, there is nothing wrong with being a beginning web dev, and your question is not a dumb question, but I'd have to call it a beginner question. I'm not sure HN is the right place for that. Someplace like Stackexchange or Reddit might be more suitable.

Well my problem isn’t really the storage, per se, but rather the management of it. I don’t really want to spend time and build my own UI for this. If for whatever reason I want to toggle has_seen_welcome_popup for a certain user, I don't want to connect to the prod DB with a client either.

I can definitely do this on my own, but a SaaS with a nice UI just makes sense for this use case.

> I don't want to connect to the prod DB with a client either

What's the difference between this and having a custom UI for it? Are you afraid of breaking stuff in production? You could simply create a different database for the "dumb" stuff.

First one can easily be solved using the local storage web API.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage...

Second one could be a file served though HTTP. Like a JSON in a S3 bucket, or an index.html on a Linux/nginx VM. A file system is a database.

> First one can easily be solved using the local storage web API.

No, he wants global user state, not local browser state. Those are fundamentally different. With a local browser state, if I clear my browser website data, I get that again. If I use a different browser, I get it again. If I use a different device, I get it again.

Local storage should always be considered ephemeral, because it's trivial and common for it to be deleted or be unavailable.

Firebase is a good idea. But also just using local storage for less important user data (like has_seen_welcome) and having your SaaS store stuff (like 40% sales) in a settings file or something like that still works. Don't underestimate the value of keeping things simple and reducing dependencies.

Do you have a backend? If so it might be easy to just use that. Big frameworks like Django provide an auto generated admin UI for your DB tables so that would satisfy your requirement of having a UI to edit things without making raw queries to the DB.

I'll +1 firebase as the easiest managed solution for this work. There are competitors like supabase that can do the same thing. Alternatively, where both your examples are about showing things to the user, maybe product walkthrough software like appcues is more approptiate.

I'd caution against Airtable, last time I used them in this capacity, the API rate limiting / response time made it a no go. I'd err more on something like hasura if you want a flexible CRM like that.

How about something like https://kv.build8.io/ ?

This sounds like an use case for Firebase

I'll 2nd CouchDB for a server side solution, but you could also use PouchDB to store that data in the user's web browser. That wouldn't work when they access it with a different browser, but that may not be a bad thing, and could be useful.

I would recommend supabase, used it in my side projects, couldn't be happier.

Sounds like Firestore from Firebase would be a good solution for you. It's a database that you can use with just a few lines of JavaScript.

The term of art you're looking for is "KV Store" - something like Amazon DynamoDB, Cloudflare Workers KV or Firestore would do the trick

Backblaze with server side lru cache. One object per kv. Eventually, CF workers with kv.

A normal "not dumb" database can also do "dumb" things.

The correct answer for #1 is just client side scripts using local storage.

Cookie

Cookies suffer from the same problem as localStorage - they change with new devices or clearing data, so won't truly hold a long-lived user state.

(And yes, I see the username and suspect this was a joke comment, but still.)

Ask HN: A Dumb Database?