1

I have a Firebase application that with store user data and deliver static data. I am struggling to figure out a safe way to store this static data.

The static data is a list of video urls and other information that a user will take as a learning course (pre-set data). These can change periodically.

My problem is any developer could accidentally delete the entire data store with the click of a button.

This is what I want but am not sure how to accomplish:

  1. I write in the static data directly into firebase
  2. There is a Live (app) version of the data, a develop (app) version, and staging (app) version - the live should be un-editable
  3. When staging has been properly tested, I want to migrate all of that data into the live Firebase app for the static data

I know how to accomplish this outside of Firebase but I would really like to build my entire back-end here on Firebase. Any thoughts?

Price can change. Ordering can change, new courses can be added,etc.

The data looks something like this:

{
"slopes": {
"slopeiOS": {
  "featuredCourse": "k43l2l2-beginner-ios", 
  "courses": {
    "k43l2l2-beginner-ios": {
      "name": "Beginner iOS 1",
      "order": 12,
      "price": 250,
      "salePrice": 150,
      "onSale": true,
      "purchases": 12000,
      "totalMinutes": 102282,
      "videos": {
        "k23j3l": {
          "order": 22,
          "duration": 150,
          "title": "How to install Xcode",
          "description": "Learn how to install Xcode.."
        }
      }
    }
  }
}
 }
}
firedev
  • 83
  • 6
  • 1
    Can you give us the actual json being stored in the database? It's hard to write rules if we don't know the names of what you are storing. It seems like this could be relatively by setting a rule that does not allow writing to videos with a certain property. The migration could be something you only allow a logged-in admin to perform. – Luke Schlangen Mar 08 '16 at 14:06
  • I updated with sample data. my ultimate fear is that one tiny wrong change could affect thousands of users so I want to be extra cautious with all data management – firedev Mar 10 '16 at 16:06
  • Thanks! After reading this a few more times, I guess I might not have needed it, sorry. I hope my answer helps. Large data sets are hard (firebase or not), but if you have a relatively small set to begin with, doing this manually might be a good option for getting started. Good luck! – Luke Schlangen Mar 10 '16 at 17:24

1 Answers1

0

Based on my understanding of what you want to do, it seems like your largest concern is developers accidentally deleting the data in a production version of the app.

I'm not totally certain what type of solution you would like, so here are a few options:

  1. It might be comforting to know that firebase does daily backups (Is it possible to backup Firebase DB?), so if your largest concern is losing your data, that solves a lot of your problems. You could also back up your own data through API calls: https://www.firebase.com/docs/rest/api/

  2. The simplest, but most manual, way I can see of doing this is to export your firebase dev data and then uploading it to staging and live versions of your app using the import and export buttons: Firebase import and export buttons

  3. If you're looking for something a little more automated. You'll have to write some code and maybe an "admin" portal for yourself. That portal could give you, after login, access to both firebase databases. You create a tool to compare the json differences between your three databases (probably doing a shallower search on classes unique ids), and you could push data to your staging and live versions of your app. This is probably the more "scalable" route, although, all of these have their issues when working with large data sets.

Community
  • 1
  • 1
Luke Schlangen
  • 3,722
  • 4
  • 34
  • 69
  • This is good info. I am almost wondering now if it makes more sense just to put my static data in my own REST API. Might be less work and more straightforward. – firedev Mar 10 '16 at 19:22