ఒక పని చేసే డిజైనర్కు, పోర్ట్ఫోలియో సైట్ ఒక ఇబ్బందికరమైన మధ్యస్థ స్థితిలో ఉంటుంది. అది చూడటానికి షార్ప్గా ఉండాలి, వెంటనే లోడ్ అవ్వాలి మరియు బిల్లేబుల్ గంటలను (billable hours) తగ్గించకుండా ఎప్పటికప్పుడు అప్డేట్గా ఉండాలి. నా పాత సెటప్ Webflowలో ఉండేది, ఇది డ్రాగ్-అండ్-డ్రాప్ బిల్డర్లకు మరియు ప్రొఫెషనల్ అవుట్పుట్కు మధ్య ఉన్న అంతరాన్ని ఇతర సాధనాల కంటే మెరుగ్గా పూరించింది. కానీ £300 వార్షిక బిల్లుతో రెన్యూవల్ నోటీసు వచ్చినప్పుడు, నేను ఒక కఠినమైన ప్రశ్న వేసుకోవాల్సి వచ్చింది: నేను విలువ కోసం డబ్బు చెల్లిస్తున్నానా, లేదా కేవలం సౌలభ్యం కోసం మాత్రమేనా?
నేను మొదటి నుండి మళ్ళీ నిర్మించాలని నిర్ణయించుకున్నాను. కొత్త స్టాక్ Astro మరియు Sanity. కొంతకాలం దీనిని ఉపయోగించిన తర్వాత, ఇందులో ఏది పని చేసింది, ఏది చేయలేదు మరియు నేను ఇంతకుముందు ఉపయోగించిన సాధనాలతో పోలిస్తే ఇది ఎక్కడ సరిపోతుందో ఇక్కడ వివరిస్తున్నాను.
పోర్ట్ఫోలియో కోసం Astro ఎందుకు?
చాలా ఆధునిక వెబ్ ఫ్రేమ్వర్క్లు మొదట JavaScriptను పంపిస్తాయి మరియు తర్వాత ఇతర విషయాలను చూసుకుంటాయి. Astro ఆ ఊహను తలకిందులు చేస్తుంది. ఇది బిల్డ్ టైమ్లో సాధారణ స్టాటిక్ HTMLని ఉత్పత్తి చేస్తుంది మరియు ఏదైనా నిర్దిష్ట కాంపోనెంట్కు అవసరమైనప్పుడు మాత్రమే బ్రౌజర్కు JavaScriptను పంపిస్తుంది. వీరు దీనిని 'islands architecture' అని పిలుస్తారు, కానీ దీని వాస్తవ ఫలితం చాలా సరళమైనది: నా పోర్ట్ఫోలియో పేజీల బరువు దాదాపు సున్నా.
రూటింగ్ ఫైల్-బేస్డ్ (file-based) పద్ధతిలో ఉంటుంది, కాబట్టి కొత్త పేజీని సృష్టించడం అనేది ఒక ఫోల్డర్లో ఫైల్ను వేయడం అంత సులభంగా ఉంటుంది. మీకు React, Vue, లేదా Svelte తెలిసి ఉంటే, కాంపోనెంట్ల సింటాక్స్ మీకు పరిచయంగా అనిపిస్తుంది. నేను ప్రతిసారీ ఒక ప్రాజెక్ట్ కేస్ స్టడీని జోడించాలనుకున్నప్పుడు కొత్త పద్ధతిని నేర్చుకోవాల్సిన అవసరం లేదు.
అయినప్పటికీ, ఒక సంక్లిష్టమైన వెబ్ అప్లికేషన్ను నిర్మించడానికి నేను Astroని ఉపయోగించను. మీరు అథెంటికేషన్ (authentication) సెటప్ చేస్తున్నా, గ్లోబల్ స్టేట్ను మేనేజ్ చేస్తున్నా లేదా రియల్-టైమ్ డేటాను హ్యాండిల్ చేస్తున్నా, మీరు ఫ్రేమ్వర్క్తో పోరాడాల్సి వస్తుంది. కానీ మార్కెటింగ్ సైట్లు, బ్లాగులు మరియు పోర్ట్ఫోలియోల కోసం, ఇది ఎటువంటి ఆటంకం లేకుండా పనిచేస్తుంది. పేజీలు వేగంగా అనిపిస్తాయి ఎందుకంటే అవి నిజంగానే వేగంగా ఉంటాయి. హెడ్లైన్ లేదా పారాగ్రాఫ్ను రెండర్ చేయడానికి వేచి ఉండాల్సిన 'hydration overhead' ఇక్కడ ఉండదు.
WordPress నుండి Sanityకి మారడం
ఈ రీబిల్డ్కు ముందు, నా ఫాల్బ్యాక్ ఎప్పుడూ Advanced Custom Fields ఉన్న WordPress మాత్రమే. ACF అనేది WordPressకు అదనపు శక్తులను ఇస్తుంది, కానీ మీరు ఇంకా వేరొకరు నిర్మించిన ఇంటిలోనే సర్దుబాటు చేసుకోవాల్సి ఉంటుంది. Sanity దీనికి భిన్నంగా పనిచేస్తుంది. మీ కంటెంట్ మోడల్ ఎలా ఉండాలో నిర్వచించే స్కీమాను (schema) మీరు కోడ్లో రాస్తారు, మరియు Sanity మీ నిర్ణయాల ఆధారంగా ఎడిటింగ్ ఇంటర్ఫేస్ను నిర్మిస్తుంది.
పునర్వినియోగపరచదగిన బ్లాక్ల (reusable blocks) ద్వారా ఒక సాధారణ పేజీ బిల్డర్ను నిర్మించడానికి నేను ఆ నియంత్రణను ఉపయోగించాను. నేను ఒకసారి హీరో సెక్షన్ను నిర్వచించాను. ఒకసారి టెస్టిమోనియల్ కారౌసెల్ను నిర్వచించాను. ఒకసారి కార్డ్ గ్రిడ్ను నిర్వచించాను. ఇప్పుడు నేను కొత్త కోడ్ రాయకుండా లేదా పేజీ టెంప్లేట్ను మార్చకుండా, ఆ బ్లాక్లను ఏ క్రమంలోనైనా అమర్చడం ద్వారా కొత్త పేజీలను రూపొందించగలను.
ఆలోచనా విధానంలో తేడా చాలా ముఖ్యం. WordPressతో, నేను తరచుగా ఒక బ్లాగ్ కావాలనుకునే సాధనంతో పోరాడుతున్నట్లు అనిపించేది. Sanityతో, నేను సాఫ్ట్వేర్ను నిర్మిస్తున్నట్లు అనిపిస్తుంది. కంటెంట్ అనేది షార్ట్కోడ్లతో కలిసిన స్టైల్డ్ HTML కాకుండా, క్లీన్ స్ట్రక్చర్డ్ డేటాగా మారుతుంది. నా ప్రాజెక్ట్ వివరణలు పోర్టబుల్ ఆబ్జెక్ట్లుగా ఉంటాయి, కావాలనుకుంటే నేను వాటిని మొబైల్ యాప్లోకి లేదా న్యూస్లెటర్లోకి పంపవచ్చు.
క్లీన్గా ఉండే డిప్లాయ్మెంట్ వర్క్ఫ్లో
నా పాత WordPress వర్క్ఫ్లో FTP అప్లోడ్లు, స్టేజింగ్ సబ్డొమైన్లు మరియు ఎప్పుడూ తప్పుడు సమయంలో బ్రేక్ అయ్యే ప్లగిన్ అప్డేట్లతో నిండిపోయి గందరగోళంగా ఉండేది. కేవలం ఒక చిన్న స్పెల్లింగ్ తప్పును సరిదిద్దడానికి కూడా నేను ఒక మెంటల్ చెక్లిస్ట్ను ఉంచుకోవాల్సి వచ్చేది.
కొత్త వర్క్ఫ్లో చాలా చిన్నది:
- నేను లోకల్గా మార్పులు చేస్తాను మరియు వాటిని వెంటనే చూడగలను.
- కోడ్ సరిగ్గా ఉన్నప్పుడు నేను GitHub కి కమిట్ చేస్తాను.
- Vercel ఆ పుష్ను తీసుకుని సైట్ను ఆటోమేటిక్గా డిప్లాయ్ చేస్తుంది.
ఇక్కడ FTP క్లయింట్ అవసరం లేదు. సింక్ చేయడానికి స్టేజింగ్ డేటాబేస్ లేదు. రిపోజిటరీయే (repository) అసలైన ఆధారం (source of truth).
కంటెంట్ కూడా అదే విధంగా పనిచేస్తుంది. నేను Sanityలో ఒక పోస్ట్ను పబ్లిష్ చేసినా లేదా అప్డేట్ చేసినా, ఒక వెబ్హుక్ (webhook) Vercelకి సైట్ను రీబిల్డ్ చేయమని చెబుతుంది. స్టాటిక్ పేజీలు కొత్త కంటెంట్తో మళ్ళీ తయారవుతాయి మరియు నేను సర్వర్ను తాకకుండానే CDN అప్డేట్ అవుతుంది. మాన్యువల్గా కాపీ చేయడం, ఎక్స్పోర్ట్ చేయడం లేదా ప్లగిన్ డేటాబేస్ మైగ్రేషన్ నిజంగా పనిచేస్తుందని ప్రార్థించడం వంటివి చేయకుండానే అంతా సింక్లో ఉంటుంది.
టోకెన్లతో డిజైన్ మరియు కోడ్ను అనుసంధానించడం
ఈ రీబిల్డ్లో జరిగిన ఒక నిశ్శబ్ద విజయం ఏమిటంటే, సరైన టోకెన్ సిస్టమ్ను సెటప్ చేయడం. సైట్లోని ప్రతి రంగు, టైప్ స్కేల్ మరియు స్పేసింగ్ విలువను కలిగి ఉండేలా నేను ఒకే ఒక JSON ఫైల్ను ఉంచుతాను. ఆ ఫైలే బాస్.
ఆ విలువలను నేరుగా Figmaలోకి తీసుకురావడానికి నేను Token Studioని ఉపయోగిస్తాను. నా డిజైన్ ఫైల్లో surface-default అని ఉన్నప్పుడు, అది కోడ్ ఉపయోగించే ఖచ్చితమైన నంబర్ను మాత్రమే సూచిస్తుంది. ఒక చిన్న స్క్రిప్ట్ బిల్డ్ టైమ్లో JSONని CSS కస్టమ్ ప్రాపర్టీలుగా మారుస్తుంది, కాబట్టి నా స్టైల్షీట్లు హార్డ్కోడ్ చేసిన హెక్స్ కోడ్లకు బదులుగా --color-surface-default వంటి వేరియబుల్స్ను ఉపయోగిస్తాయి.
ఇది ప్రాక్టికల్గా ఎందుకు ముఖ్యమో ఇక్కడ ఉంది. నా బ్రాండ్ రెడ్ (brand red) మొబైల్ స్క్రీన్లపై కొంచెం ఎక్కువగా అనిపిస్తే, నేను JSON ఫైల్లో ఒక విలువను మారుస్తాను. Figma లైబ్రరీ అప్డేట్ అవుతుంది. CSS అప్డేట్ అవుతుంది. సైట్ అంతటా ఉన్న ప్రతి చోటా అప్డేట్ అవుతుంది. నేను grep చేయాల్సిన అవసరం లేదు.
