ਇੱਕ ਡਿਵੈਲਪਰ ਨੇ ਇੱਕ ਅੰਦਰੂਨੀ ਟੂਲ ਵਿੱਚ REST API ਨੂੰ tRPC ਨਾਲ ਬਦਲਣ ਲਈ ਦੋ ਹਫ਼ਤੇ ਲਗਾਏ।

ਇਹ ਬਦਲਾਅ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ

ਪੁਰਾਣੇ ਸਟੈਕ (stack) ਕਾਰਨ ਸਾਨੂੰ ਇੱਕ DTO, ਇੱਕ ਵੈਲੀਡੇਟਰ (validator), ਅਤੇ ਫਰੰਟਐਂਡ ਲਈ TypeScript ਟਾਈਪਸ ਦਾ ਇੱਕ ਵੱਖਰਾ ਸੈੱਟ ਬਣਾਈ ਰੱਖਣਾ ਪੈਂਦਾ ਸੀ। ਜੇਕਰ ਬੈਕਐਂਡ ਫੀਲਡ ਦਾ ਨਾਮ ਬਦਲਿਆ ਜਾਂਦਾ, ਤਾਂ ਵੀ API 200 ਰਿਟਰਨ ਕਰਦੀ ਸੀ, UI ਰੈਂਡਰ ਹੁੰਦਾ ਰਹਿੰਦਾ ਸੀ, ਅਤੇ ਬੱਗ (bug) ਸਿਰਫ਼ "undefined" ਵੈਲਯੂਜ਼ ਵਜੋਂ ਸਾਹਮਣੇ ਆਉਂਦਾ ਸੀ। ਟੀਮ ਦੇ ਕਿਸੇ ਵੀ ਮੈਂਬਰ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਗਾਹਕ ਨੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਫੜ ਲਿਆ। REST ਕੰਟਰੈਕਟਸ ਨੇ ਸਮੱਸਿਆ ਨੂੰ ਲੁਕਾ ਦਿੱਤਾ ਸੀ, ਅਤੇ ਵਾਧੂ ਫਾਈਲਾਂ ਨੇ ਅਜਿਹੀ ਮੇਨਟੇਨੈਂਸ ਵਧਾ ਦਿੱਤੀ ਜਿਸਦਾ ਕੋਈ ਫਾਇਦਾ ਨਹੀਂ ਹੋਇਆ।

REST ਸੈੱਟਅੱਪ ਕਿਹੋ ਜਿਹਾ ਸੀ

  • OpenAPI spec – ਇੱਕ ਸਟੈਟਿਕ ਫਾਈਲ ਜੋ ਐਂਡਪੁਆਇੰਟਸ (endpoints) ਦਾ ਵਰਣਨ ਕਰਦੀ ਸੀ ਪਰ ਕਦੇ ਵੀ 'ਸੋਰਸ ਆਫ਼ ਟਰੂਥ' (source of truth) ਵਜੋਂ ਕੰਮ ਨਹੀਂ ਕਰਦੀ ਸੀ।
  • Client SDK generation step – ਇੱਕ CI ਜੌਬ ਜੋ JavaScript ਵੈਪਰ (wrapper) ਤਿਆਰ ਕਰਦੀ ਸੀ।
  • Postman collection – ਇੱਕ ਸਾਂਝਾ ਟੈਸਟਿੰਗ ਆਰਟੀਫੈਕਟ (artifact) ਜਿਸਦੀ ਕੋਈ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ ਸੀ।
  • Manual TypeScript interfaces – ਹੱਥ ਨਾਲ ਲਿਖੇ ਟਾਈਪਸ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਰਵਰ ਦੇ ਨਾਲ ਸਿੰਕ (sync) ਰੱਖਣਾ ਪੈਂਦਾ ਸੀ।

ਹਰ API ਬਦਲਾਅ ਘੱਟੋ-ਘੱਟ ਇਹਨਾਂ ਵਿੱਚੋਂ ਤਿੰਨ ਆਰਟੀਫੈਕਟਸ, ਵੈਲੀਡੇਟਰ ਅਤੇ ਕਿਸੇ ਵੀ ਡਾਊਨਸਟ੍ਰੀਮ fetch ਕਾਲਜ਼ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਸੀ। ਇਹ ਪ੍ਰਕਿਰਿਆ ਗਲਤੀਆਂ ਨਾਲ ਭਰਪੂਰ ਅਤੇ ਹੌਲੀ ਸੀ।

