Frontend vs Backend

Herkese merhaba,

Bu videodaki konumuz biraz ikimizi çatıştıracak bir konu 🙂 “Backend’çiler” ve “frontend’çiler”in ilişkileri dolayısıyla yaşadıkları çatışmalar. Kimi konuda backend’çinin kimi konuda frontend’çinin hataları oluyor. Bunların üzerinde biraz irdeleme yaparak, bazı sorunların nasıl çözülebileceğine dair fikirler sunacağız. Genel bir çözüm olarak ise ilgili tool’ları kullanmak ve düzgün dökümantasyon diyebiliriz.

Backend’çilerin bir sorun durumunda, önce sorunu düzeltip, sonra da “Abi orası zaten çalışıyor, tekrar kontrol et” demesi 🙂

Bilenler veya bilmeyenler olabilir, Burak Apps’te backend ve server işleriyle ilgilenirken, Mert de iOS uygulamalarıyla yani daha ziyade frontend tarafıyla ilgileniyor. İnsanlık hali belki backend işini yapan arkadaş unutmuş olabilir, yapıp deploy etmemiş olabilir çok da üzerine gitmemek lazım.

Şaka bir yana başımıza gelen bir olay. Backend’de bir sorun vardı ve biz bu sorunu ilettiğimizde backend’çi arkadaş(Burak değil başka biri 🙂 ) “orası zaten çalışıyor tekrar dener misin?” demişti. Ancak açıkça görünüyordu ki bütün backend değişmişti. Burak’ın daha farklı bir sorunu var, (ki bunu dış ses olarak Sedat söylüyor 🙂 ) Burak genelde yapması gereken  bir işi yapıyor ancak yaptığını söylemiyor. Endpoint’e eklenmesi gereken birşeyi söylediğimizde büyük ihtimalle 5 dakika içerisinde ekliyor ancak bize söylemediği için biz hala onunla uğraştığını zannedebiliyoruz. Kendi yerinde duran ve haberimizin olmadığı bir hizmet de açıkçası çok işimize yaramıyor.

Bu soruna çözüm önerisi olarak Postman gibi bir aracın kullanılmasını sunabiliriz. Backend’e birşey eklenildiği ya da orada bir sorun düzeltildiği an hemen Postman linkini alıp Frontend tarafına göndermek iyi bir alışkanlık olabilir. Bunun haricinde bir CI (continuous integration) sistemi varsa, her değişiklikte ilgililere bildirim göndermesi sağlanabilir. Ya da sırf bu iş için dünya kadar tool kullanmak yerine açık açık bir sorun vardı ve şimdi çözdüm, deneyebilirsin diyebilirsiniz 🙂 Sonuçta herkesin geliştirdiği sistemlerde bug çıkabiliyor, ayıp değil.

Frontend’çinin production ve development url’lerini karıştırması

Production’a development url’i ile çıkmak ya da development yaparken production url’i kullanmak,  frontend tarafında yaşanan karmaşalardan biri olabiliyor. Burada dikkat etmek gerekiyor  ya da build scriptler kullanıp, build ettiğiniz ortama göre url’lerin belirlenmesini sağlamak gerekiyor.

Mert bu sorunu kendi tarafında tek yönlü olarak çözmüş. Uygulamayı productiona çıkartmadan önce kontrol ettiği bir checklist’i var. Orda da bu konuyla ilgili bir madde var. Böylece productiona çıkarken development url kullanma sorununu çözmüş görünüyor. Ancak tersi için işlemiyor bu çözüm 🙂

Production url’i ile test yapmak tehlikeli olabiliyor. Bu canlı ortamda örneğin onbin kullanıcı varken, sırf test amaçlı bin kullanıcı daha eklerseniz işler karışabiliyor. Bu çıkan sorunlar da daha sonra backend’çinin başına kalıyor.

Backend’çinin hatasının faturasının Frontend’çiye kesilmesi

Mobil uygulamaların her ne kadar tasarım, backend, frontend, veritabanları vs. gibi bir çok katmanı olsa da, sonuçta uygulamayı yazan kişi frontend’çi olduğundan, tüm hatalardan ilk olarak o sorumlu tutuluyor. Tabii ki konu bir yerde backend’e ya da ilgili birime dönüyor ancak ilk darbeyi her zaman frontend karşılıyor. Baktığınızda özellikle tüm kısımlar bizim geliştirmemizdeyse çok da büyük bir sorun olarak görmüyoruz.

Genelde ufak problemler bu tarz sonuçlara yol açabiliyor. Hızlı olmak için bir kontrol es geçilmiş olabiliyor backend tarafında ya da server exceptionlar dönebiliyor bazı durumlarda. Ya da ülkemizde bir anda AWS kapatılabiliyor, ona bizim de yapabilecek birşeyimiz yok 🙂

