GraphQL ਕੀ ਹੈ? APIs ਅਤੇ ਡੇਟਾ ਫੈਚਿੰਗ ਲਈ ਸਪਸ਼ਟ ਗਾਈਡ

GraphQL ਕੀ ਹੈ (ਅਤੇ ਕੀ ਨਹੀਂ)

GraphQL ਇੱਕ query language ਅਤੇ APIs ਲਈ runtime ਹੈ। ਸਿੱਧੀ ਗੱਲ: ਇਹ ਇੱਕ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਇੱਕ ਐਪ (ਵੈੱਬ, ਮੋਬਾਈਲ, ਜਾਂ ਕੋਈ ਹੋਰ ਸਰਵਿਸ) API ਨੂੰ ਸਪਸ਼ਟ, ਸੰਰਚਿਤ ਬੇਨਤੀ ਭੇਜ ਕੇ ਡੇਟਾ ਮੰਗ ਸਕਦਾ ਹੈ—ਅਤੇ ਸਰਵਰ ਉਸ ਬੇਨਤੀ ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਜਵਾਬ ਵਾਪਸ ਕਰਦਾ ਹੈ।

ਜੋ ਸਮੱਸਿਆ ਇਹ ਹਲ ਕਰਦਾ ਹੈ

ਬਹੁਤ ਸਾਰੇ APIs ਕਲਾਇਂਟ ਨੂੰ ਉਹੀ ਡਾਟਾ ਲੈਣ 'ਤੇ ਮਜਬੂਰ ਕਰਦੇ ਹਨ ਜੋ ਇੱਕ fix ਕੀਤਾ endpoint ਰਿਟਰਨ ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ ਅਕਸਰ ਦੋ ਮੁੱਦੇ ਵਾਪਰਦੇ ਹਨ:

• Over-fetching: ਉਹ fields ਡਾਊਨਲੋਡ ਕਰਨਾ ਜੋ ਤੁਸੀਂ ਵਰਤਦੇ ਹੀ ਨਹੀਂ।
• Under-fetching: ਇੱਕ ਸਕਰੀਨ ਲਈ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਲਈ ਕਈ ਬੇਨਤੀਆਂ ਭੇਜਣੀਆਂ ਪੈਂਦੀਆਂ ਹਨ।

GraphQL ਨਾਲ ਕਲਾਇਂਟ ਸਿਰਫ਼ ਉਹੀ ਖੇਤਰ ਮੰਗ ਸਕਦਾ ਹੈ ਜੋ ਉਸਨੂੰ ਚਾਹੀਦੇ ਹਨ—ਨਾ ਵੱਧ, ਨਾ ਘੱਟ। ਇਹ ਉਸ ਵੇਲੇ ਖਾਸ ਕਰਕੇ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਵੱਖ-ਵੱਖ ਸਕ੍ਰੀਨਾਂ ਜਾਂ ਐਪਾਂ ਨੂੰ ਇੱਕੋ underlying ਡੇਟਾ ਦੇ ਵੱਖ-ਵੱਖ “ਕਟ” ਚਾਹੀਦੇ ਹੁੰਦੇ ਹਨ।

GraphQL "ਕਿੱਥੇ" ਹੁੰਦਾ ਹੈ

GraphQL ਆਮਤੌਰ 'ਤੇ ਕਲਾਇਂਟ ਐਪਾਂ ਅਤੇ ਤੁਹਾਡੇ ਡੇਟਾ ਸਰੋਤਾਂ ਦੇ ਵਿਚਕਾਰ ਰਹਿੰਦਾ ਹੈ। ਉਹਨਾ ਡੇਟਾ ਸਰੋਤਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ:

• ਡੇਟਾਬੇਸ
• ਮੌਜੂਦਾ REST ਸੇਵਾਵਾਂ
• third‑party APIs
• microservices

GraphQL ਸਰਵਰ ਇੱਕ query ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਹਰ ਮੰਗੇ ਗਏ field ਨੂੰ ਠੀਕ ਸਥਾਨ ਤੋਂ ਲੈ ਕੇ ਆਉਣ ਦਾ ਤਰੀਕਾ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਆਖਰੀ JSON ਜਵਾਬ ਜੋੜਦਾ ਹੈ।

ਇੱਕ ਛੋਟੀ ਸੋਚਣ ਦੀ ਮਿਸਾਲ

GraphQL ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸੋਚੋ ਕਿ ਤੁਸੀਂ ਇੱਕ "ਕਸਟਮ-ਆਕਾਰ" ਦਾ ਜਵਾਬ ਮੰਗ ਰਹੇ ਹੋ:

• ਕਲਾਇਂਟ ਦਿੱਸਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਡੇਟਾ ਕਿਹੜੇ ਆਕਾਰ ਦਾ ਚਾਹੁੰਦਾ ਹੈ।
• ਸਰਵਰ ਉਹੀ ਆਕਾਰ (ਜਿਤਨਾ ਸੰਭਵ ਹੋਵੇ) ਵਾਪਸ ਕਰਦਾ ਹੈ।

GraphQL ਕੀ ਨਹੀਂ

ਕੁਝ ਗੱਲਾਂ ਸਪਸ਼ਟ ਕਰਨ ਲਈ:

