> > 2014-11-11 16:42 GMT+01:00 John Anderson <[email protected]>: > >> > >> 2014-10-28 15:51 GMT+01:00 Sascha Gottfried > >> <[email protected]>: > >> > This is the announcement of the package from the author... > >> > http://blog.startifact.com/posts/announcing-bowerstatic.html > >> > > >> > > >> > On Tue, Oct 28, 2014 at 11:16 AM, Sascha Gottfried > >> > <[email protected]> wrote: > >> >> > >> >> Today I found bowerstatic, successor of fanstatic, and want to > >> >> highlight > >> >> the history page of the docs. It is a great introduction into the > topic > >> >> and > >> >> gives answers to some questions found in this thread. > >> >> > >> >> Bowerstatic@readthedocs - History > > > > > > On Wed, Nov 5, 2014 at 2:07 PM, Marc Rijken <[email protected]> wrote: > >> > >> I have made an integration of bowerstatic in Pyramid: > >> https://github.com/mrijken/pyramid_bowerstatic > >> > >> It is not released yet, because it will need some testing first. > >> > >> Marc > > > > > > > > Bower is a package manager, not as asset pipeline (bundler) system. In my > > experience getting the static assets that are required for my development > > and serving them isn't the important part. I don't see many people > actually > > serving static assets from their WSGI application outside of > development, at > > a minimum we use something like nginx to serve them and majority of the > time > > we have them deployed to a CDN like fastly or akamai instead. > > > > The important part of tools like webassets is that they can take a > related > > list of assets (backbone, underscore, and zepto for example) and in > develop > > serve them statically but for prod/deployment collect those static > assets, > > minify them into a single file, and push them up to a CDN and generate > the > > URL for the CDN. > > > > As an example, if I declare the following bundle in my code: > > > > Bundle( > > 'js/zepto.js', > > 'js/underscore.js', > > 'js/backbone.js' > > ) > > > > in development I want to see 3 static assets declare: > > > > <script src="/static/js/zepto.js"> > > <script src="/static/js/underscore.js"> > > <script src="/static/js/backbone.js"> > > > > but when I'm deploying to production I want to say "collect my static > assets > > and minify them" so that I can copy them up to my CDN, and then I expect > a > > single URL in production: > > > > <script src="http://fastly.com/sontek/static/compiled_bundle.js";> > > > > My WSGI application will not have access to a javascript minifier or css > > minifier and it wont be serving any static assets itself. > > > > Do you have a flow that solves this using bower + grunt, or are you > shipping > > to production having your application server also serve up your static > > assets? > > > > - John > > > On Tue, Nov 11, 2014 at 8:11 AM, Marc Rijken <[email protected]> wrote:
> My WSGI apps are serving the static assets. So there is no difference > in serving static assets between development and production. > > I do use http://www.cloudvps.com/openstack/cdn-acceleration/, which is > a CDN which gets the assets from my apps. So my app serve the static > assets but only a small number of requests are actually served > directly by the app. > > Note: minifying and bundling is not implement by bowerstatic yet. When > bowerstatic can do that automatically in the near future, static > assets are hassle free. > > > I still don't think just putting it behind a CDN as a cache quite solves the asset deployment issue. Using the same domain as your application is going to pass around all the cookies for that domain on every static asset request. You have to be able to customize the root URL of static assets when it generates the URL in production. This is why you see things like twimg.com and yimg.com, or just applications using akamai URLs directly. It doesn't make much sense to use up application server workers (like gunicorn) to serve a CSS file, especially if you aren't using gevent because then you are going to have a static set of threads + processes that you've configured, especially since you rarely expose it directly and are usually sitting behind a proxy like nginx anyways. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
