local memory storage publicURL and filename mismatch

[j12y]

I'm going to put this in as an issue based on our email thread and what I think might be happening.

We have a content service running with in-memory storage rather than remote cloud files storage.

A call to GET /assets returns a dictionary of items such as...

{
'src_path_img_filename_ext': '/__local_asset__/filename_random_string.ext'
...
}

The problem is GET /__local_asset__/filename_random_string.ext is not found and returns a ResourceNotFound error.

It looks like in src/storage/memory.js assetURLPrefix is prepended to form the publicURL.

A request to GET /assets/filename_random_string.ext does return the expected asset.

[j12y]

I forked the repos to take a stab at it. On the surface it seems like I could simply replace /local_asset/ with /assets/ as the MemoryStorage.prototype.assetURLPrefix but there might be more going on than I see just yet. I started a new instance of the content-service to play around and see what other ramifications might come of that.

[smashwilson]

Oh, hey. The generated /__local_asset__/ URL is built that way to be used by the local client. The client manufactures artificial content mapping files based on the control repository that you're building against (so that its presenter can render pages even if your content repository isn't mapped in the real control repository yet). Part of the generated mapping file includes a proxy mapping that proxies /__local_asset/ to the content service container.

Now that I'm writing this out, though, it seems pretty silly. A better approach would be to have the memory storage just generate asset URLs that link to the asset on the content service directly.

On the surface it seems like I could simply replace /local_asset/ with /assets/ as the MemoryStorage.prototype.assetURLPrefix but there might be more going on than I see just yet.

It's not quite that simple but it's close! The assets are served from the content service but the page content is served from the presenter, so the asset URL can't just be a relative one. You'll need to add a CONTENT_STORE_URL configuration setting to the content service (so it knows the address even if it's behind a load-balancer, nginx, etc) and URL-join it with the /assets/ path.

[j12y]

Ah, thanks for the additional context Ash.

There are several options then. In addition to proxying /local_assets/ to http://content-service:9000/assets/ from nexus-control config/content.json, another easy work around is to just use remote storage with cloud files. :)

[smashwilson]

[..] another easy work around is to just use remote storage with cloud files. :)

Haha, yep, that'll just give you CDN URLs 😉