I have been tasked with researching technology for generating a dynamic report with charts & visuals.
There are countless BI tools available and online solutions that fit the bill, however, the customers have considerable IT restrictions preventing the installation of applications or sharing data across the internet.
One solution I've dreamed up is to serve up an HTML document for offline consumption in a browser. With javaScript bundled in & data added dynamically prior to sending to the client, I believe this would be possible in much the same way a website functioning offline is possible.
How feasible is this? If it's possible, what technologies are recommended? So far I've considered building this using AngularJS since an SPA could mimic a one-page report well & javaScript bundling is readily available.
Are there better solutions? Which?
May be your clients will be okay with providing them files by SFTP. Say, if you are not using a database and are ok with building charts based on files, you can try to provide end users with the files (txt, csv, xml...). Then you will be able to execute client-side code with no server needed. You may even go for some open-source Javascript libraries for data visualisation like D3. All you have to do is to allow local file access for user's browser.
Otherwise you need a local server. I would recommend you to use Python python's SimpleHTTPServer or node.js may fit you.
Related
I'm developing an Android application, typically with a fairly small database (hundreds to a thousand or so main entries, plus similar order of magnitude in joined tables) populated by the user. There is also a file associated with each main entry, but those are kept separate, and not part of this question.
In my current prototype, the structured data is stored in a SQLite database in the usual way, and synced between devices by uploading the file to an Application Folder on Google Drive. This allows me to avoid having to provide any user storage, which is something I hope to stick to.
Storing files here also has the happy side effect that I can access them via JavaScript code in a web page using the Google Drive API. But JavaScript interacting with a remote SQLite file is an incredibly ugly thing to attempt. (Downloading the database server-side and handling it there is another option which sounds not great either.) I am wondering if anyone has any recommendations of the best practice approach here, given I would like to have a web-based version of the app accessing the same data.
The obvious most sensible idea seems to be
Exporting from SQLite to some other structured format XXX (like XML, JSON, CSV, ...) first, uploading that XXX file to Google Drive, so that JavaScript can straightforwardly interact with it, and then on sync reimporting this XXX data back into SQLite.
though I'm happy to hear any criticisms/improvements on this idea.
I'm mainly interested in best-practice recommendations of efficient ways to approach these problems. Question: What file format XXX would be good; and do you have any recommended methods for (a) exporting and importing in Java from SQLite to XXX, (b) interacting in preferably client-side JavaScript with a remote Google Drive file in format XXX? (If maintaining server-side code to interact with XXX is substantially better practice do say.)
It depends on how many clients your app will manage
Exporting from SQLite to some other structured format XXX (like XML, JSON, CSV, ...) first, uploading that XXX file to Google Drive, so that JavaScript can straightforwardly interact with it, and then on sync reimporting this XXX data back into SQLite.
IMHO, this is quite a bad idea for quite a few reasons:
If multiple users try to change data at the same time, you will have a tough problem managing all those data entries and possible conflicts
Providing direct access to your data layer is ALWAYS a bad idea since any client can wipe out all your data
If you have very few users or are making it as a personal project, you can stick with SQLite.
Kripken, the developer of Emscripten (the C/C++ to Javascript LLVM compiler) has compiled the SQLite Library to Javascript to make the sql.js library. You can find it on GitHub. There's also a demo page of sql.js
But if you have a lot of users, you might want to use Firebase by Google. It gives you a database and a REST API to use it. There are libraries to access Firebase from different programming languages too.
Cheers!
I'm starting a project that basically is a single-page app that downloads and shows a bunch of stats (using d3.js). The data layer is Mongo-powered, served through a RESTful API, and the client app will be coded in Ember.js. We want all data to be exchanged through the API, since we also have some mobile apps in the back burner that will hook to the same API.
I'm debating on whether write the API (using Express.js or other server-side MVC framework), or just serve the API use Deployd and not using a server-side framework at all, besides Deployd. I'll provide some hints about the project characteristics:
The main feature is basically a dashboard that shows aggregated stats that are already computed and stored in the Mongo database.
User interaction is minimal, enough only to allow users to customize their dashboards, but users never upload data (other that customization preferences).
Most of the app is a lot of d3.js to create and render a bunch of graphs, which can customized in many ways.
It requires a very rich and responsive user interface.
I proposed skipping completely the server-side framework, and simply go with a bunch of static HTML+CSS and do all the heavy lifting with a client-side MVC such as Ember.js. Since all data download and upload can be handled by Deployd, a pure static site would load much faster and is also easier to scale. Also, (I think) all user-related data and validation can be done with Deployd itself.
The thing is, some of my colleagues had a heart-stroke when I mentioned this idea. So I'd like a reality check: do I really need a server-side framework besides Deployd to cope with problems I cannot foresee yet? Are the benefits of having a pure static site a good enough tradeoff versus having, say, Express.js just in case?
I haven't worked with Deployd before, but from a quick skim of its docs, it is a server-side framework. It accepts requests and respond with json. It's just oriented to APIs and json and neglects html, unlike, say, default Ruby on Rails.
The main issues I can think of that might arise due to a lack of a traditional server-side framework are things like auth, CORS, and XSS/CSRF/other common security issues. You could cater for this through Deployd if it's built in or easily added, but that may be difficult.
Looking further into Deployd's docs, I see there's a guide for users and CORS. I can't find anything about XSS or CSRF.
I have a potential customer who wants an application that can download large amounts of TIFF files locally on a machine for display.
After having discarded Java apps and Windows apps as too difficult to distribute (he has no control over the client computers) I am suggesting an offline HTML5 application.
TIFF is only natively displayed by Safari, and the FileSystem API only works on Google. WebSQL will be too small for the amount of data required (3-4 GB).
I've looked at different plug-ins (AlternaTIFF and BlackIce) but both need to be installed separately, which most of the users will probably find difficult to do.
I am wondering if there was a local TIFF Viewer that I could call from the browser that would open the TIFF from the FileSystem?
If this does not work, the last solution would be a conversion of the TIFFs to something else on the server, but it's going to make my database double in volume.
Any suggestions would be welcome!
UPDATE:
The target computers are not under the control of the client. There is no easy way to distribute the software to all the target computers. I'm assuming they are all windows machines, but it's no guarantee that .NET is installed.
That's the reason I opted for HTML5. At the moment I'm considering a Java Application launched with Java Web Application.
Customer has not yet confirmed the type of files they are using.
The customer is in the construction industry, the TIFFs are scans of large plans which (I assume) will need to be high-quality (zoomable, printable etc) so I don't think a rescaling to JPG will be accepted.
SECOND UPDATE
I'm coming to the conclusion that an HTML5 App is not going to be able to answer all the requirements. In particular there is one requirement that requires a multi-document print (select n documents and have them printed out in a batch). I'm starting to consider standalone applications that can be deployed and updated easily over a wide range of Windows configurations. I'm thinking of a Java Rich Client distribution over Java Web Start or a Microsoft application distributed via one-click-run. I'd simply write the files on the local filesystem and have the client display the images in-line. Would that be a good idea?
Thanks for all the comments.
I've come to the conclusion that it's a bad idea to try and view these files in browsers.
I'm going the way of a separate standalone Windows application. I'll be using the standard viewing and printing functionalities from Windows, which will avoid me all the headache of having to recreate that myself.
I have a simple offline html5/javascript single-html-file web application that I store in my dropbox. It's a sort of time tracking tool I wrote, and it saves the application data to local storage. Since its for my own use, I like the convenience of an offline app.
But I have several computers, and I've been trying to come up with any sort of hacky way to synchronize this app's data (which is currently using local storage) between my various machines.
It seems that chrome allows synchronization of data, but only for chrome extensions. I also thought I could perhaps have the web page automatically save/load its data from a file in a dropbox folder, but there doesn't appear to be a way to automatically sync with a specific file without user prompting.
I suppose the "obvious" solution is to put the page on a server and store the data in a database. But suppose I don't want a solution which requires me to maintain apps on a server - is there another way, however hacky, to cobble together synchronization?
I even looked for a while to see if there was a vendor offering a web database service - where I could, say, post/get a blob of json on demand, and then somehow have my offline app sync with this service, but the same-origin policy seems to invalidate that plan (and besides I couldn't find such a service).
Is there a tricky/sneaky solution to this problem using chrome, or google drive, or dropbox, or some other tool I'm not aware of? Or am I stuck setting up my own server?
I have been working on a Project that basically gives you versioned localStorage with support for conflict resolution if the same resource ends up being edited by two different clients. At this point there are no drivers for server or client (they are async in-memory at the moment for testing purposes) but there is a lot of code and abstraction to make writing your own drivers really easy... I was even thinking of doing a dropbox/google docs driver myself, except I want DynamoDB/MongoDB and Lawnchair done first.
The code is not dependent on jQuery or any other libraries and there's a pretty full features (though ugly) demo for it as are well.
Anyway the URL is https://github.com/forbesmyester/SyncIt
Apparently, I have exactly the same issue and invetigated it thoroghly. The best choice would be remoteStorage, if you could manage to make it work. It allows to use 3rd party server for data storage or run your own instance.
I've been doing some research on the HTML5 local storage/offline capabilities and I'm beginning to get a better understanding of it. I've been designing a billing application with Grails and I'm just wondering if it is possible to set up a Grails application to be an offline web application, like you can with HTML5 (by utilizing a Manifest file). If so, would it be set up in the same way that you'd set it up with HTML5, or would there be any key differences to make a note of? Also, what is the best way to implement the local storage functionality of HTML5 in Grails? Is there any plugin or framwork available for this purpose . Has anyone ever used this plugin/framework before, and if so, do you know if there are any guides or examples that use it anywhere that would be really able help me get started with it?
I'd appreciate the information on making a Grails app work "offline
Thanks in advance!
I am developing an offline HTML5 app, myself. The biggest difference is that it is a single page rather than many small ones (but it might work that way if you tried it; you would need to be sure it got all the data it needs at startup).
Don't forget to add the application cache mime type to your configuration.
I never thought to look for a plugin for local storage. In my project, the local tables (I'm using WebSQL because it's in Webkit browsers) are different from the domain classes because they have a different function; that is, they have to hold the data for the domain tables untilthe device can sync with the host.
I hope there is something useful here.
Ed