ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਸਾਈਟ ਬਣਾਉਣਾ ਬਹੁਤ ਸਧਾਰਨ ਲੱਗਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਡਾਟਾਬੇਸ, ਕੈਸ਼ਿੰਗ ਲੇਅਰਾਂ, ਅਤੇ ਰੀਐਕਟਿਵ ਫਰੰਟ-ਐਂਡ ਫਰੇਮਵਰਕਾਂ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਚੁਣਵੀਂ ਵਿਸ਼ਾ-ਸੂਚੀ (table of contents) ਦਿਖਾਉਣ ਲਈ ਜੋੜਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਨਹੀਂ ਫਸਦੇ। ਮੈਂ ਹਾਲ ਹੀ ਵਿੱਚ Social Tools List ਬਣਾਈ ਹੈ, ਜੋ ਕਿ ਸੋਸ਼ਲ ਮੀਡੀਆ ਸਾਫਟਵੇਅਰ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ ਇੱਕ ਸਾਈਟ ਹੈ। ਮੇਰਾ ਉਦੇਸ਼ ਇਸਨੂੰ ਜਲਦੀ ਆਨਲਾਈਨ ਲਿਆਉਣਾ, ਇਸਨੂੰ ਤੇਜ਼ ਰੱਖਣਾ, ਅਤੇ ਅਜਿਹੇ ਕੰਟੈਂਟ ਲਈ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਤੋਂ ਬਚਣਾ ਸੀ ਜੋ ਸਿਰਫ਼ ਉਦੋਂ ਬਦਲਦਾ ਹੈ ਜਦੋਂ ਮੈਂ ਕੋਈ ਟੂਲ ਜੋੜਦਾ ਹਾਂ ਜਾਂ ਅਪਡੇਟ ਕਰਦਾ ਹਾਂ। ਮੈਂ ਇੱਕ static-first stack ਦੀ ਚੋਣ ਕੀਤੀ: ਸਾਈਟ ਜਨਰੇਸ਼ਨ ਲਈ Astro, ਸਟ੍ਰਕਚਰਡ ਡੇਟਾ ਲਈ TypeScript, ਅਤੇ ਡਿਪਲਾਈਮੈਂਟ ਲਈ Cloudflare Workers। ਨਤੀਜੇ ਵਜੋਂ ਇੱਕ ਅਜਿਹੀ ਸਾਈਟ ਮਿਲੀ ਜੋ ਤੁਰੰਤ ਲੋਡ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਨੂੰ ਹੋਸਟ ਕਰਨ ਦੀ ਲਗਭਗ ਕੋਈ ਲਾਗਤ ਨਹੀਂ ਆਉਂਦੀ, ਅਤੇ ਜਿਸ ਲਈ ਕਿਸੇ ਡੇਟਾਬੇਸ ਪ੍ਰਸ਼ਾਸਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਡਾਇਰੈਕਟਰੀ ਲਈ ਸਟੈਟਿਕ-ਫਸਟ ਕਿਉਂ ਸਹੀ ਹੈ

ਬਹੁਤ ਸਾਰੇ ਵੈੱਬ ਐਪਸ ਸਰਵਰ ਰੈਂਡਰਿੰਗ ਜਾਂ ਸਿੰਗਲ-ਪੇਜ ਆਰਕੀਟੈਕਚਰਾਂ ਨੂੰ ਡਿਫੌਲਟ ਵਜੋਂ ਚੁਣਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸੁਰੱਖਿਅਤ ਅਤੇ ਆਧੁਨਿਕ ਵਿਕਲਪ ਲੱਗਦੇ ਹਨ। ਪਰ ਹਰ ਸਾਈਟ ਨੂੰ ਹਰ ਰਿਕਵੈਸਟ 'ਤੇ ਡਾਇਨਾਮਿਕ ਯੂਜ਼ਰ ਇਨਪੁਟ ਨਹੀਂ ਮਿਲਦਾ। Social Tools List ਇੱਕ read-heavy resource ਹੈ। ਤੁਲਨਾ ਵਾਲਾ ਡੇਟਾ ਉਦੋਂ ਬਦਲਦਾ ਹੈ ਜਦੋਂ ਮੈਂ ਅਪਡੇਟ ਪੁਸ਼ ਕਰਦਾ ਹਾਂ, ਨਾ ਕਿ ਉਦੋਂ ਜਦੋਂ ਕੋਈ ਵਿਜ਼ਟਰ ਰਿਫ੍ਰੈਸ਼ ਕਰਦਾ ਹੈ। HTML ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਰੈਂਡਰ ਕਰਨ ਨਾਲ edge 'ਤੇ ਡੇਟਾਬੇਸ ਕੁਏਰੀਆਂ, ਤੁਰੰਤ ਟੈਂਪਲੇਟ ਕੰਪਾਈਲੇਸ਼ਨ, ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ hydration overhead ਦੀ ਲੋੜ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਮੈਂ ਬਿਲਡ ਟਾਈਮ 'ਤੇ ਸਾਈਟ ਜਨਰੇਟ ਕਰਦਾ ਹਾਂ, ਸਟੈਟਿਕ ਫਾਈਲਾਂ ਡਿਪਲੋਏ ਕਰਦਾ ਹਾਂ, ਅਤੇ ਇੱਕ ਹਲਕੇ (lightweight) worker ਨੂੰ ਵੈਪਰ (wrapper) ਸੰਭਾਲਣ ਲਈ ਛੱਡ ਦਿੰਦਾ ਹਾਂ। ਇਹ ਰਿਸਪਾਂਸ ਸਮੇਂ ਨੂੰ ਘੱਟ ਰੱਖਦਾ ਹੈ ਅਤੇ ਰਨਟਾਈਮ ਫੇਲ੍ਹਰਾਂ ਦੀ ਇੱਕ ਪੂਰੀ ਸ਼੍ਰੇਣੀ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ।

