What are the techniques and the tools, libraries and frameworks necessary to make a SPA in java (and javascript)?
Consider an application served by a server A. This server might go offline.
What I need is a partially functional, read-only version of that application on a second server B, but fully navigable.
Server B can only serve static files: html, css, js, images.
Server A has access to server B and can push data to it as required and on a regular basis.
My second requirement is to suffer as less as possible from vendor lock-in, so I should be using as little frameworks as possible.
The third requirement is: there should be no necessity of any tool on the client's side, in the browser.
Please list the possible techniques, and where applicable, also at least one tool/framework/library, so I can search for alternatives to that one if, for whatever reason, it doesn't fit my bill.
If you accept any client-side code:
Yes, the best answer are service workers.
You can read about various caching techniques on Jake's site
Easiest plugin to make your website accessible offline is https://github.com/GoogleChrome/sw-precache.
Service workers are framework-agnostic, you can use them with all frameworks or without one in JavaScript.
You will need typical backend (Java/PHP?) or even static html files, and JavaScript client-side code.
If you don't accept any client-side code and accept 3rd parties:
The only solution is to have some kind of proxy like CloudFlare - your DNS will point to CloudFlare, and they you set up what will happen.
If you don't accept any cliend-side code and don't accept 3rd parties:
If you want your solution exactly as you've described, you should use some kind of load balancer like HAProxy (http://www.haproxy.org/), which will route your traffic to failover server. You can read about this here: http://blog.haproxy.com/2013/12/23/failover-and-worst-case-management-with-haproxy/
Related
I've done some research and I've noticed that in a lot of examples Symfony2/AngularJS apps the frontend and backend are combined; for example, views use Twig.
I'd always thought that it's possible (and common practice) to create the frontend and backend separately and just join them by API. In that case if I want to change a PHP framework I will can do it without any problems and it will be enough to keep API.
So what are the best practices for doing it? It would be great if you could explain it to me and even greater if you just give me a link to good example on github or something.
We have been developing some projects using the same approach. Not only I think it doesn't have any "side effect", but the solution is very elegant too.
We usually create the backend in Node.js, and it is just an API server (not necessarily entirely REST-compliant). We then create another, separate web application for the frontend, written entirely in HTML5/JavaScript (with or without Angular.js). The API server never returns any HTML, just JSON! Not even an index structure.
There are lots of benefits:
The code is very clean and elegant. Communication between the frontend and the backend follow standardized methods. The server exposes some API's, and the client can use them freely.
It makes it easier to have different teams for the frontend and the backend, and they can work quite freely without interfering with each other. Designers, which usually have limited coding skills, appreciate this too.
The frontend is just a static HTML5 app, so it can (and we often did) easily be hosted on a CDN. This means that your servers will never have to worry about static contents at all, and their load is reduced, saving you money. Users are happier too, as CDNs are usually very fast for them.
Some hints that I can give you based on our experience:
The biggest issue is with authentication of users. It's not particularly complicated, but you may want to implement authentication using for example protocols like OAuth 2.0 for your internal use. So, the frontend app will act as a OAuth client, and obtains an auth token from the backend. You may also want to consider moving the authentication server (with OAuth) on another separate resource from the API server.
If you host the webapp on a different hostname (e.g. a CDN) you may need to deal with CORS, and maybe JSONP.
The language you write the backend in is not really important. We have done that in PHP (including Laravel), even though we got the best results with using Node.js. For Node.js, we published our boilerplate on GitHub, based on RestifyJS
I asked some questions in the past you may be interested in:
Web service and API: "chicken or egg"
Security of an API server: login with password and sessions
This is more of a curiosity really, to see if some one has done anything similar, or if at all it is possible.
I'm working on a project that will get notification through external notifications. Now I could go about doing this by having notifications coming to my server and have a comet setup between my client and server.
BUT
I was wondering if I could write server logic into my client and listen out for notifications from external sources. Immediately one issue I see is, external sources would need callback URL etc, which I dont know if you could do from client side (unless one could use the IP address in that way).
As you can see it is more ideas and discussions if such a thing was possible, this is somewhat inspired by P2P models whereby you wouldn't be mediating things through your central server.
Thanks in advance!
GWT compiles (nearly) Java source into JavaScript, so compiled GWT apps can't do anything that traditional JavaScript running in the browser cannot do. The major advantage of bringing Java into the picture isn't automatic access to any/all JVM classes, but the ability to not only maintain Java sources, which tend to be easier to refactor and test as well as keep consistent with the server, and to compile that statically defined code into JavaScript, performing all kinds of optimizations at compile time that aren't possible for normal JavaScript.
So no, while you can have some code shared by the client (in a browser) and the server (running in a JVM), you can't run Tomcat/Jetty/etc in the browser just by using GWT to compile the java code into JS.
As you point out, even if this was possible, it would be difficult to get different clients to talk back and forth, without also requiring that the browsers can see and connect at will to one another. BitTorrent and Skype have different ways for facilitating this, and currently browsers do not allow anything like this - they are designed to make connections to other servers, not to allow connections to be made to them.
Push notifications from the web server to the browser are probably the best way forward, either through wrapping comet or the like, or through an existing GWT library like Atmosphere (see https://github.com/Atmosphere/atmosphere/tree/master/samples/gwt-demo for a demo).
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.
When I say "Vanilla Coding", I am referring to websites that don't utilize server side coding (such as PHP, ASP, etc.), only HTML, JavaScript, and CSS.
I know that there are a plethora of sites that already exist that don't utilize (to my knowledge) any of the common, server side languages used by many others (PHP, ASP, etc.), but still function just fine!
I am confused! How do these sites continue to save login information, keep records, etc. etc. without using a server side scripting language? Is there something that I am missing? Can JavaScript access more (such as databases and local files) than what I thought it could?
EDIT
Turns out I've made a serious and shameful mistake in assuming that just because it ended with a .html extension that it was client-side only. That is okay though because I'm learning. Thanks so much for the help everybody!
Essentially, unless you have some sort of server-side programming, you don't stand a chance at making a site with any amount of functionality. To break it down for you:
What you can do without server-side scripting:
Serve static pages
What you need server-side scripting for:
Absolutely everything else
Even something so simple as keeping a site consistent and up to date is a nightmare on wheels without, at the very least, some some sort of management system that pre-generates the static pages to be served. (Technically, one could argue that Copy+Paste in Notepad counts as this.)
As has been mentioned elsewhere; obfuscating the true nature of precisely what system is being used is trivial; and having URLs ending in, say, .html while using PHP is no issue.
Edit: In the most perverse case I can think of off the top of my head, you could have a lighttpd server masquerading as an IIS server, serving pages generated by an offline renderer fed to it by a Perl FastCGI script, sent together with PHP signature heading and using a mix of .asp and .jsp file extensions.
Of course, noone would do something as silly as that. I think…
No client side script can access server side information (like a database) without some sort of server side communication (through something like ajax or the like)
If you really ( i mean really as in don't do it ) want to do logins and the like on clients side, you would have to make some sort of cookie that you store on the user's computer, also you would need a list of users (which anyone can read) to use against
This answer is very late but I leave this reply for anyone who may stumble upon it.
Using javascript/jQuery, and various APIs a simple site can be created only using client-side coding.
For instance, a simple shopping cart type of site can be created. I've done it before.
There are few (not many) strictly 100% jQuery based shopping cart solutions that are open-source.
How does the PG (pay gateway) get taken care of? You are limited to accepting payment through paypal, google checkout, and direct deposit.
What about allowing customers to leave comment? You can use API's like Disqus. What about chat support? Zopim is pretty handy.
How do you get notified when purchase is made? Paypal & google checkout notifies you.
What about sending mass email? Mail Chimp.
Personally, I almost always use WordPress or some other types of CMS but using only vanilla coding to build a simple site is not only feasible but very sensible in certain circumstances.
You're not going to see whether a site is using a server side language unless they let you see the file extensions. With URL rewriting, MVC patterns, etc., it's easy to hide, or even fake that information. Therefore, chances are very good that the sites that you think aren't using a server side language are actually using one.
Now, a site can save certain information in cookies, such as some basic preferences, but any authentication they appear to be doing wouldn't actually be doing anything without a server-side script accessing a database somewhere.
As a side note - I have worked on a site where the content was actually static, but made to look like a blog or CMS. It was an absolute nightmare and hugely error-prone.
What are these sites that you think aren't using server-side scripting?
Nowadays a lot of sites are using Javascript as a server side solution, Node.js being the most popular. Check out this list: https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node
I'm developing a jQuery-based pivot table.
The goal is not a web app but a desktop-based application (C++). In my idea, data is retrieved by the application from the database, then passed to a html page and then showed through the pivot-table plugin.
There is no web server and the web page containing the plugin cannot access to the database.
So, how to pass data in an efficient way? I've seen other questions here on SO around this matter, but I think we're in a different scenario. Of course I can write the data in a txt/xml/js file, but I've experienced that for huge amounts of data, writing down files is costing a lot.
If you don't want to add support for the http protocol to your application, and you don't want to write to additional files, then IMO your best bet is to create a wrapping http server for your application. Then the javascript page can access the running wrapper which can talk to your "real" application.
You could create such a server relatively easily in python using the twisted framework, ruby using rails and the bundled webrick server, or the v8 Javascript engine node.js. (I'm sure there's dozens of other options out there too)
Which of there would be best for you will depend a lot on which languages you have experience with and what your deployment requirements are (supported OSes, existing installed applications, installation size, license terms on your software etc.)
Do you have a specific framework for your desktop app ? If you use Qt for the GUI, you can also integrate javascript quite easily.
http://efforts.embedded.ufcg.edu.br/qt/?p=84
You might be able to use named pipes to pass data to a static page.
It might also be better to just make your c++ program into a simple web server which opens a port, and have it generate the web page when the user goes to http://localhost:8080.