tRPC ਨੇ ਕੋਡਬੇਸ (codebase) ਨੂੰ ਕਿਵੇਂ ਘਟਾਇਆ

tRPC ਵੱਖਰੀ ਕੰਟਰੈਕਟ ਫਾਈਲ ਦੀ ਲੋੜ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਸਰਵਰ ਇੱਕ router type ਐਕਸਪੋਰਟ ਕਰਦਾ ਹੈ; ਕਲਾਇੰਟ ਉਸੇ ਟਾਈਪ ਨੂੰ ਇੰਪੋਰਟ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਬੈਕਐਂਡ ਫੀਲਡ ਦਾ ਨਾਮ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਐਡੀਟਰ ਤੁਰੰਤ ਮਿਸਮੈਚ (mismatch) ਨੂੰ ਫਲੈਗ ਕਰ ਦਿੰਦਾ ਹੈ—ਕੋਈ ਕੋਡ ਚਲਾਉਣ ਜਾਂ ਫੇਲ ਹੋਈ ਰਿਕਵੈਸਟ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ। ਡਿਵੈਲਪਰ ਨੇ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਹਟਾ ਦਿੱਤਾ:

  • OpenAPI spec ਫਾਈਲ।
  • Client SDK generation step।
  • ਅਣਵਰਤੀ Postman collection।
  • Manual TypeScript interfaces ਦਾ ਫੋਲਡਰ।

ਰੈਪੋ (repo) ਹੁਣ ਹੋਰ ਸੁਚਾਰੂ ਹੋ ਗਈ, ਅਤੇ ਫੀਡਬੈਕ ਡਿਪਲਾਈਮੈਂਟ ਤੋਂ ਬਾਅਦ ਦੀ ਬਜਾਏ ਡਿਵੈਲਪਮੈਂਟ ਦੌਰਾਨ ਹੀ ਮਿਲਣ ਲੱਗਾ।

tRPC ਦੀਆਂ ਸੀਮਾਵਾਂ

tRPC ਉਦੋਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਦੋਵੇਂ ਪਾਸੇ TypeScript ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇ। ਇਹ ਹੇਠ ਲਿਖੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਕਮੀਆਂ ਰੱਖਦਾ ਹੈ:

  • ਇੱਕ ਮੋਬਾਈਲ ਟੀਮ Swift ਜਾਂ Kotlin ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ।
  • API ਦੀ ਵਰਤੋਂ ਬਾਹਰੀ ਭਾਈਵਾਲਾਂ (external partners) ਦੁਆਰਾ ਕੀਤੀ ਜਾਣੀ ਹੋਵੇ।
  • ਤੁਹਾਨੂੰ ਇੱਕ ਪਬਲਿਕ, ਭਾਸ਼ਾ-ਅਣਨਿਰਭਰ (language-agnostic) ਇੰਟਰਫੇਸ ਦੀ ਲੋੜ ਹੋਵੇ।

ਮਾਈਗ੍ਰੇਸ਼ਨ (migration) ਲਈ ਅਸਲ ਵਿੱਚ ਕੀ ਚਾਹੀਦਾ ਸੀ

