Pinco tətbiqinin kodunun daxili quruluşu və tətbiq edilən texnologiyalar

Pinco tətbiqinin mənbə kodunun detallı texniki təhlili. Proqramın arxitekturası, əsas kitabxanaları və tətbiqetmə xüsusiyyətləri haqqında məlumat.

Pinco tətbiqinin kodunun daxili quruluşu və tətbiq edilən texnologiyalar

Platformanın təhlükəsizliyini optimallaşdırmaq üçün dərhal lokal məlumat anbarının AES-256 alqoritmi ilə şifrələnməsinə və bütün API sorğuları üçün certificate pinning (sertifikatların bərkidilməsi) mexanizminin tətbiqinə diqqət yetirin. Bu iki addım, istifadəçi məlumatlarının həm cihazda saxlanarkən, həm də serverə ötürülərkən kənar müdaxilədən qorunmasını təmin edir. Şifrələmə açarlarının Keychain və ya Android Keystore kimi təhlükəsiz anbarlarda saxlanılmasına xüsusi nəzarət edin.

Proqram təminatının arxitekturası MVVM (Model-View-ViewModel) nümunəsi üzərində qurulub. Bu yanaşma, istifadəçi interfeysi (View) məntiqini biznes məntiqindən (ViewModel) ayıraraq, instruksiyalar toplusunun test edilməsini və dəstəklənməsini asanlaşdırır. Mənbə yazılışını təhlil edərkən, ViewModel və Repository təbəqələri arasındakı məlumat axınına fikir verin. View təbəqəsindən birbaşa məlumat mənbəyinə edilən istənilən müraciət, arxitektura prinsipinin pozulmasını göstərən bir siqnaldır və dərhal aradan qaldırılmalıdır.

Asılılıqların idarə edilməsi üçün layihədə Swift Package Manager və ya Gradle istifadə olunur. Package.swift və ya build.gradle fayllarını diqqətlə yoxlayın. Məlum zəiflikləri olan və ya son 12-18 ay ərzində yenilənməyən kənar kitabxanalardan istifadədən çəkinin. Məsələn, şəbəkə əməliyyatları üçün istifadə edilən Alamofire və ya Retrofit kitabxanalarının ən son stabil versiyalarının tətbiq edildiyindən əmin olun, çünki köhnə versiyalar potensial təhlükəsizlik boşluqları yarada bilər.

Pinco Tətbiqinin Kodu

Proqram təminatının arxitekturası üçün əsas kimi Model-View-ViewModel (MVVM) dizayn nümunəsi seçilib, bu da istifadəçi interfeysi (UI) məntiqinin biznes məntiqindən aydın şəkildə ayrılmasını təmin edir. Bu yanaşma komponentlərin təkrar istifadəsini asanlaşdırır və test prosesini sadələşdirir.

iOS platforması üçün proqramlaşdırma dili olaraq Swift istifadə edilir. SwiftUI freymvorku deklarativ sintaksis vasitəsilə interfeyslərin sürətli qurulmasına imkan verir. Asinxron əməliyyatlar üçün Combine freymvorku inteqrasiya edilib.

Android versiyası üçün Kotlin dili və Jetpack Compose kitabxanası tətbiq olunur. Bu, reaktiv proqramlaşdırma paradiqmalarından faydalanaraq daha az sətirlik ilkin yazılımla daha dayanıqlı komponentlər yaratmağa şərait yaradır. Koin kitabxanası asılılıqların idarə edilməsi (dependency injection) üçün istifadə olunur.

Server tərəfi Node.js mühitində qurulub və Express.js freymvorkundan faydalanır. Bu seçim asinxron sorğuların yüksək performansla idarə olunmasını təmin edir. Məlumatların saxlanması üçün PostgreSQL relyasiyalı verilənlər bazası sistemi seçilib. JSONB tiplərinin dəstəklənməsi çevik sxemlərlə işləməyə imkan verir.

Müştəri və server arasında məlumat mübadiləsi GraphQL vasitəsilə həyata keçirilir. Bu, REST API-lərdən fərqli olaraq, mobil utilitin yalnız tələb etdiyi məlumatları almasına şərait yaradır və artıq məlumat ötürülməsinin qarşısını alır.

Proqram təminatının keyfiyyətini təmin etmək üçün vahid testlər (unit tests) üçün XCTest və JUnit, inteqrasiya testləri üçün isə avtomatlaşdırılmış skriptlər istifadə olunur. Davamlı inteqrasiya və çatdırılma (CI/CD) prosesləri Jenkins aləti vasitəsilə idarə edilir.

Pinco tətbiqində istifadəçi avtorizasiyası: JWT tokenlərin tətbiqi addımları

İstifadəçi autentifikasiyası üçün /api/auth/login kimi bir son nöqtəyə POST sorğusu ilə istifadəçi adı və şifrə göndərilir. Server bu məlumatları verilənlər bazasındakı qeydlərlə yoxlayır.