• ਇਹ ਡੇਟਾਬੇਸ ਨਹੀਂ ਹੈ (ਇਹ ਤੁਹਾਡਾ ਡੇਟਾ ਸਟੋਰ ਨਹੀਂ ਹੁੰਦਾ)।
• ਇਹ ਆਪੋ-ਆਪ ਵਿੱਚ ਤੇਜ਼ ਨਹੀਂ (ਇਹ ਲੋੜੀ ਬੇਨਤੀ ਟਰਾਂਸਫਰ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ, ਪਰ ਸਰਵਰ ਦਾ ਕੰਮ ਫਿਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ)।
• ਇਹ "REST 2.0" ਨਹੀਂ ਹੈ (ਇਹ ਇੱਕ ਵੱਖਰਾ API ਰਵੱਈਆ ਹੈ ਜਿਸਦੇ ਆਪਣੇ ਫਾਇਦੇ ਅਤੇ ਟਰੇਡ-ਆਫ ਹਨ)।

ਜੇ ਤੁਸੀਂ ਇਸ ਮੁੱਢਲੇ ਪਰਿਭਾਸ਼ਾ—query language + runtime for APIs—ਨੂੰ ਯਾਦ ਰੱਖੋ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਬਾਕੀ ਸਾਰਾ ਠੀਕ ਨਿਰਮਾਣ ਹੋਵੇਗਾ।

GraphQL ਨੇ ਕਿਉਂ ਬਣਾਇਆ ਗਿਆ

GraphQL ਇਕ ਪ੍ਰਯੋਗਿਕ ਪ੍ਰੋਡਕਟ ਪ੍ਰਸ਼ਨ ਦਾ ਹੱਲ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ: ਟੀਮਾਂ APIs ਨੂੰ UI ਸਕ੍ਰੀਨਾਂ ਦੇ ਅਨੁਰੂਪ ਬਣਾਉਣ ਵਿੱਚ ਬਹੁਤ ਵਕਤ ਖਰਚ ਕਰ ਰਹੀਆਂ ਸਨ।

ਪਾਰੰਪਰਿਕ endpoint-ਅਧਾਰਤ APIs ਅਕਸਰ ਇਹ ਫ਼ੈਸਲਾ ਕਰਨ ਤੇ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ ਕਿ ਜਾਂ ਤਾਂ ਅਣਚਾਹੀ ਡਾਟਾ ਭੇਜੋ ਜਾਂ ਲੋੜੀਂਦਾ ਡਾਟਾ ਲੈਣ ਲਈ ਵੱਧ ਕਾਲਾਂ ਕਰੋ। ਜਿਵੇਂ-ਜਿਵੇਂ ਪ੍ਰੋਡਕਟ ਵਧਦੇ ਹਨ, ਇਹ ਘਟਨਾ ਪੇਜ਼ ਸਲੋ, ਕਲਾਇਂਟ ਕੋਡ ਜਟਿਲ ਅਤੇ ਫਰੰਟਐਂਡ-ਬੈਕਐਂਡ ਸਹਯੋਗ ਵਿੱਚ ਮੁਸ਼ਕਲਾਂ ਬਣਾਉਂਦੀ ਹੈ।

ਜਿਨ੍ਹਾਂ ਦਰਦ-ਬਿੰਦੂਆਂ ਨੂੰ GraphQL ਟਾਰਗੇਟ ਕਰਦਾ ਹੈ

Over-fetching ਉਦਾਹਰਨ ਵਜੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ endpoint "ਫੁੱਲ" ਆਬਜੈਕਟ ਰਿਟਰਨ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇੱਕ ਸਕਰੀਨ ਨੂੰ ਸਿਰਫ਼ ਕੁਝ ਫੀਲਡ ਚਾਹੀਦੇ ਹਨ। ਮੋਬਾਈਲ ਪ੍ਰੋਫਾਈਲ ਦੇਖਾਉਣ ਲਈ ਸ਼ਾਇਦ ਸਿਰਫ਼ ਨਾਮ ਅਤੇ avatar ਚਾਹੀਦੇ ਹੋਣ, ਪਰ API addresses, preferences, audit fields ਆਦਿ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ—ਇਸ ਨਾਲ bandwidth ਬਰਬਾਦ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਯੂਜ਼ਰ ਤਜ਼ਰਬੇ 'ਤੇ ਅਸਰ ਪੈ ਸਕਦਾ ਹੈ।

Under-fetching ਵਿਰੋਧੀ ਸਥਿਤੀ ਹੈ: ਕਿਸੇ ਵੀ ਇੱਕ endpoint ਕੋਲ ਉਹ ਸਾਰੀ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੁੰਦੀ ਜੋ ਇੱਕ view ਨੂੰ ਚਾਹੀਦੀ ਹੈ, ਇਸ ਲਈ ਕਲਾਇਂਟ ਨੂੰ ਕਈ ਬੇਨਤੀਆਂ ਭੇਜਣੀਆਂ ਪੈਂਦੀਆਂ ਹਨ ਅਤੇ ਨਤੀਜੇ ਜੋੜਣੇ ਪੈਂਦੇ ਹਨ। ਇਸ ਨਾਲ latency ਵੱਧਦੀ ਹੈ ਅਤੇ partial failures ਦੀ ਸੰਭਾਵਨਾ ਬਣਦੀ ਹੈ।

ਬਿਨਾਂ ਵੱਧ-ਵੱਧ versioning ਦੇ APIs ਨੂੰ ਉਨ੍ਨਤ ਕਰਨਾ

