SQL as API

मूल लेख ↗ Hacker News चर्चा ↗

SQL को public API boundary के रूप में इस्तेमाल करना clients के लिए शक्तिशाली, लचीला querying वादा करता है, लेकिन इससे सुरक्षा, performance, और complexity control से जुड़े कठिन सवाल भी उठते हैं। टिप्पणीकर्ता इस approach की तुलना custom JSON DSLs, GraphQL, PostgREST-style URL filters, और database-native access controls (RBAC, row-level security, timeouts) जैसी alternatives से करते हैं, और इस पर बहस करते हैं कि power users को कितना नियंत्रण मिलना चाहिए और constraints कहाँ enforce हों। बहुत से लोग SQL-like query languages या SQL में translate होने वाले limited subsets में value देखते हैं, लेकिन raw SQL को इंटरनेट पर expose करना कभी अच्छा विचार है या नहीं, इस पर राय काफ़ी बँटी हुई है।

समग्र रूपरेखा

  • थ्रेड में SQL (या SQL-जैसी) को एक API/query language के रूप में उपयोग करने पर बहस है, बजाय bespoke JSON filter structures या REST endpoints के।
  • कई लोगों को यह अनिवार्य रूप से वैसे भी “query language invent करना” लगता है; असली सवाल है: कौन-सी, और constraints कहाँ enforce किए जाएँ?

SQL बनाम custom DSL / JSON / GraphQL

  • Pro-SQL subset:
    • SQL expressive, well-known, और naturally extensible है; भाषा का और हिस्सा जोड़ना backward compatible रह सकता है।
    • एक ad‑hoc structure डिज़ाइन करने से बचाता है, जो बाद में टूट सकती है या evolve करना कठिन हो सकता है।
    • Local SQL (जैसे browser/WASM में SQLite) plus sync, API vs DB boundaries को blur कर सकता है।
  • Pro-DSL / JSON:
    • Custom JSON/AST या lispy formats parse, type-check, और SQL या अन्य backends (जैसे Elasticsearch) में transform करने में आसान हैं।
    • “SQL‑looking but not really SQL” DSLs भ्रमित करने वाले हो सकते हैं; बेहतर है कि स्पष्ट और structured रहा जाए।
    • मौजूदा standards (OData, JSON:API, Google’s filtering AIP/CEL, expression languages, Substrait) पहले से ही कई ज़रूरतें पूरी करते हैं।
  • GraphQL को लेकर मिश्रित प्रतिक्रियाएँ हैं:
    • कुछ लोग इसे “queries को bundle करने” के बराबर मानते हैं (n+1/network trips की समस्या हल करना)।
    • अन्य तर्क देते हैं कि यह मुख्यतः result-shaping language है, जिसकी query power सीमित है (no unions/recursion) और stack overhead भारी है।

सुरक्षा, permissions, और QoS

  • चिंताएँ: SQL expose करना insecure, maintain करना कठिन, और performance के लिए जोखिम भरा (table scans, DoS, wide surface area) कहा जाता है।
  • प्रतितर्क:
    • आधुनिक DBs RBAC, row-level security, constraints, views, timeouts, quotas, और rate limiting प्रदान करते हैं; ये नुकसान को सीमित कर सकते हैं।
    • Statement timeouts और resource limits pathological queries को रोक सकते हैं।
  • इस पर असहमति बनी रहती है कि DB-level security, restricted DSL को SQL में compile करने से सरल है या अधिक जटिल।

यूज़र-फेसिंग query अनुभव

  • गैर-तकनीकी users (जैसे product search) के लिए, free-form SQL बहुत कठिन माना जाता है; UI controls स्वाभाविक रूप से simple AND/OR/facets से मेल खाते हैं।
  • कुछ practitioners बताते हैं कि product search में complex OR logic शायद ही कभी माँगी जाती है; अन्य tools में richer boolean search की कमी अक्सर महसूस करते हैं।
  • power users (logs, audits, admin/reporting) के लिए, textual query languages (SQL-like, Lucene, JQL-style) को बहुत मूल्यवान माना जाता है।

मौजूदा tools और patterns

  • उद्धृत उदाहरण: PostgREST, प्रमुख vendors के SQL-like APIs, ClickHouse के controls, crt.sh का public Postgres access, और “ship the DB” patterns।
  • कुछ लोग तर्क देते हैं कि इसे “ठीक से” करना लगभग वही है जो PostgREST जैसे tools पहले से देते हैं; अन्य छोटे, context-specific implementations का बचाव करते हैं।