ਡੇਟਾ ਨੂੰ TypeScript ਵਿੱਚ ਸਟੋਰ ਕਰੋ, ਡੇਟਾਬੇਸ ਵਿੱਚ ਨਹੀਂ

ਮੈਂ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ। ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਹਰ ਟੂਲ ਨੂੰ ਇੱਕ slug, ਨਾਮ, ਡੋਮੇਨ, ਅਤੇ ਸਮਰਥਿਤ workflows ਦੀ ਇੱਕ ਐਰੇ (array) ਦੇ ਨਾਲ ਇੱਕ TypeScript ਆਬਜੈਕਟ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਇੱਕ ਆਮ ਐਂਟਰੀ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

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

ਸਾਈਟ ਬਣਾਉਣ ਵਾਲੀ ਉਹੀ ਭਾਸ਼ਾ ਵਿੱਚ ਡੇਟਾ ਸਟੋਰ ਕਰਨ ਦੇ ਦੋ ਤੁਰੰਤ ਫਾਇਦੇ ਹਨ। ਪਹਿਲਾ, pull requests ਕੰਟੈਂਟ ਰਿਵਿਊ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਜਦੋਂ ਮੈਂ ਕੋਈ ਟੂਲ ਜੋੜਦਾ ਹਾਂ, ਤਾਂ diff ਸਹੀ ਫੀਲਡਾਂ ਅਤੇ ਮੁੱਲਾਂ (values) ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਸਾਥੀ CMS ਇੰਟਰਫੇਸ ਸਿੱਖੇ ਬਿਨਾਂ ਹੀ ਟਾਈਪੋ ਜਾਂ ਗਲਤ ਡੋਮੇਨ ਨੂੰ ਪਛਾਣ ਸਕਦਾ ਹੈ। ਦੂਜਾ, TypeScript ਕੰਪਾਈਲਰ ਹਰ ਰਿਕਾਰਡ ਦੇ ਰੂਪ (shape) ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਮੈਂ slug ਸ਼ਾਮਲ ਕਰਨਾ ਭੁੱਲ ਜਾਂਦਾ ਹਾਂ ਜਾਂ ਕਿਸੇ workflow key ਨੂੰ ਗਲਤ ਲਿਖਦਾ ਹਾਂ, ਤਾਂ ਗਲਤ ਡੇਟਾ ਪੇਜ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਬਿਲਡ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਕਨੈਕਸ਼ਨ ਸਟ੍ਰਿੰਗਾਂ, ਕੈਸ਼ਿੰਗ ਰਣਨੀਤੀਆਂ, ਅਤੇ ਬੈਕਅੱਪ ਰੁਟੀਨਾਂ ਨੂੰ ਲਿਆਵੇਗਾ। ਕੁਝ ਸੌ ਐਂਟਰੀਆਂ ਵਾਲੀ ਡਾਇਰੈਕਟਰੀ ਲਈ ਜਿਸ ਨੂੰ ਮੈਂ ਮੈਨੂਅਲੀ ਮੇਨਟੇਨ ਕਰਦਾ ਹਾਂ, ਉਹ ਓਵਰਹੈੱਡ ਬੇਲੋੜਾ ਭਾਰ ਹੈ। TypeScript ਮੋਡਿਊਲ ਵਿੱਚ ਸਟੈਟਿਕ ਡੇਟਾ ਇਸ ਮਾਡਲ ਲਈ ਸਭ ਤੋਂ ਸਸਤਾ ਅਤੇ ਸਹੀ ਚੋਣ ਹੈ। "ਸਹੀ" ਹਿੱਸਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਹ ਸਿਰਫ਼ ਪੈਸੇ ਬਚਾਉਣ ਬਾਰੇ ਨਹੀਂ ਹੈ; ਇਹ ਉਹਨਾਂ ਐਬਸਟਰੈਕਸ਼ਨ ਲੇਅਰਾਂ ਨੂੰ ਹਟਾਉਣ ਬਾਰੇ ਹੈ ਜੋ ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦੀਆਂ ਹਨ ਜੋ ਮੇਰੇ ਕੋਲ ਹਨ ਹੀ ਨਹੀਂ।