ਬਹੁਤ REST-ਅਨੁਕੂਲ APIs ਬਦਲਾਵ ਦਾ ਜਵਾਬ ਨਵੇਂ endpoints ਜਾਂ versioning (v1, v2, v3) ਨਾਲ਼ ਦੇਂਦੇ ਹਨ। ਵਰਜ਼ਨਿੰਗ ਜ਼ਰੂਰੀ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰੱਖ-ਰਖਾਵ ਦਾ ਕੰਮ ਬਣਾਉਂਦੀ ਹੈ: ਪੁਰਾਣੇ ਕਲਾਇਂਟ ਪੁਰਾਣੀਆਂ ਵਰਜ਼ਨਾਂ ਨੂੰ ਵਰਤਦੇ ਰਹਿੰਦੇ ਹਨ, ਜਦਕਿ ਨਵੀਆਂ ਫੀਚਰਸ ਕਿਤੇ ਹੋਰ ਇਕੱਠੇ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

GraphQL ਦਾ ਰਵੱਈਆ schema ਨੂੰ ਸਮੇਂ ਦੇ ਨਾਲ ਨਵੇਂ fields ਅਤੇ types ਜੋੜ ਕੇ ਵਿਕਸਤ ਕਰਨ ਦਾ ਹੈ, ਜਦਕਿ ਮੌਜੂਦਾ fields ਨੂੰ ਸਥਿਰ ਰਖਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਨਾਲ ਅਕਸਰ "ਨਵੀਂ ਵਰਜ਼ਨ" ਬਣਾਉਣ ਦੇ ਦਬਾਅ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਕ API, ਬਹੁਤ ਸਾਰੇ ਕਲਾਇਂਟ

ਆਧੁਨਿਕ ਪ੍ਰੋਡਕਟ ਬਹੁਤ ਵਾਰ ਸਿਰਫ ਇੱਕ consumer ਨਹੀਂ ਰੱਖਦੇ। ਵੈੱਬ, iOS, Android ਅਤੇ partner integrations ਵੱਖ-ਵੱਖ ਡੇਟਾ ਆਕਾਰ ਚਾਹੁੰਦੇ ਹਨ।

GraphQL ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਇਆ ਗਿਆ ਕਿ ਹਰ ਕਲਾਇਂਟ ਬਿਲਕੁਲ ਉਹੀ fields ਮੰਗ ਸਕਦਾ ਹੈ ਜੋ ਉਸਨੂੰ ਲੋੜ ਹਨ—ਬਿਨਾਂ ਬੈਕਐਂਡ ਨੂੰ ਹਰ ਸਕ੍ਰੀਨ ਜਾਂ ਡਿਵਾਈਸ ਲਈ ਵੱਖ-ਵੱਖ endpoint ਬਣਾਉਣ ਦੀ ਲੋੜ ਪਏ।

GraphQL Schema: API ਦਾ contract

GraphQL API ਦੀ ਪਰਿਭਾਸ਼ਾ ਉਸਦੀ schema ਨਾਲ ਹੁੰਦੀ ਹੈ। ਇਸਨੂੰ ਸਰਵਰ ਅਤੇ ਹਰ ਕਲਾਇਂਟ ਦੇ ਵਿਚਕਾਰ ਇਕ ਸਮਝੌਤਾ ਸਮਝੋ: ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਡਾਟਾ ਕੀ ਹੈ, ਕਿਵੇਂ ਜੁੜਿਆ ਹੈ, ਅਤੇ ਕੀ ਮੰਗਿਆ ਜਾਂ ਸਕਦਾ ਹੈ ਜਾਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਕਲਾਇਂਟ endpoints ਦੀ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਉਂਦੇ—ਉਹ schema ਪੜ੍ਹਕੇ ਖਾਸ ਖੇਤਰ ਮੰਗਦੇ ਹਨ।

Schema ਮੁੱਢਲੇ ਤੱਤ: types, fields, ਸਬੰਧ

Schema types (ਜਿਵੇਂ User ਜਾਂ Post) ਅਤੇ fields (ਜਿਵੇਂ name ਜਾਂ title) ਨਾਲ ਬਣਦਾ ਹੈ। Fields ਹੋਰ types ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦੇ ਹਨ—ਇਸ ਤਰ੍ਹਾਂ GraphQL ਰਿਸ਼ਤਿਆਂ ਨੂੰ ਮਾਡਲ ਕਰਦਾ ਹੈ।

ਹੇਠਾਂ Schema Definition Language (SDL) ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਨ ਹੈ:

type User {
  id: ID!
  name: String!
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
  body: String
  author: User!
  comments: [Comment!]!
}

type Comment {
  id: ID!
  text: String!
  author: User!
  post: Post!
}

ਮਜ਼ਬੂਤ ਟਾਈਪਿੰਗ = execution ਤੋਂ ਪਹਿਲਾਂ validation

