I use restful web server to store and retrieve data on mysql database in my server. with strings all work perfect.But What should I do with images ? should i store the image on database or should i send the image on the server with ftp and put the link of image on the database ?
An answer to this would depend on a lot of things. What your restful services do, what their interface is, how your server is configured, how the images are processed, how the images are returned by services, what your client does, etc...
One answer might be - you could uuencode or base64 encode your image and then send that string as the payload in your post method to your restful webservice.
Both work, but I would recommend against using FTP. Consider uploading the data, and then using some scripts to save the file.
Storing images in a database can be a good thing in some scenarios and a bad thing in others. The big advantage is that you only have one system to worry about, the big disadvantage is that the database grows larger and has to do more work. Of course, let's not forget that databases are easier to distribute than files, since they often have built-in mechanisms for that.
Related
I looking for the best way to upload an image from mobile phone to my server. I am currently using html5 to open the camera and take the picture, then I convert the file into a base64 string, then I send to the server, then save it in MongoDB.
I am expecting around 1000 to 1500 user request per day ( upload image ) , so I have the following question :
Is it a good way to do it?
Should I compress the base64, if yes how?
Should use a specific server to handle this task?
My backend is node express and the front end is ReactJS.
Thanks
It all depends on your situation. Reading and writing images from a cdn via i.e. streams is usually faster than reading and writing binary representations of images i.e. base64 from a database. However, your speed if reading from a cdn will obviously be effected by what service you use. Today, companies like Amazon can offer storage to a very cheap price so if you are not building a hobby app for like a student project you can usually afford it. Storing binary representation of images actually end up a little bit bigger in size than storing the image itself. You don't compress the base64, you compress the image before converting it. However, if you can't afford a storage account and if you know your users won't upload that many images it is usually enough to store binary representations of the images in a database. Mongo Atlas, for example, offers 512 mb for free on their database clusters. Dividing tasks of your app such as database requests and cdn services from your main application is usually a good choice if possible. This way you will divide the cpu, memory, etc. of your hardware and it will lead to faster reading and writing tasks for the user.
There are a lot of different modules for doing this in node. JIMP is a pretty nice one with loads of built in functions like resizing images and converting them to binary, either as Buffer or base64.
I must provide a solution where user can upload files and they must be stored together with some metadata, and this may grow really big.
Access to these files must be controlled, so they want me to just store them in DB BLOBs, but I fear PostgreSQL won't handle it properly over time.
My first idea was use some NoSQL DB solution, but I couldn't find any that would replace a good RDBMS and elegantly store files together. Then I thought on just saving these files in HD somewhere WebServer won't serve them, name them their table ID, and just load them on RAM and print them with proper content-type.
Could anyone suggest me any better solution for this?
I had the requirement to store many images (with some meta data) and allow controlled access to them, here is what I did.
To the cloud™
I save the image files in Amazon S3. My local database holds the metadata with the S3 location of the file as one column. When an authenticated and authorized user needs to see the file they hit a URL in my system (where the authentication and authorization checks occur) which then generates a pre-signed, expiring URL for the image and sends a redirect back to the browser. The browser is then able to load the image for a given amount of time (as specified in the signature within the URL.)
With this solution I have user level access to the resources and I don't have to store them as BLOBs or anything like that which may grow unwieldy over time. I also don't use MY bandwidth to stream the files to the client and get cheap, redundant storage for them. Obviously the suitability of this solution will depend on the nature of the binary files you are looking to store and your level of trust in Amazon. The world doesn't end if there is a slip and someone sees an image from my system they shouldn't. YMMV.
our devices (microscopes with cameras) produce images and additional information to each image.
Now a middleware supplies wants to connect these devices to lab automation system. They have to acquire the data and we have to provide it. An astonishing thing for me was their interface suggestion - a very cryptical token separated format (ASTM E1394-97). Unfortunatelly, they even can't accomodate images in their protocol, and are aiming to get file-paths.
I thought it is not the up-to date approach. While lookink for alternatives, I saw CoachDB.
So, my idea was, our devices would import data including images in CoachDB and they could get the data. It seems even, that using mustache, we could produce the format they want (ascii-text) and placing URLs as image references instead of path's.
My question is, did someone applied CoachDB for such a use case already? It seems to be a little-bit misuse of CoachDB, as the main intention is interface not data storage. Another point disturbing me is, that the inventor of CoachDB went to other project Coachbase. Could it mean lack of support for CoachDB in the future?
Thank you very much for any insights and suggestions!
It's ok use-case and actually we're using CouchDB in such way - as proxing middleware between medical laboratory analyzers and LIS. Some of them publish images or pdf data on shared folders and we'd just loading them into related document as attachments.
More over you'd like to know, CouchDB is able to serve external processes (aka os_daemons) and take care about their lifespan: restarting if someone had terminated and starting right after you update config options through HTTP interface. This helps to setup ASTM client and server processes since this protocol is different from HTTP (which is native for CouchDB) which communicates with devices and creates documents as regular CouchDB clients. In same way you may setup daemons to monitor shared folders for specific files. And all this is just CouchDB with few "low bounded" plugins.
I have a task at hand to create a iphone app which is required to do the following.
the app should get the data entered by the user and store it into a remote server database.
other app user can see the data in the remote database.
store login information of the user using the app so as to keep track of what information as uploaded and by who
the thing that i would like to know.
1) What SQL server database is best to accomplish the task.
2) what format is best to retrieve the information from the database.
3) how to send the data from the iphone to the remover server database to it can store the data.
i read up on SQLite and found out that this particular database is a offline which stores the data locally so it cannot be viewed by other used. i wan to use a SQL database which can be accessed remotely.
1) What SQL server database is best to accomplish the task.
For implementation on server side, you can implement any server database, it does not matter. For implementation on iphone device, you have to implement SQLite database, which will provide storage locally.
2) what format is best to retrieve the information from the database.
You can retrieve data using XML or JSON format which will be parsed in device and can be stored in SQLite database, it is the easiest way to transfer data between client and server.
3) how to send the data from the iphone to the remover server database to it can store the data.
You can send data from iphone to server in XML/JSON format or by passing parameters in POST or GET request method then this format is parsed on server side and store data on server database.
For all this, you will require to implement API on server side, which will be the interface between server and device.
I know you mention SQL specifically, but is this a requirement or just a choice based on what most other people are doing? I ask because personally I would give serious thought to using a NoSQL database (document store) like couchdb for such a task. Deploying couch means you often don't need server side application layer at all, the way you will for a SQL based solution.
You talk to couch using HTTP which is perfectly suited to the ASIHTTPRequest library for example. Fetching data is usually a GET request and storing documents is done with PUT. All the data in or out comes back as JSON so a good JSON library will make life easier.
The combination of couchdb and the 2 libraries linked above, makes developing a data driven application really, really easy.
That's how I would do it ...
If you really need to stick with SQL, then as Jignesh says, use whatever database you like and implement a suitable API in the server side language of your choice. You can transfer the data however you like although JSON would still get my vote as a relatively light protocol that remains human readable.
You can use a cloud-enabled database service, like windows azure.
Working on an app where all the contents/data for it will be coming via JSON and occasionally i will display a HTML page.
The client is suggesting that maybe we should have some local database(MYSQL Lite) to cache the JSON data returned so we use less of the users data(if there search for the same item again) allowance and because it maybe slightly faster.
Are these good enough reasons for adding the extra complexity and potential problems of having a local DB on the phone?
I didn't think from my experience that the phone was particularly slow or that JSON or HTML were data heavy in there data usage. I'd prefer having a thin client.
Facebook/Twitter/etc work with very little problems using JSON and Html.
Would I be wrong to try steer away from the local DB idea?
Thanks,
-Code
Caching url request results can improve your application's latency over a slow connexion. You could use CoreData to manually manage a cache (key:url, value:request's answer)
Another more elegant solution would be (if you have write access to the webservices) to implement server-side the "if-modified-since" header so that your request data received would be kept at a minimum level.