Vercel-ის WebSocket და Neon-ის ცოცხალი მოთხოვნები: როდის სჭირდება მონაცემებს წამი, როდის წუთი

ოქტომბერში რამდენიმე პლატფორმამ ერთბაშად გამოაცხადა რეალურ დროში მუშაობა. Vercel-მა თავის ფუნქციებში WebSocket ბეტადან გამოიყვანა, Neon-მა SQL-მოთხოვნები ცოცხალი გახადა, Stripe-მა გადახდების ჩაწერა თავად დაიწყო Supabase-ისა და Neon-ის Postgres-ში, Netflix-მა კი მოყვა, როგორ გადააწყო სარეკლამო მოვლენების კონვეიერი პირდაპირი ეთერებისთვის. ბიზნესის მფლობელისთვის ამის უკან ერთი კითხვა დგას: კომპანიაში რომელი მონაცემები უნდა განახლდეს წამში, რომელს ეყოფა წუთი და რომელს ღამის გადმოტვირთვა. პასუხზეა დამოკიდებული, რა ღირს სისტემა და რამდენ ადგილას შეიძლება გაჩერდეს.

რა გამოვიდა და ვისგან

Vercel-მა 20 ოქტომბერს changelog-ში დაწერა, რომ WebSocket-ის მხარდაჭერა Vercel Functions-ში საყოველთაოდ ხელმისაწვდომი გახდა. ივნისის ბოლოს საჯარო ბეტის გაშვების შემდეგ მათმა CDN-მა 300 მილიონ კავშირს მოემსახურა, ახლა დღეში 15 მილიონია. კავშირები ფუნქციების ჩვეულებრივი გამოძახებებივით ტარიფიცირდება, ხოლო Active CPU ტარიფზე პროცესორის დრო მხოლოდ მაშინ ითვლება, როცა შეტყობინება მუშავდება.

Neon-ის ბლოგში 15 ოქტომბერს გამოვიდა მოკლე ჩანაწერი, რომ Neon Realtime საჯარო ბეტაშია: ნებისმიერი SQL-მოთხოვნა შეიძლება ცოცხალი გახდეს, მასზე გამოიწეროთ, და შედეგი მონაცემების ცვლილებასთან ერთად განახლდება, განმეორებითი გამოკითხვის გარეშე.

Supabase-მა 15 ოქტომბერს აღწერა, როგორ ახდენს Stripe Data Pipeline Stripe-ის მონაცემების სინქრონიზაციას Supabase-ში. მიერთება Stripe-ის პანელიდან ხდება. Stripe ჯერ ისტორიას ტვირთავს, შემდეგ კი მონაცემებს აქტუალურს ინახავს: გადახდები, დაბრუნებები, დავები, კლიენტები, გამოწერები და ინვოისები ცხრილებად შემოდის ცალკე სქემაში stripe_sdp პრეფიქსით. Stripe ცალკე როლით უერთდება, რომელსაც წვდომა მხოლოდ ამ სქემაზე აქვს, ხანმოკლე ტოკენებით და ბაზის პაროლის გარეშე. Neon-მა 16 ოქტომბერს იგივე გამოაცხადა თავის Postgres-ზე: მიერთება Stripe-ის პანელიდან და გადახდების ცოცხალი მონაცემები აპლიკაციის მონაცემების გვერდით.

Netflix-მა 14 ოქტომბერს გამოაქვეყნა სარეკლამო მოვლენების კონვეიერზე მონათხრობის მეორე ნაწილი. ადრე სარეკლამო სერვერი ყოველი ჩვენებისას მეტამონაცემებს სინქრონულად წერდა გლობალურ რეესტრში და დადასტურებას ელოდა. პირდაპირი ეთერებისთვის ეს არ გამოდგებოდა: Jake Paul-ისა და Mike Tyson-ის ბრძოლას 100 მილიონზე მეტი მაყურებელი უყურებდა, და ერთი სარეკლამო ბლოკი კრიტიკულ გზაზე ბაზაში წამში მილიონობით სავალდებულო ჩანაწერს ნიშნავდა. Netflix-ის ინჟინრებმა ბაზაში ჩაწერა Apache Flink-ში ნაკადური შეერთებით შეცვალეს: სერვერი ლოგში წერს, რა აჩვენა, მოწყობილობებიდან მოსულ მოვლენებთან შედარება კი მოგვიანებით ხდება. საცავის მტყუნება ჩვენებას აღარ აჩერებს.

მაგალითი: გაქირავება მონაცემების სამი სიჩქარით

ავიღოთ მანქანების გაქირავების კომპანია. გაცემაზე მენეჯერი ამოწმებს, თავისუფალია თუ არა მანქანა და რა ფოტოები აქვს დათვალიერებიდან. მას ახლანდელი მდგომარეობა სჭირდება: თუ ერთი მანქანის ორი ჯავშანი წუთით აცდენილ მონაცემებს დაეყრდნობა, კლიენტს დახლთან ლოდინი მოუწევს. ბუღალტერი გუშინდელ გადახდებს ადარებს, და მას დილის გადმოტვირთვა ეყოფა. ოფისში პარკის დატვირთვის ტაბლო შეიძლება წუთით ჩამორჩეს, ამას ვერავინ შეამჩნევს.

