We have a webapp that's backed by a java spring web application. Apparently our Rational Robot tool that we normally would use to stress test a browser application doesn't deal with the HTML5'ness of our app. We are considering simply scripting the raw http requests to beat on the application, but wondering if anyone knows of any tools out there to do the same without having to craft all of the http requests by hand?
Apache JMeter allows you to record all http requests by setting it up as a proxy. You can then save those requests and play them back in multiple threads to simulate users.
Fiddler with our free stress testing add-on called StresStimulus is another proxy that records HTTP requests and replays them with configurable user ramping.
If you have anything a bit complex, it would be easier to record a script in one of the load testing tools. I have used WebLOAD in the past, which handles things like fetching all the sub-components, script correlation, AJAX recording, etc.
You can record straight from the Android device, or use a desktop browser you like.
Related
I can go to the webpage https://open.spotify.com and select songs that are then immediately played on my desktop spotify application. How does this work? I could imagine a scenario where the webpage sends a request to a server which then tells my desktop application to play, but the website and my application seem too in sync. Sure the web is fast, but the song time counters are perfectly in sync and there is no lag when I click play.
I guess they could do something clever with syncing the song time counter, but I'm wondering if they're dong something even more clever: not using a server at all.
So the real question: Is there a way to have direct communication between a webpage and an application running on the client?
The mechanism is described on How does the Spotify web browser button interact with the Spotify app?. When you install Spotify's desktop application, a process called SpotifyWebHelper runs in the background. This process acts as a local server and receives requests from open.spotify.com to interact with the current playback. As you see, there is a way to communicate a web site and a local application.
It's worth noting that there is an increase concern by browser vendors about this mechanism (see https://bugs.chromium.org/p/chromium/issues/detail?id=378566) and it will stop working at some point in the future. A more future-proof solution could be based on a proxy service that gets requests from the web page and updates your application, and viceversa. Web sockets are a good candidate for this. Although the proxy, acting as a state management service, introduces some delay, it also allows for some other use cases: eg you don't need to have the application installed on the same machine on which the web page is browsed, and one could for instance control a mobile client.
I'd like to login to a RESTful back-end server written in Laravel5, with the single page front-end application leveraging Polymer's custom element.
In this system, the persistence(CRUD) layer lives in the server. So, authentication should be done at the server in responding to client's api request. When a request is valid, the server returns User object in JSON format including user's role for access control in client.
Here, my questions is how I can keep the session, even when a user refreshes the front-end page? Thanks.
This is an issue beyond Polymer, or even just single page apps. The question is how you keep session information in a browser. With SPAs it is a bit easier, since you can keep authentication tokens in memory, but traditional Web apps have had this issue since the beginning.
You have two things you need to do:
Tokens: You need a user token that indicates that this user is authenticated. You want it to be something that cannot be guessed, else someone can spoof it. So the token better not be "jimsmith" but something more reliable. You have two choices. Either you can have a randomly generated token which the server stores, so that when presented on future requests, it can validate the token. This is how just most session managers work in app servers like nodejs sessions or Jetty session or etc. The alternative is to do something cryptographic so that the server only needs to validate mathematically, not check in a store to see if the token is valid. I did that for node in http://github.com/deitch/cansecurity but there are various options for it.
Storage: You need some way to store the tokens client-side that does not depend on JS memory, since you expect to reload the page.
There are several ways to do client-side storage. The most common by far is cookies. Since the browser stores them without your trying too hard, and presents them whenever you access the domain that the cookie is registered for, it is pretty easy to do. Many client-side and server-side auth libraries are built around them.
An alternative is html5 local storage. Depending on your target browsers and support, you can consider using it.
There also are ways you can play with URL parameters, but then you run the risk of losing it when someone switches pages. It can work, but I tend to avoid that.
I have not seen any components that handle cookies directly, but it shouldn't be too hard to build one.
Here is the gist for cookie management code I use for a recent app. Feel free to wrap it to build a Web component for cookie management.. as long as you share alike!
https://gist.github.com/deitch/dea1a3a752d54dc0d00a
UPDATE:
component.kitchen has a storage component here http://component.kitchen/components/TylerGarlick/core-resource-storage
Simplest way if you use PHP is to keep the user in a PHP session (like a normal non SPA application).
PHP will store the user info on the server, and generate automatically a cookie that the browser will send with any request. With a single server with no load balancing, the session data is local and very fast.
We're investigating porting a fat-client .NET application to be an HTML5-based webapp, but a hangup is that we interface with a variety of usb/serial/shared devices (receipt printers, report printers, specialty archive printers, sigpads, scanners, webcams, etc).
Is there any feasible way to get an HTML5 site the ability to interface with local USB/serial peripherals, or with a local service (e.g., browse to www.site.com/app and have it interact with localhost:1234/api to request things like signatures and send stuff like print jobs)?
The other option I was thinking of is to have a local thin-client type setup, which requests UI elements from the remote server's API, but internally has logic to know what peripherals are doing and passes data via the API.
The least preferential item is to try to write some sort of browser plugin, which is is tied with using a java applet. Silverlight might work, but I haven't researched it too much.
Ideally we'd like to do this to make our app cross-platform, and we're not sure what the best practices are for our situation, or what is the path of least resistance, etc.
Try to embed a web browser into a standalone application and code the interaction in the backend:
Some alternatives:
CEF is cross platform https://code.google.com/p/chromiumembedded/
Old and tried SHDocVw ActiveX for embedding IE using COM on Windows http://msdn.microsoft.com/en-us/library/aa752040(v=vs.85).aspx
You could of course use a local service application to do the dirty work for you and you would have to communicate somehow: WebSockets, AJAX requests. There are ways around the security measures that are coded into modern browsers (cross domain requests and DNS trickery) but the major hurdle will be to get your customers to install a service. If you manage that, then the service could very well serve HTML pages directly and handle requests for peripherals.
I have a given Javascript browser application with login screen and data display screen. It does request JSON data via calls that are always the same (i.e. http://myserver.lol/api/getData?mobile), the data changing only slightly over time.
What I want is a mobile app for Android/iOS/Windows Phone/Blackberry, which
-> at best "caches" the whole web site (html/js...) in the app, so I don't have to rebuild the app whenever the web app changes;
-> provides some form of "auto-login"/"auto-form-fill", so the user does not have to give his credentials every time, and
-> some kind of long-term cache for the JSON data, so it is requested from server when a fast network connection (LTE/WLAN) is available, but taken from Cache on GSM or without connection.
Which Framework would allow to implement this the easiest? I am just now looking at the PhoneGap docs and the Titanium docs, but I guess I am overlooking something, or don't they provide an easy solution for this? Or perhaps you have an insider tip for me on another framework?
You can definitely handle this buy using both frameworks. I use only Phonegap / Cordova.
I would do this all by building the application with Phonegap together with AngularJS.
You can use templates in there, so you don't have to fetch the Ui from your server.
To cache data (user credentials or JSON data) I would just use the localStorage which is available on all devices (see here).
I recommend angularJS because it is a really great framework which helps you build Web-Applications really fast (but if you already have an existing application this might not be an option for you).
I hope this helps ;-)
Let's say I have two applications which have to work together to a certain extent.
A web application (PHP, Ruby on Rails, ...)
A desktop application (Java, C++, ...)
The desktop application has to be notified from the web application and the delay between sending and receiving the notification must be short. (< 10 seconds)
What are possible ways to do this? I can think of polling in a 10 second interval, but that would produce much traffic if many desktop applications have to be notified. On a LAN I'd use an UDP broadcast, but unfortunately that's not possible here...
I appreciate any ideas you could give me.
I think the "best practice" here will depend on the number of desktop clients you expect to serve. If there's just one desktop to be notified, then polling may well be a fine approach -- yes, polling is much more overhead than an event-based notification, but it'll certainly be the easiest solution to implement.
If the overhead of polling is truly unacceptable, then I see two basic alternatives:
Keep a persistent connection open between the desktop and web-server (could be a "comet"-style web request, or a raw socket connection)
Expose a service from within the desktop app, and register the address of the service with the web-server. This way, the web-server can call out to the desktop as needed.
Be warned, though -- both alternatives are chock full of gotchas. A few highlights:
Keeping a connection open can be tricky, since you want your web-servers to be hot-swappable
Calling out to an external service (eg, your desktop) from a web-server is dangerous, because this request could hang. You'd want move this notification onto a separate thread to avoid tying up the webserver.
To mitigate some of the concerns, you might decouple the unreliable desktop from the web-server by introducing an intermediary notification server -- the web-server could post an update somewhere, and the desktop could poll/connect/register there to be notified. To avoid reinventing the wheel here, this could involve some sort of MessageQueue system... This, of course, adds the complexity of needing to maintain the new intermediary.
Again, all of these approaches are probably quite complex, so I'd say polling is probably the best bet.
I can see two ways:
Your desktop application polls the web app
Your web app notifies the desktop application
Your web app could publish an RSS feed, but your desktop app will still have to poll the feed every 10 s.
The traffic need not be huge: if you use an HTTP HEAD request, you'll get a small packet with the date of the last modification (conveniently named Last-Modified).
I don't know exactly what to do to achieve your task but I can suggest to create a windows service at the desktop application PC.
This service checks the web application every interval of time for new changes and if changes occurred it can run the desktop application with notification that there is a change in the web application and in the web application when any change occurrs you can response with acknowledgment
I hope that this may be useful I didn't try it exactly but I am suggesting using like this idea.
A layer of syndication would help to scale out the system.
The desktop app can register itself with a "publisher" service (running on one of several/many machines) This publisher service receives the "notice" from your web app that something has changed, and immediately starts notifying all of its registered subscribers.
The number of publishers you need will increase with the number of users.
Edit: Forgot to mention that the desktop app will need to listen on a socket.