ਕਿਉਂਕਿ schema strongly typed ਹੁੰਦੀ ਹੈ, GraphQL ਇੱਕ request ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ validate ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਕੋਈ ਕਲਾਇਂਟ ਕਿਸੇ ਅਜਿਹੇ ਫੀਲਡ ਨੂੰ ਮੰਗਦਾ ਹੈ ਜੋ ਮੌਜੂਦ ਨਹੀਂ (ਉਦਾਹਰਨ ਵਜੋਂ, Post.publishDate ਜਦੋਂ schema 'ਚ ਐਸੀ ਫੀਲਡ ਨਹੀਂ), ਤਾਂ ਸਰਵਰ ਬੇਨਤੀ ਨੂੰ reject ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਹਿੱਸੇਦਾਰ ਤਰੀਕੇ ਨਾਲ ਭਰ ਸਕਦਾ ਹੈ—ਸਪਸ਼ਟ errors ਨਾਲ।

ਸਮੇਂ ਦੇ ਨਾਲ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਿਕਸਤ ਹੋਣਾ

Schemas ਨੂੰ ਵਧਾਉਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਤੁਸੀਂ ਆਮ ਤੌਰ ਤੇ ਨਵੇਂ fields (ਜਿਵੇਂ User.bio) ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਮੌਜੂਦਾ ਕਲਾਇਂਟਾਂ ਨੂੰ ਤੋੜੇ—ਕਿਉਂਕਿ ਕਲਾਇਂਟ ਸਿਰਫ਼ ਉਹੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਜੋ ਉਹ ਮੰਗਦੇ ਹਨ। fields ਹਟਾਉਣਾ ਜਾਂ ਬਦਲਣਾ ਜ਼ਿਆਦਾ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ, ਇਸ ਲਈ ਟੀਮਾਂ ਅਕਸਰ ਪਹਿਲਾਂ fields ਨੂੰ deprecate ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਹੌਲੇ-ਹੌਲੇ ਕਲਾਇਂਟਸ ਨੂੰ migrate ਕਰਦੀਆਂ ਹਨ।

Queries: ਬਿਲਕੁਲ ਉਹੀ ਮੰਗੋ ਜੋ ਲੋੜ ਹੈ

GraphQL API ਆਮਤੌਰ 'ਤੇ ਇੱਕ single endpoint ਰਾਹੀਂ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਉਦਾਹਰਨ /graphql)। ਕਈ URLs (ਜਿਵੇਂ /users, /users/123, /users/123/posts) ਦੇ ਬਦਲੇ, ਤੁਸੀਂ ਇੱਕ query ਇੱਕ ਹੀ ਥਾਂ ਤੇ ਭੇਜ ਕੇ ਉਸ ਵਿੱਚ ਉਹ ਖੇਤਰ ਵੇਰਵਾ ਕਰਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਵਾਪਸ ਚਾਹੁੰਦੇ ਹੋ।

Fields ਚੁਣਨਾ (ਨੈਸਟਡ ਡੇਟਾ ਸਮੇਤ)

ਇੱਕ query ਬੁਨਿਆਦੀ ਤੌਰ ਤੇ ਖੇਤਰਾਂ ਦੀ "ਸ਼ਾਪਿੰਗ ਲਿਸਟ" ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਸਧਾਰਨ ਖੇਤਰ (ਜਿਵੇਂ id ਅਤੇ name) ਅਤੇ ਨੈਸਟਡ ਡੇਟਾ (ਜਿਵੇਂ ਇੱਕ ਯੂਜ਼ਰ ਦੇ ਹਾਲੀਆ posts) ਇੱਕੋ ਬੇਨਤੀ ਵਿੱਚ ਮੰਗ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਵਾਧੂ ਫੀਲਡਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕੀਤੇ।

ਇੱਕ ਛੋਟੀ ਉਦਾਹਰਨ:

query GetUserWithPosts {
  user(id: "123") {
    id
    name
    posts(limit: 2) {
      id
      title
    }
  }
}

ਇੱਕ ਪੇਸ਼ ਗੋਈ ਜਵਾਬ ਆਕਾਰ

GraphQL responses predictable ਹੁੰਦੇ ਹਨ: ਜੋ JSON ਤੁਸੀਂ ਲੈਂਦੇ ਹੋ ਉਹ ਤੁਹਾਡੇ query ਦੀ ਸਾਂਝੀ ਰਚਨਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਇਹ ਫਰੰਟਐਂਡ 'ਤੇ ਕੰਮ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਇਹ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਉਣਾ ਪੈਂਦਾ ਕਿ ਡੇਟਾ ਕਿੱਥੇ ਹੋਏਗਾ ਜਾਂ ਵੱਖ-ਵੱਖ ਫਾਰਮੈਟਾਂ ਨੂੰ parse ਕਰਨਾ ਪਵੇਗਾ।

ਸਧਾਰਨ ਅਉਟਲਾਈਨ ਸ਼ਾਇਦ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗ ਸਕਦੀ ਹੈ:

{
  "data": {
    "user": {
      "id": "123",
      "name": "Sam",
      "posts": [
        { "id": "p1", "title": "Hello GraphQL" },
        { "id": "p2", "title": "Queries in Practice" }
      ]
    }
  }
}

ਜੇ ਤੁਸੀਂ ਕਿਸੇ field ਦੀ ਮੰਗ ਨਹੀਂ ਕੀਤੀ, ਉਹ ਸ਼ਾਮਿਲ ਨਹੀਂ ਹੋਏਗਾ। ਜੇ ਤੁਸੀਂ ਮੰਗਿਆ, ਤਾਂ ਤੁਸੀਂ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਉਹ ਉਸੇ ਥਾਂ ਤੇ ਮਿਲੇਗਾ—ਇਸ ਨਾਲ GraphQL queries ਹਰ ਸਕਰੀਨ ਜਾਂ ਫੀਚਰ ਲਈ ਬਿਲਕੁਲ ਲੋੜੀਂਦਾ ਡਾਟਾ ਲੈਣ ਦਾ ਸਾਫ਼ ਤਰੀਕਾ ਬਣ ਜਾਂਦੇ ਹਨ।

Mutations: ਡਾਟਾ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਲਿਖਣਾ

Queries ਪੜ੍ਹਨ ਲਈ ਹੁੰਦੇ ਹਨ; mutations ਉਹ ਤਰੀਕਾ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ GraphQL API ਵਿੱਚ ਡੇਟਾ ਬਦਲਦੇ ਹੋ—ਬਣਾਉਣਾ, ਅੱਪਡੇਟ ਕਰਨਾ, ਜਾਂ ਹਟਾਉਣਾ।

ਆਮ mutation ਫ਼ਲੋ

ਜਿਆਦਾਤਰ mutations ਇੱਕੋ ਹੀ ਪੈਟਰਨ ਫਾਲੋ ਕਰਦੇ ਹਨ:

1. Inputs: ਕਲਾਇਂਟ ਇੱਕ structured input (ਅਕਸਰ input object) ਭੇਜਦਾ ਹੈ, ਜਿਵੇਂ ਅੱਪਡੇਟ ਕਰਨ ਵਾਲੇ ਫੀਲਡ।
2. Validation & authorization: ਸਰਵਰ ਜਾਂਚਦਾ ਹੈ ਕਿ ਲੋੜੀਂਦੇ ਖੇਤਰ ਹਨ, ਡਾਟਾ ਫਾਰਮੈਟ ਠੀਕ ਹਨ, uniqueness ਆਦਿ, ਅਤੇ ਕਿ ਯੂਜ਼ਰ ਕੋਲ ਇਹ ਕੰਮ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ।
3. Write: ਸਰਵਰ ਡੇਟਾਬੇਸ ਚੇਨਜ ਕਰਦਾ ਹੈ (ਜਾਂ ਕਿਸੇ ਹੋਰ ਸਰਵਿਸ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ)।
4. Payload/return type: ਸਰਵਰ ਇੱਕ ਨਿਰਭਰ ਨਤੀਜੇ ਦੀ ਸ਼ਕਲ ਵਾਪਸ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ UI ਅੱਪਡੇਟ ਹੋ ਸਕੇ।

mutations ਡਾਟਾ ਕਿਉਂ ਵਾਪਸ ਕਰਦੀਆਂ ਹਨ

GraphQL mutations ਆਮ ਤੌਰ 'ਤੇ ਉਦੇਸ਼ਪੂਰਕ ਤੌਰ 'ਤੇ ਡਾਟਾ ਵਾਪਸ ਕਰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ “success: true”। ਅੱਪਡੇਟ ਕੀਤੀ ਗਈ ਆਬਜੈਕਟ (ਜਾਂ ਘੱਟੋ-ਘੱਟ ਉਸਦੀ id ਅਤੇ ਮੁੱਖ ਫੀਲਡ) ਵਾਪਸ ਕਰਨ ਨਾਲ UI:

• ਤੁਰੰਤ ਸਕਰੀਨ ਅੱਪਡੇਟ ਕਰ ਸਕਦੀ ਹੈ ਬਿਨਾਂ ਇੱਕ ਹੋਰ ਗੋਲ-ਚੱਕਰ ਦੇ
• cached ਡਾਟਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ refresh ਕਰ ਸਕਦੀ ਹੈ (Apollo Client ਵਰਗੇ clients ਨਾਲ ਆਮ)
• ਫੀਲਡ-ਸਤਰ ਦੀਆਂ errors ਨੂੰ ਸੰਦੇਸ਼ ਵਿੱਚ ਦਿਖਾ ਸਕਦੀ ਹੈ

ਇੱਕ ਆਮ ਡਿਜ਼ਾਈਨ “payload” ਟਾਈਪ ਹੈ ਜੋ ਅੱਪਡੇਟਡ entity ਅਤੇ ਕੋਈ errors ਦੋਹਾਂ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ।

ਬੁਨਿਆਦੀ mutation ਉਦਾਹਰਨ

mutation UpdateEmail($input: UpdateUserEmailInput!) {
  updateUserEmail(input: $input) {
    user {
      id
      email
    }
    errors {
      field
      message
    }
  }
}

UI-ਚਲਿਤ APIs ਲਈ ਇੱਕ ਚੰਗਾ ਨਿਯਮ ਹੈ: ਅਗਲੇ ਸਟੇਟ ਨੂੰ ਰੈਨਡਰ ਕਰਨ ਲਈ ਜੋ ਚਾਹੀਦਾ ਹੈ ਉਹ ਵਾਪਸ ਕਰੋ (ਉਦਾਹਰਨ ਦੇ ਤੌਰ ਤੇ, ਅੱਪਡੇਟਡ user ਅਤੇ ਕੋਈ errors)। ਇਹ ਕਲਾਇਂਟ ਨੂੰ ਸਧਾਰਨ ਰੱਖਦਾ ਹੈ, ਬਦਲਾਅ ਬਾਰੇ ਅੰਦਾਜ਼ਾ ਕਰਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ, ਅਤੇ ਫੇਲ੍ਹ ਰਹੇ ਹਾਲਤਾਂ ਨੂੰ ਨਰਮਾਈ ਨਾਲ ਸੰਭਾਲਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।

Resolvers: GraphQL ਨਤੀਜਾ ਕਿਵੇਂ ਤਿਆਰ ਕਰਦਾ ਹੈ

GraphQL schema ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਮੰਗਿਆ ਜਾ ਸਕਦਾ ਹੈ। Resolvers ਦੱਸਦੇ ਹਨ ਕਿ ਅਸਲ ਵਿੱਚ ਉਸਨੂੰ ਕਿਵੇਂ ਲਿਆਉਣਾ ਹੈ। Resolver ਇੱਕ function ਹੁੰਦਾ ਹੈ ਜੋ schema ਵਿੱਚ ਕਿਸੇ ਖਾਸ field ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਕਲਾਇਂਟ ਉਹ field ਮੰਗਦਾ ਹੈ, GraphQL ਉਸ resolver ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ ਤਾਂ ਕਿ ਮੁੱਲ fetch ਜਾਂ compute ਹੋ ਸਕੇ।

Resolvers “field-level” functions ਹੁੰਦੇ ਹਨ

GraphQL query ਨੂੰ execute ਕਰਦਿਆਂ requested shape ਨੂੰ walk ਕਰਦਾ ਹੈ। ਹਰ field ਲਈ, ਉਹ matching resolver ਲੱਭਦਾ ਹੈ ਅਤੇ ਉਸਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਕੁਝ resolvers ਸਿਰਫ਼ ਮੈਮੋਰੀ ਵਿੱਚ ਮੌਜੂਦ object ਦੀ property ਵਾਪਸ ਕਰਦੇ ਹਨ; ਹੋਰ ਕਿਸੇ ਡੇਟਾਬੇਸ, ਹੋਰ ਸਰਵਿਸ, ਜਾਂ ਕਈ ਸਰੋਤਾਂ ਨੂੰ ਜੋੜ ਕੇ ਮੁੱਲ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ।

ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ schema 'ਚ User.posts ਹੈ, ਤਾਂ posts resolver userId ਨਾਲ posts ਟੇਬਲ ਨੂੰ query ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਅਲੱਗ Posts ਸਰਵਿਸ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ।

schema fields ਨੂੰ data sources ਨਾਲ ਮੈਪ ਕਰਨਾ

Resolvers schema ਅਤੇ ਤੁਹਾਡੇ ਅਸਲੀ ਸਿਸਟਮਾਂ ਵਿਚਕਾਰ glue ਹਨ:

• Databases: SQL/NoSQL queries, stored procedures, ORM calls
• Services: REST/gRPC calls, internal microservices, third-party APIs
• Computed fields: totals, formatting, derived values

ਇਹ mapping ਲਚਕੀਲਾ ਹੈ: ਤੁਸੀਂ ਬੈਕਐਂਡ implementation ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕਲਾਇਂਟ query shape ਬਦਲੇ—ਜਦ ਤਕ schema ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ।

ਪ੍ਰਦਰਸ਼ਨ: slow resolver chains (N+1) ਤੋਂ ਬਚਾਓ

ਕਿਉਂਕਿ resolvers ਹਰ field ਅਤੇ ਸੂਚੀ ਦੇ item ਲਈ ਚੱਲ ਸਕਦੇ ਹਨ, ਬੜੀ ਆਸਾਨੀ ਨਾਲ ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ ਕਾਲਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ (ਉਦਾਹਰਨ: 100 users ਲਈ posts ਵੱਖ-ਵੱਖ 100 queries ਨਾਲ ਫੈਚ ਕਰਨਾ)। ਇਹ “N+1” ਪੈਟਰਨ ਜਵਾਬ ਨੂੰ ਹੌਲੀ ਕਰ ਸਕਦਾ ਹੈ।

ਆਮ ਸੋਧਾਂ ਵਿੱਚ batching ਅਤੇ caching ਸ਼ਾਮਲ ਹਨ (ਉਦਾਹਰਨ: IDs ਇਕੱਠੇ ਕਰ ਕੇ ਇੱਕ query), ਅਤੇ ਉਹਨਾਂ nested fields ਬਾਰੇ ਸੋਚ-ਵਿਚਾਰ ਕਰਨਾ ਜੋ ਤੁਸੀਂ clients ਨੂੰ ਅਪੀਲ ਕਰਨ ਲਈ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦੇ ਹੋ।

ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਅਤੇ validation ਕਿੱਥੇ ਹੁੰਦੇ ਹਨ

Authorization ਅਕਸਰ resolvers (ਜਾਂ shared middleware) ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ resolvers ਜਾਣਦੇ ਹਨ ਕੌਣ ਮੰਗ ਰਿਹਾ ਹੈ (context ਰਾਹੀਂ) ਅਤੇ ਕਿਹੜਾ ਡੇਟਾ ਉਹ ਐਕਸੇਸ ਕਰ ਰਿਹਾ ਹੈ। Validation ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਸਤਰਾਂ 'ਤੇ ਹੁੰਦੀ ਹੈ: GraphQL ਤਰ੍ਹਾਂ ਦੀ/ਆਕਾਰ ਦੀ validation ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਕਰਦਾ ਹੈ, ਜਦਕਿ resolvers ਵਿਅਵਸਾਇਕ ਨਿਯਮ (ਜਿਵੇਂ "ਸਿਰਫ਼ admins ਇਹ field ਸੈਟ ਕਰ ਸਕਦੇ ਹਨ") ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ।

Errors ਅਤੇ Partial Results

GraphQL ਨਵੇਂ ਲੈਣ ਵਾਲਿਆਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ request "ਸਫ਼ਲ" ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਫਿਰ ਵੀ errors ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ GraphQL field-ਅਧਾਰਿਤ ਹੈ: ਜੇ ਕੁਝ fields resolve ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਹੋਰ ਨਹੀਂ, ਤਾਂ ਤੁਹਾਨੂੰ partial data ਵਾਪਸ ਮਿਲ ਸਕਦਾ ਹੈ।

Errors ਕਿਸ ਤਰ੍ਹਾਂ ਲੱਗਦੇ ਹਨ

ਇੱਕ ਆਮ GraphQL response ਵਿੱਚ ਦੋਹਾਂ data ਅਤੇ errors array ਹੋ ਸਕਦੇ ਹਨ:

{
  "data": {
    "user": {
      "id": "123",
      "email": null
    }
  },
  "errors": [
    {
      "message": "Not authorized to read email",
      "path": ["user", "email"],
      "extensions": { "code": "FORBIDDEN" }
    }
  ]
}

ਇਹ ਲਾਭਦਾਇਕ ਹੈ: ਕਲਾਇਂਟ ਜੋ ਕੁਝ ਹੈ ਉਹ render ਕਰ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, user profile) ਜਦਕਿ ਗੁੰਮ ਹੋਏ ਫੀਲਡ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।

