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

Light cloning of templates #413

Closed

Conversation

dusdanig
Copy link

Currently we are serving templates which are re-loadable
asynchronously. There are also assets which are shared by the
templates and are accessible through an async read lock.

For rendering we need to register specific helpers which will alter
the response for each request. The solution would be to clone all
templates for each request. Then add the specific helpers for that
situation. This is not ideal, because cloning all templates is slow.

So by adding an Arc to Templates, they can be shared between all
handlers building responses. Cloning is somewhat lighter with this
change. It does break the get_templates call on registry.

The other solution I have thought of was to add a generic type to the
render call, which can be used by the helpers. This can then default
to () for common cases.

Third solution would be to separate the template management from the
registry of helpers. In that case the templates can be put into a
custom structure, and would aid custom reloading schemes. E.g. loading
of the templates and then add that to a second structure holding the
helpers, then render. The registry is a composition of these two
structures.

Asynchronous helpers would also fix this for us. But in the mean time
this would help.

Currently we are serving templates which are re-loadable
asynchronously.  There are also assets which are shared by the
templates and are accessible through an async read lock.

For rendering we need to register specific helpers which will alter
the response for each request. The solution would be to clone all
templates for each request.  Then add the specific helpers for that
situation. This is not ideal, because cloning all templates is slow.

So by adding an Arc to Templates, they can be shared between all
handlers building responses. Cloning is somewhat lighter with this
change. It does break the get_templates call on registry.

The other solution I have thought of was to add a generic type to the
render call, which can be used by the helpers. This can then default
to () for common cases.

Third solution would be to separate the template management from the
registry of helpers. In that case the templates can be put into a
custom structure, and would aid custom reloading schemes. E.g. loading
of the templates and then add that to a second structure holding the
helpers, then render.  The registry is a composition of these two
structures.

Asynchronous helpers would also fix this for us. But in the mean time
this would help.
@sunng87
Copy link
Owner

sunng87 commented Feb 13, 2021

While this patch is certainly acceptable, but I'm thinking about other solution for your case, to avoid making every reference in rust an Arc.

In the upcoming 4.0 release, we will have a dev_mode that load template from disk every time when it's accessed. We have a structure called TemplateSource to track where the template was loaded. It's pretty much like your solution 3. Currently TemplateSource is an internal mechanism for dev_mode only. I suggest you to use it for your case and make it public where needed.

@dusdanig dusdanig closed this Feb 16, 2021
@dusdanig
Copy link
Author

Thanks for taking the time to answer.

@sunng87
Copy link
Owner

sunng87 commented Feb 16, 2021

@dusdanig I attempted to make Source a public API in #415 and add a new API to registry for source registration. If it works, you can just implement your own Source, perhaps with some cache capability.

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 this pull request may close these issues.

None yet

2 participants