Le migliori pratiche nella progettazione di un'app di social network? [chiuso]

Naviga le tue risposte
0

Quali sono le migliori pratiche quando si tratta di progettare un'app di social network per Android (possibile porta iOS successiva a seconda dell'uptake)?

È la mia prima volta che architettoro qualcosa di questa scala da zero, e probabilmente sto già facendo degli errori in fase di progettazione.

Quello che ho già in mente è:

  1. Avere un backend Postgresql per archiviare i dati dei clienti. Ho intenzione di creare un utente 'app' per gestire tutte le richieste RESTful in arrivo, che porta al mio prossimo punto ..

  2. Connetti il database all'app tramite un'interfaccia RESTful (non penso che la piattaforma sia eccessivamente importante ma sto guardando Go o Puma / Sinatra o Flask perché voglio ridurre al minimo il sovraccarico e mantenere tutto il più efficiente possibile).

  3. Autentica gli utenti usando qualsiasi plugin di autenticazione adatto all'interfaccia RESTful e poi ..

  4. Tunnel tutto il traffico attraverso un socket SSL che apro sull'app che si connetterà all'interfaccia (questa è una delle aree in cui non ho una grande quantità di conoscenza / esperienza)

  5. Carica dati relativi ad altri utenti e li memorizza localmente in un db sqlite crittografato sul dispositivo Android che creerò come parte del processo di avvio dell'app. Le immagini saranno l'unico tipo di media che permetterò. Pulirò il dl sqlite ogni volta che l'utente accede all'app o quando raggiunge una certa dimensione, cioè oltre 3 mb.

  6. Crea l'abbonamento dell'app in modo tale da verificare le credenziali dell'utente ogni volta che accedono. Controllerò lo stato dell'abbonamento e abiliterò di conseguenza un comportamento diverso.

  7. Affronta problemi di connessione pesante inserendo Pgbouncer nel db.

  8. Memorizza le immagini dell'utente sul mio server come normali file di immagine e quando vengono selezionati gli utenti pertinenti, li invierò all'app tramite il socket.

  9. Esegui l'intero server come una macchina virtuale, possibilmente da macchine CoreOS / Docker, che suona come un buon adattamento da quello che ho letto.

C'è qualcosa di sbagliato in qualsiasi parte del mio progetto previsto? C'è qualcosa di necessario che ho perso?

    
posta warsong 29.07.2014 - 23:00
fonte

1 risposta

4

Sarò eccessivamente critico. Non intendo che questo sia meschino, ma per fornire il feedback più preciso che posso:

What are best practices when it comes to designing a social network app for Android (possible iOS port later depending on uptake)?

Concentrarsi su una piattaforma specifica per l'architettura non è saggio. Le app mobili hanno le loro stesse debolezze (sono collegate a Internet o no, permessi limitati / spazio su disco / spazio su schermo / tempi utente) ma molte di queste debolezze sono presenti nella progettazione del tuo prodotto (usabilità, pubblico di destinazione, ecc.) Non in il design. Le difficili sfide tecniche non sono sul lato client.

Detto questo, guarda su facebook. Hanno ampiamente definito le migliori pratiche.

Is there anything necessary I've missed out?

Sì. Questa è una piccola lista basata sulla mia esperienza limitata. Mi aspetto che ci siano circa 5 volte più problemi. Molte delle quali mi aspetto più severe / sfumate.

  • Un singolo database. Anche la macchina di database più a rischio è in scala fino ad ora. Quel database tende ad essere il primo ostacolo alla scalabilità. Sarà anche la più severa e quella che durerà più a lungo in quasi ogni arena. Spazio su disco, processore, ram, latenza del disco, latenza di rete .. tutti questi sono problemi, ma il più diffuso è che questo è un singolo touchpoint / sorgente di verità per il tuo sistema.
  • SSL. La regola empirica che ho sentito è che SSL aggiungerà circa il 20% alla larghezza di banda. Peggio ancora, questo influenza la latenza e la potenza di elaborazione dei tuoi server web, il che significa che hai bisogno di più per servire la stessa quantità di traffico. Alcuni hardware specializzati possono aiutare, ma sono costosi. Mi chiedo il vantaggio di avere crittografato tutto il traffico dei social network.
  • Dimensioni dei dati. stai assurdamente sottostimando la quantità di dati coinvolti nella sincronizzazione dei dati degli utenti sui dispositivi. Supponi di avere (solo) 10 amici. Questi 10 amici hanno 8 foto. Siamo generosi e diciamo che le immagini sono solo 50k. Bastano solo 4 meg di dati per inviare a ogni singolo uno dei tuoi utenti.
  • CDN. Ora torna a quell'ultimo esempio e renditi conto che è verosimile che 4 di quelle foto siano davvero la stessa immagine - ripubblicate 10 volte da ciascuno dei tuoi amici. Certo, un database relazionale può ridurre tale duplicazione, ma la migliore prassi comune è quella di utilizzare una sorta di CDN per diffondere la ricchezza (leggi: caricamento). Perché inviarli tramite socket dal tuo server quando puoi utilizzare le librerie http integrate per ottenere da società specializzate nella distribuzione e distribuzione di contenuti per te?
  • Sottoscrizioni (!) Ignorare le sfide di far pagare per qualcosa di nuovo le persone quando possono ottenere dozzine di altre fantastiche opzioni gratuitamente ... Gli abbonamenti comportano un onere molto maggiore sul tuo design, perché ora puoi fidarsi del cliente Devi controllare per vedere chi è questo cliente, se hanno i diritti, i diritti scaduti, il pagamento è andato a buon fine ... E devono essere semplicemente semplici per non diventare una mostruosità basata sul ruolo / livello.
  • Load Balancer. I server Web multi-thread su un cluster sono tutti fini e dandy, ma qualcosa deve prendere il traffico in entrata e dividerlo. Probabilmente CoreOS ha qualcosa da fare, ma immagino che l'hardware specializzato sarà necessario poco dopo.
  • Memorizzazione nella cache. Non si parla di cache nei tuoi punti. Avere il caching (o più probabilmente, qualche implementazione NoSQL) sarà il primo passo fondamentale per ridimensionare le limitazioni del singolo server di database.

Tutto sommato, stai gettando le tecnologie come se dovessero risolvere i tuoi problemi di architettura per te. Loro non. Gli strumenti sono buoni e gli strumenti sono necessari, ma se applicati nei posti sbagliati o nei modi sbagliati, non funzioneranno. E data la forza ambientale di applicazioni grandi e altamente concorrenti, le cose raramente funzionano in maniera "sorta". O scalano bene o muoiono orribili e orribili morti sotto quella pressione.

    
risposta data 30.07.2014 - 01:58
fonte

Leggi altre domande sui tag

Licenza open-only Dove vengono dichiarate le variabili C [duplicato]