13 पॉइंट द्वारा GN⁺ 2024-07-01 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • SQS को सीधे बदल सकने वाली Drop-In सेवा, जो developer experience को काफी बेहतर बनाती है
  • functional UI, visibility, tracking, message scheduling, और rate limiting सुविधाएँ प्रदान करती है
  • किसी भी cloud पर निजी SQS instance चलाया जा सकता है
  • एकल Go binary के रूप में deploy होता है, और मौजूदा SQS client से इस्तेमाल किया जा सकता है
  • UI :3000 पर, और SQS-compatible server :3001 पर चलता है
  • सभी भाषाओं के SQS client के साथ compatible
    • Python
      • import boto3  
        # केवल endpoint_url बदलना है  
        sqs = boto3.client("sqs", ..., endpoint_url="http://localhost:3001";)  
        sqs.send_message(QueueUrl="...", MessageBody="hello world")  
        
      • Celery के साथ भी आसानी से काम करता है
      • app = Celery("tasks", broker_url="sqs://...@localhost:3001")  
        

GN⁺ की राय

  • SmoothMQ, SQS की क्षमताओं का विस्तार करके developers को बेहतर अनुभव देता है
  • cloud vendor पर निर्भर हुए बिना निजी instance चलाया जा सकता है, इसलिए flexibility अधिक है
  • मौजूदा SQS client को वैसे ही उपयोग किया जा सकता है, इसलिए migration cost कम है
  • UI के ज़रिए queue और message को आसानी से manage किया जा सकता है, जिससे operations efficiency बढ़ती है
  • नई तकनीक अपनाते समय मौजूदा system के साथ compatibility पर पर्याप्त विचार करना चाहिए

3 टिप्पणियां

 
aer0700 2024-07-02

लगता है SQLite और postgres 10 साल बाद भी इस्तेमाल होते रहेंगे। Redis के बारे में भी ऐसा ही लगता था, लेकिन आजकल पक्का नहीं कह सकता।

 
superwoou 2024-07-02

आजकल Redis की जगह लोग क्या इस्तेमाल करते हैं?

 
GN⁺ 2024-07-01
Hacker News राय
  • k8s, kubernetes, cloud native, self-hosted, edge-enabled तकनीकों को सस्ते में इस्तेमाल करने का विचार शानदार है

    • rq और minio को k8s में कई सालों तक इस्तेमाल किया है, और हाल में SQLite को एक विकल्प के रूप में देख रहे हैं
    • personal cloud के महत्व पर ज़ोर देते हुए, उनका मानना है कि public cloud में बहुत ज़्यादा चीज़ें संभालना उचित नहीं है
    • BTLE sensors का सीधे Apple Watch से संचार करना पूरी तरह संभव है
    • cloud के रास्ते जाना फ़ायदेमंद नहीं था, और अगली पीढ़ी के tools में इसे ठीक किया जाना चाहिए
  • यह बताया गया कि SQLite एक single server पर चलता है, और ज़्यादातर मामलों में काम करेगा, लेकिन 100% भरोसेमंद नहीं है

    • अगर queue server crash हो जाए, तो SQS के चलते रहने की संभावना ज़्यादा है
    • सबसे अच्छे हालात में यह काम कर सकता है, लेकिन SQS जितनी reliability नहीं देगा
  • scale और benchmarks को छोड़ दें, तो SQS का उपयोग करने वाले feature/unit test modules के लिए यह एक उपयोगी tool है

  • लक्ष्य एक hosted queue system बनाना है, जो SQS से सस्ता हो और performance से समझौता न करे

    • जैसे Backblaze और Minio ने S3 क्षेत्र में सफलता पाई, वैसे ही queue system में भी सफलता पाने का लक्ष्य है
  • AWS API-compatible services लिखना पसंद है, और Dyna53 project का ज़िक्र किया गया है

  • LocalStack का उपयोग करके SQS और कई AWS services को test/development में इस्तेमाल किया जा सकता है; यह अच्छी तरह documented है और open source है

  • लोकप्रिय services के लिए आसान self-hosted alternatives बनाने वाले projects पसंद हैं

    • उम्मीद है कि यह Litestream के साथ बिना बड़ी समस्याओं के काम करेगा, और backend storage tuning के बिना एक अस्थायी queue system के रूप में बेहतरीन होगा
  • project structure पर एक त्वरित सुझाव:

    • models/ directory से सभी structs को root directory में ले जाने का सुझाव है
    • इससे package users q.Message और q.Queue जैसे छोटे और साफ़ नाम इस्तेमाल कर सकेंगे, और अगर user के पास अपना "models" package हो तो name collision से बचा जा सकेगा
  • ElasticMQ का ज़िक्र किया गया, जिसे Docker environment में SQS को simulate करने के लिए इस्तेमाल किया जाता है

  • foreign key support को disable करके भी database schema में उसका इस्तेमाल क्यों किया जा रहा है, इस पर सवाल उठाया गया

    • "TODO: check for errors" comment और foreign key constraint checks को disable करते दिखने वाले हिस्से इसे आज़माने में हिचक पैदा करते हैं