ਦੋ ਹਫ਼ਤਿਆਂ ਦੀ ਇਹ ਕੋਸ਼ਿਸ਼ ਸਿਰਫ਼ ਕਾਪੀ-ਅੰਡ-ਪੇਸਟ ਤੋਂ ਕਿਤੇ ਵੱਧ ਸੀ। ਡਿਵੈਲਪਰ ਨੂੰ ਇਹ ਕਰਨਾ ਪਿਆ:

  • tRPC ਦੇ ਕਲਾਇੰਟ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਹਰ fetch ਕਾਲ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ।
  • Error-handling ਲੌਜਿਕ ਨੂੰ ਐਡਜਸਟ ਕਰਨਾ।
  • ਉਹਨਾਂ UI ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਜੋ ਰੋਅ (raw) HTTP ਰਿਸਪਾਂਸ ਨਾਲ ਜੁੜੇ ਲੋਡਿੰਗ ਅਤੇ ਰੀਟ੍ਰਾਈ ਸਟੇਟਸ (loading and retry states) 'ਤੇ ਨਿਰਭਰ ਸਨ।

ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

  • ਕੀ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਦੋਵੇਂ TypeScript ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ? ਇੱਕ ਸਾਂਝੇ ਟਾਈਪ ਸਿਸਟਮ ਤੋਂ ਬਿਨਾਂ, tRPC ਆਪਣਾ ਮੁੱਖ ਫਾਇਦਾ ਗੁਆ ਲੈਂਦਾ ਹੈ।
  • ਕੀ ਦੋਵੇਂ ਪਾਸਿਆਂ ਲਈ ਇੱਕੋ ਟੀਮ ਜ਼ਿੰਮੇਵਾਰ ਹੈ? ਮਾਲਕੀ ਦੇ ਅੰਤਰ (ownership gaps) ਕੰਟਰੈਕਟ ਡ੍ਰਿਫਟ (contract drift) ਨੂੰ ਦੁਬਾਰਾ ਲਿਆ ਸਕਦੇ ਹਨ।
  • ਕੀ ਤੁਸੀਂ ਕਿਸੇ ਅਸਲ ਬੱਗ ਨੂੰ ਠੀਕ ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਸਿਰਫ਼ ਕਿਸੇ ਟ੍ਰੈਂਡ ਦੇ ਪਿੱਛੇ ਜਾ ਰਹੇ ਹੋ? ਉਤਪਾਦਕਤਾ (productivity) ਵਿੱਚ ਵਾਧਾ ਅਸਲੀ ਹੈ, ਪਰ ਇਸਨੂੰ ਮੌਜੂਦਾ ਸਮੱਸਿਆ (pain point) ਨੂੰ ਹੱਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

2025 ਲਈ ਇੱਕ ਹਾਈਬ੍ਰਿਡ (hybrid) ਪਹੁੰਚ

ਕਈ ਟੀਮਾਂ ਦੋਵੇਂ ਸਟੈਕ ਚਲਾ ਕੇ ਸਹੀ ਸੰਤੁਲਨ (sweet spot) ਲੱਭ ਲੈਂਦੀਆਂ ਹਨ:

  • ਅੰਦਰੂਨੀ ਐਪਲੀਕੇਸ਼ਨ ਲੇਅਰਾਂ ਲਈ tRPC, ਜਿੱਥੇ ਕੋਡਬੇਸ ਪੂਰੀ ਤਰ੍ਹਾਂ TypeScript ਹੈ ਅਤੇ ਇੱਕੋ ਟੀਮ ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟ ਦੀ ਮਾਲਕ ਹੈ।
  • Webhooks, public APIs, ਅਤੇ ਪਾਰਟਨਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਲਈ REST, ਜਿੱਥੇ ਭਾਸ਼ਾ-ਅਣਨਿਰਭਰ (language-agnostic) ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਹਰੇਕ ਸਤਹ (surface) ਲਈ ਸਹੀ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਅੰਦਰੂਨੀ ਡਿਵੈਲਪਮੈਂਟ ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਬਾਹਰੀ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਲੋੜੀਂਦੀ ਖੁੱਲ੍ਹ ਵੀ ਬਣੀ ਰਹਿੰਦੀ ਹੈ।

ਸਿੱਖਿਆ (Takeaway): REST ਨੂੰ tRPC ਨਾਲ ਬਦਲਣ ਨਾਲ ਡੁਪਲੀਕੇਟ ਕੰਟਰੈਕਟ ਆਰਟੀਫੈਕਟਸ ਨੂੰ ਖਤਮ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਐਡਿਟ ਸਮੇਂ ਹੀ ਬੱਗ ਸਾਹਮਣੇ ਲਿਆਂਦੇ ਜਾ ਸਕਦੇ ਹਨ, ਪਰ ਫਾਇਦੇ ਉਦੋਂ ਹੀ ਮਿਲਦੇ ਹਨ ਜਦੋਂ ਪੂਰਾ ਸਟੈਕ TypeScript ਸਾਂਝਾ ਕਰਦਾ ਹੈ ਅਤੇ ਟੀਮ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਲਾਗਤ ਨੂੰ ਸਹਿਣ ਕਰ ਸਕਦੀ ਹੈ। ਇੱਕ ਮਿਸ਼ਰਤ ਰਣਨੀਤੀ ਤੁਹਾਨੂੰ non-TypeScript ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖੇ ਬਿਨਾਂ ਲਾਭ ਉਠਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ।