ડાયરેક્ટરી સાઇટ બનાવવી સાંભળવામાં સરળ લાગે છે, જ્યાં સુધી તમે ફક્ત એક ક્યુરેટેડ ટેબલ ઓફ કન્ટેન્ટ બતાવવા માટે જ ડેટાબેઝ, કેશિંગ લેયર્સ અને રિયાક્ટિવ ફ્રન્ટ-એન્ડ ફ્રેમવર્ક જોડવા માટે મથતા નથી. મેં તાજેતરમાં Social Tools List બનાવ્યું છે, જે સોશિયલ મીડિયા સોફ્ટવેરની સરખામણી કરવા માટેની સાઇટ છે. મારો ધ્યેય તેને ઝડપથી ઓનલાઇન લાવવાનો, તેને ફાસ્ટ રાખવાનો અને એવા કન્ટેન્ટ માટે ઇન્ફ્રાસ્ટ્રક્ચર મેન્ટેન કરવાનું ટાળવાનો હતો જે ફક્ત ત્યારે જ બદલાય છે જ્યારે હું કોઈ ટૂલ ઉમેરું અથવા અપડેટ કરું. મેં સ્ટેટિક-ફર્સ્ટ સ્ટેક (static-first stack) પસંદ કર્યો: સાઇટ જનરેશન માટે Astro, સ્ટ્રક્ચર્ડ ડેટા માટે TypeScript, અને ડિપ્લોયમેન્ટ માટે Cloudflare Workers. પરિણામ એક એવી સાઇટ છે જે તરત જ લોડ થાય છે, હોસ્ટિંગ માટે લગભગ કંઈ ખર્ચ થતો નથી, અને તેમાં ડેટાબેઝ એડમિનિસ્ટ્રેશનની જરૂર પડતી નથી.

ડાયરેક્ટરી માટે સ્ટેટિક-ફર્સ્ટ શા માટે યોગ્ય છે

ઘણી વેબ એપ્સ સર્વર રેન્ડરિંગ અથવા સિંગલ-પેજ આર્કિટેક્ચરનો ઉપયોગ કરે છે કારણ કે તે સુરક્ષિત અને આધુનિક વિકલ્પો લાગે છે. પરંતુ દરેક સાઇટ પર દરેક રિક્વેસ્ટ વખતે ડાયનેમિક યુઝર ઇનપુટ મળતું નથી. Social Tools List એ રીડ-હેવી (read-heavy) રિસોર્સ છે. સરખામણીનો ડેટા ત્યારે બદલાય છે જ્યારે હું અપડેટ આપું છું, જ્યારે કોઈ વિઝિટર રિફ્રેશ કરે ત્યારે નહીં. અગાઉથી HTML રેન્ડર કરવાથી એજ (edge) પર ડેટાબેઝ ક્વેરીઝ, ઓન ધ ફ્લાય ટેમ્પલેટ કમ્પાઈલેશન અથવા બ્રાઉઝરમાં હાઇડ્રેશન ઓવરહેડની જરૂરિયાત દૂર થાય છે. હું બિલ્ડ ટાઇમ પર સાઇટ જનરેટ કરું છું, સ્ટેટિક ફાઇલો ડિપ્લોય કરું છું, અને એક લાઇટવેઇટ વર્કરને રેપર હેન્ડલ કરવા દઉં છું. આનાથી રિસ્પોન્સ ટાઇમ ઓછો રહે છે અને રનટાઇમ ફેલ્યોરની આખી શ્રેણી દૂર થાય છે.

ડેટા ડેટાબેઝમાં નહીં, TypeScript માં સ્ટોર કરો

હું ડેટાબેઝનો ઉપયોગ કરતો નથી. ડાયરેક્ટરીમાં દરેક ટૂલને slug, name, domain, અને સપોર્ટેડ workflows ના એરે (array) સાથે TypeScript ઓબ્જેક્ટ તરીકે વ્યાખ્યાયિત કરવામાં આવે છે. એક સામાન્ય એન્ટ્રી આ મુજબ દેખાય છે:

{
  slug: 'buffer',
  name: 'Buffer',
  domain: 'buffer.com',
  workflows: ['scheduling', 'analytics']
}

સાઇટ બનાવતી જ ભાષામાં ડેટા સ્ટોર કરવાના બે તાત્કાલિક ફાયદા છે. પ્રથમ, પુલ રિક્વેસ્ટ્સ (pull requests) કન્ટેન્ટ રિવ્યુ બની જાય છે. જ્યારે હું કોઈ ટૂલ ઉમેરું છું, ત્યારે diff ચોક્કસ ફીલ્ડ્સ અને વેલ્યુઝ બતાવે છે, અને ટીમનો કોઈ સભ્ય CMS ઇન્ટરફેસ શીખ્યા વગર ટાઈપો અથવા ખોટો ડોમેન શોધી શકે છે. બીજું, TypeScript કમ્પાઈલર દરેક રેકોર્ડના આકાર (shape) ને ફરજિયાત બનાવે છે. જો હું slug ઉમેરવાનું ભૂલી જાઉં અથવા workflow key માં ભૂલ કરું, તો ખરાબ ડેટા પેજ સુધી પહોંચે તે પહેલાં જ બિલ્ડ ફેલ થઈ જાય છે.

