logo

Ik heb mijn persoonlijke website volledig herschreven met Dev.to als CMS

Het laatste weekend van januari 2021 was rustig in vergelijking met andere jaren - in het VK waren we in volledige lockdown vanwege het Coronavirus. Het was echter de perfecte gelegenheid om mijn persoonlijke website volledig te herschrijven.

Waarom?

Ik heb om verschillende redenen besloten om mijn website opnieuw te ontwerpen en te herschrijven:

  • Ik wilde overstappen van JavaScript naar TypeScript.
  • De website is gestyled met styled-jsx, wat lastig te onderhouden kan zijn en IMO is een beetje rommelig. Op dit moment gebruik ik Tailwind CSS en tot nu toe ben ik er dol op en zijn praktische aard; Ik wilde dat mijn persoonlijke website dit weerspiegelde.
  • Ik hield niet meer van het ontwerp en wilde dat het schoner en eenvoudiger was.
  • Ik wilde dat mijn blog en portfolio dynamisch werden geladen vanuit een CMS in plaats van voor elk item een ​​nieuwe pagina te moeten kopiëren en plakken - Zie de Originally published at wallis.dev bovenaan dit artikel.


Gebruikte technologieën

  • TypeScript - Sinds ik op het werk kennismaakte met TypeScript, begon ik de voordelen te begrijpen ten opzichte van gewoon JavaScript.
  • Volgende.js - Ik probeer niet te verbergen dat ik dol ben op Next.js, het is zo eenvoudig te gebruiken en tot op heden bevatten de meeste van mijn artikelen op de een of andere manier Next.js.
  • Staartwind CSS - De laatste tijd gebruik ik Tailwind CSS intensief. Om hun homepage te citeren, het stelt me ​​in staat om "snel moderne websites te bouwen zonder ooit [mijn React-component] te verlaten". Tailwind CSS maakte het ook ongelooflijk eenvoudig om een ​​donkere modus toe te voegen. Ook Tailwind Typografie.
  • Dev.to API om de blog- en portfoliopagina's dynamisch te bouwen ⬅️ Mijn favoriete functie .

Dev.to gebruiken als een CMS

Mijn favoriete onderdeel van mijn website is het gebruik van Dev.to als Content Management Systeem voor de blog- en portfoliopagina's. Ik heb eerder gezien dat de Dev.to API werd gebruikt om de artikelen van een gebruiker op hun website weer te geven, maar AFAIK, niet helemaal op dezelfde manier als ik het heb toegepast.

De voordelen van het gebruik van Dev.to als CMS zijn:

  1. Dev.to slaat de artikelen en alle afbeeldingen op die zijn geüpload en gebruikt.
  2. Ik kan de editor van Dev.to gebruiken en de mogelijkheid om een ​​artikel op te stellen en later te publiceren.
  3. Heeft een ingebouwde RSS-feed die ik kan gebruiken om mijn artikelen te delen met andere sites zoals CodeNewbie en Medium.
  4. Hoewel Dev.to het artikel als eerste heeft, zorgt het gebruik van een canonieke URL ervoor dat Google en andere sites mijn persoonlijke website zien als de bronsite voor de artikelen.
  5. Zet het artikel voor mij om in HTML. Uiteindelijk heb ik de HTML van de artikelmarkering zelf weergegeven, omdat er minder verzoeken aan de Dev.to API nodig waren.

Disclaimer

Voordat ik verder ga, wil ik beklemtonen dat ik van plan ben Dev.to puur voor mijn blog en portfolio te gebruiken (voorgaande projecten / showdev ). Ik zal Dev.to niet gebruiken om pagina's te maken die geen artikelen zijn en zou ervoor zorgen dat Dev.to overvol raakt met spam als anderen dit voorbeeld volgen. Het gedeelte Info op de startpagina is bijvoorbeeld hard gecodeerd in de website en als ik een pagina voor mijn opleidingsgeschiedenis zou maken, zou ik die puur voor de website houden en niet op Dev.to plaatsen - ik zou waarschijnlijk gebruik hiervoor Markdown.

Hoe het werkt

Bekijk de code op GitHub

De website is gebouwd met Next.js en gebruikt twee dynamische routeringsfuncties (getStaticPaths en getStaticProps ) om de blog- en portfoliopagina's te genereren.

