Bir haftada n8n, NocoDB, Appsmith ve Retool: low-code nerede biter, kendi kodunuz nerede başlar

Bir haftada küçük şirketlerin kullandığı dört low-code platformunun yeni sürümleri ve iki platform karşılaştırması çıktı. Art arda okununca hep aynı şey görülüyor: “ücretsiz sürümde neler var” tablosu, kapatılan bir özellik ve uygulamadan verilere taşınması gereken erişim yetkileri. İşletme sahibi için bu, platformun nerede ucuz olmaktan çıktığı ve kendi kodunu yazdırma vaktinin ne zaman geldiği sorusunun cevabı.

Bu hafta neler çıktı

n8n 23 Ekim'de 2.45.3 yamasını yayımladı, içinde tek bir düzeltme var: editörün açık temasında metin kontrastı. Yamalar sık geliyor ve n8n'i kendi sunucusunda tutan biri için güncelleme düzenli bir görev haline geliyor.

Bundan birkaç gün önce, 20 Ekim'de n8n, 14 Ekim'deki In The Loop konferansında logosunu, yazı tipini ve renklerini neden değiştirdiğini anlattı. Metinde benim için iki satır önemli: Community Edition kalıyor, model seçimi kalıyor. Gerisi marka hakkında.

Daha da önce, 16 Ekim'de n8n büyük şirketler için 12 otomasyon platformunun karşılaştırmasını yayımladı. Oradaki kriterler işe yarıyor: veriler nerede duruyor, SSO, RBAC ve denetim kaydı var mı, ajanlar neler yapabiliyor, fiyat kullanıcı başına mı yoksa görev başına mı hesaplanıyor. n8n kendisi için şunu yazıyor: kod okunmaya açık, kendi sunucunuza kurabilirsiniz, 1000'den fazla entegrasyon var, kapsanmayan durumlar için Code node var. Diğerleri kısaca ve n8n lehine anlatılıyor.

NocoDB 23 Ekim'de 2026.10.0'ı yayımladı. Timeline View'da fazla mesainin kırmızıyla vurgulandığı iş yükü takibi yalnızca ücretli planlarda. Geçmiş bir workflow çalıştırmasını adım adım yeniden oynatma, Community dahil bütün sürümlerde var. Otomasyonu düğmeyle başlatmak bulutta ücretsiz, Community'de yok. Sürümdeki kullanılabilirlik tablosu dürüst ve ilk okunması gereken şey o.

Appsmith 21 Ekim'de 2.5.1'i yayımladı ve oradaki asıl şey bir hatırlatma: yerleşik Appsmith AI 30 Eylül 2026'da kapatıldı, ona giden eski sorgular sürümden bağımsız olarak çalışmayı bıraktı. OpenAI, Anthropic ya da Google'a doğrudan bağlantıya geçmek gerekiyor.

Workato 20 Ekim'de 27 Eylül tarihli GigaOm raporuna dayanarak Boomi ile karşılaştırmasını yayımladı: 29 test, sonuç 1363'e karşı 1058; bunlardan altı test ajanlar ve MCP hakkında, orada 370'e karşı 220. Raporu Workato'nun kendisi sipariş etmiş ve bu metinde yazıyor. Hata yönetiminde ve kullanıcı yönetiminde Boomi önde.

Retool 22 Ekim'de Data Access Enforcement'ı tanıttı: tablolara, sütunlara ve satırlara yetkiler veri kaynağında bir kez tanımlanıyor ve bütün uygulamalara, workflow'lara ve ajanlara uygulanıyor. Varsayılan olarak adminler dahil herkese kapalı, kullanıcı kimliği olmayan sorgu engelleniyor. Herkese açık beta yalnızca Enterprise için ve yalnızca Postgres için. Bu önemli bir sınır: yetkileri uygulamalardan verilere taşımak gerektiğinde platform “çiz ve çalışsın” olmaktan çıktı.

Örnek: low-code üzerinde bir servis şirketi

