Yerel Geliştirmeden Dağıtıma: Kado’yu Oluştururken Öğrendiklerim

Sonuç olarak, son birkaç ayda kişisel kullanım için finans yönetimi yapabilmemi sağlayan bir platform geliştirdim. Tablo kullanmayı sevmem ve aynı zamanda yeni şeyler öğrenmek istemem nedeniyle Filament PHP’den başlayarak bağımsız bir frontend ve backend mimarisine geçiş yaptım.

Öncelikle

Kado, kişisel finans yönetimi için bir projedir. Benim amaçlarım arasında bir ürün yaratmak yoktu; iki problemi çözmeye odaklandım: harcamaları kontrol etmek ve yeni projeler için fikir bulmak. Sonuçta bu projeyi geliştirerek daha karmaşık kavramları öğrenmeyi hedefledim: proxy reverso, frontend ve backend entegrasyonu, otomatik deploy pipeline’ları, Nginx yapılandırması, SSL sertifikaları, üretim projeleri gibi konular.

Sonunda, ihtiyaçlarımı karşılayan bir MVP’ye ulaştım. Gelir ve harcama kayıtlarını kategorize edip takip edebiliyorum, böylece paranın nereye gittiğine dair bir genel bakış elde ediyorum.

Burada amacım detaylı bir açıklama yapmak değil, şimdiye kadar yaptıklarımı paylaşmaktır.

Filament ile ne gibi bir ilişkim var?

Başlangıçta amacım, sadece Filament kütüphanesi üzerine yerel bir şeyler geliştirmekti fakat sonrasında yeterli gelmediğini fark ettim. Bazı etkileşim türlerini gerçekleştirmekteki kısıtlamalar, farklı tasarım taleplerim gibi faktörler, projeyi iki kola ayırmama neden oldu: backend’i bir API Laravel ile, frontend’i ise bir React + TypeScript uygulaması olarak geliştirmeye karar verdim. Bu benim için yeni bir ön yüz laboratuvarı oldu.

Ne öğrendim?

Bu projede çalışarak, gerçek projelerde kullanılan araçlar ve kavramlar hakkında daha iyi bir anlayış kazandım:

Proxy Reverso

Bir VPS’m vardı ve başka bir projeyi basit bir şekilde çalıştırıyordum: Nginx ve PHP-FPM, konteyner olmadan 80. portta. Ancak başka bir projeyi bu VPS üzerinde çalıştırmak isteyince, bunu nasıl yapacağımı bilmiyordum.

Bu durumu çözmek için, VPS üzerinde ana sunucu olarak kurulu bir Nginx sunucusu kullanmaya karar verdim. Bu sunucu, farklı projelere yönlendirme yapacak şekilde ayarlandı.

Böylece, bir VPS üzerinde birden fazla projeyi basit bir şekilde yönetmiş oldum.

Alan Adları ve SSL

Bir projenin IP adresi üzerinden çalışması hoş görünmüyor ve güvenli de değil.

Bu nedenle, projelerim için alan adı ve alt alan adlarını nasıl ayarlayabileceğime baktım. Alan adımı satın aldım ve DNS ayarlarını alt alan adlarını kullanacak şekilde yapılandırdım.

Bu şekilde, tek bir alan adı ile birçok proje oluşturabilirim ve proxy reverso ayarlarımla uyumlu hale getirebilirim.

Ancak bu durum bir güvenlik sorununu çözmüyor. HTTP istekleri basit durumlar için yeterli olabilirken, günümüzde HTTPS için SSL sertifikası ayarlamak oldukça kolay. Bu da projeme ek bir güvenlik katmanı ekliyor.

Sertifikaları elde etmek için Certbot kullanarak doğru Nginx yapılandırması ile hızlıca çalıştırabilirim.

Deploy ve CI/CD

Projenin yerel olarak çalıştırılması kolaydır: sadece php artisan serve veya npm run dev komutunu çalıştırmak yeterlidir. Ancak gerçek bir projeyi deploy etmek başka bir hikayedir.

Burada, ortam yapılandırması, erişim ve klasör izinleri gibi unsurlarla ilgilenmek gerekiyor. Bu noktada dikkatli olmak çok önemlidir; çünkü çoğu hata bu aşamada meydana gelir.

Otomatik deploy sırasında izin sorunları nedeniyle birçok problem yaşadım. Bu sıklıkla Laravel projelerini konteynerlerde çalıştırırken karşılaştığım bir sorun.

Ayrıca, her değişiklikte sunucunun SSH’sine erişmek de pek hoş bir durum değil. İşte burada GitHub Actions devreye giriyor.