Voordat een artikel op mijn website wordt weergegeven, moet het aan de volgende twee vereisten voldoen:

  1. Moet worden gepubliceerd (uiteraard)
  2. Moet een canonieke URL hebben die naar mijn website leidt. Hierdoor kan ik kiezen welke artikelen worden weergegeven, wat het pad van het artikel op mijn website zal zijn (niet de post-ID). Bovendien, een artikel met een canonieke URL die verwijst naar https://wallis.dev/blog/... zal worden gebouwd als onderdeel van mijn blog, terwijl, als de canonieke URL https://wallis.dev/portfolio/... is, het wordt een portfoliostuk.

Voor elk artikel dat aan de eisen voldoet, wordt het daaropvolgende bouwproces gevolgd:

  1. Tijdens het bouwen roept Next.js de getStaticPaths . aan functie die

    1. Haalt een lijst op van mijn gepubliceerde artikelen met behulp van de Dev.to API (/api/articles/me ).
    2. Converteert de afwaardering van het artikel naar HTML.
    3. Slaat de artikelen op in een cachebestand voor gebruik in de volgende stap.
    4. Er wordt een dynamische pagina gemaakt binnen de Next.js-context voor elk artikel - de pagina slug zal het canonieke URL-pad zijn.

  2. Voor elke pagina roept Next.js getStaticProps . aan die het artikel van de pagina uit de cache haalt. Het artikel bevat de naam, beschrijving en HTML.

    • Ik heb ook geprobeerd een ander API-verzoek te doen aan de Dev.to API (/api/articles/{id} ) om het artikel van de pagina op te halen, zodat ik de HTML kon gebruiken die door Dev.to wordt weergegeven. Dit veroorzaakte echter bouwfouten omdat ik te veel API-verzoeken tegelijk deed - dus nu geef ik de prijsverlaging weer met remark-html .

  3. Ten slotte wordt de pagina weergegeven. Ik gebruik aangepaste elementen om het artikel name . weer te geven en description en geef vervolgens de HTML weer die ik eerder heb weergegeven in getStaticPaths met behulp van remark-html . Voor styling gebruik ik de Tailwind Typography plugin.

Om ervoor te zorgen dat de website altijd synchroon loopt met mijn artikelen op Dev.to, gebruik ik een Vercel Deploy-hook die wordt geactiveerd telkens wanneer ik een artikel maak of bijwerk met een Dev.to-webhook. Ik gebruik een Deploy Hook in plaats van Incremental Static Regeneration, zodat de blog alleen opnieuw wordt opgebouwd als er iets is veranderd in plaats van met willekeurige tussenpozen.

Opmerking:ik gebruik Dev.to API's die autorisatie vereisen, omdat ze een hogere verzoeklimiet lijken te hebben in vergelijking met de openbare routes. Bij het gebruik van openbare API's en het ophalen van elk artikel via de artikel-API, ontdekte ik dat mijn builds faalden met een 429 fout die Dev.to-snelheidsbeperkende verzoeken zijn. - Ik zou waarschijnlijk kunnen overschakelen naar het gebruik van openbare API's nu ik een cache gebruik om de artikelen uit te lezen.

Ik ben momenteel een gedetailleerd artikel aan het schrijven dat in meer detail beschrijft hoe mijn website Dev.to als CMS gebruikt, blijf op de hoogte (en volg Dev.to om op de hoogte te worden gehouden wanneer ik het vrijgeef)!

Hoe het eruit ziet

Bezoek wallis.dev


Toekomstige verbeteringen

  1. Voeg syntaxisaccentuering toe aan codeblokken zoals op Dev.to. Voltooid met highlight.js en remark-highlight.js .
  2. Voeg een contactformulier toe met EmailJS.
  3. Verbouw de website alleen als de inhoud van een artikel is gewijzigd of als er een is gemaakt - vermindert het onnodig opnieuw implementeren van de website.

Samenvatting

In dit artikel besprak ik het herschrijven van mijn persoonlijke website vanaf het begin met Dev.to als een contentmanagementsysteem voor de blog- en portfoliopagina's.

Vind je het een leuk idee om Dev.to als CMS voor je blog te gebruiken? Reageer! Iets gevonden dat ik kan verbeteren of dat jij anders zou hebben gedaan? Laat het me weten in de reacties.

Bedankt voor het lezen!

Trouwens, je kunt dit artikel hier live op mijn website bekijken.