Gerçek zamanlı takibin, bir Porter klonunun canlı hissettirmesindeki önemi büyüktür. Müşteriler sadece bir kamyon rezervasyonu yapmakla kalmaz, aynı zamanda onun haritada hareketini an ve an görmek ister. Bu işlevin hatalı olması, diğer tüm özellikler düzgün çalışsa bile, uygulamanızın bozuk gibi hissettirmesine neden olur. Doğru yapıldığında ise, bu, ürününüzdeki en büyük güven unsuru haline gelir. Takip katmanının nasıl çalıştığını adım adım inceleyelim.
REST Polling Yönteminin Yetersizlikleri
Her 5-10 saniyede bir polling yapmak, hiçbir şey hareket etmediğinde bile sürekli sunucu yükü oluşturur.
Sürücü cihazlarının tekrar eden HTTP isteklerinden kaynaklı batarya tüketimi.
Sürücünün gerçek konumu ile müşterinin gördüğü bilgi arasında belirgin bir gecikme.
Birkaç bin eşzamanlı taşımayı geçtiğinizde ölçeklenebilirlik sorunları.
WebSocket Mimarisini Sade Bir Dille Açıklamak
WebSocket, istemci ve sunucu arasında her birkaç saniyede bir yeni bir bağlantı açmak yerine tek bir kalıcı bağlantıyı açık tutar.
Sürücü uygulaması, her 3-5 saniyede bir konum pingi gönderir.
Sunucu, bu ping’i yolculuğa özel bir kanala iletir.
Müşteri uygulaması, bu kanalı dinler ve harita işaretleyicisini anında günceller.
Bağlantı, yolculuk sona erene veya uygulama kapatılana kadar açık kalır.
Gerekli Temel Bileşenler
WebSocket sunucusu (Socket.io veya yerel ws implementasyonu)
Sürücü uygulaması içinde geolokasyon yakalama modülü
Yayınları izole etmek için yolculuğa özel bir kanal veya oda
ETA hesaplama servisi (mesafe ve trafik ayarlı hız)
Müşteri tarafında harita render işlemi (Google Maps SDK veya Mapbox)
Teknoloji Yığını Seçimi
Socket.io: en kolay kurulum, yerleşik yeniden bağlantı yönetimi, biraz daha ağır yük.
Native WebSocket (ws): daha hafif ve daha fazla kontrol, fakat daha fazla manuel çalışma gerektirir.
Yönetilen hizmetler (Pusher, Ably): en hızlı dağıtım, ancak maliyet kullanım arttıkça yükselir.
Çoğu erken aşamadaki Porter klonları için, Node.js üzerinde Socket.io, hız ve kontrol açısından doğru dengeyi sağlamaktadır.
Ölçeklenmeyi Ağırlaştırmadan Yönetmek
Birden fazla sunucu örneği arasında yayınlamak için Redis pub/sub kullanın.
Müşterinin yolculuk sırasında sunucuları değiştirmemesi için yük dengeleyicide yapışkan oturumlar kullanın.
Gürültülü istemcilerin kanalları doldurmasını önlemek için sunucu tarafında konum güncellemelerini sınırlandırın.
Her bir ping için yazmak yerine veritabanı yazmalarını toplu şekilde yapın.
Geç Kalınan Tuzaklar
Ham GPS verisi gürültülüdür; bu nedenle, gösterimden önce basit bir hareketli ortalama ile düzeltin.
iOS ve Android arka planda konum alımını farklı şekilde kısıtlar; her iki platformda da erken test edin.
İlk günden itibaren yeniden bağlantı mantığı oluşturun, bu bir düşünce sonrası olmamalıdır.
Sürücü cihazlarında batarya tüketimini izleyin; aşırı polling, sürücü kabulünü düşürür.
Kısa Bir Test Kontrol Listesi
Kötü ağ koşullarını (3G, kesilmeler) simüle edin.
Yolculuk sırasında uygulamanın arka plana ve ön plana geçişini test edin.
Eşzamanlı yolculuk kanallarıyla yük testi yapın.
Bir yön değiştirdikten sonra ETA’nın doğru bir şekilde yeniden hesaplandığını doğrulayın.
Sonuç
Bu katmanı baştan inşa etmek iyi bir öğrenme deneyimi olsa da, bu genellikle çekirdek rezervasyon akışınıza bile dokunmadan önce üç ila dört haftalık geliştirme süresi alır. Önceliğiniz piyasaya çıkmaksa ve kendi takip motorunuzu icat etmek istemiyorsanız, üstteki gerçek zamanlı takip, sürücü kanalları ve ETA mantığı ile birlikte önceden inşa edilmiş bir Porter klon scripti incelemek faydalı olabilir; bu sayede ekibiniz o süreyi işinizi gerçekten farklı kılan şeylere ayırabilir.
Kaynak: Orijinal Makale
