This question is more of a theoretical one, than a programming one.
I am currently in the process of writing a single page javascript application with Knockout.js. I choose Knockout because I love the way it handles DOM updates, but it does require you to write your own REST backend for data storage and loading.
My application is an enterprise application, where the server and client will be installed on it's own server instance, and not shared with any other users. It does not require authentication, and only will only need to save and load JavaScript objects.
My original thought was to use a node.js backend with Mongo for storage, but this seems a little overkill for me. Would it be considered a bad practice to save the raw json as a flat file, and save/load it as needed? The only problem I see is if multiple users were using the application and try to save data at the same time. Is there an easy way to handle a merge of JSON data?
If there are concurrent access to your application that can modify this data I would definitely advise to keep it on the server side. It depends on your application, but merging the JSON will most likely become a nightmare. I believe it will be better to manage concurrent access from the backend. Mongo DB is a good option, but take a look at CouchDB (which provides REST interface) and Redis as well.
On the other hand, if concurrency was not an issue, you may want to check HTML5 local storage, which basically lets you store key/value pairs on the client side. It's a great alternative to cookies since it is not sent on each request and allows you to store more data in a cleaner way.
Related
I want a way to really simply read/write to a json file (as my storage) online. I want to be able to host an app and make axios requests to this to read the data, update it locally and then push the data to the online resource. is there any simple way to do this?
I've used firebase in the passed but this is too long for me to set up now. also http://myjson.com/ only seems to let me do reads. there must be a quick way to host data in a json format that allows reads and writes
I also don't want to use localstorage because other people will be accessing the app
I think it's unfortunate your question is getting down-voted - but that's because the premise of your question is off. Reading/writing a single JSON file is expensive (e.g. timewise) and would be a naive approach (that's okay, we've all been there). What you want is a database. I would suggest starting off with a simple database such as mlab. But even before that, I would suggest you read this article - it gives a good overview of what a CRUD app is.
But if you really want to use a JSON file (again, I would highly NOT recommend this). Then:
You'll need to setup a server
Expose an API endpoint (where you handle GET/POST etc requests) for that server, so clients/people can communicate with said server
Have the server talk to some kind of store (e.g. https://aws.amazon.com/s3/) where the file would live
steps 1. and 2. you'll eventually need to do for any server. But step 3. is why I would NOT recommend using a JSON file. That's because it's very expensive (as noted before) to get the file, change the file, and then put that file back in the store. At that point, you might as well use a database.
Good luck! :)
I'm creating single page web app with ArangoDB for storage. Arango provides awesome ways for accessing and manipulating data. One of them is classic JS API. It would be easy to write straightforward DB queries in client side JS which would be direct queries for DB. So no server application in middle.
Of course, this is really unsecure pattern. So I should write some sort of REST-full API service that queries data from server via URL and later server queries the DB. But this is really inconvenient, since I'd need to write two or three times more code (first query for my server, second query for DB, and perhaps some translator between the two queries). Also, I think that API calls for my server would look almost same as API calls for DB.
I don't want to go for full abstraction since the app should be complex and there would be a lot of types of API request, which would only bring bugs and eat more time.
So what is the best way for requesting data in client app from DB in terms of, firstly, security and, secondly, ease of coding?
I'd really suggest to write REST API calls (or generally URL calls) to access your data. Anything what run on the client side or any traffic from the client can be accessed and manipulated. That comes with authentication and SQL calls themselves.
What you want to secure? DB client authentication? If you encrypt it, you need to decrypt it on the client side. SQL calls - if you build and transmit them, the client could manipulate them to get / update ANY data with ANY values. Really no easy way around..
So - to be safe - stick to the patterns here..
I found a GraphQL with Relay by Facebook which solves this problem best.
I'm learning how to build APIs so that I can make simple interactive data visualizations in the client and pull data using get requests. The data source I'm using is about 12mb, so I thought I'd put it on a backend and make requests as needed.
I don't need PUT or DELETE, just GET. Found a lot of resources that show how to make very simple APIs using Python or Node, like this one, but in this guide, Miguel Grinburg says that you'll need a database as well:
In place of a database we will store our task list in a memory structure. This will only work when the web server that runs our application is single process and single threaded. This is okay for Flask's own development web server. It is not okay to use this technique on a production web server, for that a proper database setup must be used.
Is this strictly true? What are the consequences of storing data in a memory structure? I don't wholly understand what he means by "single threaded" and "single process" either.
Let's say I wrote a little HTML site, deployed on my nginx webserver. I created a database with MongoDB and stored several million entries in it. The MongoDB server is only listening on the local interface and accessible via localhost:27017.
Now I want to go to my webpage on my publicly accessible nginx webserver and access the entries in the database via JavaScript, by clicking a button "Show Users" or "Get latest entries" and so on. I need to perform only simple read-only-queries on the database like counting, searching, aggregating, and so on, so I don't need write access.
How do you generally implement this? Do I really need to set up PHP, Python, and Java to access the DB or is it somehow possible to solve this by only using HTTP/REST Interfaces? Can NodeJS help me to solve this? Do I have to remove nginx when using NodeJS?
Sorry, but I'm quite confused with all that JavaScript/ NodeJS/ mongoose/ MongoDB/ JSON stuff.
You can keep nginx as server for static content like your html files. To serve dynamic data, use node.js to create a rest interface. The rest interface will provide the data it fetches from your MongoDb.
Since you have millions of entries in your database and do not require complex functionality I would recommend the mongodb-native-driver as node.js module.
On the client, use ajax to perform api calls to your created rest interface.
Mongoose is built on top of the native driver to allow object modeling.
I am creating a Web Application using JSP, Struts, EJB and Servlets. The Application is a combined CRM and Accounting Package so the Database size is very huge. So, in order to make Execution faster, I want prevent round trips to the Database.
For that purpose, what I want to do is create some temporary XML files on the client Machine and use them whenever required. How can I do this, as Javascript do not permits me to do so. Is there any way of doing this? Or, is there any other solution which I can adopt in order to make my application Faster?
You do not have unfettered access to the client file system to create a temporary file on the client. The browser sandbox prevents this for very good reasons.
What you can do, perhaps, is make some creative use of caching in the browser. jQuery's data method is an example of this. TIBCO General Interface makes extensive use of a browser cache for XML data. Their code is open source and you could take a look to see how they've implemented their browser cache.
If the database is large and you are attempting to store large files, the browser is likely not going to be a great place for that data. If, however, the information you want to store is fairly small, using an in-browser cache may accomplish what you'd like.
You should be caching on the web server.
As you've no doubt realised by now, there is a very limited set of things you can do on the client machine from a web app (eg, write cookie).
You can make your application use the browser plugin Google Gears, that allows you a real clientside storage.
Apart from that, remember, there is a huge overhead for every single request, if needed you can easily stack a few 100 kB in one response, but far away users might only be able to execute a few requests per second. Try to keep the number of requests down, even if it means adding overhead in form of more data.
#justkt Actually, there is no good reason to not allow a web application to store data. Indeed HTML5 specifications include a database similar to the one offered by Google Gears, browser support is just a bit too sporadic for relying on that feature.
If you absolutely want to cache it on the client, you can create the file on your server and make your web app retrieve it. This way the browser will fetch it and keep it on the client cache.
But keep in mind that this could be a pain for the client if the file is large enough.