I'm setting up the back end for an Android/iOS app that, among other things, allows users to share an image via Twitter. It's hosted on Heroku, which has no local image hosting, so the images are hosted elsewhere.
It looks like if you want to tweet an image you're supposed to POST to /statuses/update_with_media and send the image as multi-part data. But I don't have the images stored locally, so I would have to copy the image over to temp storage on Heroku, POST it to Twitter, and then delete it, which seems... inefficient.
Is there any way I can use Twitter's API to tweet an image and only supply the URL for the image?
It does not look like it's possible to send Twitter a link via their API, presumably because they would then have to download the image themselves. You could upload the image to a third party and link to that, but you have the same problem in that case.
You shouldn't need to copy the file over as such though, you could read the file into memory and serialize it to multi-part form data in order to send to Twitter.
Do you have any code to show?
Related
I'd like to implement uploading a profile picture for users. I'm using a VueJs frontend with a Rails API. What I'm trying to do is upload the image only using the frontend. I'd like for the file to get uploaded without any calls API calls. I could then store the location of the file in the picture attribute in the backend and retrieve it. Is that possible? I'm also using Element library.
<el-upload :http-request="addAttachment">
<el-button size="small" type="primary">Click Upload</el-button>
</el-upload>```
What you are looking at is called,
direct uploads or browser based uploads.
There should be support from storage service you are using.
Example: using S3 and GCS it is possible.
Upload without any API calls? -
Not sure, I once had to make a small API call to get the signature key and use it with POST params to upload file to storage service(GCS)
Once the API response is returned, you then might want to write to db about the file path.
I am working on a project where the user joins a "stream". During stream setup, the person who is creating the stream (the stream creator) can choose to either:
Upload all photos added to the stream by members to our hosting solution (S3)
Upload all photos added to the stream by members to the stream creator's own Dropbox authenticated folder
In the future I would like to add more storage providers (such as Drive, Onesky etc)
There is a couple of different questions I have in regards to how to solve this.
What should the structure be in the database for photos? I currently only have photo_url, but that won't be easy to manage from a data perspective with pre-signed urls and when there are different ways a photo can be uploaded (s3, dropbox etc.)
How should the access tokens for each storage provider be stored? Remember that only the stream creator's access_token will be stored and everyone who is on the stream will share that token when uploading photos
I will add iOS and web clients in the future that will do a direct upload to the storage provider and bypass the server to avoid a heavy load on the server
As far as database storage, your application should dictate the structure based on the interface that you present both to the user and to the stream.
If you have users upload a photo and they don't get to choose the URI, and you don't have any hierarchy within a stream, then I'd recommend storing just an ID and a stream_id in your main photo table.
So at a minimum you might have something looking like
create table photos(id integer primary key, stream_id integer references streams(id) not null);
But you probably also want description and other information that is independent of storage.
The streams table would have all the generic information about a stream, but would have a polymorphic association to a class dependent on the type of stream. So you could use that association to get an instance of S3Stream or DropBoxStream based on what actual stream was used.
That instance (also an ActiveRecord resource) could store the access key, and for things like dropbox, the path to the folder etc. In addition, that instance could provide methods to construct a URI given your Photo object.
If a particular technology needs to cache signed URIs, then say the S3Stream object could reference a S3SignedUrl model where the URIs are signed.
If it turns out that the signed URL code is similar between DropBox and S3, then perhaps you have a single SignedUrl model.
When you design the ios and android clients, it is critical that they are not given access to the stream owner's access tokens. Instead, you'll need to do all the signing inside your server app. You wouldn't want a compromise of a device to lead to exposing the access token creating billing problems as well as privacy exposures.
Hope this helps.
we setup a lot of rails applications with different kind of file storages behind it.
Yes, just an url is not manageable in the future. To save a lot of time you could use gems like carrierwave or paperclip. They handle all the thumbnail generation and file validation. One approach is, that you could upload the file from the client directly to S3 or Dropbox to a tmp folder and just tell your Rails App "Hey, here is the url of a new upload file" and paperclip and carrierwave will take care of the thumbnail generation and storaging. (Example for paperclip)
Don't know exactly how your stream works, so I cannot give a good answer to this -.-
With the setup I mentioned in 1. you should upload form your different clients directly to S3 or Dropbox etc. and after uploading, the client tells the Rails Backend that it should import the file from that url. (And before paperclip or carrierwave finish their processing you could use the tmp url from the file to display something directly in your stream)
Is it possible to use carrier wave to upload directly to amazon's S3 without using my server?
What i mean is, I don't want the images first going to my ec2 instance, and then uploaded to s3. I believe there is a way to upload directly to S3 to save my server's resources from having to process/stream the file.
I am just looking into carierwave, does it support nice html5 uploads where the user can just drag and drop the file on the web page?
If you want to upload directly to S3 from the browser you must do it with Javascript.
Heroku provides a nice tutorial : https://devcenter.heroku.com/articles/direct-to-s3-image-uploads-in-rails
Once uploaded, you can pass the finale S3 public URL of the image in a hidden field and download it server-side with carrierwave for further manipulation (resizing, ...)
I'm trying to make an app where I take pictures from users add them to a canvas, draw stuff in them, then convert them to a base64 string and upload them.
For this purpose I'm considering the possibility to use a cdn but can't find information on what I can upload to them and how the client side uploading works. I'd like to be able to send the image as base64 and the name to be given to the file, so that when it arrives to the origin cdn, the base64 image is decoded and saved under the specified name (which I will add to the database on the server).Is this possible?Can I have some kind of save.php file on the origin cdn where I write my logic to save the file and to which I'll send XHR requests? Or how this whole thing work?I know this question may sound trivial but I'm looking for it for hours and still didn't find anything which explains in detail how the client side uploading work for CDNs.
CDNs usually do not provide such uploading service for client side, so you can not do it in this way.
Before I code this, I want to make sure that I go about it in the correct way. I have a mobile application that will send an image to the server through a JSON API, preferably as an attribute on the user (or whatever is being imaged).
My current idea is for the mobile application to send the image encoded in Base64, that way it can be included as text on the User resource API calls like so:
PUT "/users/1", {"image":"Base64EncodedImageString", "name":"Dan"}
But I've read that storing the image in Base64 will make the database too large too fast. So, my plan is to take that string, convert it to an image somehow (I'm sure it will have something to do with the Paperclip gem) and store it in the server's filesystem. The mobile app can then download those images directly through an image MIME type URL, which will be some URL tagged onto the user JSON:
{"name":"Dan", "image_url":"http://mysite.com/images/dan.png"}
Is this a sound idea?