For an app (web + phone) there are two options:
Image binaries in database. Server replies to app HTTP request with images as base64
Images in storage service like Amazon S3 or Azure Blob Storage or a self-hosted one. Image links in database. Server handles app HTTP requests by sending back only the links to images. The app fetches the images from storage by their link
Which option above is the standard practice? Which one has less trouble down the road?
To some extent, the answer to this question is always opinion based, and partly depends on the specific use case.
I would think that the second approach is used more often. One reason is that normally, storage within a database is slightly more expensive than file storage in many cases. Also, what is the real use case? Assuming you use HTML pages that reference images via the img element or via CSS as background image, then the base64 return value would not be that useful, and OTOH the more complicated graphic at the bottom of your picture would get a bit more simple from the client view: The resolution of the link would be resolved by the server when generating the HTML and determine the src of the img, and then the browser would simply apply standard HTML logic and request the image data from the storage service via HTTP.
However, if you would want to optimize load times (and your images would be more or less unique per page so that browser caching of images across pages would not help much), then you could use data URLs embedded into the HTML, and then the first approach could potentially be useful. In this case, all the logic including the generation of the data URL within the HTML would be handled on the server, and the browser would have a single http request.
Related
I am writing a Swift iOS app that uses Blockfrost.io to download assets from the Cardano blockchain. The asset's images come in the format ipfs://QmSJPFVN..., which can be retrieved by using the URI in a CloudFlare URL, like this https://cloudflare-ipfs.com/ipfs/QmSJPFVN....
My issue is that most of the images I'm trying to fetch and display are enormous, and it's seriously slowing down my UI. Are there parameters that can be added to the URL to specify a smaller image size to be fetched? I've looked around for a solution but haven't been able to find any.
You have two options for this -
Use a 'proxy' to fetch the image server-side and convert before downloading. Could make use of a Cloudflare worker for instance - https://developers.cloudflare.com/images/image-resizing/resize-with-workers
Download the full size image, but convert it within your app before displaying it in the UI. You'll still use full amount of bandwidth in this approach, but may reduce complexity.
I want to upload large video file. for that i want to create firefox addon. Is this possible by create firefox addons to upload large files on my server.
or is there any other way to upload large files on server.
please suggest.
If you are POSTing the data to the server as application/x-www-form-urlencoded then you should base64 encode it using btoa() and include it as one of the POST parameters in the request body (i.e. the string passed to XMLHttpRequest.send()):
postbody = "body=" + btoa(fileContents);
xhr.send(postbody);
If you are just downloading the file and uploading it right away, you might as well keep it in memory since you're presumably going to load it into memory anyway in order to base64 encode the contents.
Well if you're reading the file into memory then you should need an nsIFile at all. You can just download it using XMLHttpRequest and use responseText, uploading it in the way I described in the answer. If you do have an nsIFile then yes, that snippet describes how to read from it.
I assume you are wanting to upload via HTTP.
If so, the upload limit is usually decided by the server-side software. This affects both the maximum size and the length of time you have to upload it.
Without a server capable of taking an upload in chunks and reassembling it, you are limited in ways you can't get around through software.
If you want to upload via FTP on the other hand, there are a lot of options... look at FireFTP.
I have made firefox addons for fileupload.
I integrate jquery file upload.
I create widget. In the widget I made panel. In panel I create separate web page for file uploading. And panel is calling that page.
For more information you can mail me at chetansinghal1988#gmail.com
I'm currently building a ASP.NET MVC 3-WebApp that handles lots of images, lets say up to 100 per page.
At the moment the WebApp itselfs serves the images. The reason is, I want to make sure that only authorized and logged on users can download the images. This approach suffers from performance, because on the one hand the Browsers loads the images sequentially, and on the other hand this scales not very well.
Therefore I would like to introduce a external WCF-WebService from another host, that serves the images and only the images. This works very well, but at the moment I have no idea how to make the Download-Url secure.
In my page from lets say "www.imageviewer.com" I would like to have many image tags like so:
[Image-Tag] Source="imageservice.imageviewer.com/Download/someID" [/Image-Tag]
I know I could send some encrypted security information within the Download Url, like UserID or other SecurityTokens and make some processing with that. But this would not prevent, that the User (or another User) can download the image in another Browser, without being logged on.
I would like to have a session-based solution. Only with a valid session after logging on to the WebApp the Browser should download the image from the WebService.
Any ideas how to solves this?
Are webservices the new regex?
Some people, when confronted with a problem, think "I know, I'll use a webservice". Now they have two problems.
Please describe in what way you think a webservice will make your images load faster? There will be more overhead (XML (un)packing, adding another layer of code), and since a webservice is not more or less an HTTP request than the thing your browser does when requesting an image you will still run into the browser's limit of connections.
A browser does not really sequentially load images, but rather does it at a rate of about two to eight at a time to the same domain.
Loading the images from different subdomains is a more common approach, and adding some lazy loading will speed it up even more. You can then still secure it, using information stored in your session, cookies or headers.
If you, on the other hand, just want an answer to your question and no friendly advice: you could simply secure your service with a Custom User Name and Password Validator, where you simply override the validator to validate against your known user credentials.
I wrote a script that uses the Google Images JSON API to automatically fetch thumbnails for posts. I'm currently linking directly to the thumbnail (eg. http://t3.gstatic.com/images?q=tbn:ANd9GcTok4m3DWNRv8gxMDTE0bwj8m-jYl2UGdlbc7ig158m0XosD-lcQEIFcg). Does Google allow that?
If not, I should be allowed to download the thumbnails to my server right?
Its all about traffic. If your app will make tons of traffic, they can ban your server.
Anyway, better/best way is to ask them about this subject.
Also this might help you : Google Terms of Service Highlights
I see problems when you download the image thumbnail to your server and render. Images shown in search results might be copyrighted/inappropriate. They are crawled images so the owner can request google to remove at anytime. On contrary, if you cache them locally and render, I see the workflow is broken and you might be rendering image that ideally should have been revoked.
Coming back to hot linking, can you explain bit more on the actual usage context. What API you are using, what are you searching at, do you own the website / posts that you are filtering?
Also image search API is deprecated one. By terms it would be active only for three years since notice.
I'm not sure how to word the question but here is what I am looking to do.
I have a site that uses custom map tile overlays on a google map.
The javascript calls a php file on my server that checks to see if an existing map tile exists for the given x, y, and zoom level.
If if exists, it displays that image using file_get_contents.
If it doesn't exist, it creates the new tile then displays it.
I would like to utilize Amazon S3 store and serve the images since there could end being a lot of them and my server is slow. If I have my script check to see if the image exists on amazon and then display it, I am guessing I am not getting the benefits of the speed and Amazons CDN. Is there a way to do this?
Or is there a way to try and pull the file from Amazon first then set up something on Amazon to redirect to my script if the files no there?
Maybe host the script on another of Amazons services? The tile generation is quite slow also in some cases.
Thanks
Ideas:
1 - Use CloudFront, but point it to a cluster of tile generation machines. This way, you can generate the tiles on demand, and any future requests are served right from Cloudfront.
2 - Use CloudFront, but back with with an S3 store of generated tiles. Turn on logging for the S3 bucket, so you can detect failed requests. Consume those logs on a schedule, and generate the missing tiles. This results in a cheaper way of generating tiles, but means that when a tile fails the user get's nothing.
3 - Just pre-generate all the tiles. Throw tasks in an SQS queue, then spin up a collection of EC2 instances to generate the tiles. This will cost the most up front, but all users get a fast experience.
I've written a blog post with a strategy for dealing with this. It's designed to make intelligent and thrifty use of CloudFront, maximize caching and deal with new versions of existing images. You may find the technique described there helpful. The example code shows how to handle different dimensions (i.e. thumbnails) of images. You could modify it to handle different zoom levels.
I need to update that post to support CloudFront custom origins, and I think that for your application you might be better off skipping S3 and using a custom origin. The advantage of a custom origin is simply that it's probably going to be easier to manage all of your images on your local filesystem compared to managing them on S3.