ਰੂਟਿੰਗ ਅਤੇ ਰੈਂਡਰਿੰਗ ਲਈ Astro ਦੀ ਵਰਤੋਂ

ਜੇਕਰ ਤੁਸੀਂ API-driven ਬੈਕਗ੍ਰਾਊਂਡ ਤੋਂ ਆਉਂਦੇ ਹੋ, ਤਾਂ ਪੂਰਾ ਮਾਰਕਅੱਪ ਸਰਵ ਕਰਨਾ ਅਕੁਸ਼ਲ ਲੱਗ ਸਕਦਾ ਹੈ। ਪਰ ਇੱਕ ਆਮ ਡਾਇਨਾਮਿਕ ਪਹੁੰਚ ਦੇ ਓਵਰਹੈੱਡ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ। ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ JavaScript ਬੰਡਲ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ, ਇੱਕ ਕੰਪੋਨੈਂਟ ਟ੍ਰੀ ਨੂੰ ਹਾਈਡ੍ਰੇਟ ਕਰਦਾ ਹੈ, ਇੱਕ ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, JSON ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਰੋਅਜ਼ ਨੂੰ ਰੈਂਡਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਲਈ ਜਿਸ ਵਿੱਚ ਸੌ ਤੋਂ ਘੱਟ ਟੂਲ ਸੂਚੀਬੱਧ ਹਨ, ਉਹ ਪ੍ਰਕਿਰਿਆ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ divs ਨੂੰ ਲੁਕਾਉਣ ਨਾਲੋਂ ਹੌਲੀ ਅਤੇ ਘੱਟ ਭਰੋਸੇਯੋਗ ਹੈ। ਮੇਰਾ ਸਕ੍ਰਿਪਟ ਫਿਲਟਰ ਬਟਨਾਂ ਨਾਲ event listeners ਜੋੜਦਾ ਹੈ, ਹਰੇਕ ਰੋਅ 'ਤੇ data-workflow ਐਟਰੀਬਿਊਟ ਪੜ੍ਹਦਾ ਹੈ, ਅਤੇ ਗੈਰ-ਮੇਲ ਹੋਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ hidden ਸੈੱਟ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਕਾਰਵਾਈ ਮਿਲੀਸੈਕਿੰਡਾਂ ਵਿੱਚ ਹੋ ਜਾਂਦੀ ਹੈ।

ਕਿਉਂਕਿ ਸੂਚੀ ਸ਼ੁਰੂਆਤੀ HTML ਵਿੱਚ ਮੌਜੂਦ ਹੈ, ਇਸ ਲਈ ਸਾਈਟ JavaScript ਤੋਂ ਬਿਨਾਂ ਵੀ ਵਰਤੋਂ ਯੋਗ ਹੈ। ਸਰਚ ਇੰਜਣ ਕਰੌਲਰ ਹਰ ਲਿੰਕ ਅਤੇ ਹਰ ਵੇਰਵਾ ਦੇਖ ਸਕਦੇ ਹਨ। ਹੌਲੀ ਨੈੱਟਵਰਕ ਵਾਲੇ ਜਾਂ ਸਕ੍ਰਿਪਟ ਬਲਾਕਰ ਵਰਤਣ ਵਾਲੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਫਿਰ ਵੀ ਪੂਰੀ ਡਾਇਰੈਕਟਰੀ ਮਿਲਦੀ ਹੈ। ਫਿਲਟਰਿੰਗ ਇੱਕ ਵਾਧਾ ਹੈ, ਕੋਈ ਰੁਕਾਵਟ ਨਹੀਂ।

Sitemaps ਅਤੇ Robots ਕੋਡ ਵਜੋਂ

Sitemaps ਅਤੇ robots.txt ਕੋਈ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਨਹੀਂ ਹਨ ਜੋ ਬਾਅਦ ਵਿੱਚ ਸੋਚ ਕੇ ਹੱਥ ਨਾਲ ਲਿਖੀਆਂ ਗਈਆਂ ਹੋਣ। ਇਹ Astro ਰੂਟਸ ਹਨ ਜੋ ਉਸੇ ਡੇਟਾ ਸੈੱਟ ਅਤੇ URL ਹੈਲਪਰਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜਿਵੇਂ ਕਿ