Laravel SaaS Proje Hakkında

Arkadaşlar merhaba.
Laravele özel bir güvenlik paketi geliştirdim. Çok güzel ve detaylı bir paket oldu.
Şu anda composer paketi olarak ve lokal çalışacak halde geliştirdim.
Fakat bunu multi-tanent yapıya geçirip SaaS'ye çevirmek ve kullanıcılara wrapper bir composer paketi sunarak API üzerinden çalışacak hale getirmeyi de planlıyorum.
Bu şekilde 2 farklı paket elimde olmuş olacak.
Lokal çalışan paketi dağıtırsam lisans kontrolü yapmam neredeyse mümkün değil.
Şimdi sormak istediğim soru şu.
Middleware, service provider ve bazı işlemler her istekte çalışıyor. SaaS'ye çevirince bu istekler API ile çalışacak.
Her istekte 2-3 farklı API isteği sistemi aşırı derecede yavaşlatacaktır.
Bu konuda ne tür çözümler kullanıyor SaaS sistemler?
Çalınma ihtimalini göze alıp local mi kullanmalıyım yoksa?
Fikir belirtirseniz memnun olurum.
Teşekkürler.

1. Ioncube Dynamic key kullanabilirsin local için. Fakat Php extension olarak Ioncube kullanım zorunluluğu dezavantajı olacaktır.
2. PHP Extension Core Logic ile binary formatta bir şifreleme ve lisanslama yapılabilir buda aynı şekilde local çözüm için. İleri seviye bypass ve decrypt gibi işlemleri aşırı zorlaştırır.
3. Web Saas içinde Lisans kontrol kısmında pratik bir çözüm olarak günlük 1 kez kontrol ve sonrasındaki tüm işlemler cache'de kayıtlı olup true ile işlemleri safe şekilde devam etmesi sağlanabilir hergün belli saatte cache yenilenip 1 kez gerçek kontrol yapıp sonrasında cache ile işlemlere performanslı ve sorunsuz gereksiz işlemlerden atlatılıp devam lisanslı gibi devam ettirilebilir. Burada kullanıcının bir lisans keyi ID'si bişeyini cache'de tutup o kişiye o gün boyunca 1 kez lisans kontrolü yaparak birdaha kontrole gerek kalmadan performans sorunu çözülebilir. Bu işlem cache yerine DB'dede tutulabilir mimari kurgunuza ve müşteri kapasitenize bağlı seçim yapılabilir.

Hocam mesele şu ki eğer sistemi SaaS ve API ile çalışacak halde tasarlayacaksak lisans kontrolü dert değil. Dediğiniz gibi Cache yapabiliriz. Fakat diğer güvenlik kontrolleri? Güvenlik ile ilgili şeyler cachelenirse çok sıkıntı oluşturur. Açık oluşturur. Pakette Firewall, rol sistemi, gelişmiş ve gerçek zamanlı oturum yönetimi gibi işlevler var. Bu istekleri birleştirip batch etmek de mümkün değil. Hepsi ayrı istek yapılmalı.
Bilemedim gerçekten de :/

hocam paketiniz tam olarak ne işe yarıyor bilmiyorum ama laravelde Api saas projesi olduğunu varsayalım ve müşteriniz doğrudan sizin saas projenizde gelip işlemleri sağlıyor ve siz bu işlemleri bir rota grubu içerisinde yapıyorsunuz diyelim yada tüm kritik fonksiyonların rotalarını bir group olarak laravelde topladınız ve bu gruba bir middleware tanımladınız buda lisans kontrolünüz yapacağınız şey günlük 1 kez lisans kontrolü sonrasında her gerçek kontrolde cache yada DBdeki müşterinizin bir ID'sinden key'inden yakaladınız lisanssız oldu kontrolden geçemedi tüm rota grubunda middleware ile lisanssızlara işlemleri sağlattırmayacaksınız keseceksiniz tüm işlemlere olan iznini bunuda aynı şekilde middleware ile yapabilirsiniz. Burada işi zorlaştıran nedir anlamadım fileslar sizde DB sizde herşey sizde bu kurguyu kurup tüm yetki ve erişimleri istediğiniz gibi kısıtlayıp at koşturabilirsiniz.

hocam mesele şurada. mesela diyelim ki kullanıcının sisteminde birisi x işlemi yapıyor.
x işlemi yaptığı sırada sistem bizim sunucuya kullanıcının bilgilerini göndererek izni ve limiti var mı diye kontrol yapacak.
local olarak bunu yapamaz çünkü veriler localde değil bizde.
oturum için de aynı şekilde kontrol yapılacak.
bunlar her biri ayrı api istekleri. bu ayrı ayrı api istekleri performans sorunu oluşturmaz mı?
ben lisans kontrolünü hiç düşünmüyorum şu anda.
anlatabildim mi bilmiyorum.