Field-level errors vs request-level failures

• Field-level errors execution ਦੌਰਾਨ ਹੁੰਦੀਆਂ ਹਨ (ਜਦੋਂ resolver throw ਕਰਦਾ ਹੈ, permission check fail ਹੁੰਦੀ ਹੈ, ਜਾਂ downstream service timeout ਹੋ ਜਾਵੇ)। ਹੋਰ fields ਫਿਰ ਵੀ resolve ਹੋ ਸਕਦੇ ਹਨ।
• Request-level failures execution ਨੂੰ ਰੋਕਦੇ ਹਨ (invalid JSON, malformed query, schema ਖ਼ਿਲਾਫ validation errors)। ਐਸਿਆਂ ਹਾਲਤਾਂ ਵਿੱਚ data ਅਕਸਰ null ਹੁੰਦਾ ਹੈ।

ਉਪਭੋਗਤਾ ਲਈ ਸੁਖਾਲੇ mensagem ਬਿਨਾਂ ਅੰਦਰੂਨੀ ਵੇਰਵੇ ਦੇ

Error messages ਨੂੰ end user ਲਈ ਲਿਖੋ, debugging ਲਈ ਨਹੀਂ। stack traces, database names, ਜਾਂ ਅੰਦਰੂਨੀ IDs ਪ੍ਰਗਟ ਕਰਨ ਤੋਂ ਬਚੋ। ਚੰਗਾ ਪੈਟਰਨ ਇਹ ਹੈ:

• ਇੱਕ ਛੋਟਾ, ਸੁਰੱਖਿਅਤ message
• ਇੱਕ ਸਥਿਰ machine-readable extensions.code
• ਓਪਸ਼ਨਲ metadata ਜੋ ਸੁਰੱਖਿਅਤ ਹੋ (ਉਦਾਹਰਨ: retryable: true)

ਵਿਸ਼ਤਾਰਤ error ਨੂੰ server-ਸਾਈਡ ਤੇ request ID ਨਾਲ ਲੌਗ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਬਿਨਾਂ ਅੰਦਰੂਨੀ ਜਾਣਕਾਰੀ ਖੋਲ੍ਹੇ ਜਾਂਚ ਕਰ ਸਕੋ।

ਕਲਾਇਂਟਾਂ ਵਿੱਚ ਲਗਾਤਾਰ ਹੈਂਡਲਿੰਗ ਲਈ ਟਿਪਸ

ਆਪਣੇ web ਅਤੇ mobile apps ਲਈ ਇੱਕ ਛੋਟਾ error “contract”.define ਕਰੋ: ਆਮ extensions.code ਮੁੱਲ (ਜਿਵੇਂ UNAUTHENTICATED, FORBIDDEN, BAD_USER_INPUT), ਕਦੋਂ toast ਦਿਖਾਉਣਾ ਹੈ ਬਨਾਮ inline field errors, ਅਤੇ partial data ਨੂੰ ਕਿਵੇਂ handle ਕਰਨਾ ਹੈ। ਇੱਥੇ ਸਥਿਰਤਾ ਹਰ ਕਲਾਇਂਟ ਵੱਲੋਂ ਵੱਖਰੇ ਨਿਯਮ ਬਣਾਉਣ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।

