> 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
>>>> other app?
>>> You could use image_tag possibly.
>> 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.
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
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 post to this group, send email to firstname.lastname@example.org.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.