Laravel geliştirme
Laravel ile web yazılımı: Laravel doğru seçim olduğunda onunla web uygulamaları, portallar ve API'ler geliştiriyor — olmadığında da bunu söylüyoruz. İş alanı modellemesinden kuyruklara ve Octane'e, yük altında işletime kadar.
Laravel geliştirme: kısa bir özet.
Karar vericiler için kısa özet: Bu hizmet hangi durumlarda uygundur, nasıl çalışırız ve nelere odaklanırız?
- Laravel uygundur, eğer
- web veya API odaklı, net bir iş alanı geliştiriliyorsa ve pazara çıkış süresi (time-to-market) önemliyse.
- Laravel zorlaşır, eğer
- katı gerçek zamanlılık, CPU'ya bağlı yük veya ilk günden en katı mimari ayrım isteniyorsa.
- Tercih ettiğimiz mimari
- modüler monolit, Eloquent'ten bağımsız iş mantığı, birden fazla istemci varsa API-first.
- Tipik proje büyüklüğü
- orta ve büyük ölçekli iş uygulamaları — tek ekip, birden fazla modül, tek dağıtım.
- Tipik riskler
- şişkin modeller (fat models), asenkron işlemede eksik idempotency, iş alanı modeli yerine framework sihri.
- Neyi optimize ediyoruz
- Yıllar boyunca değiştirilebilirlik, izlenebilir işletim ve framework'ten bağımsız bir iş alanı.
- Bilinçli olarak kaçındıklarımız
- erken mikroservisler, no-code kestirmeleri ve controller'larda ve modellerde iş mantığı.
- Beklenen kullanım ömrü
- beş ila on yıllık canlı işletim için tasarlanmış sistemler.
Erken fark ettiğimiz riskler.
Bu tür sistemlerde sık karşılaşılan riskleri, erken uyarı işaretlerini ve aldığımız önlemleri açıklıyoruz.
- 01
Şişkin modeller (fat models)
- Neden
- Eloquent, iş kurallarını doğrudan modele koymayı kolaylaştırır. Bu, sistemle birlikte büyür; ta ki model her şeyi bilir hâle gelene ve kimse onu takip edemeyene kadar.
- Erken uyarı işaretleri
- Çok sayıda sorumluluk taşıyan modeller ve uygulamanın yarısını ayağa kaldırmak zorunda kalan testler.
- Nasıl önlüyoruz
- İş mantığı servislerde, action’larda ve value object’lerde tutulur. Modelin görevi iş kurallarını yönetmek değil, verileri saklamaktır (persistence).
- Avantajlar ve sınırlamalar
- Bedeli: Daha fazla sınıf ve biraz daha fazla kurulum. Farklı durum: Küçük, kısa ömürlü bir uygulamada model daha fazlasını taşıyabilir.
- 02
Controller'da mantık
- Neden
- En hızlı yol her şeyi controller'da halletmektir. Bu, aynı mantığa ikinci bir yerde ihtiyaç duyulana kadar işe yarar.
- Erken uyarı işaretleri
- İş kuralları içeren controller'lar, controller'lar arasında tekrar eden kod, test edilmesi zor endpoint'ler.
- Nasıl önlüyoruz
- Controller isteği alır, doğrular ve iş alanına devreder. Karar vermez.
- Avantajlar ve sınırlamalar
- Bedeli: Ek bir katman. Farklı durum: Yeniden kullanılmayan basit bir endpoint'te yapı yalın kalır.
- 03
Idempotency olmadan kuyruk
- Neden
- Kuyruklar en az bir kez teslim eder. Idempotency yoksa çift teslimat çift etki yaratır — çift bildirimler, çift kayıtlar.
- Erken uyarı işaretleri
- Benzersiz anahtarı olmayan job'lar, kontrolsüz yan etkiler, nedeni belirsiz ara sıra ortaya çıkan tekrarlar.
- Nasıl önlüyoruz
- Her job idempotent'tir: bir anahtar, etkiyle aynı transaction içinde kontrol edilir ve kalıcı olarak kaydedilir.
- Avantajlar ve sınırlamalar
- Bedeli: Saklama süresi (retention) olan bir anahtar deposu. Farklı durum: Etki doğası gereği idempotent ise bu yeterlidir.
- 04
Önbellek geçersizleştirme
- Neden
- Önbellek eklemek kolay, doğru tutmak zordur. Net kurallar olmadan önbellek eninde sonunda güncelliğini yitirmiş veriler sunar.
- Erken uyarı işaretleri
- Tanımlı bir geçersizleştirme kuralı olmayan önbellekler, “bazen eski veriler”, önbelleği temizleyerek hata ayıklama.
- Nasıl önlüyoruz
- Neyin önbelleğe alınacağı ve ne zaman geçersiz olacağı sonradan düşünülen bir şey değil, tasarımın parçasıdır.
- Avantajlar ve sınırlamalar
- Bedeli: Tutarlılığı önceden düşünmek. Farklı durum: Tutarlılık gecikmeden daha önemliyse önbelleğe almak yerine sorguyu optimize ederiz.
- 05
Eksik observability
- Neden
- Her şey çalıştığı sürece görünürlük eksikliği fark edilmez. İlk olayda (incident) ise ne olduğunu anlamak için gereken sinyaller eksiktir.
- Erken uyarı işaretleri
- Yapılandırılmış log yok, trace yok, işletime dair kimsenin yanıtlayamadığı sorular.
- Nasıl önlüyoruz
- Logları, metrikleri ve trace’leri ilk günden tasarlarız. Böylece yavaş bir isteğin veya arızanın nedenini izleyebiliriz.
- Avantajlar ve sınırlamalar
- Bedeli: Ölçüm altyapısı ve gerekli sinyallerin seçimi. Farklı durum: Tek kullanımlık bir prototipte asgari düzey yeterlidir.
- 06
Veritabanı darboğazları
- Neden
- Darboğaz neredeyse her zaman framework değil, veritabanıdır. N+1 sorguları ve eksik indeksler ancak yük altında fark edilir.
- Erken uyarı işaretleri
- Yük altında yavaşlayan endpoint'ler, istek başına çok sayıda küçük sorgu, veriyle birlikte uzayan sorgu süreleri.
- Nasıl önlüyoruz
- Sorguları bilinçli yüklemek (eager loading), hedefli indeksler, işletimde ölçüm; veritabanı aradığımız ilk yerdir.
- Avantajlar ve sınırlamalar
- Bedeli: “Sadece Eloquent” yerine sorgulara dikkat. Farklı durum: Veri hacmi küçükse bu efor gereksizdir.
- 07
Erken mikroservisler
- Neden
- Mikroservisler ciddi sistemler için standart kabul edilir. Erken devreye alındıklarında faydası olmadan ağ sınırlarının ve işletim yükünün bedeli ödenir.
- Erken uyarı işaretleri
- Bağımsız ölçeklenmeyen dağıtık servisler, birden fazla servisi senkron olarak yayına alan tek bir ekip — yani dağıtık bir monolit.
- Nasıl önlüyoruz
- Net sınırlara sahip modüler bir monolitle başlangıç; bir servis yalnızca somut bir gereksinim bunu talep ettiğinde ayrılır.
- Avantajlar ve sınırlamalar
- Bedeli: Başlangıçta tek tek parçaların bağımsız ölçeklenememesi. Farklı durum: Parçaların gereksinimleri kanıtlanabilir biçimde kökten farklıysa.
- 08
Framework'e bağımlılık
- Neden
- İş alanı doğrudan Eloquent'e ve framework sihrine bağlıysa her değişiklik — ve her sürüm yükseltmesi — daha pahalı hâle gelir.
- Erken uyarı işaretleri
- Eloquent modellerinde iş kuralları, veritabanına ihtiyaç duyan testler, framework yükseltmelerinden kaçınma.
- Nasıl önlüyoruz
- İş alanı framework'ten bağımsız kalır; Laravel iş mantığının yeri değil, altyapıdır.
- Avantajlar ve sınırlamalar
- Bedeli: Başlangıçtan itibaren biraz daha fazla yapı. Farklı durum: Uzun vadeli bakımı olmayan kısa ömürlü bir uygulamada.
Koddan önce sorduğumuz sorular.
Mimariyi belirlemek için önce ihtiyaçlarınızı ve kısıtlarınızı netleştiriyoruz. Aşağıdaki sorular teknik kararlarımızın temelini oluşturur.
- 01
Birden fazla istemci aynı iş mantığını paylaşıyor mu?
- Neden önemli
- Birden fazla frontend veya iş ortağı aynı sistemi kullanmaya başladığı anda arayüz, artık serbestçe değiştirilemeyecek bir sözleşmeye dönüşür.
- Tipik sonuç
- Cevap evetse API-first tasarlıyoruz — web arayüzü oluşturulmadan önce sürümlenmiş ve belgelenmiş olarak.
- 02
Asenkron işlemeye ihtiyacımız var mı?
- Neden önemli
- Kritik yanıt yolundaki yavaş veya güvenilmez yan etkiler, gecikmeyi ve hataları işe dâhil olan en yavaş sisteme bağlar.
- Tipik sonuç
- Evetse bunlar idempotent biçimde bir kuyruğa taşınır; hayırsa yol senkron ve basit kalır.
- 03
Başlangıçtan itibaren katı bir mimari ayrım gerekiyor mu?
- Neden önemli
- Bazı bağlamlar ilk günden kesin sınırlar gerektirir — mevzuat nedeniyle ya da çok büyük iş alanları yüzünden.
- Tipik sonuç
- Durum buysa Symfony'nin daha sağlam bir temel olup olmadığını inceliyoruz; değilse temiz ayrılmış bir modüler monolit yeterlidir.
- 04
Bu sistem ne kadar süre yaşamalı?
- Neden önemli
- Beklenen kullanım ömrü, erken aşamada ne kadar yapı ve dokümantasyonun değeceğini belirler.
- Tipik sonuç
- Yıllar sürecek bir işletim için iş alanını framework'ten tutarlı biçimde ayırıyoruz; kısa ömürlü bir deney için ayırmıyoruz.
- 05
İş kuralları ne sıklıkla değişiyor?
- Neden önemli
- Sık değişen kurallar controller'lara ve modellere dağılmış değil, tek bir yerde olmalıdır.
- Tipik sonuç
- Değişim oranı yüksekse kuralları iş alanında kapsüllüyoruz; kurallar kararlıysa yapı daha yalın olabilir.
- 06
İşletimde görünürlük gerekiyor mu?
- Neden önemli
- İşletimde sorulara yanıt vermesi gereken bir sistem, ancak tasarım aşamasında oluşturulabilecek sinyallere ihtiyaç duyar.
- Tipik sonuç
- Evetse loglar, metrikler ve trace'ler en baştan dâhil edilir; sonradan eklenmeleri zordur.
- 07
Tutarlılık “eventual” olabilir mi?
- Neden önemli
- Asenkronluk ve önbellekleme beraberinde eventual consistency getirir — arayüz ve kullanıcılar bunu kaldırabilmelidir.
- Tipik sonuç
- Olabiliyorsa durumları dürüstçe iletiyoruz (örneğin “işleniyor”); olamıyorsa yol senkron ve tutarlı kalır.
- 08
En büyük riski hangi yol taşıyor?
- Neden önemli
- En büyük risk geliştirmenin sonunda ortaya çıkmamalı, en başta ele alınmalıdır.
- Tipik sonuç
- En zor yolu önce uçtan uca kanıtlıyoruz; geri kalan her şey bunun üzerine kurulur.
Bu hizmet nedir, neleri kapsar?
Laravel, web uygulamaları ve API'ler için olgun bir PHP framework'üdür ve web yazılımı çalışmalarımızda en sık kullandığımız backend framework'üdür. Onu, gereksinimleri basit CRUD'un ötesine geçen iş uygulamalarında kullanıyoruz: net sınırlanmış iş alanları, güvenilir arka plan işleme ve beş yıl sonra da izlenebilir bir işletim. Laravel bu yapıda altyapı olarak kalır — iş mantığı ondan bağımsızdır.
Hizmet kapsamı
- İş alanı modeli ve mimari
- API'ler ve entegrasyonlar (REST, sürümlenmiş)
- Kuyruklar (queue) ve Horizon ile asenkron işleme
- Önbellekleme, Redis ve performans
- Testler, CI/CD ve işletim
Kod yazılmadan önce verilen kararlar.
Teknoloji seçimlerimizin ve uygulama yaklaşımımızın gerekçeleri.
- 01
Mikroservislerden önce modüler monolit
Çoğu Laravel sistemi en iyi modüler bir monolit olarak başlar: tek bir kod tabanı içinde net modül sınırları. Bu, dağıtık sistemlere gerçekten ihtiyaç duyulmadığı sürece karmaşıklığı düşük tutar — ve bir sınır gerektirdiğinde sonradan hedefli biçimde ayrılabilir.
- 02
İş mantığı framework'ün dışında
Kurallar controller'lara veya modellere değil; servislere, action'lara ve value object'lere aittir. Böylece iş alanı test edilebilir ve Eloquent'ten bağımsız kalır. Controller isteği alır ve devreder; karar vermez.
- 03
Eloquent bilinçli olarak, dogmatik değil
Eloquent, erişimlerin büyük bölümü için verimli ve okunabilirdir. Karmaşık veya performans açısından kritik sorgularda hedefli olarak Query Builder'a başvuruyoruz. Repository pattern'i kendi başına amaç olarak değil, yalnızca gerçek bir ayrışma (decoupling) sağladığı yerde kullanıyoruz.
- 04
Birden fazla istemci erişiyorsa API-first
İş ortakları, mobil uygulamalar veya birden fazla frontend bir sistemi kullanmaya başladığında önce API'yi tasarlıyoruz: sürümlenmiş, belgelenmiş, kararlı bir sözleşme olarak. Web arayüzü bu durumda sistemin kendisi değil, birkaç tüketiciden biridir.
Geliştirme yaklaşımımız: Batunet Engineering Method.
İhtiyaçların netleştirilmesinden uzun vadeli bakım ve işletime uzanan yedi aşamalı çalışma yaklaşımımız.
- 01
FrameProblemi netleştirme
Herhangi bir çözüm düşünülmeden önce asıl problem, sınırları ve ölçülebilir bir başarı tanımı belirlenir.
- 02
ModelModelleme
İş alanını (domain) ortak ve açık bir dille modelliyor, farklı sorumlulukları ayrı bağlamlarda tanımlıyoruz.
- 03
DecideKarar
Temel mimari kararları, değişiklik maliyeti henüz düşükken değerlendirir ve gerekçeleriyle birlikte belgeleriz.
- 04
ProveKanıtlama
Kapsamı genişletmeden önce çalışan bir temel kurar, mimariyi en riskli iş akışı üzerinde doğrularız.
- 05
BuildGeliştirme
Doğrulanmış temel üzerinde küçük, test edilebilir ve geri alınabilir adımlarla geliştiririz. İlerleme her hafta görünür olur.
- 06
HardenSağlamlaştırma
Hata senaryolarını, yükü ve güvenliği test ediyoruz. Sistemin normal koşulların yanı sıra sorun anlarında da nasıl davrandığını doğruluyoruz.
- 07
Operateİşletim
Sistemi işletir, izler ve geliştirmeye devam ederiz — ve onu anlaşılır ve değiştirilebilir tutarız.
Tasarımdan canlı kullanıma.
Sistemin çalışmasının yanı sıra canlı ortamda izlenebilir ve yönetilebilir olması gerekir. Her önerinin avantajlarını, maliyetlerini ve farklı bir seçimin uygun olacağı koşulları değerlendiriyoruz.
Kuyruklar ve Horizon
Bekleyebilecek her şey kuyruklar üzerinden asenkron çalışır. Horizon; worker'ları, iş hacmini, çalışma sürelerini ve yeniden deneme (retry) stratejisiyle başarısız job'ları görünür kılar.
Avantajlar ve sınırlamalar · Bedeli: Eventual consistency ve idempotency zorunluluğu. Farklı durum: İşlem yanıt için kritikse senkron kalır.
Octane — performans mühendisliği
Gecikmeye duyarlı servislerde Octane, uygulamayı istekler arasında bellekte tutar ve böylece gecikmeyi belirgin biçimde azaltır. Ama önce zamanın gerçekte nerede kaybedildiğini ölçüyoruz — çoğunlukla veritabanında.
Avantajlar ve sınırlamalar · Bedeli: Durumsuz (stateless) kod, kaynakların özenle yönetilmesi, bellek sızıntısı riski. Farklı durum: Gecikme kritik değilse klasik PHP-FPM yeterlidir ve işletilmesi daha basittir.
Önbellekleme ve Redis
Redis; önbellek, kuyruk backend'i ve dağıtık kilitler (lock) için kullanılır. Neyin önbelleğe alınacağı ve nasıl geçersizleştirileceği bilinçli bir tasarım kararıdır: Ne eskiyebilir, ne tutarlı olmak zorundadır?
Avantajlar ve sınırlamalar · Bedeli: Önbellek geçersizleştirme zordur; yanlış önbellekleme eski veriler sunar. Farklı durum: Tutarlılık gecikmeden daha önemliyse önbelleğe almak yerine sorguyu optimize ederiz.
Olay güdümlü ayrışma
Domain event'ler yan etkileri ana mantıktan ayırır. Kuyruk üzerinden işlendiklerinde transaction'ları yalın, sistemi ise mevcut yollara dokunmadan genişletilebilir tutarlar.
Avantajlar ve sınırlamalar · Bedeli: Daha fazla dolaylı akış, takip etmesi daha zor. Farklı durum: Süreç basit ve senkron olarak net ise event kullanılmaz.
Observability
Yapılandırılmış loglar, metrikler ve trace'ler ilk olaya (incident) değil, ilk güne aittir. İşletimdeki bir sistem, belirli bir isteğin neden yavaş olduğunu yanıtlayabilmelidir.
Avantajlar ve sınırlamalar · Bedeli: Enstrümantasyon, depolama ve gürültü üretmek yerine sinyalleri özenle seçme disiplini. Farklı durum: Kısa ömürlü bir prototipte asgari enstrümantasyon.
Test stratejisi
Kritik yollarda feature testleri, iş alanı mantığı için unit testleri. Testler hataların pahalıya mal olduğu yerlerde — ve yıllar boyunca güvenli değişiklikler için bir güvenlik ağı olarak.
Avantajlar ve sınırlamalar · Bedeli: Test bakımı ve daha yavaş ilk teslimat. Farklı durum: Canlı ortama gitmeyecek atılık bir deneme (spike) için test yazılmaz.
Kesintisiz dağıtım
Health check'li, tekrarlanabilir dağıtımlar (Docker, Forge/Envoyer). Şema değişiklikleri expand/contract kalıbıyla geriye dönük uyumlu yürür: önce eklemeli olarak genişletmek, sonra kodu geçirmek, en son temizlemek.
Avantajlar ve sınırlamalar · Bedeli: İki aşamalı migration'lar ve daha fazla dağıtım disiplini. Farklı durum: Kısa bir bakım penceresi kabul edilebilirse daha basit bir migration yolu yeterlidir.
Güvenlik — kendi çözümü yerine standartlar
Yerleşik paketlerle kimlik doğrulama (örneğin Sanctum veya OIDC), en az yetki ilkesi (least privilege), kodun dışında tutulan secret'lar, doğrulanmış girdiler ve escape edilmiş çıktılar. Güvenlik en sondaki bir denetim değil, bir tasarım kararıdır.
Avantajlar ve sınırlamalar · Bedeli: Daha az serbestlik, daha fazla konvansiyon. Farklı durum: Çok özel bir gereksinim varsa bilinçli ve incelenmiş biçimde sapmak — asla doğaçlama değil.
Sürüm yükseltme stratejisi
Laravel'in yıllık sürüm döngüsünü disiplinli ve test edilmiş yükseltmelerle takip ediyor, bağımlılıkları güncel ve bilinçli olarak az tutuyoruz.
Avantajlar ve sınırlamalar · Bedeli: Daha kısa destek süresi nedeniyle düzenli yükseltme eforu. Farklı durum: Uzun yıllar boyunca azami yükseltme sakinliği öncelikliyse LTS'li Symfony daha sağlam bir temeldir.
Uzun vadeli işletim ve bakım kolaylığı
İş alanı Eloquent'ten bağımsız kalır, temel kararlar ADR olarak kayda alınır, işletim izlenir ve sorumluluklar nettir. Böylece sistem yıllar boyunca güvenle değiştirilebilir kalır.
Avantajlar ve sınırlamalar · Bedeli: Başlangıçtan itibaren daha fazla yapı ve dokümantasyon disiplini. Farklı durum: Kısa ömürlü bir deneyde bilinçli olarak yapı yerine hız.
Risk — önce zor yol
En riskli yol önce çalışan bir iskelet olarak uçtan uca hayata geçirilir. Hata durumları varsayılmaz, test edilir; her değişiklik geri alınabilir kalır.
Avantajlar ve sınırlamalar · Bedeli: Başlangıçta daha yavaş görünür ilerleme. Farklı durum: Risk kanıtlanabilir biçimde düşükse doğrudan genişliğe yayılmak.
Şematik mimari.
Müşteriye özel bilgi içermeyen mimari örnekler. Olay güdümlü ve idempotent işleme içeren modüler bir monolitin yapısını gösterir.
Projenize sağladığımız katkılar.
- 01
İş mantığı framework'ten bağımsız olarak test edilebilir kalan bir sistem
- 02
İzlenebilir işletim: görünür kuyruklar, metrikler ve loglar
- 03
Bir ekibin yıllar boyunca geliştirmeye devam edebileceği bir kod tabanı
Ne zaman uygun — ne zaman değil?
Dürüst yanıt, danışmanlığın bir parçasıdır. Soruna uyan yolu öneririz.
Uygun
- Net bir iş alanına ve web arayüzüne sahip iş uygulamaları
- Pazara çıkış süresinin önemli olduğu SaaS ürünleri, API'ler ve portallar
- Bir ekibin yıllar boyunca bakımını yapacağı ve geliştireceği sistemler
- Geniş ve olgun bir ekosistemden fayda sağlayan projeler
Uygun değil
- Sistem düzeyinde katı gerçek zamanlılık veya çok düşük gecikme gereksinimleri
- CPU'ya bağlı, yoğun hesaplama gerektiren işlemler — orada başka bir kullanılan teknolojiler uygundur
- Gerçek bir uygulama mantığı olmayan çok küçük, statik sayfalar
- İlk günden en katı mimari ayrımın zorunlu olduğu durumlar — orada Symfony çoğu zaman daha sağlam bir temeldir
Kullanılan teknolojiler
Laravel geliştirme hakkında sorular
Laravel ne zaman doğru seçimdir?
Web arayüzü veya API'si olan, net sınırlanabilen bir iş alanı geliştiriliyorsa, pazara çıkış süresi önemliyse ve sistemin bakımını yıllar boyunca bir ekip yapacaksa. Olgun ekosistem, mimari üzerindeki kontrolden vazgeçmeden tekrarlayan işleri azaltır.
Laravel ne zaman doğru seçim değildir?
Katı gerçek zamanlılık gereksinimlerinde, CPU'ya bağlı hesaplama yükünde ya da ilk günden en katı mimari ayrımın zorunlu olduğu durumlarda. Bu gibi durumlarda başka bir kullanılan teknolojiler — ya da ayrım ön plandaysa Symfony — öneriyoruz.
Laravel nasıl ölçeklenir?
Yatay olarak: load balancer arkasında durumsuz uygulama sunucuları, Redis'te oturumlar ve önbellek, kuyruklarda asenkron işler, read replica'lar üzerinden okuma erişimleri. Darboğaz neredeyse her zaman framework değil, veritabanıdır — önce oraya odaklanıyoruz. Octane ise gerektiği yerde gecikmeyi ayrıca azaltır.
Büyük Laravel projelerini nasıl yapılandırıyorsunuz?
Modülleri teknik katmanlara göre değil, iş alanına göre ayrılmış modüler bir monolit olarak. İş mantığı, Eloquent'ten bağımsız olarak servislerde ve value object'lerde yer alır. Net modül sınırları karmaşıklığı yönetilebilir tutar ve gerekirse sonradan ayrıştırmayı mümkün kılar.
Bir Laravel uygulaması yıllar boyunca nasıl bakımı yapılabilir kalır?
Framework'ten bağımsız bir iş alanı, risklere göre yazılmış testler, belgelenmiş kararlar (ADR'ler), disiplinli sürüm güncellemeleri ve bilinçli seçilmiş, olgun bağımlılıklarla. Bakım kolaylığı, erken alınan kararların bir sonucudur.
Kesintisiz dağıtımı nasıl yapıyorsunuz?
Health check'li tekrarlanabilir dağıtımlar ve expand/contract kalıbına göre geriye dönük uyumlu migration'larla: önce eklemeli şema değişikliği, sonra kod, ardından temizlik. Bedeli iki aşamalı bir migration'dır; kısa bir bakım penceresinin kabul edilebildiği yerlerde daha basit bir yol mümkündür.
Uygulamayı nasıl güvenli tutuyorsunuz?
Yerleşik kimlik doğrulama paketleri, en az yetki ilkesi, kod dışında saklanan gizli bilgiler, doğrulanmış girdiler ve güvenli biçimde kodlanmış çıktılar kullanıyoruz. Güvenliği ilk günden tasarlıyoruz. Bu yaklaşım, kanıtlanmış standartlara uymak için bazı uygulama seçeneklerini sınırlar.
Laravel sürüm yükseltmelerini nasıl yönetiyorsunuz?
Yıllık sürüm döngüsünü test edilmiş yükseltmelerle ve az sayıda, güncel bağımlılıkla takip ediyoruz. Bedeli, daha kısa destek süresi nedeniyle düzenli bir efordur; uzun yıllar boyunca azami yükseltme sakinliğine ihtiyaç duyanlar için Symfony ve LTS politikası çoğu zaman daha uygundur.
Kaynak kod bize mi ait olur?
Evet. Projeye özgü kaynak kod ve üzerinde anlaşılan proje çıktıları — dokümantasyon, migration'lar, dağıtım yapılandırması — size teslim edilir. Framework, paketler ve diğer açık kaynak bileşenler kendi lisanslarına tabi kalır. Teknik olarak bağımsız kalırsınız — bizden de.
İlgili teknik içerikleri inceleyin.
Konuyu derinleştiren kavramları, mimari kararları, uygulama kılavuzlarını ve değerlendirmeleri birlikte inceleyin.
Teknolojiler
Hizmetler
