Home/ Questions/Q 3345316
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T01:10:18+00:00

I am building a full featured web application. Naturally, you can save when you

  • 0

I am building a full featured web application. Naturally, you can save when you are in ‘offline’ mode to the local datastore. I want to be able to sync across devices, so people can work on one machine, save, then get on another machine and load their stuff.

The questions are:

1) Is it a bad idea to store json on the server? Why parse the json on the server into model objects when it is just going to be passed back to the (other) client(s) as json?

2) Im not sure if I would want to try a NoSql technology for this. I am not breaking the json down, for now the only relationships in the db would be from a user account to their entries. Other than the user data, the domain model would be a String, which is the json. Advice welcome.

In theory, in the future I might want to do some processing on the server or set up more complicated relationships. In other words, right now I would just be saving the json, but in the future I might want a more traditional relational system. Would NoSQL approach get in the way of this?

3) Are there any security concerns with this? JS injection for example? In theory, for this use case, the user doesn’t get to enter anything, at least right now.

Thank you in advance.

EDIT – Thanx for the answers. I chose the answer I did because it went into the most detail on the advantages and disadvantages of NoSql.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    JSON on the SERVER

    It’s not a bad idea at all to store JSON on the server, especially if you go with a noSQL solution like MongoDB or CouchDB. Both use JSON as their native format(MongoDB actually uses BSON but it’s quite similar).

    noSQL Approach: Assuming CouchDB as the storage engine

    • Baked in replication and concurrency handling
    • Very simple Rest API, talk to the data base with HTTP.
    • Store data as JSON natively and not in blobs or text fields
    • Powerful View/Query engine that will allow you to continue to grow the complexity of your documents
    • Offline Mode. You can talk to CouchDb directly using javascript and have the entire app continue to run on the client if the internet isn’t available.

    Security

    Make sure you’re parsing the JSON documents with the browers JSON.parse or a Javascript library that is safe(json2.js).

    Conclusion

    I think the reason I’d suggest going with noSQL here, CouchDB in particular, is that it’s going to handle all of the hard stuff for you. Replication is going to be a snap to setup. You won’t have to worry about concurrency, etc.

    That said, I don’t know what kind of App you’re building. I don’t know what your relationship is going to be to the clients and how easy it’ll be to get them to put CouchDB on their machines.

    Links

    1. CouchDB @ Apache
    2. CouchOne
    3. CouchDB the definitive guide
    4. MongoDB

    Update:

    After looking at the app I don’t think CouchDB will be a good client side option as you’re not going to require folks to install a database engine to play soduku. That said, I still think it’d be a great server side option. If you wanted to sync the server CouchDb instance with the client you could use something like BrowserCouch which is a JavaScript implementation of CouchDB for local-storage.

    • 0