zooniverse / scribeAPI

scribe API
MIT License
79 stars 25 forks source link

precompile custom styles and JS #440

Closed camallen closed 8 years ago

camallen commented 8 years ago

any reason not to precompile the custom JS and stylesheets instead of rendering them in the request / response cycle? Do they change between reqeusts?

image

nonword commented 8 years ago

Do you mean to ask why the custom js and stylesheets aren't automatically included in the precompiled application.js and application.css respectively?

The asset:precompile is currently fired once on deploy for our projects. In order to fold in custom js/css, a current project would have to be saved in the db at the point of precompile; That's not necessarily true at the time of deploy (i.e. the first time). Also, a database may hold multiple projects, so any time a project is activated, we'd have to re-run asset:precompile to fold in the custom js/css.

That said, I really want to reduce http, so if you have suggestions, I'm open. Thanks!

camallen commented 8 years ago

Yeah the idea is to precompile the required files instead of rendering them server side every time (though a fragment cache here will help too). Perhaps a rake task to create the /projects_id.{ext} asset so you can override the required project or create them all and then reference the correct one in the front end on page load.

I'm not au fait with the specifics of how you're projects load / work but if the resulting content is static then it can be served via a static file via the web server and you can free up the rails app to serving dynamic content.

nonword commented 8 years ago

In the current build, custom.js and styles.css are assumed to be plain Javascript and CSS respectively, so no server-side compilation is necessary. Those files are served as-is directly from the project's asset folder (e.g. /project/anzac/assets/custom.js) via ActionDispatch::Static, which is prioritized immediately after the default ActionDispatch serving /public. See https://github.com/zooniverse/scribeAPI/blob/master/config/initializers/register_project_static_routes.rb In effect, I believe these static assets are served with as little overhead as possible without copying them into /public or serving them from another server. Does that reduce your concern, or do you still think we should copy these assets into /public? Thanks

camallen commented 8 years ago

ah right, my misunderstanding, I thought you were rendering these server side.

I think you should run your app behind a http proxy(nginx) and serve these static public / asset files via that web server to free up the rails puma processes for dynamic queries. Might complicate your deployment process though.