Tokenin generasiyası: Uğurlu yoxlamadan sonra server JSON Web Token yaradır. Bu token üç hissədən ibarət olmalıdır: başlıq (header), yük (payload) və imza (signature). Başlıq alqoritmi (məsələn, HS256) və token tipini (JWT) müəyyən edir. Yük istifadəçiyə aid məlumatları saxlayır: `sub` (istifadəçi ID-si), `iat` (yaradılma vaxtı), `exp` (bitmə vaxtı) və xüsusi iddialar (məsələn, `rol: “admin”`). Giriş tokenlərinin etibarlılıq müddəti qısa olmalıdır, məsələn, 15 dəqiqə. İmza isə kodlanmış başlıq, kodlanmış yük və yalnız serverə məlum olan məxfi açarın birləşməsindən istifadə edilən alqoritmlə yaradılır. Məxfi açar yüksək entropiyalı olmalı və mühit dəyişənlərində (environment variables) saxlanmalıdır.

Server yaradılmış giriş tokenini və opsional olaraq yeniləmə tokenini JSON formatında klientə geri qaytarır: { "accessToken": "...", "refreshToken": "..." }.

Tokenin klient tərəfində saxlanması: Proqram təminatı alınan tokeni təhlükəsiz şəkildə saxlamalıdır. Veb platformaları üçün HttpOnly kukilər XSS hücumlarının qarşısını almaq üçün ən yaxşı seçimdir. localStorage istifadəsi daha az təhlükəsiz hesab olunur.

Mühafizə olunan sorğular: Qorunan marşrutlara sonrakı sorğular üçün klient JWT-ni Authorization başlığında Bearer sxemi ilə göndərir: Authorization: Bearer <token>.

Serverdə yoxlama: Platformanın arxa hissəsindəki ara proqram təminatı (middleware) bütün qorunan sorğuları tutur. O, başlığı yoxlayır, tokeni çıxarır və məxfi açar vasitəsilə imzanı təsdiqləyir. Həmçinin tokenin bitmə müddəti (`exp` iddiası) yoxlanılır. Token etibarlıdırsa, sorğu növbəti mərhələyə ötürülür; əks halda, 401 Unauthorized statusu qaytarılır.

Tokenin yenilənməsi: Giriş tokeninin müddəti bitdikdə, proqram təminatı uzunömürlü yeniləmə tokenindən istifadə edərək xüsusi bir son nöqtəyə (məsələn, /api/auth/refresh) sorğu göndərir. Bu proses istifadəçinin yenidən daxil olmasını tələb etmədən yeni bir giriş tokeni əldə etməyə imkan verir. Yeniləmə tokenləri hər istifadədən sonra server tərəfində etibarsız edilməlidir.

Pinco-nun əsas lenti üçün məlumat modelinin və API endpoint-lərin qurulması

Əsas lent üçün məlumat strukturunu təşkil edərkən, hər bir paylaşıma aid olan sahələri dəqiq müəyyən etmək lazımdır. JSON formatında təqdim olunan model aşağıdakı sahələri ehtiva etməlidir:

id: Unikal identifikator (UUIDv4 formatı tövsiyə olunur).
author: Paylaşımı edən istifadəçinin məlumatlarını saxlayan obyekt. Bu obyektə user_id, username və profile_picture_url daxil edilməlidir.
content: Mətn məzmunu üçün bir sahə (text) və media faylları üçün bir massiv (attachments). Hər bir qoşma faylı type (məsələn, ‘image’ və ya ‘video’) və url sahələrinə malik olmalıdır.
stats: Statistik məlumatları saxlayan obyekt. Bura likes_count, comments_count və views_count kimi tam ədəd tipli dəyərlər daxildir.
is_liked: Cari istifadəçinin bu paylaşımı bəyənib-bəyənmədiyini göstərən boolean dəyər. Bu, klient tərəfdə interfeysin dərhal yenilənməsi üçün lazımdır.
created_at: Paylaşımın yaradılma tarixi (ISO 8601 formatında).

Platformanın əsas lent funksionallığı üçün RESTful prinsiplərinə əsaslanan aşağıdakı API endpoint-lər hazırlanmalıdır:

