5 ms·

Ask HN: A Dumb Database?

• rudasn 4y ago
  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..
• altdataseller 4y ago
  This sounds like an use case for Firebase
• d_watt 4y ago
  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.
• joeld42 4y ago
  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.
• patatino 4y ago
  I would recommend supabase, used it in my side projects, couldn't be happier.
• rad_gruchalski 4y ago
  Backblaze with server side lru cache. One object per kv. Eventually, CF workers with kv.
• oblib 4y ago
  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.
• Nextgrid 4y ago
  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.
• speedgoose 4y ago
  First one can easily be solved using the local storage web API. https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_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.
  • nomel 4y ago
    > 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.
• feoren 4y ago
  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?
• monsterofcookie 4y ago
  Cookie
  • codingdave 4y ago
    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.)
• deleted 4y ago
  [deleted]
• throwaway81523 4y ago
  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.
  • kashnote 4y ago
    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.
    • XCSme 4y ago
      > 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.
• cyanydeez 4y ago
  The correct answer for #1 is just client side scripts using local storage.
• deleted 4y ago
  [deleted]
• rozenmd 4y ago
  The term of art you're looking for is "KV Store" - something like Amazon DynamoDB, Cloudflare Workers KV or Firestore would do the trick
• michaelanckaert 4y ago
  How about something like https://kv.build8.io/ https://kv.build8.io/ ?
• XCSme 4y ago
  A normal "not dumb" database can also do "dumb" things.
• leros 4y ago
  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.