GitHub Actions ile, GitHub’daki bir olayda (örneğin yeni bir release oluşturma) deploy pipeline’ı ayarlayabiliyoruz. Sunucuya erişim, kod güncellemesi, migration’ların çalıştırılması gibi adımları tanımlayarak bu süreci otomatikleştirebiliriz.

Kado API’sinin deploy sürecini böylece yapılandırdım, çünkü Vercel, React projeleri için bunu basit bir şekilde sağlıyor. Sadece projemi bir kez ayarlamak yeterli. Sonrasında, her push ile otomatik olarak deploy ediliyor.

Ayrıca, PR’lar için testlerin veya linters’ın çalıştırılması gibi güvenlik adımları da ayarlayabiliyoruz. Ancak ben bu yapıyı seçmedim, çünkü şu anda Kado’nun koduyla sadece ben ilgileniyorum ve bu kadar karmaşıklığa gerek yok.

Frontend ile Backend’i Entegre Etmek

Monolitik projelerde, CORS, token ile kimlik doğrulama gibi konularla fazla uğraşmak gerekmeyebilirken, frontend ile backend’in ayrı olduğu projelerde bu durum farklıdır.

Bu projede, bu ayrım kasıtlıydı. React üzerinde çalışmak, değişiklikleri görsel hale getirmenin kolaylığı ve yayının basitliği nedeniyle benim için daha mantıklıydı. Ancak bu durum her zaman avantaj sağlamıyor.

Backend ve frontend ayrıldığında iyi tanımlanmış bir sözleşmenin gerekliliği, gelişimin mutluluğu için anahtar noktadır. Küçük bir değişiklik bile büyük hata olasılıklarını artırır.

Bu noktada, otomatik testlerin ve linters’ın ne kadar önemli olduğunu garanti edebilirim.

Frontend için gerçek anlamda otomatik test yazmadım, ancak Biome (linter) yapılandırması, kod stilini standart hale getirmek ve yeniden yapılandırma önerileri almak için çok önemliydi. Böylece, potansiyel sorunların üstesinden gelinmiş oldu.

Backend için daha derine inerek: otomatik testler oluşturmak için Pest kullandım, kodun statik analizi için PHPStan, stil ayarlamaları için Laravel Pint ve yeniden yapılandırma için Rector’ü kullandım. Projelerde PHP ile çalışıyorsanız bu kütüphaneleri kesinlikle bilmelisiniz.

Kod kalitesi her sorunu çözmez ama Cuma gününü daha huzurlu şekilde tamamlayabilmeniz için şansınızı artırır; böylece hafta sonu boyunca bir dd() kullanmayı unuttuğunuz için aramayla karşılaşmazsınız.

Bugün farklı neler yapardım?

Şimdi geriye baktığımda, oldukça başarılı bir öğrenme laboratuvarım olduğunu görüyorum ama yapmak istediğim bazı şeyler vardı.

• Yeni projeler için koddan önce ön planlama: Kişisel bir proje olmasına rağmen, süreci daha iyi yapılandırmak için daha fazla zaman harcamak isterdim. Bu bana büyük sorun ve fazla iş yükü kazandırmazdı.
• Başladığımdan itibaren linters ve testler: Projenin başında epeyce ‘moda akımı’ gibi davrandım ve birçok şeyi yeniden yazmak zorunda kaldım.
• Geliştirme sürecini paylaşmak: Eğer daha fazla zamanım olsaydı, LinkedIn veya Dev.to gibi yerlerde geliştirme sürecimi daha iyi belgelerdim. Fikirleri ve bilgiyi ifade etmek, bu belirsiz alanda iyi bir profesyonel olmanın temellerinden biridir.

Fakat farklı bir yaklaşım sergilediğim için şu anki sonuçtan hoşlanmadığım bir durum yok. Uçtan uca bir projeye sahip olmak gerçekten büyük bir fayda. Bu, baştan aşağıya gerçekleştirebileceğin bir şey olduğunu görmek için bir kanıt niteliğindedir.

Sonuç

Sonunda, Kado belki de piyasada birçok mevcut finans yönetim aracından sadece biri olabilir fakat benim için, son bir yılda yazılım geliştirici olarak kazandığım deneyimi ve ürün hakkında geliştirdiğim anlayışı kanıtlıyor.

Durumdan memnunum ama geliştirmeye devam edeceğim. Her zaman yaratacak bir şey vardır ve artık nereden başlayacağımı biliyorum.

Proje linki: https://kado-tan.vercel.app/inicio