ડેટાબેઝના ઉપયોગથી માઈગ્રેશન, કનેક્શન સ્ટ્રિંગ્સ, કેશિંગ સ્ટ્રેટેજીસ અને બેકઅપ રૂટિન જેવી બાબતો ઉમેરાશે. જે ડાયરેક્ટરી હું મેન્યુઅલી મેન્ટેન કરું છું અને જેમાં થોડાક સો એન્ટ્રીઝ છે, તેના માટે આ ઓવરહેડ માત્ર બોજ છે. TypeScript મોડ્યુલ્સમાં સ્ટેટિક ડેટા આ મોડેલ માટે સૌથી સસ્તો અને સાચો વિકલ્પ છે. 'સાચો' ભાગ મહત્વનો છે. આ માત્ર પૈસા બચાવવા વિશે નથી; તે એવા એબ્સ્ટ્રેક્શન લેયર્સ દૂર કરવા વિશે છે જે એવી સમસ્યાઓ ઉકેલે છે જે મારી પાસે છે જ નહીં.

રાઉટિંગ અને રેન્ડરિંગ માટે Astro નો ઉપયોગ કરો

Astro એક સિંગલ ડાયનેમિક રૂટ પરથી દરેક ટૂલ માટે એક HTML પેજ જનરેટ કરે છે. હું એક લેઆઉટ કમ્પોનન્ટ વ્યાખ્યાયિત કરું છું, અને Astro આપમેળે દરેક એન્ટ્રી માટે મેટાડેટા, હેડિંગ્સ અને સ્ટ્રક્ચર્ડ ડેટા તૈયાર કરી દે છે. કારણ કે સમાન ડેટાસેટ જ મુખ્ય ઇન્ડેક્સ, વર્કફ્લો કેટેગરી હબ્સ અને વ્યક્તિગત ડિટેલ પેજ ચલાવે છે, તેથી હોમ પેજ પરનું કાર્ડ ડિટેલ પેજ કરતા અલગ વર્ણન બતાવવાની કોઈ શક્યતા રહેતી નથી. પરંપરાગત CMS સેટઅપમાં, તમે ઘણીવાર ડ્રિફ્ટ (drift) જુઓ છો: API એક વર્ઝન આપે છે, કેશ બીજું, અને ક્લાયન્ટ-સાઇડ રેન્ડરિંગ ત્રીજું. સિંગલ સોર્સ ઓફ ટ્રુથ (single source of truth) માંથી સ્ટેટિક જનરેશન તેને અટકાવે છે.

Astro નું આઇલેન્ડ આર્કિટેક્ચર (island architecture) આખી પેજને JavaScript થી ભરી દે્યા વગર નાના ઇન્ટરેક્ટિવ ભાગો ઉમેરવાનું પણ સરળ બનાવે છે. સાઇટ સ્ટેટિક HTML તરીકે ડિલિવર થાય છે, અને ફક્ત ફિલ્ટરિંગ સ્ક્રિપ્ટ જ DOM ના તેના ચોક્કસ ભાગને હાઇડ્રેટ કરે છે. આખા ડોક્યુમેન્ટને રેપ કરવામાં કોઈ ફ્રેમવર્ક રનટાઇમ હોતું નથી. Astro પેજ મેટાડેટાને પણ પ્રાથમિકતા આપે છે. દરેક ટૂલ પેજને TypeScript રેકોર્ડમાંથી સીધું મેળવેલું પોતાનું ટાઇટલ ટેગ અને મેટા ડિસ્ક્રિપ્શન મળે છે, તેથી મારે અલગ પ્લગઇન અથવા હેડ મેનેજમેન્ટ લાઇબ્રેરીની જરૂર પડતી નથી.

ફ્રેમવર્ક વગર ફિલ્ટરિંગ

સર્ચ અને ફિલ્ટરિંગ ઘણીવાર ડેવલપર્સને React, Vue અથવા હેવી સ્ટેટ મેનેજમેન્ટ લાઇબ્રેરી ઇન્સ્ટોલ કરવા માટે પ્રેરે છે. મેં તે ટાળ્યું. Astro સર્વર પર પ્લેન HTML તરીકે આખી યાદી રેન્ડર કરે છે. એક નાની વેનિલા JavaScript સ્ક્રિપ્ટ, જે એક કિલોબાઇટથી પણ ઓછી છે, બ્રાઉઝરમાં ચાલે છે અને વર્કફ્લો ટેગ અથવા ટેક્સ્ટ મેચના આધારે લિસ્ટ આઇટમ્સના ડિસ્પ્લે પ્રોપર્ટીને ટોગલ (toggle) કરે છે.

Serving the complete markup sounds inefficient if you come from an API-driven background. But consider the overhead of a typical dynamic approach. The browser downloads a JavaScript bundle, hydrates a component tree, calls an endpoint, waits for JSON, and then renders rows. For a directory that lists fewer than one hundred tools, that ritual is slower and less reliable than hiding divs that are already in the document. My script attaches event listeners to filter buttons, reads a data-workflow attribute on each row, and sets non-matches to hidden. The operation takes milliseconds.

Because the list is present in the initial HTML, the site is usable without JavaScript. Search engine crawlers see every link and every description. Users on slow networks or with script blockers still get the full directory. The filtering is an enhancement, not a gate.

Sitemaps and Robots as Code

Sitemaps and robots.txt are not afterthoughts written by hand. They are Astro routes that consume the same dataset and URL helpers as