Vad är Tillgångsrörledningen
mål
- förstå de 4 huvuddragen i tillgångsrörledningen.
- identifiera Tillgångsvägarna
- vet hur Tillgångsmanifestationer ger sammanslagning av CSS och JS.
- använd förbehandlingsspråk som Sass eller CoffeeScript
- Define Asset Fingerprinting
Outline
under lång tid behandlade vi JavaScript och CSS som en eftertanke vid utveckling av webbapplikationer. All vår tillgångskod-saker som bilder, stilmallar och Javascript — förvarades i en massiv mapp som heter public
och serverades utanför ramen för vår Rails-applikation. När webben utvecklades var det inte längre meningsfullt.
tillgångsrörledningen är skenans svar på hantering av formatmallar, JavaScript och bilder.
Tillgångsvägar
många filer går till att skapa webbapplikationer. CSS-och JavaScript-filerna ensamma kan vara svåra att organisera. Vilka mappar skapar vi? Vilka filer går vart? Tillgångsrörledningen ger ett svar på detta problem. Vi måste hålla saker väldigt organiserade i vår ansökan, men genom att hålla separata filer och mappar för varje koncept eller kodenhet har vi 2 problem.
- Hur vet skenor var saker är? Är Kalender JS-filen i
app/assets/javascripts/calendar.js
ellervendor/javascripts/calendar.js
? - vi vill inte servera varje fil separat eftersom det gör att vår sida laddas mycket långsamt. Det är vettigt för oss att behålla separata små filer för läsbarhet och organisation, men för webbläsaren skulle vi hellre krossa alla de små filerna tillsammans och ladda 1 JS-fil och 1 CSS-fil. Denna process kallas sammanfogning.
låt oss prata om vårt första problem: Hur vet skenor var de ska leta? Tillgångsrörledningen har ett koncept som kallas Tillgångsvägar för att hantera detta. Precis som i BASH där vi har en PATH-miljövariabel som är en kombination av mappvägar, är Tillgångsvägen en kombination av mappvägar för Rails att leta efter tillgångar i. Låt oss ta en titt på ett exempel på hur vår Tillgångsväg är konfigurerad.
Rails.application.config.assets.paths =>
om vi lägger en tillgång i någon av dessa mappar kan vi komma åt dem via URL ’/tillgångar’ i vår applikation. Om du har ytterligare mappar för Rails att söka kan du lägga till mapparna i Tillgångsvägen. Detta görs i filen config/initializers/assets.rb
.
Rails.application.config.assets.paths << "New Path"
vi kan placera tillgångar var som helst, konfigurera vår Tillgångsväg och komma åt dem via en enda ’/tillgångar’ URL.
manifest och sammanfogning
nu när vi kan lägga filer var som helst, Hur får vi dem att inkluderas på våra webbsidor? Tillgångsrörledningen använder en manifest-fil för att berätta för Rails vad som ska laddas. Denna manifest-fil är en central plats där vi kan lista alla CSS-och JS-filer som vår applikation behöver. Detta är inte en funktion i JS eller CSS utan snarare tillgångsrörledningen. Här är ett exempel på hur vår JS manifest-fil ser ut:
fil: app/assets/Javascript/application.js
//= require jquery//= require calendar
när du inkluderar manifest-filen i din layout med javascript_include_tag
kommer tillgångsrörledningen att leta efter alla filer som anges i Tillgångsvägen. Lägg märke till hur vi behöver kalender. Den här filen lever i app/assets/javascripts/calendar.js
, men vi angav bara namnet och inte hela sökvägen. Tillgångsrörledningen söker efter alla konfigurerade sökvägar efter en fil med namnet vi tillhandahöll.
nu när vi löste frågan om upptäckbarhet, låt oss prata om sammankoppling. Som vi diskuterade tidigare vill vi inte ladda våra filer i webbläsaren en efter en. Det är bättre att utföra en nedladdning än en massa små nedladdningar från vår webbläsare. De manifest-filer Vi konfigurerar i Rails kommer automatiskt att sammanfoga filerna som anges i dem till en fil i produktion. Det här kanske inte är det bästa alternativet när vi utvecklar vår applikation eftersom det kan göra felsökning svårt. Rails kommer dock faktiskt att betjäna varje fil separat när vi kör i utvecklingsläge. Inget behov av att göra någonting.
slutligen kommer kedjedirektiven som driver våra tillgångsmanifestationer att behandlas i detalj senare.
förbehandling
att kunna kombinera filer och ladda dem från en uppsättning fördefinierade platser i vår applikation är en stor fördel med Tillgångsrörledningen. Det är bara början. Eftersom vi laddar tillgångar genom skenor kan vi förbehandla filerna med populära språk som SCSS för att skriva bättre CSS och Coffeescript för renare JS. Om du gör en tillgång som heter Tema.css.scss, du berättar för tillgångsrörledningen att köra filen via SCSS-förprocessorn innan du serverar tema.css till webbläsaren. SCSS-förprocessorn sammanställer filen till CSS. Det enda vi behövde göra var att tillhandahålla rätt filtillägg, .scss
, till filen och tillgångsrörledningen vet att köra den genom SCSS-förprocessorn.
fingeravtryck
den sista fördelen vi kommer att prata om är fingeravtryck, men först låt oss prata om problemet det hjälper oss att lösa. När vi serverar filer till webbläsaren kommer de sannolikt att cachas för att undvika att ladda ner dem igen i framtiden. Vad är caching du kanske frågar?
Caching något innebär att hålla en kopia av en tidskrävande operation lokalt så att du inte behöver göra om den dyra operationen igen om ingångarna och utgångarna kommer att vara exakt samma. Cachar är vanligtvis viktiga värdebutiker, där värdet är svaret på den dyra operationen och nyckeln är något som är unikt för det objektet. Om du begär en sida från servern och sedan begär samma sida från servern igen, är det snabbaste sättet att få den begäran uppfylld att faktiskt behålla en kopia av vad du fick förra gången lokalt. Webbläsare cache massor av de svar de får på förfrågningar de har gjort med hjälp av rubriker som får skickas med svaret. Rubrikerna berättar för webbläsaren hur länge sidan förblir ’färsk’ innan den ’löper ut.’När sidan har gått ut kommer webbläsaren att göra en ny begäran om att sidan ska uppdatera sin cache. Vi säger att den snabbaste begäran är begäran som inte görs. Det sägs också ofta att cache-ogiltigförklaring är ett av de två hårda problemen inom datavetenskap, så tänk noga när du börjar cacha saker! Caching sparar bandbredd för oss och ger en hastighetsökning för användaren. Det här är bra tills du ändrar filen och du vill att alla dina användare ska få den nya istället för den gamla versionen som de har lagrat i webbläsarens cache. Men hur låter vi webbläsaren veta att vi har ändrat filen? Om den nya versionen har samma namn som den gamla versionen fortsätter webbläsaren att använda den gamla filen från cachen. Vi behöver ett sätt att ändra filnamnet när innehållet ändras så att webbläsare inte fortsätter att betjäna den gamla filen.
från Rails Guides Primer
”fingeravtryck är en teknik som gör namnet på ett filnamn beroende av innehållet i filen. När filinnehållet ändras ändras också filnamnet. För innehåll som är statiskt eller sällan ändrat, ger detta ett enkelt sätt att berätta om två versioner av en fil är identiska, även över olika servrar eller distributionsdatum.
när ett filnamn är unikt och baserat på dess innehåll kan HTTP-rubriker ställas in för att uppmuntra cachar överallt (antingen på CDn, på Internetleverantörer, i nätverksutrustning eller i webbläsare) att behålla sin egen kopia av innehållet. När innehållet uppdateras ändras fingeravtrycket. Detta gör att fjärrklienterna begär en ny kopia av innehållet. Detta kallas cache busting.
tekniken kedjehjul använder för fingeravtryck är att lägga till en hash av innehållet till slutet av filnamnet. Ta till exempel en CSS-fil med namnet global.css
. Kedjehjul lägger till hash 908e25f4bf641868d8683022a5b62f54
i slutet av filnamnet som så:
global-908e25f4bf641868d8683022a5b62f54.css
om du råkar använda en äldre version av Rails (Rails 2.X), brukade strategin vara att lägga till en datumbaserad frågesträng till varje tillgång som är kopplad till en inbyggd hjälpare. Detta såg ut så:
global.css?1309495796
frågesträngsstrategin har flera nackdelar:
- inte alla cachar kommer tillförlitligt cache innehåll där filnamnet bara skiljer sig från frågeparametrar.
- Steve Souders rekommenderar ”att undvika en querystring för cacheable resurser.”5-20% av dina förfrågningar kommer inte att cachas. Frågesträngar i synnerhet fungerar inte alls med vissa CDN för cache-ogiltigförklaring.
- filnamnet kan ändras mellan noder i flera servermiljöer.
- standard frågesträngen i Rails 2.x är baserat på modifieringstiden för filerna. När resurser distribueras till ett kluster finns det ingen garanti för att tidsstämplarna kommer att vara desamma, vilket resulterar i att olika värden används beroende på vilken server som hanterar begäran.
- för mycket cache ogiltigförklaring.
- när statiska tillgångar distribueras med varje ny version av kod ändras mtime (tid för senaste ändring) av alla dessa filer, vilket tvingar alla fjärrklienter att hämta dem igen, även om innehållet i dessa tillgångar inte har ändrats.
fingeravtryck åtgärdar alla dessa problem genom att se till att filnamn är konsekventa baserat på deras innehåll.
fingeravtryck är aktiverat som standard för produktion och inaktiverat för alla andra miljöer. Du kan aktivera eller inaktivera den i din konfiguration via alternativet config.assets.digest
.”
slutsats
Tillgångsrörledningen är definitivt mer komplex än att bara betjäna tillgångar från en offentlig mapp och det kan vara svårt att felsöka. Att lära sig att använda det kommer att löna sig på lång sikt genom att spara tid och huvudvärk. Tänk bara på alla problem det löser för oss.
- Tillgångsvägar
- manifest och sammanfogning
- förbehandling
- fingeravtryck
slutligen, definitivt kolla in keynote där DHH introducerar tillgångsrörledningen.