Mobil tətbiq backend hazırlanması mobil interfeysin işləməsi üçün sadəcə server qurmaq deyil. O, istifadəçi hesablarının, məlumat sahibliyinin, biznes qaydalarının, API-lərin, push bildirişlərin, media yükləmələrinin və komandanın gündəlik əməliyyatlarının arxasında duran idarəetmə qatıdır. Təklif almadan əvvəl bu hissələri ayrıca deyil, bir məhsul arxitekturası kimi müəyyənləşdirmək lazımdır.
Praktik nəticə budur: tətbiqdə istifadəçinin gördüyü hər ekran üçün məlumatın mənbəyi, onu dəyişməyə kimin icazəsi olduğu, dəyişiklik uğursuz olduqda nə baş verdiyi və dəstək komandasının problemi necə araşdıracağı aydın olmalıdır. POLADO-da mobil tətbiqlərin hazırlanması işini məhz bu məhsul və əməliyyat baxışı ilə planlaşdırırıq.
Backend hansı məlumatın sahibi olmalıdır?
Mobil tətbiqi backend-in sadəcə məlumat ötürdüyü müstəqil ekranlar toplusu kimi düşünmək risklidir. Backend biznes üçün etibarlı mənbə olmalıdır: hesab statusu, rol və səlahiyyət, sifariş və ya müraciət vəziyyəti, abunəlik, ödəniş nəticəsi, bildiriş seçimləri və audit tarixi burada idarə olunmalıdır.
İlk arxitektura sessiyasında hər əsas obyekt üçün bu sualları cavablandırın:
- Bu obyektin əsas sahibi hansı sistemdir: yeni backend, mövcud CRM, ERP, ödəniş provayderi, yoxsa başqa platforma?
- Mobil tətbiq məlumatı oxuyur, yaradır, redaktə edir, yoxsa yalnız sorğu göndərir?
- Məlumat hansı vəziyyətlərdən keçir və keçidə kim icazə verir?
- Eyni əməliyyat iki dəfə göndərilərsə, nəticə necə qorunur?
- İstifadəçi və ya operator bu dəyişikliyi sonradan necə izah edə bilər?
Məsələn, çatdırılma tətbiqində kuryerin telefondakı “çatdırıldı” düyməsi sifarişin həqiqəti deyil; bu, backend-ə göndərilən hadisədir. Backend kuryerin həmin sifarişə təyin olunduğunu yoxlayır, keçid qaydasını tətbiq edir, vaxtı qeyd edir və sonra yeni vəziyyəti həm tətbiqə, həm də admin panelinə qaytarır.
Autentifikasiya və rollar: girişdən daha geniş məsələ
Mobile app authentication architecture qeydiyyat və parol ekranı ilə bitmir. Sistem hesabın yaradılması, e-poçt və ya telefon təsdiqi, parolun bərpası, cihazdan çıxış, sessiyanın yenilənməsi, bloklama, hesab silinməsi və dəstək üçün hesabın araşdırılmasını əhatə etməlidir.
Native tətbiqlər üçün OAuth əsaslı girişdən istifadə edilirsə, mobil tətbiq gizli müştəri sirrini etibarlı saxlaya bilən mühit sayılmamalıdır. IETF-in native tətbiqlər üçün tövsiyəsi xarici brauzer vasitəsilə avtorizasiya və public client-lər üçün PKCE dəstəyini nəzərdə tutur. ([rfc-editor.org](https://www.rfc-editor.org/info/rfc8252/?utm_source=openai))
Rol modeli ekran siyahısı deyil, icazə matrisi olmalıdır
“İstifadəçi”, “menecer” və “admin” kimi rol adları kifayət etmir. Hər həssas hərəkət üçün icazəni yazın: kim müştərinin əlaqə məlumatını görə bilər, kim sifarişi ləğv edə bilər, kim geri ödəniş sorğusu yarada bilər, kim digər operatorun qeydlərini oxuya bilər?
- Autentifikasiya: sistem istifadəçinin və ya xidmətin kimliyini təsdiqləyir.
- Avtorizasiya: həmin kimliyin konkret obyekt və əməliyyat üçün icazəsini yoxlayır.
- Audit izi: kim, nəyi, nə vaxt və mümkün olduqda hansı səbəblə dəyişib.
İcazə yoxlaması yalnız tətbiq ekranında gizlədilməməlidir. Server hər sorğuda obyekt və funksiya səviyyəsində qərar verməlidir. OWASP API risklərində obyekt səviyyəli avtorizasiya çatışmazlığı və zəif autentifikasiya əsas təhlükələr sırasındadır. ([api-security.owasp.org](https://api-security.owasp.org/editions/2023/en/0x11-t10/?utm_source=openai))
Mobil tətbiq API hazırlanması: müqaviləni tətbiqdən əvvəl dəqiqləşdirin
Mobile app API development üçün API yalnız endpoint siyahısı deyil, mobil komanda ilə backend komandasının işlək müqaviləsidir. Bu müqavilə tətbiqin hansı məlumatı, hansı formatda, hansı səhv kodu ilə və hansı gecikmə davranışı ilə gözlədiyini müəyyən edir.
Əsas istifadəçi axınları üçün aşağıdakıları sənədləşdirin:
- Metod, URL və tələb olunan identifikasiya;
- Sorğu və cavab sahələri, məcburi və seçimli sahələr;
- Boş siyahı, qismən məlumat, səhv giriş və icazəsiz giriş davranışı;
- Səhifələmə, filtr, sıralama və tarix saat formatı;
- Yenidən cəhd edilən yazma sorğuları üçün idempotency qaydası;
- Mobil versiya köhnə olduqda uyğunluq və API dəyişiklik siyasəti.
Məsələn, profil yeniləmə endpoint-i bütün profil obyektini kor-koranə qəbul etməməlidir. İcazə verilən sahələri, dəyişdirilə bilməyən server sahələrini və doğrulama səhvlərini dəqiq ayırmaq lazımdır. Bu, həm tətbiq davranışını proqnozlaşdırılan edir, həm də həddindən artıq məlumat açıqlanması və mass assignment riskini azaldır. ([api-security.owasp.org](https://api-security.owasp.org/editions/2023/en/0x11-t10/?utm_source=openai))
Oxuma və yazma axınlarını ayrı planlayın
Ən vacib ekranların sürətli açılması üçün tətbiqin nələri keşləyə biləcəyini, hansı məlumatın isə hər dəfə serverdən yoxlanacağını təyin edin. Yazma əməliyyatlarında istifadəçiyə “qəbul edildi”, “emal olunur” və ya “uğursuz oldu” kimi real vəziyyətlər göstərilməlidir. Optimistik interfeys faydalı ola bilər, lakin server cavabını əvəz etməməlidir.
Push notification backend: bildiriş hadisədir, həqiqətin özü deyil
Push bildiriş sistemində düzgün sual “bildirişi necə göndərəcəyik?” deyil, “hansı biznes hadisəsi kimə, nə vaxt, hansı üstünlüklə və hansı dərin keçidlə çatmalıdır?” sualıdır. Apple modelində şirkətin provider server-i cihaz tokenlərini hesablarla əlaqələndirir, bildiriş payload-unu yaradır və APNs-ə göndərir. FCM də göndərmə məntiqinin etibarlı server mühitində qurulmasını nəzərdə tutur. ([developer.apple.com](https://developer.apple.com/documentation/UserNotifications/setting-up-a-remote-notification-server?changes=__9&utm_source=openai))
Etibarlı push notification backend üçün bu axını hazırlayın:
- Backend-də biznes hadisəsi yaranır: yeni mesaj, görüş xatırlatması, status dəyişikliyi və ya təsdiq gözləyən sorğu.
- Hadisə qayda mühərriki tərəfindən qiymətləndirilir: alıcı, kanal, dil, prioritet, sakit saat və istifadəçi seçimi.
- Arxa plan job-u göndəriş cəhdini yaradır, provayder cavabını və uğursuz tokenləri qeyd edir.
- Bildiriş tətbiqi konkret dərin keçidlə açır, sonra tətbiq aktual məlumatı API-dən yenidən alır.
- Admin və dəstək komandası göndəriş, açılma, səhv və imtina tarixçəsini araşdıra bilir.
Bu son addım vacibdir: push payload-u sifariş, mesaj və ya hesab vəziyyəti üçün yeganə mənbə olmamalıdır. Bu, platforma çatdırılmasının cihazın vəziyyətindən və platforma qaydalarından asılı olması faktından çıxan arxitektura nəticəsidir; tətbiq açıldıqda aktual vəziyyəti backend-dən yoxlamalıdır. Android-də məsələn, fon rejimində notification və data mesajlarının emalı fərqlənir. ([firebase.google.com](https://firebase.google.com/docs/cloud-messaging/android/receive-messages?hl=en&utm_source=openai))
Media yükləmələri, analitika və admin əməliyyatları
Foto, sənəd, video və ya səs qəbul edən tətbiqdə media faylının özünü API serverindən keçirmək həmişə ən doğru seçim deyil. Tipik həll backend-in yükləmə icazəsi və məhdud müddətli upload ünvanı yaratması, faylın obyekt yaddaşına birbaşa göndərilməsi, backend-in isə fayl metadatasını, sahibini, görünürlük qaydasını və emal statusunu idarə etməsidir.
Bu mövzuda əvvəlcədən qərar verin:
- Fayl ölçüsü, formatı və say limiti;
- Şəxsi fayla girişin yoxlanması;
- Preview, sıxılma və ya virus yoxlaması kimi emal addımları;
- Uğursuz yükləmə, yarımçıq fayl və silinmə siyasəti;
- Faylın hansı biznes obyektinə aid olduğu və saxlanma müddəti.
Analitika isə “neçə ekran açıldı?” sualından başlamamalıdır. Məhsul qərarı üçün hadisələri istifadəçi niyyəti ilə əlaqələndirin: qeydiyyat başladı və tamamlandı, ilk əsas əməliyyat edildi, dəvət göndərildi, ödəniş axını dayandı, bildirişdən hansı ekrana keçildi. Hadisə adı, sahələri, identifikatoru və məxfilik qaydası backend, mobil və analitika komandaları üçün eyni sənəddə olmalıdır.
Mobile app admin panel development ayrıca “sonra baxarıq” işi deyil. Operatorların istifadəçini tapması, vəziyyətləri idarə etməsi, istisnaları həll etməsi və müştəri müraciətlərinə cavab verməsi üçün ən azı məqsədli back-office tələb olunur. Admin paneli mobil tətbiqin bütün imkanlarını təkrarlamamalıdır; o, gündəlik əməliyyatlar üçün lazımi axtarış, filtr, icazə, təsdiq və audit imkanlarını verməlidir. Bu hissəni veb platforma hazırlanması ilə eyni backend üzərində qurmaq adətən məlumatın ikiləşməsinin qarşısını alır.
Mühitlər, buraxılış və dəstək sahiblikləri
Mobil tətbiq App Store və Google Play-ə çıxdıqdan sonra backend dəyişməyə davam edir. Buna görə development, staging və production mühitləri; ayrıca konfiqurasiya və sirlər; miqrasiya planı; geriyə uyğun API dəyişiklikləri; monitorinq və insident prosesləri layihə planında olmalıdır.
Buraxılışdan əvvəl cavablandırılmalı suallar:
- Kim production dəyişikliklərini təsdiqləyir və geri qaytarır?
- Mobil tətbiqin köhnə versiyası yeni backend ilə nə qədər işləyəcək?
- Token, parol bərpası, ödəniş və ya bildiriş xətası necə aşkar olunacaq?
- Dəstək əməkdaşı istifadəçiyə kömək edərkən hansı məlumatı görəcək və hansı əməliyyatı edə biləcək?
- API, bulud infrastrukturu, push provayderi və mağaza hesabları üçün sahib kimdir?
Bu tələblər başlanğıcda konkretləşərsə, tətbiq yalnız demo üçün deyil, gündəlik istifadə və böyümə üçün hazırlanır. Uzunmüddətli monitorinq, təhlükəsiz buraxılışlar və texniki ownership üçün texniki dəstək və konsaltinq xidmətimizdən istifadə etmək mümkündür.
Qərar vermə mərhələsi üçün backend checklist
- Əsas biznes obyektləri, vəziyyət keçidləri və sistem-of-record müəyyənləşdirilib.
- Qeydiyyat, giriş, sessiya, hesab bərpası, rol və audit qaydaları yazılıb.
- API müqaviləsi əsas mobil axınlar, səhvlər və versiyalaşdırma ilə təsdiqlənib.
- Push hadisələri, alıcı qaydaları, deep link-lər və token idarəetməsi planlanıb.
- Media, analitika, admin panel və dəstək iş axınları scope-a daxildir.
- Mühitlər, buraxılış məsuliyyətləri, monitorinq və post-launch support sahiblikləri təyin olunub.
Əgər mobil məhsulunuzun ekranları artıq təxminən bəllidirsə, növbəti addım backend və əməliyyat boşluqlarını aşkar etməkdir. POLADO ilə konsultasiya üçün əlaqə saxlayın; tətbiq, API, admin panel və dəstək qatını birlikdə real scope-a çevirək.