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! :)
Related
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.
I taught myself programming so my knowledge is very fragmented and now I have encountered a fragment I know nothing about. Sending and receiving Date. In addition I want to do it across domains. I know about the security policies that prohibit this but have read about some solutions. I still can't make sense of it in relation to my challenge.
What I want to do:
I want to build a plugin that sends data to my server when a function is called. The function is bound to an event listener.
this plugin contains of a little html-form and some js in the back. i want to send json or simular.
my questions:
I) how do I send data to an other server?
II) how do I receive this data? I know about parsing and dom but all I did so far is handle requested data. now this data is posted to my server-app without me knowing beforehand. the data is used to update a DB. the backend is coded in JS or python. I would prefer JS for compatability reasons.
III) how can I test the cross server connection on my local machine? especially without an active internet-connection?
I don't expect a complete guide or the code i need. just the resources and where to get the knowledge-chunks I need to build this.
Thanks a bunch in advance!
I) how do i send data to an other server?
You may use AJAX (or jQuery.ajax a more convenient way)
II) how do i receive this data? i know about parsing and dom but all i
did so far is handel requested data. now this data is posted to my
server-app without me knowing beforehand. the data is used to update a
DB. the backend is coded in JS or python. i would prefer JS for
compatability reasons.
As long as you send some data via AJAX, the browser makes a HTTP call and you could receive the data from server-side. Both JS or python would compatible with your client-side javascript and seldom do there have compatibility issue.
III) how can i test the cross server connection on my local maschine?
especially without an active internet-connection?
localhost and 127.0.0.1 is treated as different host and I usually use these to test cross server scenario. One issue of AJAX is that browser usually disallow Cross Domain calls unless you specify Access-Control-Allow-Origin headers.
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.
I had a discussion with my colleague about Flash security. We're in the phase of planning some things for our web project that is using Flash plugin to display content. We need to dynamically pull settings for the Flash application from the server, using JSON.
Proposal that I offered was that we should save an extra HTTP request to pull the data file after the plugin is loaded and embed the JSON directly in the page containing the Flash plugin. Flash would fire a Javascript function that'd return the deserialized JSON data to it.
My colleague opposed this proposal with significant "security concerns".
I believe that there's literally zero difference between these two approaches besides the fact that his approach requires additional HTTP request. All of this is client/server and client should never be trusted. If I want to change the data that is in the JSON query, I can do that in both cases. File pull is little more difficult to hack though, but possible with custom HTTP proxy.
What are your thoughts?
There is no difference. Both can be fabricated.
if you really care that much about delivering original settings to the .swf:
don't use http - httpFox is a brilliant plugin - use a server that supports RTMP/RTMPE and NetConnection.call() to retrieve the data.
create an algorithm for validating original json so that your app won't work if the config doesn't pass the test.
after the config is loaded your swf might check the values with the server (not all at a time) and throw an error if something goes wrong
I'm looking to confirm or refute the following:
For what I have read so far it is not possible to write a web application with only javascript -- no server side logic -- served from Amazon S3 that also store data only to S3 if you need to have multiple clients with private data per client.
The issue I see is the Authorization header required for every Ajax call that would force me to put the signature (and my AWS id) right there in the page source for everybody to see.
Is that correct or I misunderstood the docs?
Are there workarounds?
In short, you are correct.
If your AWS key ends-up in any way on the client-side, you are in trouble.
A possible solution is, of course, to have the user specify their AWS key for storing their data.
I'm working on a project that will do something similar to this, mine will have the users use their own S3 which I will store in HTML5 localStorage. It's a bit tricky, but I've got the basics working.
It involves making an Javascript program that replicates itself into S3, gets itself from S3 and then transfers credentials and control into the S3 loaded version.
I'm using the excellent SJCL to do signature generation and jQuery's ajax functionality for the parts I can.
My work simply initializes the S3 side application and does a test PUT/GET sequence to S3. I also rewrote a JQuery postMessage plugin (which StackOverflow won't let me post for lack of rep) for communicating between my frames.
In my case, I'm trying to fit the entire application into a single HTML file so that I don't have to do as much initial transfer into S3, but perhaps there are other ways to work this out.
iBeans offers a way around this without having to write any server side code. There's an S3 iBean (a developer is working on it to be released in the next few days - watch the mulesoft blog for an announcement) and you can access it right from your javascript. The iBean itself runs on a server so you wouldn't need to store your keys in the javascript.