I would like to generate a PDF with a QR code for a web-app I'm making. Should I generate the PDF on the server side or the client side?
In my experience, generating on the server has the following advantages:
more options - tools/libraries, language support, fonts etc
storage options - your servers can store the PDF if required in a db/document-store
security - your storage options are all secured on the server and hidden from the browser
reliability - your PDF will be generated on the server, stored and available to the client. This same PDF can live for as long as required in storage and delivered to the client whenever required. You can confirm any time that the PDF the client has is the same one as stored.
Generating on the client might be quicker, so it depends on what the life-cycle of your PDF is as to which path is best.
I hope that helps.
Related
I need to be able to obtain performance metrics such as loading times, REST Calls time through a google extension and mozilla firefox add-on.
The challenge is to get the extension itself. I can't seem to be able to obtain an extension having those functionality on both google extension and mozilla firefox add-on.
Another challenge is that the data obtained from the performance metrics should be exported so as to be put in a structured database.
Anyone know any extension/add-on with those requirements?
I don't think you will find such extension, in particular storing the results into the database will not be possible at all as extensions can only access limited subset of browser functionality, so called sandbox.
So instead of looking for an extension I would recommend investigating Navigation Timing API
The output of the API can be converted into i.e. JSON object using JSON.stringify() function
JSON is some kind of universal data interchange format so databases either can consume it directly or you can convert it into whatever you want.
If you're looking for a way to automate everything you can consider using Apache JMeter tool as an unified testing solution:
browser automation is being provided via WebDriver Sampler
database connectivity is implemented via JDBC Connection Configuration and JDBC Request elements
JMeter by nature is a load testing tool so you can combine the above steps which check client-side performance with the backend performance test.
I'm developing a project using CakePHP 3 for server side and Android for client side. In this project I have to send a lot of images of products from the server to the app. When the app requests the images of a product, the server searches in the database for the urls of the images and send them to the app through a json response. Then, in the app I load the images using NetworkImageView from Volley library.
This process works, but the images are heavy in size, so it consumes a lot of data if you use mobile network like 4g. I can't to lose image quality, so I can't treat the images too much.
What I was thinking was to compress (somehow) the images in server side, send the array of bytes through json and uncompress them in the app, so I could minimize data consumption.
I coudn't find any info for what I described above and I'm not sure if this is the right aproach. Any help would be appreciated.
What I was thinking was to compress (somehow) the images in server side, send the array of bytes through json and uncompress them in the app, so I could minimize data consumption.
JSON will increase and not lower the amount of data that needs to be send for obvious reasons. It's an envelope in your use case and the way JSON works it will add more data. Check the JSON spec.
You want to enable gzip compression on your Webserver (Nginx here), check Google for that or superuser.com for more details.
But this won't make a dramatic difference either for mobile use when you send a 20mpx image. I would send small images and only send a lager version when needed, when the user zooms in. Guess that's doable.
I've made a website for an arts organisation. The website allows people to browse a database of artists' work. The database is large and the image files for the artists' work come to about 150Gb. I have my own server that is currently just being used to keep the images on its hard-drive.
I'm going to purchase hosting so I don't have to worry about bandwidth etc... but would it be better to purchase hosting that allows me to upload my entire image database or should I use the website to get the images from my server? If so how would I do that?
Sorry I am very new to this
I think it could be better to have the data on the same server so you avoid calls to another server for images which are quite big as you say and this can slow you down overall.
I assume you will need to set up some API on your server to deliver the images or at least URLs for them but then you must make sure they are accessible.
You'll want the image files on the same server as your website, as requests elsewhere to pull in images will definitely hinder your site's performance - especially if you have large files.
Looking at large size of database and consideration of bandwidth, dedicated server will be suitable as they includes large disk spaces and bandwidth. You can install webserver as well as database server on same server inspite of managing them separately. Managing database backups and service monitoring becomes much more easier.
For an instance, you can review dedicated server configuration and resources here :- https://www.accuwebhosting.com/dedicated-servers
I am building a new web application. I use google appengine , jsf2, primefaces , java technologies for building this web application. I have to build a dynamic image gallery within this web application. ie registered users should be able to load images to a gallery and then it should be available for viewing by the public.
My issue is that :
1) app engine allows only a maximum of 1mb file to be written to its blob store at a time.
2) app engine doesn't allow to write to the server file system.
3) Should I store each image as a blob to the gae database?. But if I do that the whole application will be damn slow as there can be a lot of images. So reading the images from the blob store can make it slow and will cost heaps of processing power.
Am really confused about a proper solution and couldn't find any proper recommendation in the web. I am pretty sure that there will be a descent solution available !
It would be a great help if some one with prior experience in building web application's which deals with a lot of image content could advice me a good solution.
The solution is to use upload URLs when users are uploading images, so that they get uploaded directly to the Blobstore:
https://developers.google.com/appengine/docs/java/blobstore/#Java_Uploading_a_blob
Then just reference the blobs directly via getServingUrl() rather than having your application try to read them into memory.
You really should use GCS (Google Cloud Storage), and not the blobstore. The call from a users browser to an image stored in GCS goes directly to there, and is not charged to your app.
Consider a HTML5 game, rather heavy on the assets, is it possible to somehow provide the user with an option to store the assets locally, in order to avoid loading all those assets again each time he loads the game?
Yes, there are several options:
Web Storage (localStorage/sessionStorage) can be used to store strings (or stringified objects). It has limited storage capacity but is very easy to use.
Indexed DB is a light database which allow you to store any kind of objects incl. BLOBs. It has a default limit (typically 5 mb) but has an interface that allows you to request more storage space.
Web SQL is also a database, although deprecated it has still good support in for example Safari (which do not support Indexed DB) and works by executing short SQL queries.
File system API is in the works but not widely supported (only Chrome for now). As with Indexed DB you can request larger storage space, in fact very large in this case. It's a pseudo file system which allow you store any kind of data.
And finally there is the option of application cache using manifest files and off-line storage. You can download the assets and define them using manifest files which makes them available to the app without having to consult server.
There are legacy mechanisms such as UserData in IE and of course cookies which probably has very limited use here and has it downsides such as being sent forth and back between server for every page request.
In general I would recommend web storage if the amount of data is low, or Indexed DB (Web SQL in browsers which do not support Indexed DB) for larger data. File system is cool but has little support as of yet.
Note: There is no guarantee the data will be stored on client permanently (user can choose directly or indirectly to clear stored data) so this must be taken into consideration.