I was thinking about a better system to deal with assets generated by asset-pipeline
, caching and performance for using it in production.
From all your considerations and decisions you made, it seems to me, that performance in production environments is really important to you.
I was listening to Laravel.io Podcast #3 where Taylor, Eric and Ryan were talking about packages that aim to make your life easier while dealing with assets.
Many people, like Taylor himself, stick with using tools like grunt, CodeKit or guard.
These tools are easy to set up, because they just compile the assets to vanilla js/css sitting in your public directory. You can leave the worry about serving them to your webserver. There will be no cost booting up Laravel just to get correct Routing going.
I can see downsides using one of the above methods in
- losing the flexibility of manifest files
- losing the ability to write your own filters
- the need to set up and install yet another dependencies on every developer's machine
- having to check the compiled files into your SCM, or install the dependencies on the server as well. This means creating noise in your
git log
by committing the css file, whenever you change the tiniest partial file.
So how about doing it a little different:
In Development
http://foo.dev/assets/some.css
still gets served by your Controller. If no app/assets/stylesheets/some.css
exists, it will look for app/assets/stylesheets/some.css.scss
or app/assets/stylesheets/some.css.less
, compile it down to regular css and serve the output.
In Production
For production, the assets get precompiled. Running a php artisan assets:precompile
command would be part of the deployment process. It will save your compiled css/js files into public/assets/
. Your webserver will happily serve them "as is" โ no bootstrapping Laravel for assets anymore in production (where it really counts)!
That way, I think, there is no potential performance or scaling issue caused by this package (no more than by any other file generated by other tools/methods and served as static files by the webserver), while preserving the flexibility of manifest files, custom filters, and more.
Also, you won't have to install node or ruby on your servers and can keep your git history clean.
Lastly, you won't have to keep getting a headache about crazy caching methods. Your code affects fairly non-critical parts of the software development process (development, deployment), that can spare some milliseconds longer execution time.
Thoughts?