I'm building an ASP.NET AJAX application that uses JavaScript to call web services to get its data, and also uses Silverlights Isolated Storage to cache the data on the client machine. Ultimately once the data is downloaded it is passed to JavaScript which displays in on the page using the HTML DOM.
What I'm trying to figure out is, does it make sense for me to make these Web Service calls in Silverlight then pass the data to JavaScript once it's loaded? Also, Silverlight will be saving the data to disk using Isolated Storage whether I call the Web Services with JavaScript or Silverlight. If I call the Web Services with JavaScript, the data will be passed to Silverlight to cache.
I've done some prototyping both ways, and I'm finding the performance to pretty much be the same either way. Also, one of the kickers that is pointing me towards using Silverlight for the whole client-side data access layer, is I need to have timers periodically check for updated data and download it to the cache so the JavaScript can loading when it needs to.
Has anyone done anything similar to this? If so, what are your experiences relating to performance with either the JavaScript or Silverlight method described?
Since Silverlight can handle JSON and XML based services, the format of the response is totally irrelevant. What you must consider, however, is the following:
1) Silverlight is approximately 1000 times faster than JavaScript
2) If your web service is natively SOAP based, Visual Studio can generate a proxy for you, so that you don't need to parse the SOAP message.
3) Silverlight has LINQ to XML and LINQ to JSON, which makes parsing both POX and JSON a breeze.
In a perfect world, I would go with Silverlight for the "engine", and fall back to JavaScript in case Silverlight is not available.
Greetings,
Laurent
Another thing to consider - getting your data in JSON format will be faster than XML and Web Services. JSON becomes a JavaScript object pretty quickly and doesn't have to be parsed like XML does. Personally, I'd go with JavaScript.
article: Speeding Up AJAX with JSON
Since JavaScript isn't multithreaded, I'm finding that using Silverlight to access/cache the data then pass it to JavaScript for display produces much better performance, while refraining from locking/freezing the browser so the user can keep doing stuff while the data loads.
Passing JSON-formatted data is in part faster because unlike an XML SOAP message, it doesn't require a SOAP header or any other miscellaneous info - it's just pure data. Thus, making the total size of the message smaller.
Related
I have asked this quesion few days before here and no one answered it.
I had asked it in forum.javascriptMVC.com too and now I have a answer, however I need a a bit more idea.
Question:
I read javascriptMVC's documents and I loved it.
But I don't know how to use it in a large scale project.
I think on the server-side a MVC framework is needed or can help so much. And I've worked with server side PHP frameworks.
I am confused, my understanding of JavascriptMVC projects is that they handle client side events on the browser capture events, execute AJAX requests, manage the responses/data from the server and also show them to user in a graphical interface.
I know that in PHP MVC projects we also have controllers (and actions) that any of them is a separate page with a single entry point, my point is that these pages are whole HTTP requests.
I think the combination of these two frameworks would be in a form of a single or few heavy files (including js , css , imgs etc) that loads and managed by another Javascript libary such as steal.js.
Now user can work with site and its actions (as events) that result in running js functions that may change something in the UI or cause a AJAX request, as in Yahoo Mail where most things happens in one page.
So how will this affect the design of controllers and actions in PHP ? I mean normally in PHP MVC frameworks a lot of controllers and actions means a lot of pages. I think because of AJAX the number of controllers and actions should be actually less. I also think because of JMVC most controllers (and actions) should turn to AJAX responders, however how are layouts and views to be handled in this context?
Finally
I want to know about different aspects of using this method(JMVC+MVC). (I am using Yii as my server-side MVC framework and JavascriptMVC as my client-side MVC).
I also want to know about management of data on the client-side.
I would like to understand how AJAX and web-sockets could be used, where we can use AJAX and where we can use websockets?.
I want to understand about local-storage how we can use it for simulated page data management and maybe caching, how we can cache data coming from server as JSON in a form of a page? I am working on a very large project and I want to build its foundation very strong.
Say that you jave a JMVC framework where
The model gets data from the server using AJAX request - expecting JSON results.
The view does not rely on the server, for more that providing the raw HTML.
The Controllers do not rely on the server, for more that serving the JS files.
Essentially you use the server what it "should" be used for, data storage and processing, while you let your client browser handle all the tedious stuff.
Now, lets see how to define a server-side framework. As I see it we have several options, all of them fairly similar, albeit somewhat different (all returning someing in JSON format):
A fully fledged MVC such as cakePHP
Custom implementation
WebService implementation
Personally I would use a WebService, and I already have. Or rather, I used a WebSocket based JSON-RPC WebService.
Using a fully fledged MVC will have it's drawbacks in maintainability and, not insignificantly, server load. But it is very possible, just implement a view which formats the page as JSON...
Making a JMVC client does not, in my view, mean that it cannot request new HTML from the server. But it does mean that that requested HTML should be free of data, other than meta-data the Java-View needs to know where to put data recieved from, for example, the WebService.
So a main page in the JMVC could just contain a single
<div id=content></div>
and menu clicks can fetch a subpage from the server and load the content into content. Then that loaded content can contain some more javascript which starts WebService requests to get data from the server, to display in the empty placefolders it in turn contains.
First check https://stackoverflow.com/a/4458566/718224 after that you can move forward.
Try this (from https://stackoverflow.com/a/8424768/718224)
No, you don't need to use it server-side, but it will help with organization / separation of application and business logic. Depending on the scale of your application, that could help tremendously in the future.
The key is just making sure you organize your backend code well, otherwise you will end up with a monolithic and/or difficult-to-maintain codebase.
Server-side views would contain your HTML and any JavaScript that may or may not make requests to the server. This assumes that you are actually using PHP to build the pages that a user navigates to.
If you have a static html page that builds itself using AJAX requests, then you may not need to use server-side views at all. Your controllers would more than likely be outputting JSON data. If this is the case, it doesn't make models and controllers any less useful.
Try this (from https://stackoverflow.com/a/8424760/718224)
If you are using any of the major PHP frameworks (CakePHP, Code Igniter, Symfony, etc.) then you ARE using MVC already. If your server side logic is more complex than just a few really simple scripts than you probably should be using one of those frameworks listed, using MVC on the server and the client.
Many (most?) larger web apps being built today are moving towards using an MVC framework for both client-side and server-side application code. It's a fantastic pattern for separating concerns for many large applications, especially request/response server apps and event-driven browser apps.
Try this (from https://stackoverflow.com/a/8427063/718224)
Backbone.js connects your application over a RESTful JSON interface. I honestly find that it works wonderfully in conjunction with the MVC framework. If you build a RESTful API, you can let you server manage CRUD updates quite easily. All your server side code will be responsible is saving and sending back JSON objects to Backbone.js. Then let most of your logic and magic happen within the Backbone.js framework.
Try this (from https://stackoverflow.com/a/8078282/718224)
First, a client-side MVC framework like Backbone isn't just for single-paged apps. You can also use it to add some rich interaction to one or many views of a more traditional app. They simply provide structure and data abstractions on the client.
Next, these client-side frameworks are designed specifically to work with your back-end MVC frameworks. Backbone.js (since you tagged it specifically) models and collections work with REST services. They will talk via GET/POST/PUT/DELETE verbs and will ultimately communicate with your controllers on the back-end when they make asynchronous requests.
In the case of Backbone, it talks JSON instead of HTML. In the case of Rails, this is really easily handled in the controller. If the request is an HTML one, then you return a view as HTML. If it is a JSON request (*.json or Content-type) then the controller returns a JSON representation of the data. I am assuming that it is as easy in Django as it is in Rails to have the same controller respond to multiple content requests (HTML, XML, JSON, etc)
may this help you.
client side web apps and rich client side web pages often use jmvc backbones and etc. and with that kind if js libraries and HTML5 technologies like webstorage you can have a more applocation like websites that all things happens in client side like templating management and etc. and just we have ajax request/response to servers to get/set data or update status. and abput first section they are right a jmvc site are more like a single pages websites. ie hotmail yahoo , etc.
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 am currently having an idea where I want to save an image from a c++/openGL application on demand from a browser. So basically I would like to run the application itself on the server and have a simple communication layer like this:
JS -> tell application to do calculations (and maybe pass a string or some simple data)
application -> tell JS when finished and maybe send a link, text or something as simple as that.
I don't really have alot of experience with webservers and as such don't know if that is possible at all (it's just my naive thinking). And note: I am not talking about a webGL application, I just want to have simple communication between a c++ serverside application, and the user.
Any ideas how to do that?
Thanks alot!
Basically no matter what your language/framework you choose for your web server, you just need a interface that is callable from your browser JS, and you can do whatever you want in the server once it recieves the call.
Most likely any web service interface exposed from the server.
Just need to safeguard your server not to get DoS since it sounds like it's a huge process.
As far as I know, JavaScript (at least when embedded in HTML) is executed on your local machine and not on the server so that there is IMHO no way to directly start your server-application using JS.
PHP for example is executed on the server-side and so you could use e.g. the php system function to call your C++/OpenGL application on the server - initiated on demand through a web-browser.
When the call is finished you could then directly present the image.
Well you could always use the cgi interface to invoke your application
and have it save that image somewhere accessible to the webserver.
Then have your js load that via ajax.
Or make a cgi App that talks to the app and then serves a small
page with the pic in it.
[EDIT]
Answering the comments:
CGI is not complex to learn, it is mostly a simple convention
you can follow. I think it would give you the maximum of
flexibility. I don't know which php mods allow you to leave the cozy protection of the server-application and interact with other stuff on your server.
Using Google Mini for a website that needs output from the Google Mini in a JSON/JSONP format for front-end querying purposes. Google Mini does publish an XML feed that could potentially be used by a middle process to convert to JSON/JSONP.
Can Google Search Appliance / Mini output to JSON/JSONP using a plug-in, modification to an XSLT template, or other unknown method?
Solutions discovered
Seems like digging through code.google.com reveals that GSA/Mini does not have a method to output in the JSON/JSONP format without using XSLT to create the feed. It is a matter of creating this XSLT to do the conversion.
Other option is to create a server-side script using available technology (PHP?) to retrieve the XML from GSA/Mini and convert the feed to JSONP upon request from the Front-end (AJAX). Downside is the increased overhead in this call.
Update 10/8/2010
Created a Google Mini frontend that generates a JSONP response.
I had the same problem trying to get JSON and JSONP. The solution worked in general on all other browsers, but IE. I could not change the mime-type to something other than text/html since that was global in GSA. Created an XSLT to solve that problem for browsers like IE which will not allow content to be returned due to a security feature ( IE – SEC7112 )
https://github.com/kjonnala/gsa_template
Hope that helps.
I'm working on approach #2 above. We have version 6.4 of the appliance and it provides JSON for the suggestion service (probably new since Riley's question). For example:
http://code.google.com/apis/searchappliance/documentation/64/xml_reference.html#RichOutputFormat
What I ran into was that cross-domain limitations prevented using the appliance JSON service on non-appliance website search forms, including those in subdomains of our shared high level domain.
I'm testing a simple Java servlet now that makes the suggest call. It takes incoming requests, gets the response from the appliance, outputs in JSONP and sends back to the calling page.
There are a couple references I've found related to proxying the suggest service:
http://groups.google.com/group/Google-Search-Appliance-Help/browse_thread/thread/72406a271a6d9917/
http://www.mcplusa.com/blog/2009/07/adding-google-search-appliance-suggest-search-to-your-existing-page/
http://sites.google.com/site/lightbends/gsa_qs_6_2
and some related to JSONP with jQuery:
http://devlog.info/2010/03/10/cross-domain-ajax/
http://www.ibm.com/developerworks/library/wa-aj-jsonp1/
JSON to JSONP in the servlet is quick and probably dirty in the approach I'm taking :)
It's not in production yet, so I can't speak to what we'll find in terms of performance and other challenges. I like that the service is exposed from a secondary server rather than directly from the appliance (allowing for throttling of incoming requests if needed, etc.) if the performance can keep up.
October 1, 2010 Update
Sorry - my post above applies only to the suggest service and not to the general search results. You could still take the XML response, process and wrap that in JSON/JSONP, but that would take longer I suspect. I was using the JSONP in the context of suggesting search queries with jQuery autocomplete, so having the quick response (as they type) is important.
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.