Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prember / Multiple File Support #132

Open
evoactivity opened this issue Feb 1, 2022 · 2 comments · May be fixed by #147
Open

Prember / Multiple File Support #132

evoactivity opened this issue Feb 1, 2022 · 2 comments · May be fixed by #147

Comments

@evoactivity
Copy link

evoactivity commented Feb 1, 2022

Prember pre-renders routes into a static directory structure with index.html files at build time. I'd like to be able to use the lightning strategy for deployment and pre-render my static routes. This can be supported by grabbing the files from s3 as assets, but you lose the ability to effectively use revisions, uploading the html as assets using the s3 plugin means the index.html files will be overwritten as they are not fingerprinted. I would like to upload all the html into redis just as it stores the main ember index.html file to retain the ability to have revisions.

I've noticed in the past a PR was rejected, as a use case didn't really exist at the time and the suggestion of using the plugin multiple times as part of the pipeline was the correct advice. The past issues and pr were about uploading a single other file. An app may have tens or hundreds of static routes being prerended by prember so creating a plugin entry for each html file would be cumbersome, prone to error and not very scalable.

I'm creating this issue to spark at the least a discussion about if prembers rising popularity changes the conversation around supporting multiple file support and if it should be pursued as part of this plugin.

@evoactivity evoactivity changed the title Prember / Multiple FIle Support Prember / Multiple File Support Feb 1, 2022
@lukemelia
Copy link
Contributor

@evoactivity I'm open to the idea if we can come up with a way to do it that doesn't diminish usability for the primary use case for this plugin. Perhaps you can describe your proposed changes in this thread and we can discuss.

@evoactivity
Copy link
Author

evoactivity commented Feb 1, 2022

I think it could be acheived by using the filePattern as a glob and always expecting an array of files with 1 or more entries. Then in the plugin upload method loop over the list of files and upload each to redis. We would need to generate the file identifier for the key based on the file path. So if you have a prember file structure like so

dist/
├─ _empty.html
├─ index.html
├─ about/
│  └─  index.html
├─ privacy-policy/
│  └─  index.html

keys such as keyPrefix:_empty:revisionKey, keyPrefix:index:revisionKey, keyPrefix:about-index:revisionKey, keyPrefix:privacy-policy-index:revisionKey would be generated.

To activate a revision the redisClient.activate method would need to first search redis for all keys matching keyPrefix:*:revisionKey rather than looking for the single keyPrefix:revisionKey and then activate each of them.

This would allow the users server code to translate a route like domain.com/about/ to about-index and use that to return the correct html for that route by concatenating to keyPrefix:about-index:current, if it doesn't exist they can look up keyPrefix:_empty:current and let ember handle the routing client side.

I believe this can be done without breaking or changing current build pipelines. Currently the keyPrefix includes what I'm going to call the page identifier (index by default). To keep this change backwards compatable we could add a check if the keyPrefix passed in by the user includes a separator character (:, /, | etc) then we use the keyPrefix as is for the root index.html but for other files split it at the separator and only use the first part to generate the rest of the keys. That way if someone has their server fetching theirKey:homepage:current this won't break and their build will continue creating a theirKey:homepage entry.

It will be a while before I'm up to deployment on my current project but I can take a look at an initial PR when I get to it.

@evoactivity evoactivity linked a pull request Sep 1, 2023 that will close this issue
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants