Jak jsem vytvořil webdesignrepo za 17 dní s JAMstackem

webdesignrepo – Nové odkazy na vývoj a design každý den. Plus sbírka užitečných odkazů.

Tady je návod, jak jsem to postavil za 17 dní. (Při pobytu v co největším počtu volných úrovní)

Rozhodování o zásobníku

webdesignrepo se skládá ze dvou věcí:

  • Velké úložiště špičkových odkazů, které slouží jako referenční bod pro návrháře a vývojáře, téměř jako velký seznam záložek.
  • Denní sekce odkazů, kde jsou zveřejňovány nové zajímavé články, výzkumy, projekty a zajímavosti. Zde jsou také zveřejňovány nové přírůstky do úložiště, s malou hvězdičkou, která ukazuje, že jsou speciální a že byly „uloženy“ do úložiště.

Takže vše, co jsem potřeboval, byl systém, kam bych mohl přidat tyto odkazy (a značky, ikony atd.) a web by se stavěl každý den. Spustit JAMstack nad objemnou databází se zdálo zbytečné.

Zásobník, na kterém jsem se usadil:

  • Gatsby (generátor statických stránek založený na React)
  • Sanity (úžasný bezhlavý CMS)
  • Netlify (hostování a sestavování kanálu)

To je pro web, ale také jsem používal Azure Functions, Sendy (e-maily) a raspberry pi, k těm kouskům se dostanu později.

Den 1 – Nastavení projektu

Vytvořil jsem dvě úložiště github, jedno pro frontend Gatsby a druhé pro Sanity the CMS.

Sanity je tak rychlý na nastavení rychlého schématu, přidal jsem základní typ dokumentu „Daily link“ a přidal nový dokument do svého CMS.

Gatsby se také rychle zprovozní, i když je potřeba odstranit několik standardních souborů, které nejsou potřeba.

Použil jsem plugin gatsby-source-sanity, abych začal stahovat data z CMS v době sestavování.

Sanity a Gatsby napsali články o tom, jak používat kombinaci společně, můžete je vidět zde:Gatsbyho průvodce a Příručka pro Sanity.

Už jsem natahoval data z CMS! Zde je to, co jsem měl na konci dne 1:

Den 2 – Uspořádání podle dnů

Každý den je zveřejněno 3-5 odkazů denně. Potřeboval jsem seřadit odkazy podle dne, abychom mohli zobrazit „pondělí – x, y, z“ a poté „úterý – a, b, c“ atd. Schéma pro tyto denní odkazy nyní vypadalo takto:

export default {
  title: 'New link',
  name: 'newLink',
  type: 'document',
  fields: [
    {
      title: 'Label',
      name: 'label',
      type: 'string',
      validation: (Rule) => Rule.required(),
    },
    {
      title: 'Link',
      name: 'link',
      type: 'string',
      validation: (Rule) => Rule.required(),
    },
    {
      title: 'Post date',
      name: 'postDate',
      type: 'date',
      validation: (Rule) => Rule.required(),
    },
    {
      title: 'Added to vault',
      name: 'addedToVault',
      type: 'boolean',
    },
  ],
}

addedToVault je, zda byl odkaz přidán také do repozitáře. Vault bylo hloupé slovo, které jsem použil na začátku a nikdy jsem se neobtěžoval změnit. Slovo vault používám zaměnitelně s odkazy na repo. Lituji toho a měl jsem to brzy změnit na repo.

Pro ty, kteří neviděli příčetnost, zde je to, co toto schéma znamená:

Takto to vypadalo uspořádané podle dne:

Pokračoval jsem v přidávání základního lešení, jak by úložiště odkazů mohlo vypadat. Znovu jsem nastavil základní schéma pro tyto odkazy na úložiště a natáhl data do Gatsby.

Příčetnost vás vybízí k tomu, abyste svá data rozdělili logicky, spíše než na základě toho, co se vizuálně objevuje v blízkosti jiných věcí. Je to zajímavé, jakmile se dostanete do tohoto myšlení, ale chvíli mi to trvalo.

Mám například samostatné typy dokumentů pro kategorie, podkategorie a odkazy na úložiště. Takže půjdete do CMS a přidáte novou kategorii jako Pluginy. Poté přidáte novou podkategorii, například Animace, která je propojena s nadřazenou kategorií pluginů. Poté přidáte odkaz na trezor, který je propojen s podkategorií Animace. Umožňuje přejmenovat, vyměnit nebo změnit jakoukoli část řetězce, aniž by to zasahovalo do zbytku.

Přidal jsem několik fiktivních odkazů na trezor a začal jsem stahovat data do frontendu. Také jsem přidal vyhledávací pole, ale nic to neudělalo.

Pokračoval jsem do večera, trochu jsem design vyčistil a posunul k tomu, jak jsem chtěl, aby vypadal:

Den 3 – CSS a odstranění budoucích příspěvků

Přidal jsem ještě více CSS:

Při přidávání denních odkazů je mohu naplánovat na den nebo dva v budoucnu. Potřeboval jsem tedy způsob, jak odstranit tyto budoucí příspěvky a zobrazit pouze odkazy z „dnes“ az minulosti. Zdá se to jako velmi jednoduchý koncept, ale ve skutečnosti jsem na této frontě narazil na několik problémů s Gatsbym.

Problém pochází od Gatsbyho, který umožňuje pouze statické dotazy v komponentách. Takže dotazování na data na základě data bylo mimo okno uvnitř komponent. Potřeboval jsem, aby můj dotaz graphql vypadal takto (s SERVER_DATE je něco jako 2020-12-25 ):

