> On Aug 11, 2017, at 2:34 AM, Colin Law <clan...@gmail.com> wrote:
> On 10 August 2017 at 13:36, fugee ohu <fugee...@gmail.com> wrote:
>> On Thursday, August 10, 2017 at 3:01:06 AM UTC-4, Colin Law wrote:
>>> On 10 August 2017 at 07:50, fugee ohu <fuge...@gmail.com> wrote:
>>>> One of my apps drives the others and stores pictures that the others use
>>>> Both apps are on the same server How do i build a link to the image on
>>>> the
>>>> other app?
>>> You could use image_tag possibly.
>>> Colin
>> how do i get above / ?
> Good point, you will have to arrange the upload to save to a location
> visible to both servers, or accessible via another server, and do the
> download link manually.
> Colin

There's many ways to get this to work, and depending on how your server(s) 
is/are architected, some are more elegant than others.

In one application I built, there are three separate VPS hosts: database, 
admin, and public. Admin and public have the same NFS share mounted to each of 
them, with admin able to write to it, and public only able to read from it. The 
NFS share is defined in my file upload gem (Dragonfly) as the place where files 
are written. Dragonfly is somewhat unique in how it manages files (everything 
is proxied through a Rack app, never hosted directly through Apache/Nginx) so 
this means I don't have to have that NFS directory in the app's 
public/system/whatever path. But even if I wanted to allow direct httpd hosting 
of uploaded images, I could do that through the Apache configuration file, by 
aliasing a folder from /mount/nfs/share/whatever into public/system/images, for 
example. https://httpd.apache.org/docs/2.4/urlmapping.html#outside

So that's an extreme example, brought about by having these apps on different 
(quasi-physical) servers. If you were hosting them on different virtual hosts 
on the same server (real or virtual), then your task is a lot simpler. Forget 
about the NFS mounts, and just configure your Web server to include the same 
directory, as above, and ensure that only one app is writing into that folder, 
and both are sharing a single database, so that the apps don't get confused.

And I've completely overlooked S3 (or any of its various clones), which is sort 
of a giant share-point in the sky. If you use Fog or another cloud storage 
adapter, you can treat S3 as you would a local folder, and two or more servers 
can be configured to use the same S3 "bucket" at the same time. With UUID 
primary keys, you don't even need to coordinate the databases.

As far as building a link goes, my apps assume that only one app is doing the 
writing, and the other one is read-only, so they share a database. Building a 
link is in the normal Rails manner, based on an ID. But if you had two 
independent apps that didn't share anything, you would need to build a bridge 
between them. One could advertise the images it has available through an API, 
and the other could use that API to periodically update a local cache of what 
images are available, for example, and what their addresses are, and use those 
directly. You would build an image tag with the src set to 
//other.host.dom/path/to/image.jpg rather than pretending it was on your local 

In the end, your solution will depend entirely on what your needs are. In my 
example above, I needed to support a team of editors, who could write things 
and add metadata to them and approve them, and a largish audience who were 
read-only on the things that were complete and "published". You might get some 
more focused solutions for your problem if you can articulate why you have 
separated these concerns.


You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to