I came across this question and was quite baffled. I could not understand the underlying thoughts behind this. I have done some API intergation using AngularJS usng $http and $resource when its RESTFul, but these two questions was something like a puzzle. I want to understand this in detail.
Does the JavaScript framework you choose support a model abstraction
with REST integration? If so, what schema does it expect the JSON
replies to use?
Can anyone explain me the two questions.
Some libraries expect your REST API to return specifically structured result. (HAL, JSONP, HATEOAS, ...)
By default, $resource works best with HAL, but it can easily be extended to support other types of return formats (https://github.com/jmarquis/angular-hateoas)
Maybe the question is asking about something like jQuery.map() which allows you to convert the JSON object from the server to your own internal object (abstracted model).
If you use the object from the server throughout your code, and that object's schema changes (e.g. email string changes to emails array), you may have to change your code in many places. But if you've mapped the server data to a local object, you may only need to change the mapping (e.g. set internal email to first value from server emails).
Related
So, I'm originally a native application developer (mostly C++), but I've found myself working on a small business Coding project for a friend. I'm used to self contained native applications and I'm struggling with a current problem on my project:
I have an AppInstance class in PHP which is implemented as a singleton (I've heard that most of the time this isn't really the best way to do things, and I concede this). This class contains a few basic operating parameters for the application (mostly simple strings and numbers), as well as an array of complex objects (objects composed of other objects, arrays and other members and methods). I'd like to be able to pass any/all of this application data between this original PHP script (which initializes all of the values that my program needs to run, and outputs the default HTML of my UI).
I then begin to handle user input actions with Javascript. Some of these inputs require information from the original PHP script. Because the processing of these inputs requires a bit more computation, I'd like to use AJAX to call this processing on the server (in PHP) and return the output. However, Because this processing requires some of the objects from the original PHP script, I'm trying to figure out how I should pass these objects around in the most efficient way?
I've read that I can use JSON encode to effectively serialize my objects and send them to JS (the UI in this case), and these objects can be returned to PHP (see this). But my question really is a multi-part:
Would it be more efficient to perform all calculations and processing on the server (in PHP, rather than doing it all on the client-side in JS)?
If the answer to #1 is "Yes", my first inclination is to serialize the PHP object to a file on the server, and have the new PHP script read and deserialize the object. Is there a more efficient method than this and,if not, should I serialize in JSON or PHP's serialize() format?
Edit: I should probably mention that some of my objects also possess resource variable, as I know this has some effect on serialization.
In terms of efficiency I would be looking at whatever reduces the number of network (AJAX) calls, as this will usually be your largest overhead. This is hard to comment on in your case because I don't know how often a client is going to be making such calls. A bigger worry for me is security, as Javascript would be able to manipulate values it gets from the AppInstance. I personally would consider an API which only exposes actions you permit.
is there any "ready to you" solution how to export mongoose models to client side app? If I imagine perfect world, mongoose models would let me define which properties and methods of entity is needed on client side and generates needed classes for client so I can easily use them with BreezeJS for example.
Any idea? Or is it road to hell combine it together? :))
Update - As of v 1.2.7 - we have provided two facilities that will help accomplish tasks like this.
The Breeze metadata format has been documented and any json object that adheres to this format and is returned from the breeze metadata call will be used to configure breeze's client side metadata.
The JsonResultsAdapter may be used to reshape or assist with interpreting the result of any web service call so that any results returned by the call can become Breeze entities.
--- Previous post
Please stay tuned, we will be releasing a new version of breeze in the next few days with support for pluggable json adapters that will allow the consumption of any web service. And since breeze metadata can already be defined for an arbitrary model, you should be able to consume your mongoose models pretty easily. Of course, the devil IS in the details.
I am playing around with CouchDB to test if it is "possible" [1] to store scientific data (simulated and experimental raw data + metadata). A big pro is the schema-less approach of CouchDB: we have to be very flexible with the metadata, as the set of parameters changes very often.
Up to now I have some code to feed raw data, plots (both as attachments), and hierarchical metadata (as JSON) into CouchDB documents, and have written some prototype Javascript for filtering and showing. But the filtering is done on the client side (a.k.a. browser): The map function simply returns everything.
How could I change the (or push a second) map function of a specific _design-document with simple browser-JS?
I do not think that a temporary view would yield any performance gain...
Thanks for your time and answers.
[1]: of course it is possible, but is it also useful? feasible? reasonable?
[added]
Ah, the jquery.couch.js (version 0.9.0) provides a saveDoc() function, which could update the _design document with the new map function.
But I also tried out the query function, which uses a temporary view. Okay, "do not use this in the real product, only during development"... But scientific research is steady development, right?
Temporary views are getting cached, as I noticed, and it works well for ~1000 documents per DB. A second plus: all users (think of 1 to 3, so a big user management is quit of an overkill) can work with their own temporary view.
Never ever use temporary views. They are really only there for dev and debugging purposes. For more information, see http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views (specifically the bold "NOTE").
And yes, because design documents are really just documents with special powers, you can run you GET/POST/PUT/DELETE methods on them. However, you will usually need admin privileges to do this. So, if you are allowing a client side piece of software to do that, you are making your entire database public for read/write access - this may be fine for your application, but is important to remember.
Ex., if you restrict access to your database, but put the username and password in client side javascript, then anyone can see that username and password.
Cheers.
I´ve written an helper functions for jquery.couch and design docs, take a look at:
https://github.com/grischaandreew/jquery.couch.js
I am working on a web application that gets JSON data from the server (Ruby/Rails) into the client using jQuery/ajax and then renders it to the browser using jQuery to populate the DOM. To simplify access to my data on the client side, I would like to use an object-relational mapper similar to ActiveRecord, but which starts with JSON data instead of data directly from a SQL data source.
Are there any such ORMs in Javascript that convert a JSON data set (itself derived from a set of SQL queries on the server side) to a set of ActiveRecord-like objects?
I may be missing something here, but JSON (JavaScript Object Notation) is already a Javascript object in and of itself.
If the data you are getting from the server doesn't map well to a usable Javascript object, I would argue that it's the server side that needs to change to return a more useful serialized object rather than a simple recordset.
ExtJS has a very nice JsonStore class
There is CouchDB which is a DB written in Erlang that uses HTTP as the transport. This eliminates the need for middle-ware and permits you to navigate the DB directly with AJAX calls. I can't speak good or bad about it. I haven't heard much about it in months and it seems as if the hype train departed a few years ago.
You can't have an ORM to a remote DB in Javascript.. An, ORM requires transcendental knowledge of the DB schema, and sending that out with an API just isn't that pragmatic as of yet.
For persistent local storage, there is the now deprecated Google Gears and the HTML5 Clientside DB.
Yes there is JSON ODM. Exactly what you are looking for. If you need a method that is not supported yet post an issue and I'll try my best to support it as soon as possible.
If you like it please give it a star!
My current project uses JSON as data interchange format. Both Front-end and Back-end team agree upon a JSON structure before start integrating a service. At times due to un-notified changes in JSON structure by back-end team; it breaks the front-end code.
Is there any external library that we could use to compare a mock JSON (fixture) with servers JSON response. Basically it should assert the whole JSON object and should throw an error if there is any violation in servers JSON format.
Additional info: App is built on JQuery consuming REST JSON services.
I would recommend a schema for your JSON objects.
I use Kwalify but you can also use Rx if you like that syntax better.
I've been using QUnit: http://docs.jquery.com/QUnit recently for a lot of my JS code.
asyncTest http://docs.jquery.com/QUnit/asyncTest could be used pretty effectively to test JSON Structure.
Example:
asyncTest("Test JSON API 1", 1, function() {
$.getJSON("http://test.com/json", function(data) {
equals(data.expected, "what you expected", "Found it");
});
});
Looks like you're trying to solve a problem from other end. Why should you as a front-end developer bother with testing back-end developer's work?
A JSON that is generated on server is better to test on server using standard approach, i.e. functional tests in xUnit. You could also look at acceptance test frameworks like FITnesse if you want to have tests and documentation wiki all in one.
If even after introducing testing on server you'll get invalid JSON it is a problem in human communication, not in tests.
Since there is no answer I'll put my two cents in.
If the problem is that you are dealing with shifting requirements from the back-end then what you need to do is isolate yourself from those changes. Put an abstraction between the front-end and back-end.
Maybe you can call this abstraction the JSON Data Format Interchange.
So when GUI unit-testing (hopefully you are TDDing your Web GUI) you will have a mock for the JSON DIF. SO when the time to integrate the back-end with the front-end*, any software changes will be done in the abstraction layer implementation. And of course you already have tests for those based upon the agreed upon JSON structure.
OBTW, I think that the server-side team should have responsibility for specifying the protocol to be used against the server.
*Why does this remind of the joke my butt and your face could be twins.
https://github.com/skyscreamer/JSONassert may be helpful in eliminating false positives, so that if the order of fields returned by server changes, but overall response is the same, it doesn't trigger a failure.