Subscriptions: Real-Time Updates

Subscriptions GraphQL ਦੀ ਢੰਗ ਹੈ ਜਿਸ ਨਾਲ ਕਲਾਇਂਟਾਂ ਨੂੰ ਜਿਵੇਂ-ਜਿਵੇਂ ਡੇਟਾ ਬਦਲਦਾ ਹੈ ਉਹ ਤੁਰੰਤ push ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਬਜਾਏ ਇਸਦੇ ਕਿ ਕਲਾਇਂਟ ਹਰ ਵਾਰੀ ਪੁੱਛੇ। ਇਹ ਆਮਤੌਰ 'ਤੇ persistent connection (ਜ਼ਿਆਦਾਤਰ ਵੈਬਸਾਕਟਸ) ਤੇ ਡਿਲਿਵਰ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਜੋ ਸਰਵਰ ਤੁਰੰਤ events ਭੇਜ ਸਕੇ।

Subscriptions ਕੀ ਹਨ (ਅਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ)

Subscription ਕਾਫੀ ਹਦ ਤੱਕ query ਵਰਗੀ ਹੀ ਹੁੰਦੀ ਹੈ, ਪਰ ਨਤੀਜਾ ਇੱਕ ਹੀ ਜਵਾਬ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਇੱਕ results ਦੀ stream ਹੁੰਦੀ ਹੈ—ਹਰ ਇਕ event ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ।

ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, ਇੱਕ ਕਲਾਇਂਟ ਕਿਸੇ topic ਨੂੰ “subscribe” ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ: chat ਐਪ ਵਿੱਚ messageAdded)। ਜਦੋਂ ਸਰਵਰ event publish ਕਰਦਾ ਹੈ, ਕਿਸੇ ਵੀ connected subscribers ਨੂੰ subscription ਦੇ selection set ਨਾਲ ਮਿਲਦਾ payload ਭੇਜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਆਮ ਵਰਤੇ ਜਾਂਦੇ ਕੇਸ

Subscriptions ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਚਮਕਦਾਰ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਤਬਦੀਲੀਆਂ ਤੁਰੰਤ ਚਾਹੀਦੀਆਂ ਹਨ:

