Using shins in AWS lambda
Closed this issue · 2 comments
Hello!
I have case where we have lot's of different API products, all having their own slate-doc file.
Because all those API's / slate-docs have different maintainers, we are currently experimenting in storing those slate-docs to Contentful, and then generating slate-html when requested. (and obviously caching the result for next requests)
I tried to use AWS Lambda and shins for that, but it failed somewhat miserably because shins tries to modify files under node_modules/shins/* , which is read-only filesystem on lambda.
Some options to fix this came to my mind:
- Could shins be modified so it could create it's files to /tmp instead of node_modules/shins dir ?
- Could we generate those files during npm install (of our app), and then shins would not try to regenerate files because they exist already ? Or do those files change for every slate-doc ?
I undestand that this may not be very common usecase, but would either of those solutions be acceptable for Shins ? Or perhaps there is a better solution ?
I would of course be willing to create PR for this.
*) It tried to write to atleast /var/task/node_modules/shins/pub/js/shins.js
I think an option to override the default output directory would be useful. It might be time to move to a proper arguments parsing library like yargs. Very happy to work with you on a PR for this.
One other thing worth looking at might be shinola - if you cache everything else (css and js) all that needs to change for each API is the html file.
So I investigated this a bit more, and it seems that inlining CSS, JS and images could be the best solution. I created PR to show case that.
This way there is no need create new files, and output html will be self containing, which works great, for my use case atleast.
Fonts are still loaded externally, and I don't think that will be easy to change.
But that is not problem for my case, as we will override lot of CSS anyway.