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.
Kısaca Laravel geliştirme.
Kararınız için en önemli noktalar: ne zaman uygun olduğu, nasıl ilerlediğimiz ve nelere dikkat ettiğimiz.
- 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.
Nedir — ve 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
Ne zaman uygun — ne zaman değil?
Projeye uyan yolu öneririz — bu hazır bir ürün olsa bile.
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 teknoloji yığını 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
Kod yazılmadan önce verilen kararlar.
Teknolojinin ne yapabildiği değil, onu neden bu şekilde kullandığımız.
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.
İş 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.
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.
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.
Erken fark ettiğimiz riskler.
Bu tür sistemlerde tipik olarak neyin ters gittiği — ve bunu canlı ortamda görünür hâle gelmeden nasıl önlediğimiz.
Ş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; model kurallardan değil, kalıcılıktan (persistence) sorumlu kalır.
- Ödünleşim
- 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.
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.
- Ödünleşim
- Bedeli: Ek bir katman. Farklı durum: Yeniden kullanılmayan basit bir endpoint'te yapı yalın kalır.
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 mükerrer işlemleri önleyen (idempotent)'tir: bir anahtar, etkiyle aynı transaction içinde kontrol edilir ve kalıcı olarak kaydedilir.
- Ödünleşim
- Bedeli: Saklama süresi (retention) olan bir anahtar deposu. Farklı durum: Etki doğası gereği mükerrer işlemleri önleyen (idempotent) ise bu yeterlidir.
Ö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.
- Ödünleşim
- Bedeli: Tutarlılığı önceden düşünmek. Farklı durum: Tutarlılık gecikmeden daha önemliyse önbelleğe almak yerine sorguyu optimize ederiz.
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, metrikler ve trace'ler ilk güne aittir; sistem bir isteğin neden yavaş olduğunu söyleyebilir.
- Ödünleşim
- Bedeli: Enstrümantasyon ve özenle seçilmiş sinyaller. Farklı durum: Atılık bir prototipte asgari düzeyde.
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.
- Ödünleşim
- Bedeli: “Sadece Eloquent” yerine sorgulara dikkat. Farklı durum: Veri hacmi küçükse bu efor gereksizdir.
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.
- Ödünleşim
- 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.
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.
- Ödünleşim
- Bedeli: Başlangıçtan itibaren biraz daha fazla yapı. Farklı durum: Uzun vadeli bakımı olmayan kısa ömürlü bir uygulamada.
Uygulamadan önce netleştirdiğimiz sorular.
Mimariyi araç seçiminden çok sizin yanıtlarınız şekillendirir.
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.
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 mükerrer işlemleri önleyen (idempotent) biçimde bir kuyruğa taşınır; hayırsa yol senkron ve basit kalır.
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.
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.
İş 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.
İş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.
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.
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.
Tasarımdan işletime.
Sistemin yalnızca çalışması yetmez, işletimde de ayakta kalması gerekir. Her önerinin bir bedeli vardır — ve farklı karar verdiğimiz durumlar da.
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.
Ödünleşim · 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.
Ödünleşim · 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?
Ödünleşim · 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.
Ödünleşim · 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.
Ödünleşim · 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.
Ödünleşim · 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.
Ödünleşim · 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.
Ödünleşim · 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.
Ödünleşim · 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.
Ödünleşim · 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.
Ödünleşim · 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üşteri detaylarından arındırılmış soyutlanmış kesitler — mimari yaklaşımımızın birebir karşılığı: Olay güdümlü yapıda, yinelense dahi yan etki yaratmayan tutarlı süreçlerle kurgulanmış modüler monolit bir altyapı.
İlk görüşmeden çalışan sisteme.
Her proje aynı dört adımı izler. Ara sonuçları yalnızca sonda değil, süreç boyunca görür ve değerlendirirsiniz.
- 01
İhtiyacı anlamak, gereksinimleri netleştirmek
İlk görüşmeyi doğrudan yönetimle yaparsınız; projenizi, iş süreçlerinizi ve mevcut sistemlerinizi konuşuruz. Ardından hedefleri ve gereksinimleri yazılı hâle getirir, özel geliştirmenin anlamlı olup olmadığını açıkça söyleriz.
- 02
Çözümü ve mimariyi planlamak
Teknik bir çözüm önerir, kapsamı ve uygulama sırasını belirler, temel kararları gerekçeleriyle birlikte belgeleriz.
- 03
Geliştirmek ve birlikte kontrol etmek
Testler ve kod incelemeleriyle aşama aşama geliştiririz. Ara sonuçları düzenli olarak sunarız; böylece erken değerlendirip öncelikleri değiştirebilirsiniz.
- 04
Yayına almak ve desteğe devam etmek
Yayına alındıktan sonra bakım, güncelleme, izleme ve geliştirmeyi kararlaştırılan kapsamda üstleniriz. Projeye özel kaynak kod ve dokümantasyon size teslim edilir.
Proje sonunda elinizde olanlar.
İş mantığı framework'ten bağımsız olarak test edilebilir kalan bir sistem
İzlenebilir işletim: görünür kuyruklar, metrikler ve loglar
Bir ekibin yıllar boyunca geliştirmeye devam edebileceği bir kod tabanı
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 teknoloji yığını — 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?
Kendi çözümü yerine yerleşik kimlik doğrulama paketleri, en az yetki ilkesi, kodun dışında tutulan secret'lar, doğrulanmış girdiler ve escape edilmiş çıktılar. Güvenlik en sondaki bir denetim değil, en baştan verilen bir tasarım kararıdır — ödünleşim, kanıtlanmış konvansiyonlar uğruna biraz daha az serbestliktir.
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 konular.
Bu sayfayla bağlantılı rehberler, kararlar, hizmetler ve projeler.
Teknolojiler
Hizmetler
Projenizi konuşalım.
Projenizi kısaca anlatın. İlk görüşmeyi doğrudan yönetimle yaparsınız.