• ਚੈਟ ਮੈਸੇਜ ਜੋ ਬਿਨਾਂ refresh ਦੇ 룸 ਵਿੱਚ ਆ ਜਾਂਦੇ ਹਨ
• ਨੋਟੀਫਿਕੇਸ਼ਨ (mentions, order status changes, alerts)
• ਲਾਈਵ ਡੈਸ਼ਬੋਰਡ (ਸਿਸਟਮ ਹੈਲਥ, ਲੌਜਿਸਟਿਕਸ, trading, ਖੇਡ ਸਕੋਰ)

Subscriptions vs polling

Polling ਵਿੱਚ ਕਲਾਇਂਟ ਹਰ N ਸਕਿੰਟਾਂ 'ਚ ਪੁੱਛਦਾ ਹੈ “ਕੋਈ ਨਵਾਂ ਹੈ?”। ਇਹ ਸਾਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਕੁਝ ਵੀ ਬਦਲਦਾ ਨਹੀਂ ਤਾਂ ਬੇਕਾਰ ਬੇਨਤੀਆਂ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਅਜੇ ਵੀ ਦੇਰੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।

Subscriptions ਨਾਲ ਸਰਵਰ ਤੁਰੰਤ ਕਹਿੰਦਾ ਹੈ “ਇਹ ਰਹਾ update”। ਇਸ ਨਾਲ ਬੇਕਾਰ ਟ੍ਰੈਫਿਕ ਘਟ ਸਕਦਾ ਹੈ ਅਤੇ ਮਹਿਸੂਸ ਕੀਤੀ ਤੇਜ਼ੀ ਵਧ ਸਕਦੀ ਹੈ—ਪਰ ਇਸਦਾ ਕੀਮਤ connections open ਰੱਖਣ ਅਤੇ real-time infrastructure ਨੂੰ manage ਕਰਨ 'ਚ ਹੁੰਦੀ ਹੈ।

ਕਦੋਂ subscriptions ਅਣਜਰੂਰੀ ਜਟਿਲਤਾ ਹਨ

Subscriptions ਹਮੇਸ਼ਾਂ ਲਾਭਕਾਰੀ ਨਹੀਂ ਹੁੰਦੇ। ਜੇ updates ਅਕਸਰ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਸਮੇਂ-ਸੰਵੇਦਨਸ਼ੀਲ ਨਹੀਂ ਹਨ, ਜਾਂ ਆਸਾਨੀ ਨਾਲ batch ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਤਾਂ polling (ਜਾਂ user actions ਤੋਂ ਬਾਅਦ re-fetch) ਕਾਫ਼ੀ ਹੋ ਸਕਦਾ ਹੈ।

ਉਹ<|vq_image_14639|><|vq_image_2326|><|vq_image_3432|><|vq_image_1293|><|vq_image_107|><|vq_image_107|><|vq_image_14702|><|vq_image_11960|><|vq_image_4436|><|vq_image_8986|><|vq_image_4660|><|vq_image_14202|><|vq_image_16104|><|vq_image_2490|><|vq_image_1425|><|vq_image_12662|><|vq_image_1176|><|vq_image_877|><|image_border_904|><|vq_image_11291|><|vq_image_8885|><|vq_image_1331|><|vq_image_11943|><|vq_image_6739|><|vq_image_2586|><|vq_image_9039|><|vq_image_6718|><|vq_image_14455|><|vq_image_14455|><|vq_image_8936|><|vq_image_9147|><|vq_image_6298|><|vq_image_16056|><|vq_image_1458|><|vq_image_1458|><|vq_image_1458|><|vq_image_638|><|vq_image_16311|><|vq_image_3364|><|vq_image_5096|><|vq_image_11847|><|vq_image_10130|><|vq_image_15138|><|vq_image_5764|><|vq_image_10117|><|vq_image_1204|><|vq_image_13925|><|vq_image_1984|><|vq_image_4190|><|vq_image_4744|><|vq_image_9289|><|vq_image_8590|><|vq_image_4171|><|vq_image_14466|><|vq_image_13825|><|vq_image_15482|><|vq_image_15482|><|vq_image_15482|><|vq_image_11070|><|vq_image_1500|><|vq_image_4144|><|vq_image_5504|><|vq_image_14369|><|vq_image_6384|><|vq_image_4012|><|vq_image_13212|><|vq_image_2213|><|image_border_905|><|vq_image_14455|><|vq_image_991|><|vq_image_9203|><|vq_image_14291|><|vq_image_11756|><|vq_image_5286|><|vq_image_14585|><|vq_image_7023|><|vq_image_6298|><|vq_image_1458|><|vq_image_12683|><|vq_image_12683|><|vq_image_10305|><|vq_image_10088|><|vq_image_9684|><|vq_image_15029|><|vq_image_3224|><|vq_image_13161|><|vq_image_5843|><|vq_image_12928|><|vq_image_11248|><|vq_image_7617|><|vq_image_1204|><|vq_image_12105|><|vq_image_4502|><|vq_image_53|><|vq_image_8338|><|vq_image_15437|><|vq_image_585|><|vq_image_15689|><|vq_image_8799|><|vq_image_1565|><|vq_image_9692|><|vq_image_8358|><|vq_image_1668|><|vq_image_1959|><|vq_image_3319|><|vq_image_1646|><|vq_image_15560|><|vq_image_2020|><|vq_image_15632|><|vq_image_10192|><|vq_image_5834|><|vq_image_3774|><|vq_image_3182|><|vq_image_9077|><|vq_image_7023|><|vq_image_1718|><|image_border_906 analysis>