Writing code to dynamically load and render theme code or calling theme rendering via an API.
It probably also needs to allow.
Attaching assets from theme code
Distributing themes as node modules
Building themes with webpack.
I think the interface to themes should either be a file system with known structure or a lambda function responding to api calls / events. The lambda API would allow for massive flexibility but could add a lot of latency to rendering.
I can see how this would work for html rendering but processing assets and referencing them in templates with the right urls makes this trickier. I guess the theme webpack could run at theme build time so the asset urls are known when the blog is rendered.
In this scenario the theme is responsible for deploying assets at build time which is when they change. The theme would be its own Javascript project that would install a base theme node module that would provide helpers, default theme methods and theme management commands including a seehund-theme deploy --bucket target-assets-bucket command which packages assets and deploys the theme lambdas.
Rendering is via an API so:
POST /render-index {settings, posts}
POST /render-post {settings, post}
These endpoints return html to the blog engine which is responsible for uploading rendered pages to the S3 bucket.
The theme only needs IAM permissions to build its own lambdas and upload assets to the web bucket. It could export its assets somehow and there's definitely a path here for a theme to be a third-party managed service so you could try different themes without installing anything.
This is a tricky one it requires.
It probably also needs to allow.
I think the interface to themes should either be a file system with known structure or a lambda function responding to api calls / events. The lambda API would allow for massive flexibility but could add a lot of latency to rendering.
I can see how this would work for html rendering but processing assets and referencing them in templates with the right urls makes this trickier. I guess the theme webpack could run at theme build time so the asset urls are known when the blog is rendered.
In this scenario the theme is responsible for deploying assets at build time which is when they change. The theme would be its own Javascript project that would install a base theme node module that would provide helpers, default theme methods and theme management commands including a
seehund-theme deploy --bucket target-assets-bucketcommand which packages assets and deploys the theme lambdas.Rendering is via an API so:
POST /render-index {settings, posts}POST /render-post {settings, post}These endpoints return html to the blog engine which is responsible for uploading rendered pages to the S3 bucket.
The theme only needs IAM permissions to build its own lambdas and upload assets to the web bucket. It could export its assets somehow and there's definitely a path here for a theme to be a third-party managed service so you could try different themes without installing anything.