If this question is more appropriate for another forum please do point me to the same.
I am writing a web application that would pull data in JSon format from a number of REST sources. The UI uses a number of javascript technologies like Knockout.js etc using which I am displaying graphs, charts etc.
I have written a mid-tier in java, that acts as a 'broker' between the java script and the REST sources - the idea is to make javascript layer REST calls agnostic to the user/user role etc and let the mid tier decide with REST server/endpoint to call.This java code calls the actual REST endpoints, and exposes a generic REST endpoint to be called by java script.
The problem is that the json returned by most of the REST calls is of a different structure than the one that is required by my java script technologies ( they are a plain array of the data, while each java script component like graph need the data in a very specific format). Also I can in no way modify the source of those REST calls.
This means I will have to do some amount of processing on the json I receive.
My question is, where should I make this processing? Should I do it in the java script code or it would be more appropriate to do it in the java mid-tier code?
A friend of mine suggested that I should do it in javascript because :
In future I might end up making some REST calls directly from
java script, and then I would end up similar logic in two places -
java script and java
JSon being JSon, javascript will have better handling capabilities
If I do it in java, I also increase the number of rest calls
considerably.
I am a bit uncomfortable doing it in java script because:
I am not comfortable coding in javascript(I admit)
If written in java the logic executes on the server instead of users
browser, which I expect to be faster.(A fast loading page is kind of
a must have here)
Am I right or wrong? Any other pros/cons?
P.S. Not that I care so much, but down-voting/close voting without mentioning the reason doesn't help anyone.
Do not listen your friend. Both his arguments are wrong.
While you use Java server side it is a bad idea to call your providers directly from JavaScript. Use mixed patterns is very-very bad idea.
JSon handles easy and better in Java than in JavaScript disregarding that JSON is "JavaScript Object Notation". Just pick a package you'd like better: Jackson, Gson or something else...
So... do it on server in Java. It is a proper place to do that.
You have trivial integration use case, when you need to transform data from external providers to the client required format.
Related
I am working on a project which involves building a web service on the top of a .js library. I successfully completed that but now I have create another library (or something) in which everything should be customizable from the client side and server should just provide the JavaScript functions so that client can attach them with buttons and work with them.
Right now, I can think of two possible implementations:
Creating a new .js library and provide the functions which the client can use after including my .js file.
(Overheads - client will still have to include other .js libraries which I am using inside my library...so frankly speaking, this is kind of overhead on the client and is probably not a good way to go about the problem). My server in this case will just process the data which will be used by my .js library on the client side.
I directly return the necessary JavaScript functions along with the processed data so that client does not have to know about my internal implementation and can work with less overhead.
The problem is I don't know how to go about the second approach which looks quite promising. Is there any example implementation, or a better way to go about the first approach?
Ok. Let me try and explain this in my own words.
As far as I understood your problem, you do not want to include all the JS libraries in your code and would rather have the data passed to the JS libraries and then the inbuilt functions within your libraries process your data and return processed output.
I have not heard of this being done. Maybe it is so we can wait for an answer regarding that. But ideally what you would do is create a "Web service".
So this "Web service" basically act's like your "external javascript function". You pass data to the Web service and this data is processed and returned to you. You then process this output and display it the way you like.
So simply put, you will have to design a Web service with functions, that act the way your Javascript functions do.
I'm planning to write a web app using either Backbone or Angular. We want to push "widgets" from the server to the client (i.e. semi-complicated, dynamic but largely autonomous UI elements... something maybe like the popular TodoMVC app). So we'll need to send over a template, some javascript (controllers etc.), probably CSS, and JSON data (models).
We're debating how to send over all the information. How much can be, and what should be encapsulated in the JSON?
Is it possible to create files out of data passed over? i.e. could we pull out CSS and apply the rules to our document? I believe it would be easier to run javascript passed over this way.
I'm under the impression that being able to cache the template is important... does that require loading it as a (separate) resource rather than as part of some huge JSON object?
As for CSS, it needs to be loaded before inserting into the DOM (so we don't want just a promise). Would it make sense - or even be possible - to pass our CSS rules in the JSON and extract them somehow?
EDIT: to more fully describe what I'm working with, I'm focusing only on the front-end. The back-end can be customized to send over resources however we want - they'll optimize that depending on what the front-end needs. Our backend stack includes MongoDB, Tapestry, ActiveMQ.
The payload that needs to get sent over will be all the resources necessary to push something like a Mac Dashboard Widget or Windows Gadget into the browser. So HTML, CSS, Javascript, data will all get sent over. We want things to be snappy and minimize server requests as much as possible, as some of these payloads may get to be somewhat large.
Your questions are rather vague and the answers can change by coding on a different build platform. Your chosen application design can also impact the best practices to follow for implementing X type of application to X device(s). There's more than one way to skin a cat ya know.
What information are you sending over? Is it a lot of raw data arrays? Is it more document based where XML could be more beneficial? You'll need to work with your DBA if the data is stored in a repository and you'll be querying it. Will you need to write code to format your data or will the DBMS output it in the format you need?
What do you mean the CSS needs to be loaded before being inserted? Everything loads in the order you specify so making sure your CSS loads at the proper time shouldn't be an issue. If you're using ASP.NET, you can also use a SSM (style-sheet manager) to serve your CSS and only load whats required. SSM's are great if you have a lot of style-sheets to serve.
A lot of the questions you asked will be answered as you get further into the design phase. In order to get some solid answers and not just speculation on what is the best method, you will need to publish a lot more details than this. Any answers at this point shouldn't carry much weight in your decisions. They certainly wouldn't mine.
I have a site written in Asp.net webforms. It uses ajax heavily.
Most forms on the site are submited with javascript. Javascript validates the input and sends it to /ajax.ashx on the server. The server processes the request and sends back a JSON response. My javascript uses the JSON to create html, which it inserts into the Dom.
I'm making a new version of my website written using asp.net MVC3. I've been looking at tutorials on this subject, and some of them recommend doing ajax in a different way. Rather than sending data and then building + inserting html with javascript, they create html at the server, and use javascript only to insert it into the Dom. For instance, in this tutorial.
Which way should I use? Using the new method will be quicker, but is it better?
That's a subjective question. Both approaches are possible and there is no better way. There are pros and cons of each approach.
Building the HTML on the server is easier and will require you less efforts but consumes more bandwidth compared to the first approach.
If you decide to go the first way you could use some client side templating framework which might help you simplify the generation of DOM elements on the client.
Creating html code directly into the server and injecting it with an ajax call is very fast and simple, the real problem is that in that way your service is bound to be used with that specific application. By sending RAW data you allow any app to use that data in any way, without bounding it to a specific application.
returning json feels more flexible to me; you can change what happens with your json response, like the layout it results in. If you return html you return data mixed with layout. This doesn't feel right to me.
I believe it is better to separate the layout from the actual data. That is why you should pass data between your scripts and not HTML.
If you go about it sending HTML, consider that you would have to build valid HTML and CSS, which might not sound hard at first but then you'll start using CSS that is not loaded in the file calling the ajax, etc.
Always separate content (data) from layout. That's why there is HTML and CSS, to separate layout from data. So why mess things up by mingling HTML between data?
Building the html serverside will probably be faster and not bog down the client which is important. Rendering data into HTML with javascript takes time and not every browser is fast with js (i.e. older versions of IE) so things can slow down if you're doing a lot of this.
Like previous posters said, it's kinda subjective because it depends on how much you're offloading to the client. I'm of the opinion that if you can do things serverside, you should.
If you are going to be using this service to return JSON to other applications/clients, then it's probably a good idea to just leave it as JSON and let the client do what it needs on their side.
First of all, I'm not much of a programmer if at all. This question may seem silly but I would honestly like some advice from real programmers.
I'd like to make a bit of an adventure game on a webpage.
Could I make it by having a MySQL database setup to store variables while JavaScript, HTML and CSS is used for the user interface and JavaScript for the game programming and PHP to communicate with MySQL.
I don't entirely understand it but I followed a tutorial and got it working. It also showed me how you can replace text on the screen by giving that text an elementid and then just setting its value to other text.
In this tutorial script, it has it so when the JavaScript file wants to communicate with php, it will open the php file with a ?=value at the end of the hyperlink where the value part turns into some kind of MySQL search value.
Something like this:
xmlhttp.onreadystatechange=function()
xmlhttp.open("GET","index.php?q="+str,true);
and then in the PHP file:
$q=$_GET["q"];
$sql="SELECT * FROM user WHERE id = '".$q."'";
This means you will always search by specific id number. The problem with this is that the php file is always set to look at the exact same table.
Sometimes you want to look at different tables, or multiple values from multiple tables, etc. Basically, you should be able to select each value like it's a record from one of those automatic DJs that radio stations used to have. Also, sometimes you'd want to write or append the database like when variables change and need to be updated and all of that has to happen securely.
The only thing I can think of is to have a ton of php files that work the same way and call the appropriate file when you want a certain kind of response. But then if I have a file on my website that has a php file that lets me write TO the database then someone can just read the javascript code, see that, and then basically hijack the mysql database.
So how can I securely do this?
I would recommend you to look into using jQuery and Ruby on Rails.
jQuery is a JavaScript library that will make easy your interaction with a server (MySQL) and will help you to get code that works in a lot of different web browsers.
Ruby on Rails is a web framework that will encapsulate everything you need to store state (game data) to a database (MySQL) and handle secure communication, as well as a host of other needs you may eventually face.
In addition to jQuery and Ruby on Rails, there are tons of other comparable frameworks you could use.
YUI3 (http://yuilibrary.com) and Django are two more examples. Express (for Node.js) is a JavaScript back end framework (like Ruby on Rails) that you could use with your existing JavaScript knowledge.
Anyway, good luck!
Theoretically, without moving towards different frameworks, here are a few things to think about...
I think you have the right idea with this what you are trying to do. The PHP file is used as server side logic. It should not be available to the user.
What the user can see is that there is a function available to make changes to something. This he will see from your AJAX call in JavaScript ( xmlhttp.onreadystatechange=function() xmlhttp.open("GET","index.php?q="+str,true); ).
Your responsibility, in the PHP (server side logic) is to make sure you scan the parameters to this function before you allow any changes to be made on the Database.
As with any requests to a database, you need to make sure you are escaping the parameters before any call is made to prevent SQL Injections.
As with previous answer, there are some libraries that exist that have some tools already built in. Some poeple prefer certain tools/languages/libraries over others, but they can all pretty much all do the same thing. What changes is a bit of how it's done. I think you are on the right path, just need to protect those PHP pages of injections and inputs/parameters you do not want.
If you are using multiple PHP pages for different actions, it is possible to have the same PHP script accessed from all other pages. Therefore your escaping (preventing SQL Injections) can be done in the same script and don't need to include it in every single PHP page that makes a database call.
Hope this helps a bit!
I've been looking at the API for Flattr, http://flattr.com/support/integrate/js , which has a cool way of accepting query variables for their JavaScript to load.
My question is, do most APIs use something other than JavaScript to accept these different variables for their services? EG:
Ruby on Rails
PHP
Python
Then these are parsed by the respective language and returned as outputted JavaScript to the requesting website?
Cheers
Javascript itself is totally capable of reading how it's embedded to the HTML it belongs to, by reading document.getElementsByTagName("script") and further parse/match their src attributes. Therefore, it's not a problem at all for it to further parse the query variables attached at the end, and dynamically (all in javascript, client side) load components within.
Any javascript libraries that allow you to pack the whole thing and deploy to your own web server should take this approach, since there's no server to handle the request anyways.
On the other hand, javascript libraries that are hosted on other sites that allow you to use (like YUI) MAY take the server approach like you mentioned.
In my personal experience, projects that I have worked on have used server side languages to deal with get params.
So a request might be /myjavascript.js?id=123123 The server side language would create the correct javascript for that request.
Keeping everything on the server side has the advantage of not allowing the user to see what is going on. If this isn't a problem for you, javascript is more than capable of handling different params.
In my experience it's fairly common that widgets embedded into others' sites gets their parameters by parsing them from their script tags. It makes the widget script static and self-contained and thus easier to distribute through eg. a fast CDN. Performance is important when you're going to convince someone else to add your javascript to their site as poor performance from the widget can make the entire site appear sluggish.
A better place to specify the parameters than query parameters would however be to specify them in the URL:s hash-part as that part isn't included when caches are checked and thus the script would have to be downloaded fewer times - which of course is good for performance, especially if the parameters might shift a lot.