Cloudflare Workers ਉੱਤੇ ਸਥਿਰ Next.js ਸਾਈਟ
ਇਹ ਸਾਈਟ ਛੋਟੇ Worker ਵੱਲੋਂ ਪਰੋਸਿਆ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਥਿਰ Next.js ਐਕਸਪੋਰਟ ਕਿਉਂ ਹੈ: ਤੇਜ਼ ਪੰਨੇ, ਲਗਭਗ ਸਿਫ਼ਰ ਲਾਗਤ, ਸਰਵਰ ਉੱਤੇ ਐਡਮਿਨ ਸੁਰੱਖਿਆ ਅਤੇ ਸੁਰੱਖਿਆ ਹੈਡਰ।
3 ਮਿੰਟ ਪੜ੍ਹਨ ਲਈGryffin Forge
ਇਹ ਸਾਈਟ Next.js ਅਤੇ React ਨਾਲ ਬਣੀ ਹੈ, ਪਰ ਕਿਤੇ ਵੀ ਕੋਈ Node.js ਸਰਵਰ ਨਹੀਂ ਚੱਲਦਾ। ਹਰ ਜਨਤਕ ਪੰਨਾ ਬਿਲਡ ਵੇਲੇ ਸਥਿਰ HTML ਵਜੋਂ ਬਣਦਾ ਹੈ ਅਤੇ Cloudflare ਦੇ edge ਤੋਂ ਪਰੋਸਿਆ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਛੋਟਾ Worker ਉਨ੍ਹਾਂ ਕੁਝ ਕੰਮਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸੱਚਮੁੱਚ ਸਰਵਰ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਕਿਉਂ ਅਤੇ ਹਿੱਸੇ ਕਿਵੇਂ ਜੁੜਦੇ ਹਨ।
ਪਹਿਲਾਂ ਸਥਿਰ
ਪੋਰਟਫ਼ੋਲੀਓ ਅਤੇ ਨਮੂਨਿਆਂ ਵਾਲੀ ਸਾਈਟ ਉੱਤੇ ਲਗਭਗ ਸਭ ਕੁਝ ਸਥਿਰ ਸਮੱਗਰੀ ਹੈ: ਨਮੂਨਿਆਂ ਦੇ ਵੇਰਵੇ, ਲੇਖ, ਕੇਸ ਸਟੱਡੀਆਂ, ਟੂਲ ਪੰਨੇ। ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਵਿਜ਼ਿਟਰ ਮੁਤਾਬਕ ਨਹੀਂ ਬਦਲਦਾ, ਇਸ ਲਈ ਹਰ ਬੇਨਤੀ ਉੱਤੇ ਬਣਾਉਣਾ ਬਿਨਾਂ ਫ਼ਾਇਦੇ ਦੇਰੀ ਅਤੇ ਲਾਗਤ ਜੋੜੇਗਾ।
output: "export" ਨਾਲ Next.js ਹਰ ਰੂਟ — generateStaticParams ਨਾਲ ਗਿਣੇ /demos/[slug] ਵਰਗੇ ਗਤੀਸ਼ੀਲ ਰੂਟਾਂ ਸਮੇਤ — ਸਾਦੀਆਂ HTML ਫ਼ਾਈਲਾਂ ਵਜੋਂ ਬਣਾਉਂਦਾ ਹੈ। ਨਤੀਜਾ:
- ਤੇਜ਼ ਪਹਿਲਾ ਦਰਸ਼ਨ — HTML ਪੂਰਾ ਆਉਂਦਾ ਹੈ, ਸਰਵਰ ਰੈਂਡਰ ਸਮੇਂ ਤੋਂ ਬਿਨਾਂ।
- ਘੱਟੋ-ਘੱਟ JavaScript — ਸਰਵਰ ਕੰਪੋਨੈਂਟ ਕਲਾਇੰਟ ਨੂੰ ਕੋਡ ਨਹੀਂ ਭੇਜਦੇ; ਸਿਰਫ਼ ਇੰਟਰਐਕਟਿਵ ਹਿੱਸੇ ਜਾਗਦੇ ਹਨ (ਫ਼ਿਲਟਰ, ਕੈਲਕੁਲੇਟਰ, ਨਮੂਨਾ ਵਿਊਅਰ)।
- ਲਗਭਗ ਸਿਫ਼ਰ ਲਾਗਤ — Cloudflare ਉੱਤੇ ਸਥਿਰ ਫ਼ਾਈਲਾਂ ਕੈਸ਼ ਤੋਂ ਪਰੋਸੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
- ਸੌਖੀਆਂ ਨਾਕਾਮੀਆਂ — ਕੋਈ ਐਪ ਸਰਵਰ ਨਹੀਂ ਜੋ ਡਿੱਗ ਸਕੇ।
ਸਰਵਰ ਅਜੇ ਵੀ ਕਿੱਥੇ ਚਾਹੀਦਾ ਹੈ
ਤਿੰਨ ਚੀਜ਼ਾਂ ਸਥਿਰ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ:
- ਐਡਮਿਨ ਹਿੱਸਾ ਕੋਈ ਵੀ ਸਮੱਗਰੀ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
- ਅੰਕੜਿਆਂ ਅਤੇ ਗ਼ਲਤੀ ਰਿਪੋਰਟਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਐਂਡਪੁਆਇੰਟ ਚਾਹੀਦਾ ਹੈ।
- ਵਪਾਰਕ ਫ਼ੰਕਸ਼ਨ ਸਰਵਰ ਉੱਤੇ ਨਕਾਰੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ, ਸਿਰਫ਼ ਲੁਕਾਏ ਨਹੀਂ।
ਇੱਕ Worker ਸਥਿਰ ਫ਼ਾਈਲਾਂ ਦੇ ਅੱਗੇ ਸਿਰਫ਼ /admin ਅਤੇ /api/* ਲਈ ਖੜ੍ਹਦਾ ਹੈ। ਇਹ ਐਡਮਿਨ ਰੂਟਾਂ ਲਈ ਦਸਤਖ਼ਤ ਕੀਤੀ ਸੈਸ਼ਨ ਕੂਕੀ ਜਾਂਚਦਾ ਹੈ, ਲੌਗਇਨ ਕੋਸ਼ਿਸ਼ਾਂ ਸੀਮਤ ਕਰਦਾ ਹੈ, ਬਿਨਾਂ ਕੂਕੀਜ਼ ਜਾਂ IP ਪਤਿਆਂ ਦੇ Durable Object ਵਿੱਚ ਪੰਨਾ-ਦਰਸ਼ਨ ਗਿਣਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਉੱਤੇ ਸਪਸ਼ਟ ਫ਼ਲੈਗ ਨਾ ਹੋਣ ਤੱਕ ਹਰ ਵਪਾਰਕ ਐਂਡਪੁਆਇੰਟ ਨੂੰ 403 ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਬਾਕੀ ਹਰ ਬੇਨਤੀ ਸਿੱਧੀ ਸਥਿਰ ਫ਼ਾਈਲਾਂ ਨੂੰ ਜਾਂਦੀ ਹੈ।
ਖਰੜੇ ਕਦੇ ਆਨਲਾਈਨ ਨਹੀਂ ਜਾਂਦੇ
ਸਮੱਗਰੀ ਦੀ ਸਥਿਤੀ ਹੁੰਦੀ ਹੈ: ਖਰੜਾ, ਪ੍ਰੀਵਿਊ, ਪ੍ਰਕਾਸ਼ਿਤ ਜਾਂ ਪੁਰਾਲੇਖ। ਬਿਲਡ ਸਿਰਫ਼ ਪ੍ਰਕਾਸ਼ਿਤ ਅਤੇ ਪ੍ਰੀਵਿਊ ਪੰਨੇ ਬਣਾਉਂਦਾ ਹੈ; ਪ੍ਰੀਵਿਊ noindex ਨਾਲ ਹਨ ਅਤੇ ਸੂਚੀਆਂ ਤੇ ਸਾਈਟਮੈਪ ਵਿੱਚ ਨਹੀਂ। ਖਰੜੇ ਕਦੇ ਫ਼ਾਈਲਾਂ ਨਹੀਂ ਬਣਦੇ, ਇਸ ਲਈ ਲੀਕ ਹੋਣ ਲਈ ਕੁਝ ਨਹੀਂ।
ਇੱਕ ਫ਼ਾਈਲ ਵਿੱਚ ਸੁਰੱਖਿਆ ਹੈਡਰ
Workers ਉੱਤੇ ਸਥਿਰ ਫ਼ਾਈਲਾਂ _headers ਫ਼ਾਈਲ ਦਾ ਸਮਰਥਨ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਸੁਰੱਖਿਆ ਹੈਡਰ ਇੱਕ ਵਾਰ ਲਿਖੇ ਜਾਂਦੇ ਹਨ: ਸਖ਼ਤ ਸਮੱਗਰੀ ਸੁਰੱਖਿਆ ਨੀਤੀ ਜੋ ਫ਼ਰੇਮਾਂ ਵਿੱਚ ਸਿਰਫ਼ ਨਮੂਨਾ ਰੈਂਡਰਰ ਦਾ ਮੂਲ ਮਨਜ਼ੂਰ ਕਰਦੀ ਹੈ, X-Content-Type-Options, ਸਾਵਧਾਨ ਰੈਫ਼ਰਰ ਨੀਤੀ ਅਤੇ ਅਨੁਮਤੀ ਨੀਤੀ ਜੋ ਸਾਈਟ ਵੱਲੋਂ ਨਾ ਵਰਤੇ ਸੈਂਸਰ ਬੰਦ ਕਰਦੀ ਹੈ।
ਸਹੀ 404
ਸਥਿਰ ਫ਼ਾਈਲਾਂ ਦੀ ਸੈਟਿੰਗ ਅਣਜਾਣ ਪਾਥਾਂ ਲਈ ਬਣਿਆ 404.html ਅਸਲ 404 ਕੋਡ ਨਾਲ ਪਰੋਸਦੀ ਹੈ, ਇਸ ਲਈ ਸਰਚ ਇੰਜਣ soft-404 ਪੰਨੇ ਇੰਡੈਕਸ ਨਹੀਂ ਕਰਦੇ।
ਸਮਝੌਤੇ
- ਹਰ ਬੇਨਤੀ ਲਈ ਨਿੱਜੀਕਰਨ ਨਹੀਂ। ਗਤੀਸ਼ੀਲ ਹਰ ਚੀਜ਼ ਬ੍ਰਾਊਜ਼ਰ ਜਾਂ Worker ਵਿੱਚ ਚੱਲਣੀ ਚਾਹੀਦੀ ਹੈ।
- ਪ੍ਰਕਾਸ਼ਨ ਲਈ ਮੁੜ ਬਿਲਡ। ਸਮੱਗਰੀ ਤਬਦੀਲੀਆਂ ਲਈ ਬਿਲਡ ਅਤੇ ਡਿਪਲੌਏ ਚਾਹੀਦਾ ਹੈ। ਹਫ਼ਤੇ ਵਿੱਚ ਕੁਝ ਵਾਰ ਬਦਲਣ ਵਾਲੀ ਸਾਈਟ ਲਈ ਇਹ ਫ਼ਾਇਦਾ ਹੈ: ਹਰ ਤਬਦੀਲੀ ਜਾਂਚੀ ਅਤੇ ਵਰਜ਼ਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
- ਬਿਲਟ-ਇਨ ਤਸਵੀਰ ਅਨੁਕੂਲਨ ਨਹੀਂ। ਸਕ੍ਰੀਨਸ਼ਾਟ ਬਣਾਉਣ ਵੇਲੇ WebP ਵਿੱਚ ਬਦਲੇ ਅਤੇ ਪੱਕੇ ਆਕਾਰਾਂ ਵਿੱਚ ਪਰੋਸੇ ਜਾਂਦੇ ਹਨ।
ਪ੍ਰਦਰਸ਼ਨੀ ਸਾਈਟ ਲਈ ਇਹ ਸਮਝੌਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫ਼ਾਇਦੇਮੰਦ ਹਨ: ਨਤੀਜਾ ਤੇਜ਼, ਸਸਤਾ, ਸ਼ੁਰੂ ਤੋਂ ਸੁਰੱਖਿਅਤ ਅਤੇ ਸਮਝਣ ਵਿੱਚ ਸੌਖਾ ਹੈ।