Bir servis şirketini ele alalım. Siteden gelen talepler n8n üzerinden bir tabloya düşüyor, tablo Appsmith'te gösteriliyor, müşteri temsilcileri oradan çalışıyor. Altı ay her şey yolunda. Sonra muhasebecinin indirim sütununu görmemesi, taşeronun ise yalnızca kendi taleplerini görmesi gerekiyor. Sahibi “sadece sütunu gizleyin” diyor. Arayüzde gizlemek mümkün, ama tablonun API'si üzerinden sütun görünür kalıyor. Bundan sonrası ya her uygulamada yetkileri yeniden kurmak ya da Retool'un yaptığı şey: veri seviyesinde kurallar.

Platformun sınırı, veriye dair kuralların ekranın dışında da uygulanması gereken yerden geçiyor. Bunu ne kadar erken fark ederseniz geçiş o kadar ucuz olur.

Benim sınırım: 2015, 2017 ve AppSheet

2015'te bir pazarlama ajansı açtım ve onun için CRM'i ve otomasyonları no-code ile kurdum. Programlamaya 2017'de, şirketlerimin hazırda bulunmayan sistemlere ihtiyacı olduğunda başladım. Low-code platformlarını kötülemiyorum: benim yolum onlarla başladı.

ABD'de PDR alanındaki şirkette aynı sınır gözümün önünde geçti. 2021'de veriler Google E-Tablolar'daydı, ikinci geliştirici bunların üzerine AppSheet'te uygulamalar kuruyordu ve tablolar süreçleri yavaşlatıyordu. 2023'te hız ve tek tip veri formatı için SQL veritabanına geçmeyi önerdim, fikir desteklendi ve MariaDB'ye geçtikten sonra yeni servisleri birbiri ardına bağladık. Şimdi şirketin geliştiricileriyle birlikte yaptığımız React Native süper uygulaması AppSheet'in yerini alıyor: ofis, satış ekibi ve şirket sahibi onu zaten kullanıyor. AppSheet de yerinde duruyor: ikinci geliştirici onu yürütüyor ve içinde birçok uygulama yaptı.

2021'den 2025'e kadar Upwork üzerinden bana Google Sheets etrafında işler geldi. Kural orada da aynı: tablodaki script, süreç Google Sheets'te yaşadığı ve onu ayrı bir sisteme taşımak için erken olduğu sürece iyidir. Veri hacmi, kullanıcı sayısı ya da yetki gereksinimleri büyüdüğünde veritabanını konuşma vakti gelmiştir.

Ben ne yapardım

Platformu seçmeden önce sürümün kullanılabilirlik tablosunu ve son bir yılda kaldırılan özelliklerin listesini okuyun. Appsmith'te yerleşik AI uzun yaşamadı.

Yetkilerin nerede uygulandığını kontrol edin: ekranda mı, verilerde mi. Ekrandaysa, ilk değişiklikte kaç ekranı düzeltmek gerekeceğini hesaplayın.

Şirket için değerli olan mantığı kendi sunucunuzda tutun. Bir üretim şirketi için bütün hesaplamayı Node.js üzerindeki sunucuya taşıdım, böylece program arayüzüyle birlikte kopyalanamıyor.

Tabloların artık yetmediği anı İşletmenin tablolar yerine sisteme ihtiyaç duyduğu zaman yazısında anlattım. Daha önce hazır bir bağlayıcıda sürecinizin mantığının nerede başladığını ve sohbet gruplarıyla yönetim yerine ne zaman bir iç sistem gerektiğini yazmıştım. Aynı konuda: Google E-Tablolar'da Gemini ve beceri katalogları ve MCP. Hizmet alanları: süreç otomasyonu ve tek bir sistem olarak işletme. Projeler: PDR şirketiyle teknik ortaklık ve Upwork'te Google Sheets ve Apps Script. Platformunuz yetkilere ya da hacme takıldıysa, içinde şu anda neyin kurulu olduğunu anlatın. Görevi konuşalım.