Anlattığınız mimariyi tanımlayamadım hocam Saas projeniz sanırım tenant bir yapı içeriyor. Fakat hiç farketmez alt alta müşterilerinizin altında oluşacak onlarında müşterileri yada müşterinizin kendisi yönetici altında onun farklı kullanıcıları bile olsa. Burada sizin dikkat etmeniz gereken kişi Doğrudan üst müşteriniz yani müşterinizin alt kullanıcılarını umursamanıza gerek yok sizin zaten sorgularınızda ilişkisel bir yapı ile alt kullanıcılar bile istek atsa üst kullanıcısının kim olduğunu İlişkisel sorguda çekip o üst kullanıcının lisansının aktif olup olmadığını kontrol edip aktif değilse o üst kullanıcı ve onun altındaki tüm kullanıcıları Komple middleware ile ilişkisel sorguda hepsini tespit edip o gruba ait herkesin api isteklerini lisans kontrolünde kesebilirsiniz. Anladığım kadarıyla siz mimari kurgularında biraz amatörsünüz yani veritabanı kurgularında zaten müşterileriniz ve müşterilerinize ait kullanıcılar yada alt müşteriler diyelim hepsi birbirine bağlı bir id'de ilişkilendirilecek yani birbirlerine bağı olması için siz bu bağı kullanarak her birinin kime nasıl ilişkisi var sorgularda tespit edip en üstten en alta kadar hepsini tek bir middleware ile en üstteki kişinin lisansı kontrol ederek kesebilirsiniz basit sorgularla.

Hocam çok teşekkür ederim vakit ayırdınız ama anlayamadık birbirimizi
Dediğiniz konular ile ilgili hiç bir problemim yok. Lisans kontrolü hakkında da problemim yok.
Ben çoklu API isteklerinden dolayı oluşan performans problemi ve N+1 istek probleminden kaynaklanan ağ gecikmeleri hakkında müzdaribim.
Teşekkür ederim ama gene de. Biraz daha araştırayım bulurum inşallah.
Sağ olun.

N+1 problemi için kullanacağınız veritabanı motoru(PostreSQL,MariaDB,Mysql gibi) veya sunucu kaynaklarınız sorgu optimizasyonları gibi birçok şeyi etkileyen faktörler olacak fakat bu başlangıçta big data için kurguladığınız bir sistemi ilgili tablolara 100binlerce dummydata oluşturup api çağrılarında sorguların kaç ms ile cevap verdiğini ve sunucunuzun kaynak tüketimlerini kontrol ederek stabil bir şekilde testlerden geçirerecek durumu gözlemleyip optimizasyon sağlıyabilirsiniz. Hepsinin çözümleri var başlangıçta bunları orta düzeyde ayarlayıp ilgili trafik ve müşteri kapasitesine ulaştığınızda sorguları optimize ederek sunucu kaynaklarınızı arttırarak Redis cache indexing gibi mekanizmaları uygun görebileceğiniz sorgular ve verilerde kullanıp performans artışı sağlayabilirsiniz.. Yani şöyle düşünün projenizi yaptınız tablolarınıza dummy datalar oluşturdunuz api requestlerinde milyon data olan tablolardaki sorguların ve response sürelerini analiz ettiniz çok geç yanıt veriyor o requestteki sorguları optimize edip çok düşük ms'lere kadar indirmeniz gerekmektedir. 1-2 saniyeden uzun her api isteği eşzamanlı olarak trafiğinizin yüksekliğine göre arkada yanıtlanmayı bekleyip sunucunuzun kaynaklarını %100'lere gelmesine sebep olucaktır hatta bazı durumlarda Veritabanı motorunun çalışmayı durdurmasına bile sebep olacaktır. Kısaca ihtiyacınıza göre güçlü bir sunucu ve optimize sorgular gerekliyse cache yada tablolarda indexing gibi işlemler ile hedeflediğiniz big datadaki veri yönetimlerinizi performanslı şekilde ele almayı sağlıyabilirsiniz. Şöyle örnek vereyim iç içe foreach ile yapılan veri tabanı sorguları hatalıdır mesela process time'ı optimize bir sorguya göre çok daha uzun sürecektir. Bunu Sunucu kaynaklarını arttırarak örnek 1 dakikada tamamlanan işlem sunucu kaynağı arttırınca 30-40 saniyelere düşebilir fakat bu mantıklı değildir maliyetinizi arttırır daha esnek sorgu ve kod tarafında optimizasyon sağlamak hem maliyet düşürür hem daha sağlam bir çözüm olacaktır. Minimum sunucu ile yapabileceğiniz en iyi sorgular ve çözümler kullanıp sonrasında yapılabilecek hiçbirşey kalmadığında sunucu kaynakları arttırmaya gidersiniz. Ama kod tarafında her zaman bir çözüm vardır trafiğin uçuk kaçık olmadığını varsayarsak