Connexion & Communication serveur

Bonjour,

Je me lance définitivement dans le développement d'une application sur un type "social networking" concernant la photographie d'art .



Outre l'aspect code "offline" qui devrait pas être trop dur (j'ai de solides notions de C/C++), je n'ai par contre AUCUNE idée de comment connecter mon application au net .



Faut-il un serveur classique ou un serveur type "cloud" ?

Une base de donnée de type MySQL suffit ?

Quel hébergeur ?

Hébergement mutualisé ou Un serveur complet ?



Connaissez vous des tutorials concernant les requêtes que l'on peut effectuer sur la DB ? Parceque autant sur du web en php c'est facile ... Une autre affaire en Objective-C et je n'ai rien trouvé à  ce sujet ...



Merci infiniment pour vos réponses,



John
Mots clés:

Réponses

  • Il te suffit de .. euh .. je ne sais pas du tout ! Ce genre de développement n'est pas ma tasse de thé, ça manque de sprites, de boules de feu, de sortilèges, d'épées, de cris et d'explosions. Heureusement la taverne regorge de topics sur les serveurs, HTML, les téléchargements de données, etc.. Utilise la fonction de recherche du forum, tu devrais y trouver ton bonheur.
  • zoczoc Membre
    juin 2012 modifié #3
    'marcoflint' a écrit:


    Faut-il un serveur classique ou un serveur type "cloud" ?

    Une base de donnée de type MySQL suffit ?

    Quel hébergeur ?

    Hébergement mutualisé ou Un serveur complet ?


    Toutes les réponses à  ces questions vont dépendre du succès de l'application (du nombre de clients quoi). Parce qu'au départ le mutualisé peut suffire, mais clairement du seras dépendant des autres services hébergés par d'autres utilisateurs du serveur. Donc pour moi, pour une application sérieuse, il faut partir directement sur du dédié.



    Après, cloud ou "classique"... Je n'ai pas franchement d'avis ni d'expérience, si ce n'est que les solutions "cloud" permettent généralement une augmentation de capacité immédiate (un bouton à  cliquer sur l'interface d'administration en gros), alors qu'une solution serveur classique peut nécessiter l'installation/configuration d'une nouvelle machine plus puissante.



    En ce qui concerne la partie logicielle du coté serveur, tu auras évidemment une base de donnée MySQL, PostgreSQL ou je ne sais quoi. Mais je déconseille de stocker les photos en BDD (pour des raisons de perf liées à  la méthode d'accès aux photos, j'en parlerai plus bas). Tu auras besoin également d'un serveur WEB et d'un langage de script coté serveur (PHP ou autre, j'en parle plus bas également).


    Connaissez vous des tutorials concernant les requêtes que l'on peut effectuer sur la DB ?


    Bon, déjà , quelle que soit la DB, tu ne vas pas l'attaquer en direct. Exposer un accès à  une DB en direct est trop dangereux, car elles n'ont pas été conçues pour supporter les aléas des connexions grandes distances (latence et fragilité de la connexion), et les mécanismes d'authentification ne sont pas assez forts.



    Donc tu vas obligatoirement devoir développer une API de communication entre tes clients mobiles et ton serveur. C'est la raison du besoin d'un serveur WEB coté serveur, car ce genre d'API est majoritairement conçu sous la forme d'un WEB Service.



    Pour schématiser, pour chaque action que le client peut effectuer sur le serveur, tu vas avoir sur le serveur un script qui va faire l'interface entre la requête du client (requête matérialisée par une requête HTTP classique vers une URL particulière, avec passage de paramètres en GET ou POST) et la DB.



    Il existe plusieurs standards (RPC-XML / RPC-JSON / REST) pour ce genre de mécanismes, et tu trouves assez facilement pour ces standards du cote tout prêt, que ce soit en Objective-C coté client, et en PHP/Ruby/Whatever coté serveur, qui implémentent ces standards. RPC-JSON a ma préférence, car le JSON a l'avantage d'être simple et rapide à  décoder, ce qui est important coté client. De plus, notre cher ami Ali du forum a développé un framework en Objective-C pour s'interfacer avec un serveur JSON-RPC.



    Le cas échéant, ton WEB Service devra également exposer une API permettant l'authentification de tes utilisateurs.



    Je terminerai sur la raison pour laquelle je conseille de ne pas stocker les photos dans la BD: Stocker/Extraire des gros volumes de donnée binaires (BLOBS) d'une base est couteux. Les stocker en tant que fichier et faire "servir" ces fichiers directement par le serveur WEB en tant que donnée statique est bien plus performant (le serveur WEB est conçu pour cela). Donc, grosso modo, la solution est:
    1. Lors de l'upload d'une photo, lui attribuer un nom unique (GUID ou checksum SHA de la photo). Stocker la photo avec ce nom dans un dossier accessible au serveur Web, et stocker le nom de ce fichier avec les metadonnées liées à  la photo en BD.
    2. Lorsque le client veut accéder à  une photo, construire coté serveur l'URL de la photo et la lui transmettre. Le client fait alors une requête HTTP sur l'URL reçu pour télécharger la photo sans surcharger la DB.
  • Amazingly cool !!! You saved my life image/biggrin.png' class='bbc_emoticon' alt=':D' /> it's greatttt !
Connectez-vous ou Inscrivez-vous pour répondre.