Taylor Otwell ਨੇ Laravel ਨੂੰ ਇੱਕ ਆਧੁਨਿਕ PHP ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਕਿਵੇਂ ਰੂਪ ਦਿੱਤਾ—ਸਾਫ਼ conventions, ਪ੍ਰਯੋਗਿਕ ਟੂਲਿੰਗ, ਅਤੇ ਇੱਕ ਕਮਿਊਨਿਟੀ ਜੋ ਟੀਮਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ।
Laravel ਦੇ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਸਾਰਾ PHP ਵਿਕਾਸ ਐਸਾ ਲੱਗਦਾ ਸੀ ਜਿਵੇਂ ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਤੋਂ ਜੋੜ ਰਹੇ ਹੋ। ਤੁਹਾਡੇ ਕੋਲ ਗੰਭੀਰ ਉਤਪਾਦ ਬਣਾਉਣ ਦੀ ਖਮੀਆ ਸੀ—ਪਰ ਅਕਸਰ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਸਾਰੇ ਫੈਸਲੇ ਲੈਣੇ ਪੈਂਦੇ ਸੀ: ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ, ਰouting ਅਪ੍ਰੋਚ, ਡੇਟਾਬੇਸ ਐਕਸੈਸ ਦਾ ਸਟਾਈਲ, ਫਾਰਮ ਹੈਂਡਲਿੰਗ, authentication, validation, ਅਤੇ ਟੀਮ ਵਿੱਚ ਇਹ ਸਭ ਕਿਵੇਂ ਇਕਸਾਰ ਰਹੇਗਾ। ਬਹੁਤ ਪ੍ਰੋਜੈਕਟ ਆਖਿਰਕਾਰ "ਤੁਹਾਡੇ ਕੰਪਨੀ ਦਾ PHP ਫਰੇਮਵਰਕ" ਬਣ ਜਾਂਦੇ ਸਨ—ਜ਼ਰੂਰੀ ফੈਸਲੇ ਹੱਥੋਂ ਬਣਾਏ ਹੋਏ ਜੋ ਕੰਮ ਕਰਦੇ ਰਹਿੰਦੇ ਜਦ ਤੱਕ ਨਹੀਂ ਕਰਦੇ।
Laravel ਨੇ PHP ਭਾਸ਼ਾ ਨੂੰ "ਠੀਕ" ਨਹੀਂ ਕੀਤਾ ਬਲਕਿ ਇਸ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਰੋਜ਼ਾਨਾ ਅਨੁਭਵ ਨੂੰ ਬੇਹਤਰ ਬਣਾਇਆ। ਇਸ ਨੇ ਆਮ ਕੰਮਾਂ ਨੂੰ ਪੇਸ਼ਗੀ, ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਬਣਾ ਦਿੱਤਾ—ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਜੋ ਡੈਡਲਾਈਨਾਂ ਹੇਠਾਂ ਅਸਲ ਐਪ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ।
ਜਦ ਕਿ ਡਿਵੈਲਪਰ ਕਹਿੰਦੇ ਹਨ Laravel ਨੇ PHP ਨੂੰ ਆਧੁਨਿਕ ਮਹਿਸੂਸ ਕਰਵਾਇਆ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਵਿਵਹਾਰਕ ਗੱਲਾਂ ਦਾ ਜ਼ਿਕਰ ਕਰਦੇ ਹਨ:
ਇਹ ਟੈਕਨੀਕਲ ਫੈਸਲੇ ਜਿੰਨੇ ਵੀ ਉਤਪਾਦੀ ਫੈਸਲੇ ਹਨ—ਅਤੇ ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ Laravel ਨੇ PHP ਵਿੱਚ ਬਣਾਉਣ ਵਾਲਿਆਂ ਦਾ ਤਣਾਵ ਘਟਾਇਆ।
Laravel ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਇਸ ਤਰ੍ਹਾਂ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਦਾ ਇੱਕ ਪਲੇਬੁੱਕ ਹੈ: ਸਾਫ਼ conventions, ਮਜ਼ਬੂਤ ਟੂਲਿੰਗ, ਅਤੇ "ਆਧਿਕਾਰਿਕ" ਹੱਲਾਂ ਦਾ ਇੱਕ ਕੋਹੀਸਿਵ ਸੈੱਟ ਜੋ ਹਰ ਟੀਮ ਨੂੰ ਆਖ਼ਿਰਕਾਰ ਲੋੜੀਂਦੇ ਹਨ। ਇਹ ਈਕੋਸਿਸਟਮ ਪ੍ਰਭਾਵ ਸਧਾਰਨ ਹੈ: ਟੂਲਾਂ ਨੂੰ ਜੁੜਨ ਵਿੱਚ ਘੱਟ ਸਮਾਂ, ਫੀਚਰ ਬਣਾਉਣ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸਮਾਂ।
ਅਗਲੇ ਹਿੱਸਿਆਂ ਵਿੱਚ, ਅਸੀਂ ਉਹ conventions ਵੇਖਾਂਗੇ ਜੋ ਤੁਹਾਨੂੰ ਆਗੇ ਵਧਾਉਂਦੀਆਂ ਹਨ ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਬੰਦ ਕਰਕੇ ਰੱਖਣ ਦੇ, ਉਹ ਟੂਲਿੰਗ ਜੋ ਤੁਹਾਡੇ ਵਰਕਫਲੋਅ ਦੀ ਰਹਿਨੁਮਾਈ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਹ ਕਮਿਊਨਿਟੀ ਰਿਸੋਰਸ ਜੋ ਸਾਰੇ ਅਨੁਭਵ ਨੂੰ ਅਪਣਾਉਣ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
Laravel "ਡਿਫਾਲਟ" ਆਧੁਨਿਕ PHP ਫਰੇਮਵਰਕ ਬਣਨਾ ਕਿਸੇ ਯਾਦਨਸ਼ੀਲ ਘਟਨਾ ਨਹੀਂ ਸੀ। ਇਸਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ Taylor Otwell ਦੀ ਭੂਮਿਕਾ ਹੈ—ਉਹ ਨਾ ਸਿਰਫ਼ ਸਿਰਜਣਹਾਰ ਹੈ ਸਗੋਂ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸਟਿਊਅਰਡ ਵੀ। Laravel ਨੂੰ ਇੱਕ ਇੱਕਲੌਤਾ open-source ਰਿਲੀਜ਼ ਵਾਂਗ ਨਹੀਂ ਦੇਖਿਆ ਗਿਆ; ਉਹ ਇਸਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ ਵਾਂਗ ਗਾਈਡ ਕਰਦੇ ਰਹੇ: ਕੋਰ ਨੂੰ ਸੁਮਤਲ ਰੱਖਣਾ, ਉਮੀਦਾਂ ਸੈੱਟ ਕਰਨਾ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ ਜਦ ਫਰੇਮਵਰਕ ਵਧਦਾ ਹੈ ਤਾਂ ਦਿਨ-ਪਰ-ਦਿਨ ਅਨੁਭਵ ਸੁਖਦ ਹੁੰਦਾ ਰਹੇ।
Taylor ਦੇ ਫੈਸਲੇ ਲਗਾਤਾਰ ਡਿਵੈਲਪਰ ਅਨੁਭਵ ਨੂੰ ਅੱਗੇ ਰੱਖਦੇ ਹਨ: ਸਮਝਦਾਰ ਡਿਫਾਲਟਸ, ਪੜ੍ਹਨਯੋਗ APIs, ਅਤੇ ਉਹ ਵਰਕਫਲੋਅ ਜੋ "ਚਲਾਕ" ਵਜੋਂ ਨਹੀਂ ਪਰ ਸੁਚੱਜੇ ਤਰੀਕੇ ਨਾਲ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਇਹ ਸਿਰਫ਼ Laravel ਨੂੰ ਵਧੀਆ ਬਣਾਉਂਦਾ ਨਹੀਂ—ਇਹ ਸਮੇਂ ਦੇ ਨਾਲ ਐਪ ਬਣਾਉਣ ਅਤੇ ਰੱਖ-ਰੱਖਾਵ ਦੀ ਲਾਗਤ ਘਟਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਕੋਈ ਫਰੇਮਵਰਕ ਤੁਹਾਨੂੰ ਆਮ ਕੰਮ ਇੱਕ ਸਥਿਰ ਤਰੀਕੇ ਨਾਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਟੀਮਾਂ ਪੈਟਰਨਾਂ 'ਤੇ ਵਾਦ-ਵਿਵਾਦ ਕਰਨ ਵਿੱਚ ਘੱਟ ਊਰਜਾ ਲਗਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਜ਼ਿਆਦਾ ਤੌਰ 'ਤੇ ਸ਼ਿਪ ਕਰਨ ਤੇ ਧਿਆਨ ਦਿੰਦੀ ਹਨ। ਨਤੀਜਾ ਇੱਕ ਐਸਾ ਟੂਲ ਹੈ ਜੋ ਨਵੇਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਸੁਆਗਤਯੋਗ ਅਤੇ ਅਨੁਭਵੀ ਲੋਕਾਂ ਲਈ ਨਿਰਾਸ਼ਾਜਨਕ ਨਹੀਂ ਹੁੰਦਾ।
Laravel ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ, ਪੇਸ਼ਗੋਈਯੋਗ ਫੈਸਲਿਆਂ ਰਾਹੀਂ ਭਰੋਸਾ ਕਮਾਉਂਦਾ ਹੈ। ਨਾਂਮਕਰਨ convention, ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ, ਅਤੇ "Laravel ਢੰਗ" ਅਚੰਭੇ ਘਟਾਉਂਦੇ ਹਨ। ਇਹ ਪੇਸ਼ਗੋਈ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਦੋਂ ਤੁਸੀਂ ਅੱਪਗਰੇਡ ਕਰੋ, ਨਵਾਂ ਪੈਕੇਜ ਜੋੜੋ, ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਕਿਸੇ ਹੋਰ ਡਿਵੈਲਪਰ ਨੂੰ ਸੌਂਪੋ, ਤੁਸੀਂ ਫਰੇਮਵਰਕ ਤੋਂ ਇਹ ਉਮੀਦ ਕਰ ਰਹੇ ਹੋ ਕਿ ਇਹ ਕੱਲ੍ਹ ਵਾਂਗ ਹੀ ਵਰਤਾਵ ਕਰੇਗਾ।
ਟਾਈਮ ਦੇ ਨਾਲ, ਇਹ ਇਕਸਾਰਤਾ ਇੱਕ ਬ੍ਰਾਂਡ ਵਾਗ੍ਹਾਂ ਵਾਅਦਾ ਬਣ ਜਾਂਦੀ ਹੈ: ਜੇ ਤੁਸੀਂ Laravel ਦਾ ਇੱਕ ਹਿੱਸਾ ਠੀਕ ਤਰ੍ਹਾਂ ਸਿੱਖ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਬਾਕੀ ਭਾਗ ਆਮ ਤੌਰ 'ਤੇ ਸਮਝਦਾਰ ਹੁੰਦੇ ਹਨ।
Laravel ਮਤਲਬ ਰਾਏਵਾਲਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ escapе-hatches ਛੱਡਦਾ ਹੈ। ਤੁਸੀਂ ਤੇਜ਼ੀ ਲਈ conventions ਨੂੰ ਫਾਲੋ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ ਜਦ ਲੋੜ ਪਏ ਤਾਂ ਕਸਟਮਾਈਜ਼ ਕਰ ਸਕਦੇ ਹੋ—ਕੰਪੋਨੈਂਟ ਬਦਲੋ, ਵਿਹਵਾਰ ਵਧਾਓ, ਜਾਂ ਆਪਣੇ abstraction ਬਣਾਓ।
ਇਹ ਸੰਤੁਲਨ ਪ੍ਰੋਡਕਟ ਮਾਇੰਡਸੈੱਟ ਦਾ ਕਾਰਜ ਹੈ: ਆਮ ਰਾਹ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਆਰਾਮਦਾਇਕ ਬਣਾਓ, ਅਤੇ ਫਰੇਮਵਰਕ ਨੂੰ ਅਸਲੀ ਸੰਸਾਰ ਦੀਆਂ ਜਟਿਲਤਾਵਾਂ ਲਈ ਕਾਫ਼ੀ ਲਚਕੀਲਾ ਰੱਖੋ।
Laravel ਦੀ "conventions over configuration" ਦ੍ਰਿੜਤਾ ਸਕੱਤੀ ਨਿਯਮਾਂ ਬਾਰੇ ਘੱਟ ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਸਮਝਦਾਰ ਸ਼ੁਰੂਆਤ ਦੇਣ ਬਾਰੇ ਵੱਧ ਹੈ। ਜਦੋਂ ਫਰੇਮਵਰਕ ਤੁਹਾਡੇ ਲਈ ਆਮ ਚੋਣਾਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਫੋਲਡਰ ਨਾਂ, ਬੋਇਲਰਪਲੇਟ ਵਾਇਰਿੰਗ, ਜਾਂ ਰੋਜ਼ਾਨਾ ਕੰਮਾਂ ਲਈ "ਸਹੀ ਤਰੀਕਾ" ਲੱਭਣ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਗੁਜ਼ਾਰਦੇ ਹੋ।
ਇੱਕ convention ਇੱਕ ਸਹਿਮਤ ਡਿਫਾਲਟ ਹੁੰਦਾ ਹੈ: ਚੀਜ਼ਾਂ ਕਿੱਥੇ ਜਾਂਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਦੇ ਨਾਮ ਕਿਵੇਂ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਕੁਝ ਨਹੀਂ ਕੀਤਾ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। Laravel ਬਹੁਤ ਸਾਰੀਆਂ ਫੈਸਲਿਆਂ ਨੂੰ ਸ਼ਾਂਤ ਤਰੀਕੇ ਨਾਲ ਮਿਆਰੀ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਵੱਖਰੇ ਤੌਰ 'ਤੇ friction ਪੈਦਾ ਕਰਦੇ।
ਉਦਾਹਰਨ ਲਈ:
app/Http/Controllers ਵਿੱਚ, models app/Models ਵਿੱਚ, views resources/views ਵਿੱਚ.Post ਮਾਡਲ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ posts ਟੇਬਲ ਨਾਲ ਮੈਪ ਹੁੰਦਾ ਹੈ; PostController ਜਿਹੜਾ ਰਿਕਵੇਸਟ-ਹੈਂਡਲਿੰਗ ਰੱਖਦਾ ਹੈ ਉਸਦੀ ਥਾਂ ਸੁਝਾਉਂਦਾ ਹੈ.ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ decision fatigue ਘਟ ਜਾਂਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਹਰ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਲਈ ਇੱਕ ਕਸਟਮ ਆਰਕੀਟੈਕਚਰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਜਾਂ "hello world" ਤੱਕ ਪਹੁੰਚ ਸਕੋ।
Conventions ਟੀਮਾਂ ਦੇ ਅੰਦਰ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ। ਇੱਕ ਨਵੇਂ ਡਿਵੈਲਪਰ ਨੂੰ Laravel ਕੋਡਬੇਸ ਖੋਲ੍ਹ ਕੇ ਸਹੀ ਅੰਦਾਜ਼ਾ ਲੱਗ ਜਾਂਦਾ ਹੈ ਕਿ ਚੀਜ਼ਾਂ ਕਿੱਥੇ ਹਨ—ਕਿਸੇ ਕਸਟਮ ਵਿਕੀ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਨਹੀਂ।
ਇਹ ਪੇਸ਼ਗੋਈ ਹੈਂਡਆਫ਼ਸ ਅਤੇ ਕੋਡ ਰਿਵਿਊਜ਼ ਦੀ ਲਾਗਤ ਘਟਾਉਂਦੀ ਹੈ। ਜਦੋਂ ਹਰ ਕੋਈ ਇਕੋ ਜਿਹਾ ਅਨੁਮਾਨ ਰੱਖਦਾ ਹੈ, ਫੀਡਬੈਕ ਉਤਪਾਦ ਲਾਜਿਕ 'ਤੇ ਕੇਂਦਰਤ ਹੋ ਸਕਦਾ ਹੈ ਬਜਾਏ ਸਟਾਈਲ ਵਾਲੇ ਦੇਬੇਟਾਂ ਦੇ।
Laravel ਦੀਆਂ conventions ਤੁਹਾਨੂੰ ਫਸਾਉਂਦੀਆਂ ਨਹੀਂ। ਇਹ ਡਿਫ਼ੌਲਟ ਹਨ, ਬਾਂਹਾਂ ਨਹੀਂ।
ਨਤੀਜਾ ਇੱਕ ਐਸਾ ਫਰੇਮਵਰਕ ਹੈ ਜੋ ਛੋਟੇ ਪੱਧਰ 'ਤੇ opinionated ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ (ਦਿਨ-ਦਰ-ਦਿਨ ਫੈਸਲੇ) ਪਰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ (ਆਰਕਿਟੈਕਚਰ ਅਤੇ ਸਕੇਲ) ਅਨੁਕੂਲ ਰਹਿੰਦਾ ਹੈ।
Artisan Laravel ਦਾ ਕਮਾਂਡ-ਲਾਈਨ ਟੂਲ ਹੈ, ਅਤੇ ਕਈ ਟੀਮਾਂ ਲਈ ਇਹ ਰੋਜ਼ਾਨਾ ਕੰਮਾਂ ਲਈ "ਫਰੰਟ ਡੋਰ" ਬਣ ਜਾਂਦਾ ਹੈ। ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਭਾਲ ਕਰਨ ਜਾਂ ਫਾਇਲਾਂ ਦੇ ਅਸਥਾਨ ਯਾਦ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ: ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਬਣਾਓ, ਚਲਾਓ, ਜਾਂ ਜਾਂਚੋ।
ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਚੰਗੀਆਂ ਆਦਤਾਂ ਨੂੰ ਡਿਫਾਲਟ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਸਭ ਤੋਂ ਆਸਾਨ ਰਾਹ ਹੀ ਸੁਝਾਇਆ ਗਿਆ ਰਾਹ ਹੋਵੇ, ਟੀਮਾਂ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਇੱਕਸਾਰ ਸਟ੍ਰਕਚਰ ਵੱਲ ਮੁੜਦੀਆਂ ਹਨ ਅਤੇ ਘੱਟ ਇੱਕ-ਆਫ਼ ਹੱਲ ਬਣਦੇ ਹਨ।
Artisan ਆਮ ਕੰਮਾਂ ਨੂੰ ਸਪਸ਼ਟ, ਪੜ੍ਹਨਯੋਗ ਕਮਾਂਡਾਂ ਵਿੱਚ ਗਰਹਿ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਯਾਦ ਨਾ ਵੀ ਰੱਖੋ, ਤਾਂ php artisan list ਨਾਲ ਤੁਸੀਂ ਫੁਟ ਭੀ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਉਪਲੱਬਧ ਹੈ ਜਾਂ ਕਿਸੇ ਇਕ ਕਮਾਂਡ ਲਈ php artisan help migrate ਵਰਗਾ ਮਦਦ ਲੈ ਸਕਦੇ ਹੋ।
ਕੁਝ ਵਰਕਫਲੋਅ ਜੋ ਤੁਸੀਂ ਲਗਾਤਾਰ ਵੇਖੋਗੇ:
ਇਕ CLI-ਪਹਿਲਾ ਵਰਕਫਲੋਅ ਇਹ ਮਿਆਰੀ ਕਰਦਾ ਹੈ ਕਿ ਕੰਮ ਲੈਪਟੌਪ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਕਿਵੇਂ ਚੱਲਦਾ ਹੈ। ਨਵੇਂ ਸਾਥੀ ਨੂੰ "ਸਾਡੀ ਖਾਸ ਸੈਟਅਪ" ਸਿੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ—ਉਹ Laravel ਦੇ ਡਿਫਾਲਟਸ ਸਿੱਖਦੇ ਹਨ, ਜੋ ਬਹੁਤ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਸਮਝੇ ਜਾਂਦੇ ਹਨ।
ਇਸ ਦਾ ਅਮਲ ਵਿੱਚ ਕੀ ਰੂਪ ਹੁੰਦਾ ਹੈ:
# Generate a controller (and optionally resources)
php artisan make:controller BillingController
# Create and run a migration
php artisan make:migration add_status_to_orders_table
php artisan migrate
# Work queues locally
php artisan queue:work
# Run scheduled tasks (often triggered every minute by cron)
php artisan schedule:run
ਫਾਇਦਾ ਸਿਰਫ਼ ਗਤੀ ਨਹੀਂ। ਇਹ ਕਮਾਂਡਾਂ best practices ਨੂੰ ਉਕਸਾਉਂਦੀਆਂ ਹਨ: migrations schema changes ਨੂੰ versioned ਰੱਖਦੇ ਹਨ, queues slow tasks ਨੂੰ request cycle ਤੋਂ ਬਾਹਰ ਭੇਜਦੀਆਂ ਹਨ, ਅਤੇ schedules application code ਦੇ ਨਾਲ-ਨਾਲ ਰਹਿੰਦੇ ਹਨ ਨਾ ਕਿ servers 'ਤੇ ਵਿਖਰੇ ਹੋਏ।
Artisan ਦੋਸਤਾਨਾ ਢੰਗ ਨਾਲ opinionated ਹੈ: ਕਮਾਂਡਾਂ ਤੁਹਾਨੂੰ separation of concerns ਵੱਲ ਧੱਕਦੀਆਂ ਹਨ (jobs ਬੈਕਗ੍ਰਾਉਂਡ ਕੰਮ ਲਈ, policies authorization ਲਈ, ਆਦਿ) ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਸਖ਼ਤ ਬਕਸੇ ਵਿੱਚ ਫਸਾਏ। ਨਤੀਜਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਇੱਕ Laravel ਕੋਡਬੇਸ ਅਕਸਰ ਪਰਿਚਿਤ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ ਭਾਵੇਂ ਤੁਸੀਂ ਕੰਪਨੀ ਬਦਲ ਰਹੇ ਹੋ।
ਇਹ ਵਿਚਾਰ—"ਖੁਸ਼ ਰਾਹ" ਨੂੰ ਟੂਲਾਂ ਵਿੱਚ encode ਕਰੋ—ਸਿਰਫ਼ ਫਰੇਮਵਰਕਾਂ ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ। ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਇੱਕੋ ਜਿਹੀ ਸੋਚ ਨੂੰ chat-driven ਇੰਟਰਫੇਸ ਨਾਲ ਲਗਾਉਂਦਾ ਹੈ: ਖਾਲੀ ਰੀਪੋ ਅਤੇ ਹਜ਼ਾਰ ਚੋਣਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਵਣਾਉਂਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕੀ ਬਣਾ ਰਹੇ ਹੋ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਐਪ (ਵੇਬ, ਬੈਕਐਂਡ, ਜਾਂ ਮੋਬਾਈਲ) ਨੂੰ scaffolds ਅਤੇ ਵਿਕਸਤ ਕਰਦਾ ਹੈ—ਅਜੇ ਵੀ ਤੁਹਾਨੂੰ source code export ਕਰਨ ਅਤੇ snapshots/rollback ਨਾਲ iteration ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ।
Laravel ਦੀ ਡੇਟਾਬੇਸ ਕਹਾਣੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ "ਆਧੁਨਿਕ PHP" ਹਕੀਕਤ ਬਣਦੀ ਹੈ। ਡੇਟਾਬੇਸ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਦੁਨੀਆਂ ਵਜੋਂ ਦੇਖਣ ਦੀ ਥਾਂ, Laravel ਇਸਨੂੰ ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਪਹਿਲਾ ਦਰਜੇ ਦਾ ਹਿੱਸਾ ਬਣਾਉਂਦਾ ਹੈ।
Eloquent Laravel ਦਾ built-in ORM ਹੈ, ਪਰ ਤੁਹਾਨੂੰ acronym ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਵਿਚਾਰ ਸਮਝੋ: ਹਰ ਡੇਟਾਬੇਸ ਟੇਬਲ ਇੱਕ PHP ਕਲਾਸ ਦੁਆਰਾ ਦਰਸਾਈ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਹਰ ਰਿਕਾਰਡ ਇੱਕ ਆਬਜੈਕਟ ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ।
ਇਸ ਤਰ੍ਹਾਂ ਕਈ ਆਮ ਕਾਰਜਾਂ ਲਈ SQL ਲਿਖਣ ਦੀ ਥਾਂ ਤੁਸੀਂ ਕਹਿ ਸਕਦੇ ਹੋ "ਇਸ ਯੂਜ਼ਰ ਨੂੰ ਲੱਭੋ", "ਉਨ੍ਹਾਂ ਦੀ ਈ-ਮੇਲ ਅਪਡੇਟ ਕਰੋ", ਜਾਂ "ਨਵੀਂ ਆਰਡਰ ਬਣਾਓ", ਅਤੇ Eloquent ਪਿੱਛੇ ਡੇਟਾਬੇਸ ਵਿਵਰਣ ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ। ਇਸ ਨੂੰ "active record" ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਮਾਡਲ ਆਬਜੈਕਟ ਸਿਰਫ਼ ਡੇਟਾ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦਾ—ਇਹ ਆਪਣੇ ਆਪ ਨੂੰ ਫੈਚ ਅਤੇ ਸੇਵ ਵੀ ਕਰ ਸਕਦਾ ਹੈ।
Migrations ਵਰਜ਼ਨ-ਕੰਟਰੋਲ ਫਾਈਲਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਡੇਟਾਬੇਸ ਬਦਲਾਅ (ਟੇਬਲ ਬਣਾਉਣਾ, ਕਾਲਮ ਜੋੜਨਾ, ਇੰਡੈਕਸ ਦਾ ਨਾਮ ਬਦਲਣਾ) ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ। ਇਸ ਨਾਲ ਬਦਲਾਅ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਹਨ: ਹਰ ਵਾਤਾਵਰਣ ਨੂੰ ਇਕੋ ਸਕੀਮਾ ਰਾਜ 'ਤੇ ਲਿਆ ਜਾ ਸਕਦਾ ਹੈ ਇੱਕੋ ਹੀ migrations ਚਲਾਕੇ।
Seeders ਇਸ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ by predictable starter data ਪੈਦਾ ਕਰਕੇ—ਲੋਕਲ ਵਿਕਾਸ, ਸਟੇਜਿੰਗ, ਅਤੇ ਡੈਮੋਜ਼ ਲਈ ਵਧੀਆ। migrations + seeders ਮਿਲ ਕੇ "ਮੇਰੇ ਮਸ਼ੀਨ ਤੇ ਚਲਦਾ ਹੈ" drift ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ rollbacks ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ।
Eloquent relationships (ਇੱਕ user has many posts, ਇੱਕ order belongs to customer) ਕੋਡਬੇਸ ਵਿੱਚ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ ਵਰਗੀ ਕਾਰਜ ਕਰਦੀਆਂ ਹਨ। ਜਦੋਂ ਟੀਮ ਇਹ ਰਿਸ਼ਤੇ ਇਕ-ਸਮਝਦਾ ਹੈ, ਤਾਂ ਬਾਕੀ ਐਪ ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ: controllers, services, ਅਤੇ views ਸਾਰੇ ਇੱਕੋ ਮਾਡਲ ਵਾਕ-ਸੰਪਦ ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ।
ਸਹੂਲਤ ਮਹਿੰਗੇ ਕਵੈਰੀਆਂ ਨੂੰ ਛੁਪਾ ਸਕਦੀ ਹੈ। ਆਮ ਖ਼ਤਰਾ over-fetching ਹੈ—ਸੰਬੰਧਿਤ ਡੇਟਾ ਨੂੰ ਇੱਕ-ਇਕ ਰਿਕਾਰਡ ਵਾਰ ਲੋਡ ਕਰਨਾ ("N+1 query" ਸਮੱਸਿਆ)। ਹੱਲ ਆਮ ਤੌਰ 'ਤੇ eager loading ਹੈ: ਜਦੋਂ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਰਿਲੇਸ਼ਨ ਲੋੜਾਂਗੇ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਖੁਲਾਸਾ ਕਰਕੇ ਲੋਡ ਕਰੋ, ਅਤੇ ਟਾਰਗਟਿਡ ਰਹੋ। ਸੋਚ-ਸਮਝ ਕੇ eager loading ਪੇਜਾਂ ਨੂੰ ਤੇਜ਼ ਰੱਖਦੀ ਹੈ ਬਿਨਾਂ ਹਰ ਕਵੈਰੀ ਨੂੰ ਵੱਡੇ ਡੇਟਾ ਡੰਪ ਵਿੱਚ ਬਦਲ ਦੇਵੇ।
Laravel ਦਾ ਫਰੰਟ-ਐਂਡ ਕਹਾਣੀ ਜ਼ਿਆਦਾ pragmatic ਹੈ, ਅਤੇ Blade ਸਭ ਤੋਂ ਵਧੀਆ ਉਦਾਹਰਨ ਹੈ। ਇਹ ਇੱਕ ਟੈਮਪਲੇਟਿੰਗ ਸਿਸਟਮ ਹੈ ਜੋ ਪਹਿਲਾਂ HTML ਵਰਗਾ ਲੱਗਦਾ ਹੈ, ਤੇ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ ਕੁਝ ਸਹਾਇਕ ਨਿਰਦੇਸ਼ (helpers) ਦੇਂਦਾ ਹੈ—ਜਿਵੇਂ dynamic output, conditions, loops, ਅਤੇ layouts।
Blade ਟੈਮਪਲੇਟਸ ਆਮ ਮਾਰਕਅਪ ਵਰਗੇ ਦਿਖਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਕੋਡ ਰਿਵਿਊਜ਼ ਵਿੱਚ ਪੜ੍ਹਨਯੋਗ ਹਨ ਅਤੇ ਟੀਮ ਮੇਂਬਰਾਂ ਵਿਚਕਾਰ ਹینڈਆਫ਼ ਕਰਨ ਵਿਚ ਆਸਾਨ ਹਨ। ਹਰ ਚੀਜ਼ ਲਈ ਇੱਕ ਨਵੀਂ syntax ਬਣਾਉਣ ਦੀ ਥਾਂ, Blade ਕੁਝ ਚੰਗੇ-ਨਾਂ ਵਾਲੇ directives (ਜਿਵੇਂ @if ਅਤੇ @foreach) ਜੋੜਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਜ਼ਰੂਰੀ ਹੋਵੇ PHP ਉਪਲਬਧ ਰੱਖਦਾ ਹੈ।
ਨਤੀਜਾ "ਕਾਫੀ" ਢਾਂਚਾ ਹੈ: ਤੁਹਾਡੇ views ਸਾਫ਼ ਰਹਿੰਦੇ ਹਨ, ਪਰ ਤੁਸੀਂ ਮਹਿਸੂਸ ਨਹੀਂ ਕਰਦੇ ਕਿ ਤੁਸੀਂ ਕਿਸੇ ਫਰੇਮਵਰਕ-ਖਾਸ ਭਾਸ਼ਾ ਨਾਲ ਲੜ ਰਹੇ ਹੋ।
ਜਿਵੇਂ ਐਪ ਵਧਦੇ ਹਨ, ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ UI ਪੈਟਰਨ ਸਮਰਭਾਲ ਸਮੱਸਿਆ ਬਣ ਜਾਂਦੇ ਹਨ—buttons, alerts, navbars, form fields. Blade components ਇਹ ਇੱਕ ਸਧਾਰਨ, ਫਾਇਲ-ਅਧਾਰਿਤ ਪੈਟਰਨ ਨਾਲ ਹੱਲ ਕਰਦੇ ਹਨ:
ਕਿਉਂਕਿ components ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ HTML ਟੈਮਪਲੇਟ ਹਨ, ਉਹ ਕੋਈ ਵੱਡਾ ਧਾਰਮਿਕ ਕੂਟ-ਭਾਈ ਨਹੀਂ ਲਿਆਉਂਦੇ। ਤੁਸੀਂ reuse ਅਤੇ consistency ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ ਬਿਨਾਂ ਇੱਕ ਭਾਰੀ ਫਰੰਟ-ਐਂਡ ਆਰਕੀਟੈਕਚਰ ਬਣਾਉਣ ਦੇ।
Blade ਟੀਮਾਂ ਨੂੰ ਉਹਨਾਂ ਪੈਟਰਨਾਂ ਵੱਲ ਧੱਕਦਾ ਹੈ ਜੋ ਸਕੇਲ ਕਰਦੇ ਹਨ: layout files,.named sections, partials, ਅਤੇ ਪੇਸ਼ਗੀ ਫੋਲਡਰ ਆਰਗੇਨਾਈਜ਼ੇਸ਼ਨ. ਇਹ conventions ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ views ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਬਹੁਤ ਪ੍ਰੋਜੈਕਟ ਚੁਪਚਾਪ "ਹਰ ਪੇਜ ਵੱਖਰਾ" ਕਾਫ਼ਲਾ ਹੋ ਜਾਂਦੇ ਹਨ।
ਜਦੋਂ ਹਰ ਕੋਈ ਇੱਕੋ ਜਿਹਾ layout ਅਤੇ component ਪੈਟਰਨ ਫਾਲੋ ਕਰਦਾ ਹੈ, ਨਵੇਂ ਪੇਜਾਂ ਅਸੈਂਬਲੀ ਕੰਮ ਬਣ ਜਾਂਦੇ ਹਨ ਬਜਾਏ ਕਟਮ ਕਾਰਪੈਂਟਰੀ ਦੇ—ਜ਼ਿਆਦਾ ਤੇਜ਼ ਬਣਾਉਣ ਲਈ, ਆਸਾਨ QA ਲਈ, ਅਤੇ ਡਿਜ਼ਾਈਨ ਬਦਲਣਾ ਸੌਖਾ ਬਣਾਉਣ ਲਈ।
Blade ਇਹ ਦਿਖਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ ਕਿ ਇਹ ਅਧੁਨਿਕ JavaScript ਨੂੰ ਤਿਆਗ ਦੇਵੇ। Laravel ਇੱਕ ਸਕੇਲ ਸਹਾਇਕਤਾ ਦਿੰਦਾ ਹੈ:
ਲਚਕੀਲਾਪਣ ਮਕਸਦ ਹੈ: Blade ਤੁਹਾਨੂੰ ਆਰਾਮਦਾਇਕ ਡਿਫਾਲਟ ਦਿੰਦਾ ਹੈ, ਅਤੇ Laravel ਤੁਹਾਡੇ ਫਰੰਟ-ਐਂਡ ਨੂੰ ਉਤਪਾਦ ਦੀ ਲੋੜ ਅਨੁਸਾਰ ਵਿਕਸਤ ਕਰਨ ਦੀ ਥਾਂ ਛੱਡਦਾ ਹੈ।
ਸ਼ਿਪ ਕਰਨਾ ਸਿਰਫ਼ "deploy ਅਤੇ ਉਮੀਦ ਕਰੋ" ਨਹੀਂ ਹੁੰਦਾ। Laravel ਉਹ ਆਦਤਾਂ ਬੁੰਨਦਾ ਹੈ ਜੋ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਬਣਾਉਂਦੀਆਂ ਹਨ—ਇਹ ਕੁਝ ਐਹੋ ਜਿਹਾ ਹੈ ਜੋ ਤੁਸੀਂ ਰੋਜ਼ ਕਰਦੇ ਹੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਤਬ ਜਦੋਂ ਚੀਜ਼ਾਂ ਖਰਾਬ ਹੋਂਦੀਆਂ ਹਨ।
Laravel ਟੈਸਟਿੰਗ ਨੂੰ ਇੱਕ ਪਹਿਲ-ਕਲਾਸ ਵਰਕਫਲੋਅ ਮੰਨਦਾ ਹੈ, ਨਾ ਕਿ ਇਕ ਐਡ-ਆਨ। ਡਿਫਾਲਟ ਪ੍ਰੋਜੈਕਟ ਸਟ੍ਰਕਚਰ ਇਹ ਮੰਨਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਟੈਸਟ ਲਿਖੋਗੇ, ਅਤੇ ਫਰੇਮਵਰਕ ਤੁਹਾਨੂੰ ਐਸੇ ਹਥਿਆਰ ਦਿੰਦਾ ਹੈ ਜੋ ਟੈਸਟਾਂ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਂਦੇ ਹਨ: HTTP request testing, ਡੇਟਾਬੇਸ assertions, ਅਤੇ realistc ਡੇਟਾ ਬਣਾਉਣ ਲਈ factories।
ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਭਰੋਸਾ ਸਕੇਲ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਵਿਹਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ—authentication, permissions, forms, payments—ਤਾਂ ਤੁਸੀਂ refactor ਕਰਨ, dependencies upgrade ਕਰਨ, ਅਤੇ ਛੋਟੀਆਂ ਬਦਲਾਵਾਂ ਹੋਰ ਜ਼ਿਆਦਾ ਅਕਸਰ ਸ਼ਿਪ ਕਰਨ ਲਈ ਤਿਆਰ ਹੁੰਦੇ ਹੋ। "Move fast" ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
ਅਸਲੀ ਉਤਪਾਦ ਉਹ ਕੰਮ ਕਰਦੇ ਹਨ ਜੋ ਵੈੱਬ ਰਿਕਵੇਸਟ ਦੇ ਦੌਰਾਨ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ: ਇਮੇਲ ਭੇਜਣਾ, PDFs ਬਣਾਉਣਾ, ਚਿੱਤਰਾਂ ਦਾ ਰੀਸਾਈਜ਼ ਕਰਨਾ, third-party APIs ਨਾਲ sync ਕਰਨਾ। Laravel ਇਹ default ਕਹਾਣੀ jobs ਅਤੇ queues ਰਾਹੀਂ ਦਿੰਦਾ ਹੈ।
ਇੱਕ-ਆਫ਼ ਸਕ੍ਰਿਪਟਾਂ ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਹੈਕਸ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕੰਮ ਨੂੰ ਇੱਕ job ਵਜੋਂ ਮਾਡਲ ਕਰੋ, ਇਸ ਨੂੰ queue driver 'ਤੇ ਭੇਜੋ, ਅਤੇ workers ਨੂੰ ਇਸਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ process ਕਰਨ ਦਿਓ। retries, timeouts, ਅਤੇ failed-job tracking ਲਈ ਵੀ sensible ਟੂਲ ਮਿਲਦੇ ਹਨ—ਜੇਕਰ ਯੂਜ਼ਰ ਐਪ 'ਤੇ ਨਿਰਭਰ ਹੋ ਜਾਂਦੇ ਹਨ ਤਾਂ ਇਹ ਸ਼ੀਘਰ ਹੀ ਜ਼ਰੂਰੀ ਬਣ ਜਾਂਦੇ ਹਨ।
Scheduling ਉਹੀ ਫਿਲਾਸਫ਼ੀ ਫਾਲੋ ਕਰਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਸੈਰ-ਸਪਾਟਾ cron entries ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ। Laravel scheduled tasks ਨੂੰ ਕੋਡ ਵਿੱਚ ਕੇਂਦਰਿਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ schedule versioned, reviewable, ਅਤੇ ਹਰ ਵਾਤਾਵਰਣ ਵਿੱਚ consistent ਰਹਿੰਦਾ ਹੈ।
ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ, Laravel ਦੀ logging ਅਤੇ exception handling "ਰਹੱਸਮਈ ਆਊਟੇਜ" ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਅਗਲਾ ਕਦਮ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ। ਲੌਗਜ਼ channels ਅਤੇ levels ਦੇ ਆਧਾਰ 'ਤੇ ਬਣੇ ਹੁੰਦੇ ਹਨ, exceptions ਨੂੰ ਇਕਸਾਰ ਰਿਪੋਰਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਰੇਮਵਰਕ ਅਸਲ failure ਹੇਠਾਂ predictably ਹਥਿਆਰ ਰੱਖਣ ਦੀ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦਾ ਹੈ।
ਆਮ ਥਰੇਡ ਦੁਹਰਣੀਯਤਾ ਹੈ: tests ਜੋ ਤੁਸੀਂ ਮੰਗ 'ਤੇ ਚਲਾ ਸਕਦੇ ਹੋ, background work ਜੋ ਇੱਕ ਸਟੈਂਡਰਡ ਆਕਾਰ ਫਾਲੋ ਕਰਦਾ ਹੈ, scheduled tasks ਜੋ ਕੋਡ ਵਿੱਚ ਨਿਰਧਾਰਿਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ errors ਜੋ ਇੱਕਸਾਰ ਤਰੀਕੇ ਨਾਲ surface ਹੁੰਦੇ ਹਨ। ਭਰੋਸੇਯੋਗਤਾ ਉਹ ਪੈਟਰਨਾਂ ਦਾ ਸੈੱਟ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿਸਨੂੰ ਸਾਰੀ ਟੀਮ ਫੋਲੋ ਕਰ ਸਕਦੀ ਹੈ—ਕੋਈ ਹੀਰੋਇਕਸ ਦੀ ਲੋੜ ਨਹੀਂ।
Laravel ਸਿਰਫ਼ ਫਰੇਮਵਰਕ ਖਾਸੀਅਤਾਂ ਉੱਤੇ ਹੀ "ਆਧੁਨਿਕ PHP" ਨਹੀਂ ਬਣਿਆ। ਕਹਾਣੀ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਇਹ ਹੈ ਕਿ Laravel ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਕੋਡ ਉਧਾਰ ਲੈਣ, ਸਾਂਝਾ ਕਰਨ, ਅਤੇ ਦੁਬਾਰਾ ਵਰਤਣ ਦੀ ਸਮਰੱਥਾ ਮਿਲਦੀ ਹੈ—ਜ਼ਿਆਦਾਤਰ ਤੌਰ 'ਤੇ Composer ਦੀ ਵਜ੍ਹਾ ਨਾਲ।
Composer ਨੇ PHP ਨੂੰ ਡਿਪੈਂਡੇਬਲ, ਸਟੈਂਡਰਡ ਤਰੀਕਾ ਦਿੱਤਾ dependencies ਦਾ ਐਲਾਨ ਕਰਨ, ਉਹਨਾਂ ਨੂੰ install ਕਰਨ, ਅਤੇ ਵਰਜ਼ਨ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਣ ਦਾ। ਇਹ ਮਾਮੂਲੀ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਸਨੇ ਵਰਤਾਰ ਬਦਲ ਦਿੱਤੀ: projects ਵਿੱਚ snippets ਕਾਪੀ ਕਰਨ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਇੱਕ ਪੈਕੇਜ ਇਕ ਵਾਰੀ ਪਬਲਿਸ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਉਸਨੂੰ ਸੁਧਾਰ ਸਕਦੀਆਂ ਹਨ। Laravel ਦਾ ਆਗਮਨ ਉਸ ਸਮੇਂ ਹੋਇਆ ਜਦ PHP ਡਿਵੈਲਪਰਜ਼ ਸਾਂਝੇ ਵਿਕਾਸ ਕਰਨ ਦੇ ਲਈ ਤਿਆਰ ਸਨ।
Laravel extension ਨੂੰ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ। Service providers, facades, configuration publishing, middleware, events, ਅਤੇ macros ਸਾਫ਼ "hooks" ਬਣਾਉਂਦੇ ਹਨ ਜਿੱਥੇ third-party ਕੋਡ ਬਿਨਾਂ ਹੈਕਸ ਦੇ plug in ਕਰ ਸਕਦਾ ਹੈ। ਪੈਕੇਜ ਲੇਖਕ ਇੱਕ ਸਾਫ਼ install ਅਨੁਭਵ ਦੇ ਸਕਦੇ ਹਨ—ਅਕਸਰ ਸਿਰਫ਼ Composer require—ਅਤੇ ਡਿਵੈਲਪਰ ਨੂੰ ਐਸੀ ਫੀਚਰ ਮਿਲਦੀਆਂ ਹਨ ਜੋ native ਜਿਵੇਂ ਲੱਗਦੀਆਂ ਹਨ।
ਇਹ ਜੋੜ (Composer + ਚੰਗੇ extension points) ਇੱਕ ਕਾਮਯਾਬ ਖ਼ਿਆਲ ਨੂੰ ਇੱਕ ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਵਧੀਆ ਬਣਾਇਆ ਹੋਇਆ ਪੈਕੇਜ ਨਾ ਸਿਰਫ਼ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ; ਇਹ ਹੋਰ ਪੈਕੇਜਾਂ ਲਈ ਇੱਕ ਪੈਟਰਨ ਸੈੱਟ ਕਰਦਾ ਹੈ।
ਤੁਸੀਂ ਲਗਭਗ ਹਰ ਲੇਅਰ ਲਈ ਪੈਕੇਜ ਵੇਖੋਗੇ:
ਸਭ ਤੋਂ ਵਧੀਆ ਪੈਕੇਜ Laravel ਨਾਲ ਟਕਰਾਅ ਨਹੀਂ ਕਰਦੇ—ਉਹ ਇਸਦੇ conventions 'ਤੇ ਹੀ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਜ਼ਿਆਦਾ consistent ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ।
ਕਿਸੇ ਪੈਕੇਜ ਨੂੰ ਅਪਨਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਛੋਟਾ ਬੁਨਿਆਦੀ ਚੈੱਕ ਕਰੋ:
ਇੱਕ sehatmand Laravel ਕੋਡਬੇਸ ਆਮ ਤੌਰ 'ਤੇ پੈਕੇਜਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ—ਪਰ "ਰਹੱਸਮਈ ਕੋਡ" 'ਤੇ ਨਹੀਂ। ਸੋਚ-ਸਮਝ ਕੇ ਚੁਣੋ, ਅਤੇ Composer ਇੱਕ multiplier ਬਣ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ ਖਤਰਾ।
Laravel "ਇੱਥੇ ਫਰੇਮਵਰਕ ਹੈ, ਗੁੱਡ ਲੱਕ" ਤੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਇਸਦੇ kohesive ਮਹਿਸੂਸ ਕਰਨ ਦਾ ਕਾਰਨ ਉਹ ਸੈੱਟ ਹੈ ਆਧਿਕਾਰਿਕ ਟੂਲਾਂ ਦਾ ਜੋ ਉਹੀ conventions ਫਾਲੋ ਕਰਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਕੋਡ ਵਿੱਚ ਵਰਤਦੇ ਹੋ। ਇਹ alignment ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਦੋਂ ਫਰੇਮਵਰਕ, ਡਿਪਲੌਇਮੈਂਟ, queues, ਅਤੇ admin UI ਸਭ "Laravel ਵਾਂਗ ਬੋਲਦੇ" ਹਨ, ਤੁਸੀਂ ਉਤਪਾਦ ਭੇਜੇ ਜਾਣ ਅਤੇ tools ਵਿੱਚ ਤਰਜਮਿਆਂ 'ਤੇ ਘੱਟ ਸਮਾਂ ਗੁਜ਼ਾਰਦੇ ਹੋ ਅਤੇ ਵੱਧ ਸਮਾਂ ਸ਼ਿਪ ਕਰਨ 'ਤੇ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਆਖ਼ਿਰਕਾਰ ਇੱਕੋ ਚੈੱਕਲਿਸਟ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ: ਤੁਹਾਨੂੰ ਇੱਕ ਸਰਵਰ, deploy ਪ੍ਰਕਿਰਿਆ, ਅਤੇ ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਨਰਵਸ ਰੀਤਿ ਵਿੱਚ ਨਾ ਬਦਲਣ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ। Laravel ਉਹ ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ ਜੋ ਆਮ ਸੈਟਅਪਾਂ ਨਾਲ ਨਕਸ਼ੇ 'ਤੇ ਫਿਟ ਹੋਂਦੇ ਹਨ।
Laravel Forge ਨਾਲ ਤੁਸੀਂ ਸਰਵਰ provision ਅਤੇ manage ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਖੁਦ scripts ਇਕੱਠੇ ਬਣਾਉਣ ਦੇ। Envoyer ਨਾਲ ਤੁਸੀਂ zero-downtime deployments ਅਤੇ rollbacks ਨੂੰ ਸੰਭਾਲ ਸਕਦੇ ਹੋ ਉਹਨਾਂ ਪੈਟਰਨਾਂ ਨਾਲ ਜੋ Laravel ਡਿਵੈਲਪਰਾਂ ਲਈ ਪਹਿਲੇ ਹੀ ਜਾਣ-ਪਛਾਣ ਵਾਲੇ ਹਨ (environments, release directories, build steps)।
ਜੇ ਤੁਹਾਡੀ ਐਪ serverless ਲਈ ਵਧੀਆ ਹੈ ਤਾਂ Laravel Vapor ਇੱਕ opinionated ਰਾਹ ਦਿੰਦਾ ਹੈ ਜੋ ਫਿਰ ਵੀ ਜਾਣ-ਪਛਾਣ ਵਾਲਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ—ਆਪਣਾ ਐਪ ਕੰਫਿਗਰ ਕਰੋ, ਬਦਲਾਅ push ਕਰੋ, ਅਤੇ ਪਲੇਟਫਾਰਮ scaling ਦੇ ਵਿਵਰਣ ਸੰਭਾਲੇ।
ਅਸਲੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਵਿਸ਼ੀਬਲਟੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। Laravel Horizon ਤੁਹਾਨੂੰ queue workloads (jobs, failures, throughput) ਦੀ ਕੇਂਦਰਿਤ ਨਜ਼ਰ ਦਿੰਦਾ ਹੈ Laravel ਦੇ queue ਸਿਸਟਮ ਦੇ concepts ਨਾਲ ਮਿਲਦੀ-ਜੁਲਦੀ। ਜਨਰਲ ਕਿਊ ਡੈਸ਼ਬੋਰਡ ਨੂੰ custom conventions ਨਾਲ ਜੋੜਨ ਦੀ ਥਾਂ, ਤੁਹਾਨੂੰ ਇੱਕ ਟੂਲ ਮਿਲਦਾ ਹੈ ਜੋ ਫਰੇਮਵਰਕ ਦੇ primitives ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ।
ਬਿਜ਼ਨਸ ਐਪ ਸਾਈਡ 'ਤੇ, Laravel Nova ਇੱਕ practical ਜਵਾਬ ਹੈ recurring ਲੋੜ ਲਈ: ਇੱਕ admin UI। ਇਹ Laravel ਦੇ ਮਾਡਲ ਅਤੇ authorization ਪੈਟਰਨਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਜੋ CRUD-ਭਾਰੀ back offices ਲਈ ਮਨੋਵਿਗਿਆਨਕ ਓਵਰਹੈੱਡ ਘਟਾਉਂਦਾ ਹੈ।
ਇੱਕ ਕੋਹੀਸਿਵ suite ਦੇ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ ਘੱਟ integration projects:
ਤੁਸੀਂ ਫਿਰ ਵੀ third-party ਸੇਵਾਵਾਂ ਮਿਲਾ ਸਕਦੇ ਹੋ ਜਦੋਂ ਲੋੜ ਹੋਵੇ, ਪਰ first-party defaults ਛੋਟੀ ਟੀਮਾਂ ਨੂੰ ਕੋਡ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਇੱਕ ਨਿਰਭਰ "ਖੁਸ਼ ਰਾਹ" ਦਿੰਦੇ ਹਨ।
Laravel ਦੀ ਪਾਲਿਸ਼ ਸਿਰਫ਼ ਕੋਡ ਵਿੱਚ ਹੀ ਨਹੀਂ—ਇਹ ਇਸ ਵਿੱਚ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਤੇਜ਼ੀ ਨਾਲ ਕੋਡ ਨੂੰ ਸਮਝ ਸਕਦੇ ਹੋ। ਡੌਕਸ ਇੱਕ ਪ੍ਰੋਡਕਟ ਵਾਂਗ ਲਿਖੀਆਂ ਗਈਆਂ ਹਨ, ਨਾ ਕਿ API references ਦਾ ਸੰਗ੍ਰਹਿ। ਪੰਨੇ ਇਕ ਸਥਿਰ ਢਾਂਚਾ ਫਾਲੋ ਕਰਦੇ ਹਨ (ਇਹ ਕੀ ਹੈ, ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ), ਉਦਾਹਰਣ ਜੋ ਅਸਲ ਐਪ ਕੰਮ ਨਾਲ ਮੈਪ ਹੁੰਦੇ ਹਨ: request validation, mail ਭੇਜਣਾ, files ਸੰਭਾਲਣਾ, queues ਨਾਲ ਕੰਮ ਕਰਨਾ। ਇਹ ਸਥਿਰਤਾ ਭਰੋਸਾ ਬਣਾਉਂਦੀ ਹੈ: ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਭਾਗ ਸਿੱਖਦੇ ਹੋ, ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਅਗਲਾ ਭਾਗ ਕਿਵੇਂ ਲੇਆਉਟ ਕੀਤਾ ਗਿਆ ਹੋਵੇਗਾ।
Laravel ਦਾ ਇਕ ਵੱਡਾ ਕਾਰਨ ਕਿ "ਚਿ" ਟਿਕਦਾ ਹੈ ਇਹ ਹੈ ਕਿ docs ਤੁਹਾਨੂੰ ਸਹੀ ਆਦਤਾਂ ਸ਼ੁਰੂ ਤੋਂ ਬਣਾ ਕੇ ਦਿਖਾਉਂਦੇ ਹਨ। ਤੁਸੀਂ framework conventions ਵੱਲ ਧੱਕੇ ਜਾਂਦੇ ਹੋ—ਡਾਇਰੈਕਟਰੀ ਸਟ੍ਰਕਚਰ, naming patterns, recommended defaults—ਬਿਨਾਂ ਤਨਾਅ ਮਹਿਸੂਸ ਕੀਤੇ। ਪ੍ਰਾਇਕਟੀਕਲ ਅੱਪਗਰੇਡ ਨੋਟਸ ਅਤੇ ਸਪਸ਼ਟ ਵਰਜ਼ਨਿੰਗ ਵੀ ਵਾਪਸੀ 'ਤੇ ਪ੍ਰੋਜੈਕਟ ਦੇਖਣ ਸਮੇਂ ਚਿੰਤਾ ਘਟਾਉਂਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਉਤਪਾਦ ਨੂੰ maintain ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਸਬਕ ਹੈ: ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ UX ਦਾ ਹਿੱਸਾ ਹੈ। ਇੱਕ ਐਸਾ ਫਰੇਮਵਰਕ ਜੋ ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਹੈ, ਲੋਕ ਰੱਖਦੇ ਹਨ।
ਜਿੱਥੇ docs ਤੁਹਾਨੂੰ "ਕੀ" ਅਤੇ "ਕਿਵੇਂ" ਦਿੰਦੇ ਹਨ, Laracasts "ਮੈਨੂੰ ਨਾਲ ਕਰੋ" ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਢਾਂਚਾਬੱਧ ਸਿਰੀਜ਼ ਅਤੇ ਲਰਨਿੰਗ ਪਾਥ ਕੰਪਿਟੈਂਸ ਬਣਾਉਣ ਦਾ ਸਮਾਂ ਕਮ ਕਰ ਦਿੰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਲਈ ਜੋ ਆਧੁਨਿਕ PHP ਅਭਿਆਸਾਂ ਦੇ ਨਵੇਂ ਹਨ। ਤੁਸੀਂ random tutorials ਤੋਂ ਕਿਉਰੇਟ ਕੋਰਸ ਸਮੇਤ ਇੱਕ ਲੜੀ ਦੀ ਪਾਲਣਾ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਕਦਮ-ਦਰ-ਕਦਮ ਭਰੋਸਾ ਬਣਾਉਂਦੀ ਹੈ।
Laravel ਦੀ community ਇੱਕ ਸਹਾਇਕ ਗੱਲ ਨਹੀਂ—ਇਹ ਫਰੇਮਵਰਕ ਦੇ ਅਪ੍ਰੋਚ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੀ ਹੈ।
ਜਦੋਂ documentation, ਲਰਨਿੰਗ ਸਰੋਤ, ਅਤੇ community ਸਭ ਇੱਕੋ ਦਿਸ਼ਾ ਵਿੱਚ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, conventions ਰੂਲ ਨਹੀਂ ਰਹਿੰਦੇ—ਉਹ ਇੱਕ ਕਾਰਗਰ ਰਾਹ ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਕਾਰਜਸ਼ੀਲ ਐਪ ਤਿਆਰ ਕਰਨ ਲਈ ਆਸਾਨ ਰਾਹ ਦਿਖਾਉਂਦਾ ਹੈ।
Laravel ਦਾ "ਰਾਜ਼" ਕਿਸੇ ਇਕ ਫੀਚਰ ਵਿੱਚ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਦੁਹਰਾਉਣ ਵਾਲਾ ਲੂਪ ਹੈ: ਸਾਫ਼ conventions decision fatigue ਘਟਾਉਂਦੀਆਂ ਹਨ, ਟੂਲਿੰਗ ਖੁਸ਼ ਰਾਹ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ community (ਨਾਲ ਹੀ first-party products) ਇਸ ਖੁਸ਼ ਰਾਹ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਮਿਆਰੀ ਬਣਾਉਂਦਾ ਹੈ।
Conventions: ਉਹ ਡਿਫਾਲਟ ਚੁਣੋ ਜੋ ਸਪਸ਼ਟ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਅਤੇ bikeshedding ਘਟਾਉਂਦੇ ਹਨ।
Tooling: ਡਿਫਾਲਟ ਵਰਕਫਲੋਅ ਨੂੰ frictionless ਬਣਾਓ (create, test, deploy, debug).
Community reinforcement: docs, examples, upgrades, ਅਤੇ support ਰਾਹੀਂ ਇੱਕੋ ਰਾਹ ਸਿਖਾਉਂਦੇ ਰਹੋ।
ਜਦੋਂ ਇਹ ਤਿੰਨ ਮਿਲਦੇ ਹਨ, ਯੂਜ਼ਰ "ਇਹ ਕਿਵੇਂ ਜੋੜਾਂ?" ਪੁੱਛਣਾ ਛੱਡ ਦਿੰਦੇ ਹਨ ਅਤੇ "ਅਗਲੇ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਮੈਂ ਕਿਵੇਂ ਬਣਾਵਾਂ?" ਪੁੱਛਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਕੰਪਨੀ ਵਿੱਚ ਇੱਕ ਪਲੇਟਫਾਰਮ, ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ, ਡੇਟਾ ਟੂਲਕਿਟ, ਜਾਂ ਸਾਂਝੀ ਸੇਵਾਵਾਂ ਬਣਾ ਰਹੇ ਹੋ, ਤਦ ਇਹ ਸਰਚੀਤਰ ਚੁੱਕੋ:
ਇਹੀ ਚੈੱਕਲਿਸਟ ਅਧੁਨਿਕ "vibe-coding" ਟੂਲਿੰਗ ਵਿੱਚ ਵੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ: ਯੂਜ਼ਰ ਸਿਰਫ਼ ਕੱਚੀ ਤਾਕਤ ਨਹੀਂ ਚਾਹੁੰਦੇ—ਉਹ ਇੱਕ ਗਾਈਡ ਕੀਤਾ ਰਾਹ ਚਾਹੁੰਦੇ ਹਨ idea → working app → deployment. ਇਸੇ ਲਈ ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai planning mode, repeatable deployments/hosting, ਅਤੇ snapshot/rollback ਦੀ ਸਮਰੱਥਾ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੇ ਹਨ—ਕਿਉਂਕਿ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਵੇਲੋਸਿਟੀ ਵਰਕਫਲੋਅ ਫੀਚਰ ਹਨ, ਸਿਰਫ਼ ਇੰਨਫ਼ਰਾਸਟਰਕਚਰ ਨਹੀਂ।
ਨਕਲ ਕਰੋ opinionated defaults, ਉਦਾਹਰਣ ਜੋ ਅਸਲ ਐਪ ਵਰਗੇ ਲੱਗਣ, ਅਤੇ support loops ਜੋ consistency ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ ਹਨ।
ਪਰ ਰੋਕੋ ਇਹ ਲਾਲਸਾ ਕਿ ਹਰ ਚੀਜ਼ ਨੂੰ ਕਨਫਿਗਰੇਬਲ ਬਣਾ ਦਿਓ। ਉਸ ਦੀ ਥਾਂ, escape hatches ਦਿਓ: ਦਸਤਾਵੇਜ਼ੀ ਤਰੀਕੇ ਜਿਨ੍ਹਾਂ ਨਾਲ ਉਤਰਾਅ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਸਚਮੁੱਚ ਵੱਖਰਾ ਤਰੀਕਾ ਲੋੜੀਂਦਾ ਹੋਵੇ।
ਸਭ ਤੋਂ ਵਧੀਆ ਈਕੋਸਿਸਟਮ ਬੇਅੰਤ ਵਿਕਲਪਾਂ ਦੀ ਵਿਜੇਤ ਨਹੀਂ ਹੁੰਦੇ; ਉਹ ਸਪਸ਼ਟ, ਸਿੱਖਣਯੋਗ, ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਲਈ ਦਯਾਲੂ ਹੋ ਕੇ ਜਿੱਤਦੇ ਹਨ। ਰਾਹ ਬਾਰੇ ਸਖ਼ਤ ਹੋਵੋ, ਯਾਤਰਾ ਬਾਰੇ ਉਦਾਰ ਹੋਵੋ: "ਕਿਉਂ" ਸਮਝਾਓ, ਆਨ-ਰੈਂਪ ਦਿਓ, ਅਤੇ ਅਗਲਾ ਸਹੀ ਕਦਮ ਆਸਾਨ ਬਣਾਓ।
Laravel ਨੇ ਰੋਜ਼ਾਨਾ ਵਰਕਫਲੋਅ ਨੂੰ ਇੱਕ ਮਿਆਰੀ ਰੂਪ ਦਿੱਤਾ: ਪਹਚਾਣਯੋਗ ਸਟ੍ਰਕਚਰ, ਪ੍ਰਗਟ APIs, ਅਤੇ ਰੂਟਿੰਗ, ਵੈਲੀਡੇਸ਼ਨ, ਆਥ, ਕਿਊ, ਅਤੇ ਟੈਸਟਿੰਗ ਲਈ ਬਣੀ ਹੋਈ ਹੱਲ.
ਪ੍ਰਾਇਕਟੀਕਲ ਤੌਰ 'ਤੇ, ਇਹਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਨਵੇਂ ਕੰਵੈਂਸ਼ਨ ਬਣਾਉਣ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਲੱਗਦਾ ਅਤੇ ਟੀਮ ਫੀਚਰਜ਼ ਸ਼ਿਪ ਕਰਨ 'ਤੇ ਜ਼ਿਆਦਾ ਧਿਆਨ ਦੇ ਸਕਦੀ ਹੈ।
ਇੱਕ opinionated ਫਰੇਮਵਰਕ ਤੇਜ਼ ਡਿਫਾਲਟ ਰਾਹ ਦਿੰਦਾ ਹੈ (ਨਾਮਕਰਨ, ਫੋਲਡਰ, ਪੈਟਰਨ) ਤਾਂ ਜੋ ਟੀਮ ਹਰ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਬੁਨਿਆਦੀ ਗੱਲਾਂ 'ਤੇ ਵਾਦ-ਵਿਵਾਦ ਨਾ ਕਰੇ.
Laravel ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਲਈ ਲਚਕੀਲਾ ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ "escape hatches" ਦਿੰਦਾ ਹੈ (service container bindings, configurable drivers, middleware, custom auth flows) ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਡਿਫਾਲਟ ਤੋਂ ਵੱਧ ਲੋੜ ਰੱਖਦੀ ਹੈ।
Laravel ਦੀਆਂ conventions ਫੈਸਲੇ ਘਟਾਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਇਹ ਆਮ ਚੋਣਾਂ ਨੂੰ ਪੇਸ਼ਗੀ ਤੌਰ 'ਤੇ ਨਿਸ਼ਚਿਤ ਕਰ ਦਿੰਦੇ ਹਨ:
ਇਸ ਨਾਲ onboarding ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਨਵੇਂ ਡਿਵੈਲਪਰ ਨੂੰ ਅੰਦਾਜ਼ਾ ਲਗ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ ਅਤੇ ਕਿਵੇਂ ਐਪ ਨੂੰ ਵਧਾਉਣਾ ਹੈ।
Artisan ਦੋਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਕੰਮਾਂ ਨੂੰ ਕਮਾਂਡਾਂ ਦਾ ਰੂਪ ਦਿੰਦਾ ਹੈ, ਜੋ ਟੀਮਾਂ ਨੂੰ ਇੱਕਸਾਰ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ.
ਰੋਜ਼ਮਰਾ ਦੀਆਂ ਆਮ ਕਮਾਂਡਾਂ ਸ਼ਾਮਲ ਹਨ:
php artisan make:controller … ਫਾਰ ਸਕੈਫੋਲਡਿੰਗ ਲਈEloquent ਮਾਡਲ ਟੇਬਲਾਂ ਦਾ ਪ੍ਰਤੀਨਿਧਿਤ ਕਰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਡੇਟਾ ਨਾਲ PHP ਅਬਜੈਕਟਾਂ ਰਾਹੀਂ ਕੰਮ ਕਰਨ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਕਿ ਹਰ ਓਪਰੇਸ਼ਨ ਲਈ ਹੱਥੋਂ SQL ਲਿਖਣ ਦੀ ਲੋੜ ਨਾ ਪਏ.
ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ:
N+1 ਪ੍ਰਸ਼ਨ ਸਭ ਤੋਂ ਆਮ ਫੇਲ ਹੈ (ਸਬੰਧਿਤ ਡੇਟਾ ਨੂੰ ਇੱਕ-ਇਕ ਰਿਕਾਰਡ ਨਾਲ ਲੋਡ ਕਰਨਾ).
ਪ੍ਰਾਇਕਟੀਕਲ ਹੱਲ:
ਸਹੂਲਤ ਵਧੀਆ ਹੈ—ਪਰ ਜਦੋਂ performance ਮਾਮਲਾ ਬਣੇ ਤਾਂ ਕਵੈਰੀ ਬਿਹੇਵਿਅਰ ਨੂੰ ਸਪਸ਼ਟ ਰੱਖੋ।
Migrations ਡੇਟਾਬੇਸ ਬਦਲਾਅਾਂ ਨੂੰ ਵਰਜ਼ਨ-ਕੰਟਰੋਲ ਕੀਤਾ ਕੋਡ ਰੂਪ ਵਿੱਚ ਰੱਖਦੇ ਹਨ ਤਾਂ ਕਿ ਹਰ ਵਾਤਾਵਰਣ ਨੂੰ ਇੱਕੋ ਹੀ ਸਕੀਮਾ ਰਾਜ ਹਾਲਤ 'ਤੇ ਲਿਆ ਜਾ ਸਕੇ.
Seeders ਲੋਕਲ ਡੈਵ, ਸਟੇਜਿੰਗ, ਅਤੇ ਡੇਮੋਜ਼ ਲਈ ਪੈਟਰਨਦਾਰ ਸਟਾਰਟਰ ਡੇਟਾ ਭਰਨ ਦੇ ਕੰਮ ਆਉਂਦੇ ਹਨ.
ਇਕਠੇ ਹੋ ਕੇ ਇਹ “ਮੇਰੇ ਮਸ਼ੀਨ ਤੇ ਚਲਦਾ ਹੈ” ਵਾਲੀ drift ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ rollback ਅਤੇ onboarding ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ।
Blade Laravel ਦਾ ਟੈਮਪਲੇਟਿੰਗ ਸਿਸਟਮ ਹੈ ਜੋ HTML ਦੇ ਨੇੜੇ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਹਲਕੇ ਡਾਇਰੈਕਟਿਵ (conditions, loops, layouts) ਜੋੜਦਾ ਹੈ.
Blade components ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ UI ਪੈਟਰਨਾਂ ਨੂੰ ਬਿਨਾਂ ਭਾਰੀ ਰੀਅਰਕੀਟੈਕਚਰ ਦੇ ਰੀਯੂਜ਼ ਕਰਨ ਦਾ ਆਸਾਨ ਤਰੀਕਾ ਦਿੰਦੇ ਹਨ:
ਇਹ ਵਰਕਫਲੋਅ server-rendered ਹਿੱਸਿਆਂ ਲਈ ਇੱਕ ਉੱਤਮ ਡਿਫਾਲਟ ਹੈ ਅਤੇ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ ਅਧੁਨਿਕ JS ਨਾਲ ਵੱਧ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ।
Laravel reliability ਨੂੰ ਰੋਜ਼ਾਨਾ ਵਰਕਫਲੋਅ ਦਾ ਹਿੱਸਾ ਮੰਨਦਾ ਹੈ:
ਨਤੀਜਾ: ਘੱਟ "ਡਿਪਲੌਇਮੈਂਟ ਰੀਟੂਅਲ" ਅਤੇ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਵਿਹਾਰ ਜਦੋਂ ਕੋਡਬੇਸ ਵਧਦਾ ਹੈ।
ਪੈਕੇਜਾਂ ਨੂੰ ਅਪਨਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਜੀ ਚੈਕ ਕਰੋ:
Composer reuse ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਸੋਚ-ਸਮਝ ਕੇ ਪੈਕੇਜਾਂ ਚੁਣੋ ਤਾਂ ਜੋ ਕੋਡਬੇਸ ਸਮਝਣ ਯੋਗ ਅਤੇ ਬਦਲਣ ਯੋਗ ਰਹੇ।
php artisan make:migration …php artisan migratephp artisan queue:work ਬੈਕਗ੍ਰਾਉਂਡ ਜਾਬਸ ਲਈphp artisan schedule:run ਸ਼ੈਡਿਊਲਡ ਟਾਸਕ ਲਈCLI ਨੂੰ “ਫਰੰਟ ਡੋਰ” ਵਜੋਂ ਵਰਤਣਾ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਸਹੀ ਰਾਹ 'ਤੇ ਰੱਖਦਾ ਹੈ ਅਤੇ ad-hoc ਸਕ੍ਰਿਪਟਿੰਗ ਘਟਾਉਂਦਾ ਹੈ।