Lentin yüklənməsi:
- Metod: GET
- Endpoint: /api/v2/feed
- Parametrlər: Sonsuz sürüşmə (infinite scroll) üçün kursor əsaslı paqinasiya istifadə edin. Məsələn, ?limit=20&cursor=A_PREVIOUS_POST_ID. İlk sorğuda cursor parametri göndərilmir.
- Uğurlu cavab (200 OK): Paylaşım obyektlərindən ibarət massiv və növbəti səhifə üçün next_cursor dəyərini qaytaran bir JSON obyekti.
Yeni paylaşımın yaradılması:
- Metod: POST
- Endpoint: /api/v2/posts
- Sorğu (Request Body): Məzmunun mətni (content.text) və əlavə edilmiş media fayllarının identifikatorlarını (content.attachments) özündə saxlayan JSON obyekti.
- Uğurlu cavab (201 Created): Server tərəfindən yaradılmış və bütün sahələri doldurulmuş yeni paylaşım obyekti.
Paylaşımın bəyənilməsi/bəyənmənin ləğvi:
- Metod: POST
- Endpoint: /api/v2/posts/id/like
- Sorğu (Request Body): Boş.
- Uğurlu cavab (200 OK): Bəyənmə sayının yenilənmiş dəyərini (likes_count) və is_liked: true statusunu qaytaran kiçik bir JSON obyekti. Bəyənməni ləğv etmək üçün DELETE metodu ilə /api/v2/posts/id/like endpoint-inə sorğu göndərilir və cavab olaraq is_liked: false qaytarılır.

Bütün cavablar standartlaşdırılmış bir quruluşda qaytarılmalıdır. Uğurlu sorğular üçün cavab formatı { "status": "success", "data": { ... } }, xəta baş verdikdə isə { "status": "error", "error_code": 1204, "message": "Məlumat tapılmadı." } şəklində olmalıdır. Bu yanaşma klient tərəfdə vahid xəta emalı mexanizminin qurulmasını asanlaşdırır.

GitHub Actions vasitəsilə Pinco backend-in qurulma və deploy prosesinin avtomatlaşdırılması

Deployment prosesini avtomatlaşdırmaq üçün `.github/workflows/deploy.yml` faylında `main` branch-ə hər `push` əməliyyatında işə düşən bir workflow yaradın. Bu, yalnız təsdiqlənmiş dəyişikliklərin istehsal mühitinə (production) ötürülməsini təmin edir. Workflow-u `on: push: branches: [ “main” ]` konfiqurasiyası ilə başladın.

Workflow-un ilk addımı olaraq, `actions/checkout@v3` istifadə edərək repozitoriyanın mənbə fayllarını runner-a yükləyin. Dərhal sonra, layihənin tələb etdiyi mühiti qurun, məsələn, Node.js üçün `actions/setup-node@v3` ilə konkret versiyanı (`node-version: ’18.x’`) təyin edin. Bu, qurulma prosesinin müxtəlif mühitlərdə stabil qalmasına zəmanət verir.

Asılılıqların quraşdırılması üçün `npm install` əvəzinə `npm ci` əmrini icra edin. `npm ci` əmri `package-lock.json` faylına əsaslanaraq paketləri quraşdırır və CI/CD proseslərində daha sürətli və etibarlı nəticə verir. Asılılıqlar quraşdırıldıqdan sonra `npm run build` skripti ilə backend-in istehsal üçün hazır versiyasını yaradın.

Qurulma prosesindən sonra mütləq şəkildə unit və inteqrasiya testlərini işə salın (`npm test`). Workflow-da elə bir şərt təyin edin ki, testlərdən hər hansı biri uğursuz olarsa, deploy prosesi dərhal dayandırılsın və komandaya bildiriş göndərilsin. Bu, xətaların serverə çatmasının qarşısını alır.

Testlər uğurla başa çatdıqdan sonra, sistemin son vəziyyətini Docker obrazına paketləyin. Obrazı `docker build -t ghcr.io/USERNAME/IMAGE_NAME:$ github.sha ` . əmri ilə yaradın. Burada `$ github.sha ` istifadə etmək hər bir obrazı unikal commit hash-i ilə əlaqələndirir və versiyalara nəzarəti asanlaşdırır.

Docker obrazını GitHub Container Registry (GHCR) və ya Docker Hub kimi bir reyestrə yükləməzdən əvvəl `docker/login-action@v2` istifadə edərək autentikasiya edin. Bu proses üçün `secrets.GITHUB_TOKEN` istifadə etmək təhlükəsizdir. Sonra `docker push` əmri ilə obrazı reyestrə göndərin.

Son addım olaraq, `appleboy/ssh-action@master` kimi bir action vasitəsilə istehsal serverinə (production server) SSH ilə qoşulun. Qoşulduqdan sonra, reyestrdən yeni Docker obrazını (`docker pull`) çəkin, köhnə konteyneri dayandırın və yeni obraz əsasında yeni konteyneri işə salın. SSH açarlarını və digər həssas məlumatları GitHub Secrets bölməsində saxlayın.

Workflow-un icra müddətini azaltmaq üçün `actions/cache@v3` istifadə edərək asılılıqları (məsələn, `node_modules` qovluğunu) keşləyin. Bu, təkrar qurulma proseslərində asılılıqların yenidən yüklənməsinə sərf olunan vaxtı aradan qaldırır. Keşləmə `package-lock.json` faylının hash-inə əsaslanmalıdır.