query loadNewLinksQuery {
      allSanityNewLink(
        sort: { fields: [postDate], order: DESC }
        filter: { postDate: { lte: "${SERVER_DATE}" } }
      )

Stránky v Gatsby fungují trochu jinak a nejsou statické stejným způsobem. Ale nemůžete použít ani literály šablony v dotazech na stránku 😞 Můžete můžete procházet proměnné dotazu prostřednictvím kontextu stránky, ale to mi přišlo trochu zbytečné, takže jsem v podstatě všechna volání API (do Sanity) prováděl v gatsby-node.js .

I když je nepříjemné, že nevolám data uvnitř komponent, nakonec jsem uvnitř gatsby-node.js udělal značné množství logiky po volání dat a jejich předání komponentám stránky, takže to začalo dávat větší smysl, jak jsem pokračoval. To znamená, že bych rád viděl, aby Gatsby povolil v komponentách doslovné dotazy šablony nebo proměnné dotazu.

Všechny odkazy jsem objednal podle data v gatsby-node .

Den 4 – Animace dnů a archivních stránek

S importovaným framer-motion (react animation library) jsem se pustil do animace přechodů mezi dny. Ve skutečnosti to trvalo mnohem déle, než se očekávalo, jak to u animací často bývá, jen dlouho trvá dolaďování, aby to vypadalo dokonale.

Později během dne jsem přidal archivní stránky. Ty jsou docela přímočaré. Chtěl jsem na domovské stránce zobrazit 7 dní, které by uživatel mohl prolistovat, a po 7 dnech je to přesměrovalo na archivní stránku, která na jedné stránce ukazovala 10–20 „denních“ odkazů, a uživatel se mohl vracet čas, kdyby chtěli.

Den 5 – Menší CSS

Den 5 byl docela pomalý den a já jsem se rychle podíval na to, jak by mohl vypadat styl pro repo sekci. To byla práce, kterou jsem odkládal a nechtěl jsem ji dělat, protože uspořádat obrovské množství dat, jako je tato, aby byla skenovatelná a čitelná, je docela obtížná konstrukční výzva.

Takhle to vypadalo na začátku:

Den 6 – stránka vyhledávání

Vyhledávací panel seděl v horní části stránky téměř po celou dobu vytváření tohoto a byl zcela k ničemu. Dnes byl den zazářit!

Funkce vyhledávání byla něco, o čem jsem věděl, že by ji nevyužilo mnoho uživatelů, ale byla by to obrovská pomoc pro tu část uživatelů, kteří ji používali. Tak jsem to postavil.

Nejprve jsem musel ke každému odkazu přidat značky. Věděl jsem, že pouhé vyhledávání prostřednictvím štítků/domén by bez značek nebylo tak užitečné. Takže každý odkaz repo a každý denní odkaz nyní přijímají řadu odkazů na dokumenty značek (čtěte:můžete přidat seznam značek). V kódu schématu Sanity to vypadá takto:

{
      title: 'Tags',
      name: 'tags',
      type: 'array',
      of: [
        {
          type: 'reference',
          to: [{ type: 'tag' }],
        },
      ],
      validation: (Rule) => Rule.required(),
    },

Každý dokument tagu měl pouze jedno pole:štítek.

Vytvořil jsem tedy spoustu značek, o kterých jsem věděl, že se budou hodně používat:'Javascript', 'React', 'CSS' a napadlo mě, že zbytek přidám, jak budu potřebovat.

S nastavenými značkami jsem začal vytvářet to, co mohu popsat pouze jako velmi rudimentární vyhledávací funkce. gatsby-node chytne každý . single . odkaz . spolu s jednotlivými značkami odkazů a předá je všechny do /search strana. Poté vyhledávací stránka zkontroluje URL na parametry a provede obří filtr.

Uživatel je tedy na domovské stránce. Do vyhledávacího vstupu napíše „animace reakce“ a stiskne Enter. Budou přesunuty do /search?terms=react,animation . Stránka vyhledávání extrahuje tyto hledané výrazy a poté filtruje obrovský seznam odkazů na těch několik, které tyto výrazy obsahují buď ve štítku, doméně nebo značkách odkazu.

To není skvělé řešení. Jsem si plně vědom a jak se stránka rozrůstá, toto řešení bude horší a horší. Takže během příštích pár měsíců to nějakým způsobem přestavím, ale zatím to funguje.

Jak můžete vidět níže, přidal jsem dokonce pole „Jak funguje vyhledávání“, abych lidem řekl, jak mizerné toto vyhledávání bylo.

Možná jste si v zápatí všimli také pole pro odběr newsletteru! Vlastně jsem přidal ten den 5 a ukazuje se to na několika místech.

Den 7-11 – Výměna Mailchimp

Ach, Mailchimp. Mailchimp je skvělý nástroj – ale je velmi drahý. Ve snaze udržet tuto přestavbu co nejzdarma, rozhodl jsem se zbavit Mailchimp jako svého zvoleného odesílatele newsletteru. Předtím jsem nashromáždil 2000 e-mailových odběratelů ze sledování webdesignrepo a potřeboval jsem levnější způsob, jak jim posílat všechny aktualizační e-maily. Představujeme Sendy.

Sendy je e-mailové řešení s vlastním hostitelem. Je založen na PHP (což neznám) a používá Amazon SES k odesílání e-mailů. Šel jsem se Sendy, protože je to jednorázová cena 59 USD. Těch 59 babek se mi vrátí do měsíce nebo dvou a pak budu posílat e-maily v podstatě zdarma.

Hostování Sendy se zdá být velmi snadné a pravděpodobně je, pokud jste běžným člověkem, který spustí kapku DigitalOcean, aby ji spustil na nebo na jakémkoli jiném serveru. Ale v šuplíku mi leželo Raspberry Pi Zero W, které jsem nikdy nepoužil, a usoudil jsem, že ho do toho dám. Jestli mě v této celé věci něco mrzí, je to tato část.

Ušetřím všechny detaily, ale v podstatě jsem narazil na tunu problémů. Toto není Chyba Sendy, bylo to kvůli tomu, že jsem to spustil na Pi z mé domácí sítě. Nikdy předtím jsem „nepřipojil zařízení k internetu“, což je divné říkat jako profesionální senior front-end vývojář, ale není to něco, co jsem dělal dříve. Vždy jsem používal cloudové servery.

Stačí říct, že jsem se během tohoto procesu naučil spoustu věcí o připojování zařízení k internetu. Pár věcí, na které jsem po dlouhém googlování přišel:

  • Pro své zařízení (druh) potřebujete statickou IP. A to tuzemští poskytovatelé internetu opravdu nenabízejí. Váš domácí internet mění svou IP poměrně často. Nastavil jsem tedy své Pi tak, aby bylo interně statické , takže ostatní zařízení ve stejné síti jej mohou vždy najít pod stejnou IP. Ale také potřebuje externí statickou IP, abych mohl nasměrovat foo.com na 123.111.222.333 a být si jistý, že se IP nezmění. Potřeboval jsem buď upgradovat na internet na podnikové úrovni pro statickou IP (to se nestane), nebo najít jiné řešení. Ukázalo se, že existuje jiný způsob! Mnoho poskytovatelů domén (nebo DNS) nabízí dynamické DNS. Jsem s namecheap a vše, co jsem musel udělat, bylo nastavit záznam A+ pro svou subdoménu a nasměrovat jej na IP mé sítě. Takže záznam A+ pro foo.webdesignrepo.com ukázal na 123.111.222.333. Namecheap má URL, na kterou můžete kliknout a aktualizovat IP tohoto záznamu A+. Takže jsem na svém Pi nastavil úlohu cron, abych každých 5 minut pingl na adresu URL namecheap, a pokud se IP mé sítě změnila, namecheap aktualizuje záznam A+. Skvělé!

  • Nyní jsem foo.webdesignrepo.com ukázal na IP mé sítě. Co se stane dál? Opět jsem se cítil trapně, že jsem to nevěděl, ale hej, bylo to skvělé učení. Jakmile budete mít doménu nasměrovanou na vaši síťovou IP, musíte tyto požadavky přeposlat na správnou interní IP. Nastavil jsem tedy na routeru přesměrování portů, abych přesunul provoz :80 na moje malinové pi (které má statickou interní IP).

  • Lokálně jsem testoval tlačítko pro přihlášení k odběru newsletteru a fungovalo to! Nové webdesignrepo bylo (tajně) hostováno na v4.webdesignrepo.com, tak jsem ho spustil a zkusil se přihlásit k odběru newsletteru, ale nepodařilo se. Přihlašovací pole na webu pouze pingne na foo.webdesignrepo.com a říká „Hej! [email protected] se chce zaregistrovat“. Problém pocházel z toho, že v4.webdesignrepo.com byl obsluhován přes HTTPS a instalace Sendy byla na HTTP (http://foo.webdesignrepo.com). Prohlížeč tedy požadavek zablokoval. Nebo server Sendy požadavek zablokoval. Jeden z těch dvou, upřímně si nepamatuji, co co blokovalo, ale pamatuji si, že to nefunguje. Potřeboval jsem tedy, aby se foo.webdesignrepo.com obsluhoval přes HTTPS. Použil jsem Let's Encrypt dříve, takže jsem si myslel, že bude snadné získat certifikát SSL. Ukázalo se, že Pi Zero W má s ním problémy kvůli omezené paměti RAM. Smůla. Po skoku přes milion obručí, aby Pi správně používal Lets Encrypt... při pokusu o registraci stále selhal. To byl můj nejnižší bod 😂 Upřímně jsem byl tak blízko přechodu na Mailchimp, v tuto chvíli jsem nad touto věcí strávil 3 nebo 4 dny a všechen ten čas jsem strávil procházením příspěvků na fóru a snažil se vyřešit problém za problémem. Po něčem, co mi připadalo jako věčnost, jsem narazil na odpověď a bylo to jednoduché. Výchozí port HTTPS je 443 🤦‍♂️ Nastavil jsem tedy přesměrování portu na 443 a co víte, všechno fungovalo.

V tuto chvíli mi všechno fungovalo se Sendy na mém Pi Zero W! Upřímně mi to trvalo celé dny a většinu z toho jsem nenáviděl, ale tolik jsem se z toho naučil.

Když bylo nastavení mimo cestu, mohl jsem začít pálit e-maily. Tak jsem spustil nové github repo s názvem 'webdesignrepo-newsletter-sender' a tato část byla docela přímočará. Je to jen malá uzlová aplikace, která přebírá dnešní odkazy ze Sanity, poté vytvoří základní HTML pro e-mail s těmito odkazy a poté odešle ping na foo.webdesignrepo.com s HTML e-mailu. Sendy poté odešle e-mail. Snadno.

Nastavil jsem to na cronu, aby se dokončil každý den.

Takže navzdory únavným několika dnům, kdy jsem byl blízko k pláči, jsem efektivně nastavil alternativu Mailchimp za celkem asi 70 USD (Sendy je 59 USD a Pi myslím 9 GBP).

Odeslání 2000 e-mailů denně, 30 dní v měsíci s Amazon SES vyjde na 6 USD, což není špatné.

Den 12–13 – Usnadnění a mobilní návrhy

Chci, aby webdesignrepo bylo přístupné všem, takže jsem tam, kde bylo potřeba, přidal všechny relevantní atributy árie a začal pracovat na pořadí fokusu.

Strávil jsem chvíli přemýšlením o tom, jak by pořadí zaměření mělo fungovat, a rozhodl jsem se pro toto:

Zde můžete vidět pořadí fokusu karty (z nějakého důvodu mi dev.to nedovolí vložit tento gif)

Zeptal jsem se Twitteru, jaký by byl nejlepší způsob, jak zpracovat pořadí zaměření pro tyto položky, a nikdo neodpověděl.

A11y je pro mě důležitý a chci být co nejvíce inkluzivní, takže pokud něco nevypadá správně, nefunguje správně nebo čtečky obrazovky nefungují podle očekávání ve webdesignrepo, pak mi prosím napište ping na Twitter a dejte mi vědět.

V tuto chvíli se celý web dával dohromady, ale já jsem navrhoval pouze pro desktop. Takže jsem začal pracovat na citlivé stránce věcí a neustále jsem testoval, abych se ujistil, že je vše v pořádku.

Den 14 – Obrázky pro každý příspěvek

Chtěl jsem, aby každý denní odkaz měl vedle odkazu na web malou ikonu, jako favicon/logo. Přidání tohoto zvuku triviální, ale v praxi byl trochu více zapojený.

Sanity má limit 500 000 měsíčně na své CDN pro aktiva, což je ve skutečnosti super štědré, ale chtěl jsem zůstat v rámci bezplatné úrovně tak dlouho, jak to jen bude možné, a mohl bych splnit požadavky na 500 000 obrázků dříve, než byste si mysleli.

Trochu matematiky:

  • Na domovské stránce denních odkazů je zobrazeno 7 dní
  • Každý z těchto dnů má 3–5 odkazů, předpokládejme, že je to 5
  • To je 5 * 7, 35 malých obrázků loga jen na domovské stránce

Při každém zobrazení stránky bych použil 35 požadavků CDN. Pokud se uživatel chtěl vrátit dále v čase, každá archivní stránka obsahuje odkazy za 10 dní, což je 50 dalších obrázků.

I za předpokladu, že nikdo nenavštíví stránku archivu (pro 50 dalších požadavků), 500 000 / 35 je 14 285 zobrazení stránky.

Takže při 14 tisíc zobrazeních stránek za měsíc bych musel začít platit za přístup k CDN. Je pravda, že náklady společnosti Sanity jsou skutečně levné a činí 1 USD za každých dalších 100 000 žádostí (což je přibližně 3 000 zobrazení stránky). A Sanity si mé peníze zaslouží, myslím, že vytvořili úžasný produkt a rád za to zaplatím, ale opravdu jsem to myslel jako cvičení ve škálování za co nejnižší cenu (jen pro zábavu to).

Kromě nákladů bych musel nahrát logo pro každý jednotlivý odkaz. Jistě, některé se často znovu používají, zveřejňuji spoustu odkazů na Github, triků s CSS atd. Ale také zveřejňuji spoustu menších blogů, které mohu zveřejnit pouze jednou. Nechtěl jsem nahrávat obrázek pro každý jednotlivý odkaz.

Případně bych mohl nechat robota jít a chytit obrázky za mě. Favicony jsou bohužel příliš malé, protože jsem chtěl alespoň 64x64px. Obrázky na Twitteru a otevřené grafy na Facebooku fungovaly dostatečně slušně, vyšší rozlišení a často i logo webových stránek! Ale ze stejného důvodu jako výše jsem to nechtěl dělat pro každý obrázek, protože by to stálo spoustu peněz, pravděpodobně mnohem víc než jen použití Sanity's CDN.

Potřeboval jsem rovnováhu obou.

Ve skutečnosti jsem použil tři různé způsoby, jak získat obrázky. Funguje to takto:

  • Ikonu jsem přidal jako typ dokumentu v Sanity, takže mohu nahrávat obrázky. Přidal jsem pole do schématu DailyLink pro výběr těchto ikon. U nejčastěji používaných webů jsem si stáhl obrázek jejich loga, upravil jsem jeho velikost na 64x64 a projel TinyPNG a poté nahrál do Sanity. V gatsby-node , (který běží během procesu sestavení gatsby), když požádám o všechny denní odkazy, vyžádám si také ikony. To znamená, že ikony jsou požadovány pouze jednou denně. Každá ikona je pak base64'd a umístěna přímo do kódu. Bleskově rychlý pro uživatele, udržuje mě uvnitř bezplatné vrstvy a přidává pouze ~20 kb k načtení stránky. Toto funguje pouze pro weby, které zveřejňuji nejčastěji, aktuálně mám uloženo jen asi 20 ikon.

  • Vytvořil jsem funkci bez serveru a hostoval jsem ji v Azure. Předám mu seznam URL a vrátí seznam obrázků otevřených grafů na Twitteru a FB jako URL. Upřímně řečeno, mohl jsem na to použít své Pi, ale v tomhle je to pomalé a nechtěl jsem, aby to byl bod selhání, moje Pi má dost na talíři. Cloudové funkce Azure mají také velkorysou bezplatnou úroveň. Získáte 400 000 GB-s, to jsou gigabajty sekund. Ušetřím si matematiku, ale vzhledem k tomu, že spuštění mé funkce pokaždé trvá asi sekundu, to vychází na přibližně 3 miliony vyvolání funkcí. Opět v gastby-node v době sestavení nazývám tuto cloudovou funkci se všemi adresami URL na domovské stránce (kromě těch, pro které již mám obrázky od společnosti Sanity). Tyto adresy URL obrázků pak přidám do kódu a jsou požadovány z webových stránek v dotazovacích serverech.

  • U archivních stránek, kdy se uživatel vrátí v čase, se tyto obrázky nedodávají. Když se stránka načte a najde odkazy bez obrázku base64 (od Sanity) nebo URL src (z webu odkazů), zavolá funkci Azure se seznamem adres URL a poté tyto obrázky načte.

Je to trochu spletitý, třístupňový proces pro něco docela triviálního, ale funguje to a je to zdarma.

Pro rekapitulaci:

  • Do CMS přidávám oblíbené obrázky. Jsou začleněny do kódu na bázi base64
  • Funkce Azure je volána pro zbývající chybějící obrázky na domovské stránce, použité adresy URL na Twitteru/otevřeném grafu.
  • U archivních stránek není v době sestavování nic vloženo a klient zavolá funkci Azure, aby načetla obrázky twitter/otevření grafů.

Stálo to za to? 🤷‍♂️ Bylo zábavné snažit se co nejvíce snížit náklady

Jediným problémem tohoto systému je, že některé z těchto menších blogů, které zveřejňuji, jsou hostovány na serverech bez HTTPS. Webdesignrepo tedy provádí HTTP volání aktiv a některé prohlížeče si toho všimnou v ikoně bezpečnostního zámku. To je něco, o čem budu muset přemýšlet.

Den 15-16 – Přidání všech dat

Uklidil jsem design pro repo sekci:

Přidal jsem tlačítko nabídky pro rychlou navigaci v repo:

Když byla většina webu hotová, musel jsem jen přidat data. Měl jsem na to stovky odkazů v záložkách, všechny uspořádané podle kategorií a podkategorií. Odhaduji, že přidání všech do CMS trvalo 8-12 hodin. Samozřejmě mi trvalo roky, než jsem shromáždil tak skvělou sadu odkazů.

Sanity má API pro přidávání věcí, které by to mohlo urychlit, ale jakmile jsem se dostal do rytmu, nebylo to tak špatné. Po takovém chaosu s nastavením Sendy Pi bylo vlastně docela terapeutické mít takový bezduchý úkol.

Den 17 – Cron Jobs a Twitter bot

Mám účet na Twitteru pro webdesignrepo a chtěl jsem tam každý den zveřejňovat všechny nové denní odkazy, aniž bych to musel dělat sám.

Pomocí knihovny Twit je tak snadné nastavit tento druh bota. Roztočil jsem nové repo, vytvořil jeden indexový soubor a bylo hotovo. Vyžaduje dnešní odkazy a zveřejňuje je v průběhu dne. Také jsem přidal pole twitter handle na denní schéma Sanity odkazu, takže to přidávám při přidávání nových odkazů a tweety Twitteru bot takto:

${link.label}

${link.url}

@${link.twitter_handle} #${link.tags}

Toto je zjednodušené, ale v jádru to je vše, co dělá. Značky, které přidávám ke každému dennímu odkazu (a repo odkazu) pro vyhledávání, jsou skvělé pro twitter, který také používá hashtagy. Znovu, cron dejte tomu padouchovi práci a je dobré jít.

Obvykle, když nastavíte bezhlavý CMS s generátorem statického webu, budete web znovu sestavit pokaždé, když jsou do CMS přidána data. Už jsem to dělal s Gatsby a Sanity, ale ve skutečnosti to není to, co jsem chtěl nebo potřeboval.

webdesignrepo stačí přestavět jednou denně v 6 hodin ráno, aby se zobrazily nové denní odkazy. Netlify k tomu nabízí opravdu jednoduchý webhook, a když pingnete URL, obnoví se, takže na Pi nastavím úlohu cron, abych web každý den znovu sestavil.

To je vše, přátelé

V tomto příspěvku nebylo zmíněno mnoho menších věcí, jako je:přidání ikony „přidáno do úložiště“, ikony favicon/sociálních médií, meta/SEO věci, přidání sponzorovaných značek, testování atd.

Momentálně jsem v rámci všech bezplatných úrovní na Sanity, Azure a Netlify docela daleko. Vedlejší poznámka, bezplatná úroveň Netlify nabízí 300 minut sestavení za měsíc. Sestavení webu trvá každý den přibližně 2 minuty, což je přibližně 60 minut na sestavení měsíčně. Bude zajímavé sledovat, jak se tato doba sestavení prodlouží za rok, kdy byly přidány potenciálně tisíce dalších odkazů.

A je to, tak jsem postavil webdesignrepo za 17 dní. Ve skutečnosti to bylo rozložené asi na 6-8 týdnů, protože mám práci na plný úvazek a bylo také mnoho dní, kdy jsem dělal jen 15-30 minut práce, ale většinou to bylo jen 17 celých dní.

Jak to vypadá dnes:

webdesignrepo - podívejte se na odkazy na javascript, reakce, css, design a všechny věci pro vývoj webu!