თუ ყველა ნაკადს WebSocket-ით ატარებთ, კავშირებში იხდით ტაბლოს გულისთვის, რომელსაც წუთში ერთი მოთხოვნა ეყოფოდა. თუ ყველაფერს ღამით აგროვებთ, გაცემაზე მენეჯერი კოლეგას დაურეკავს და ჰკითხავს, ხომ არავის წაუყვანია მანქანა. Netflix-ს იგივე ამოცანა აქვს სხვა მასშტაბით: კლიენტამდე გზაზე ყოველი სავალდებულო სინქრონული ნაბიჯი დასაბუთებას საჭიროებს.

როგორ ვირჩევ არხს

აშშ-ის PDR-კომპანიაში, რომელთანაც 2021 წლიდან ვმუშაობ, TV-ბარათები 4 ტელევიზორზე რეალურ დროში ახლდება: მფლობელი, წარმოება, რეცეფცია და გამყიდველები ხედავენ დატვირთვასა და შეკვეთების მოძრაობას. ზარი IVR-ზე CRM-ში ლიდს მაშინვე ქმნის, რადგან აქ დაგვიანება კლიენტის დაკარგვას ნიშნავს. გამყიდველების სუპერაპი კი offline first პრინციპითაა აწყობილი: გასვლაზე გამყიდველი ფოტოს იღებს და ლიდს კავშირის გარეშე უძღვება, აპლიკაცია კი მონაცემებს მაშინ სინქრონიზებს, როცა კავშირი გაჩნდება.

2023 წელს ლონდონის საკონსულტაციო კომპანიისთვის Scraper Hub გავაკეთე, სიახლეების შეგროვების სერვისი 120 წყაროდან. შეგროვების მსვლელობა ინტერფეისში WebSockets-ით ჩანდა, რადგან ადამიანი შეგროვებას უშვებდა და შედეგს ელოდა. საწარმოო კომპანიისთვის შეკვეთების გაანგარიშების პროგრამაში სერვერი და კლიენტი ასევე WebSocket-ით არის დაკავშირებული: გაანგარიშებას საშუალოდ 65 წამი სჭირდება, და კონსტრუქტორი ხედავს, რა ხდება.

შიდა სერვისში „ყავა ერთად“ კი მომწოდებლის კატალოგი განრიგით სინქრონიზდება, კვირაში სამ გაშვებამდე. შეკვეთის თანხა მას შემდეგ ჩნდება, რაც ორგანიზატორი ნამდვილ კალათას შეამოწმებს. აქ წამი არავის სჭირდება, მომწოდებლის API-სთან მუდმივი კავშირი კი დაამატებდა ადგილებს, სადაც ყველაფერი შეიძლება გატყდეს. Vercel-ის WebSocket, Neon-ის ცოცხალი მოთხოვნები და Stripe-ის კონვეიერი ჩემთან არ შემიმოწმებია და მათი აღწერებით ვმსჯელობ.

რას გავაკეთებდი

ჩამოწერეთ კომპანიაში მონაცემების ნაკადები და თითოეულისთვის დაასახელეთ წუთით და საათით დაგვიანების ფასი.

წამიერი ნაკადებისთვის აიღეთ WebSocket ან ცოცხალი მოთხოვნა, მაგრამ რეზერვით: კავშირის გაწყვეტისას კლიენტი სრულ მდგომარეობას თავიდან ითხოვს.

წუთიერი ნაკადებისთვის გააკეთეთ ფონური ვორკერი განმეორებებით და ორმაგი დამუშავებისგან დაცვით.

გარე სერვისები კრიტიკული გზიდან მოაშორეთ. თუ საგადახდო სისტემა ან CRM გაჩერდა, მანქანის გაცემა გრძელდება, მონაცემები კი მოგვიანებით მივა.

დაითვალეთ ფასი: პლატფორმაზე კავშირებში ფუნქციის გამოძახებებივით იხდით, საკუთარ სერვერზე კი მათი ფასი მეხსიერება და ლიმიტების კონტროლია.

ფონური ამოცანები და განმეორებები განვიხილე სტატიაში ვორკერებზე და მიმოხილვაში განმეორებით დამუშავებაზე განმეორებითი შედეგის გარეშე. ამ მიმოხილვის პროექტები: PDR-კომპანია, Scraper Hub და შეკვეთების გაანგარიშება წარმოებისთვის. ტელევიზორებსა და leaderboard-ზე არის მიმოხილვა მეტრიკებზე, რომლებიც გუნდს ცუდ გადაწყვეტილებებს ასწავლის, პლატფორმების ფასზე მიმოხილვა ბექენდებზე Vercel-ზე, Fly-სა და Supabase-ში, ერთ სერვერზე დაკვირვებადობაზე ეს. მიმართულებები: შიდა სისტემები და API-ინტეგრაციები. თუ გაქვთ მონაცემები, რომლებიც ახლანდელზე სწრაფად უნდა განახლდეს, მომიყევით, რომელი და რატომ. ამოცანის განხილვა.