Fiziksel olarak backend ve frontend geliştiricilerin yakın olması çok önemli. Tüm sorunlar bu şekilde hızlıca çözülebiliyor. Aynı şehirde olmak bile büyük avantajken, aynı odada çalışmak işleri gerçekten çok hızlandırıyor. Örneğin bir müşterimizle kapı komşusuyuz hatta tam kameradan baktığınız duvarın arkasında onlar var. Ve işin backend kısmı ile onlar ilgileniyor. Böyle olunca da tüm sorunlar çok hızlı bir şekilde çözülebiliyor.

Yanlış yapılan requestler

Bunun genel sebebi: kodun kopyala-yapıştır yapılması, en azından biz öyle tahmin ediyoruz 🙂 Özetle, POST metodu göndermeniz gereken yerde GET metodu göndermeniz ya da bir parametreyi body’den göndermek yerine header’dan göndermeye çalışmanız, hatalı bir request yapmanıza sebep olacaktır. Eğer bir frontend’çi olarak böyle bir durumda hemen backend’çiye dönüp “bu sorgu çalışmıyor” derseniz, üzülürsünüz 🙂 AppEngine gibi platformlarda bu hatalı requestler kolayca görünebiliyorken, kendi geliştirdiğimiz ortamlarda bu kadar kolay farkedilemeyebiliyor ve zaman kaybına yol açıyor.

REST mimarisine uygun geliştirilen sistemlerde aynı url üzerinden dört işlem yapılabiliyor. Dolayısıyla örneğin daha önce bir url ile POST metodunu kullanarak ekleme yaptığınız servise, aynı url ile okuma yapmak istediğinizde, kopyala-yapıştır yaparak aynı kodu kullanıp POST metodunu GET ile değiştirmediğiniz için istek düzgün cevaplanmıyor.

Çözüm olarak Burak her ne kadar Postman’de yeterince detay olduğunu söylese de, Mert bu detayların bazen gözden kaçabildiğini (kopyala yapıştıra devam edecek) söylüyor. Başka bir seçenek olarak 5 defa “neden?” sorusunu sorarak sorunun neden kaynaklandığını bulabilirsiniz. Konu ile ilgili tecrübeleriniz de arttıkça yani aynı sorunu sıkça yaşamaya başladıkça zaten suçu backend’e atmadan önce tüm sorguları kontrol etmeye başlıyorsunuz.

Tabii en güzel çözüm kopyala yapıştır yapmadan, her sorguyu baştan yazmak. Ancak Mert pek bu fikre sıcak bakmıyor gibi 🙂

Bütün iş mantığının client’a aktarılma çabası

Sebebi tamamen backend’çinin işten kaçıp, işi frontend’çiye yıkması 🙂 Bir işin mobilde yapılabiliyor olması, orada yapılmasını gerektirmiyor. Çünkü işlem gücü olarak mobil uygulamaların çalıştıkları cihazlar ile backend hizmetlerinin çalıştıkları makinalar aynı değil. Bir sunucunun görüntü işleme gücü ile mobil cihazın işleme gücü takdir edersiniz ki aynı değil. Hatta o kadar karmaşık bir işleme bile gerek yok. En basitinden uygulamada kullanılacak tarih formatı neyse, backend’den tüm tarihlerin o şekilde gelmesi gerekir, mobil uygulama tarihleri formatlama ile uğraşmamalıdır. Ya da uygulamada sadece kişinin yaşı kullanılacak, doğum tarihi kullanılmayacaksa, backend’den doğum tarihi gönderip, mobil uygulamada yaşı hesaplayıp göstermek yerine, backend’den doğrudan yaşın gelmesi daha doğru bir yaklaşım olacaktır.

Konumuzla doğrudan alakalı olmasa da artık mobil cihazlar sadece bilgi gösteren cihazlar haline gelmeye başladı ve bu devam edecek. Özellikle IoT ve giyilebilir cihazların yaygınlaşmasıyla mobil uygulamaların rolü iyice bilgi aktarımı ve gösterimi olmaya başladı. Bunun içindir ki işlemlerinizi backend’de yapın, bırakın frontend sadece bilgi göstersin 🙂

 

 

Bizim yaşadığımız sorunların bazıları bunlardı. Burak ve Mert kanlı bıçaklı değiller bu arada, sadece iş icabı bazı küçük tatlı çekişmeler 🙂 Eğer sizin de başınıza gelen backend-frontend çatışması varsa yorum ile bildirebilirsiniz.

 

Okuduğunuz / dinlediğiniz / izlediğiniz için teşekkür ederiz! 🙂

 

Leave a Reply

Your email address will not be published. Required fields are marked *