API कसले उपभोग गर्छ र तिनका data आवश्यकता कति विविध छन् भन्ने आधारमा छान्नुहोस् — hype मा होइन। धेरै विविध client हरूले आफ्नै data आकार दिनुपर्दा GraphQL जित्छ; requests एकरूप, cacheable, र सरल हुँदा REST जित्छ।
API कसले उपभोग गर्छ र तिनका data आवश्यकता कति विविध छन् भन्ने आधारमा छान्नुहोस् — hype मा होइन। धेरै विविध client हरूले आफ्नै data आकार दिनुपर्दा GraphQL जित्छ; requests एकरूप, cacheable, र सरल हुँदा REST जित्छ।
user -> posts -> comments) traverse गर्छ।GET model हरेक तहमा सजिलै cache हुन्छ; GraphQL लाई नजिक पुग्न persisted queries चाहिन्छ।| पक्ष | GraphQL | REST |
|---|---|---|
| Over/under-fetching | डिजाइनले नै समाधान | सामान्य समस्या |
| HTTP/CDN caching | कठिन (काम चाहिन्छ) | Native र सजिलो |
| Query-cost/DoS control | तपाईंले थप्नैपर्छ | स्वाभाविक रूपमा सीमित |
| Client flexibility | उच्च | न्यून |
| Server complexity | उच्च | न्यून |
यी परस्पर अनन्य पनि होइनन् — धेरै system हरूले public/cacheable endpoint हरूका लागि REST र समृद्ध internal client हरूका लागि GraphQL expose गर्छन्।
Senior interviewer हरूले निष्ठा होइन, विवेक जाँचिरहेका हुन्छन्। बलियो जवाफले axes हरू नाम लिन्छ — client विविधता, caching आवश्यकता, team परिपक्वता, DoS surface — र GraphQL लाई सार्वभौमिक रूपमा राम्रो भनेर बेच्नुको सट्टा यसका वास्तविक लागत (caching र query-cost control) स्वीकार गर्छ।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्