onilink_ administrateur

Un rouge comme ça c'est mieux, le vôtre fait trop sanguinolent je trouve :

Pourquoi faire le back-end nouveau site web en C/C++ ? Si c'est une question de performance pour la question est dépassée.

Petite observation sur les routes REST d'API ;

Ne renvoyez pas de tableau (tout le temps des objets), pour les tableaux faire des structures de ce genre :

Code:

{
  meta: {
    size: {nombre_total_element_en_base},
    pageSize: {nombre_maximum_element_renvoyer_dans_le_tableau},http://www.nytimes.com/2010/12/19/business/global/19bank.html?src=busln
    page: {sur_quel_page_nous_sommes}
  },
  results: []
}

Plusieurs intérêts : Rappel de la taille total du résultat de l'URL, système de pagination (on affiche que 50 résultats même si la route devrait nous renvoyer 4000 résultats, et ce qui permet de faire une navigation avec des query ?page=XX).

Par exemple sur une route :
GET cbna.org/users/ plutot que renvoyer 10 000 inscrits on renvoie :

Code:

{
  meta: {
    size: 10000,
    pageSize: 20,
    page: 1
  },
  results: [
    {
      _id: 1
    ...
    },
  ...
  ]
}

Deuxième observations pour simplifier la lecture de vos API faites toujours quelque chose comme ça :
/[thèmeA]/[themeA_ID]/[themeB]/[themeB_ID]

Je vous donne l'exemple qui m'a fait piquer les yeux : le forum

http://test.lecbna.org:8080/api/forum/topics/1/2 : Pour avoir le topic 2 de la catégorie 1
http://test.lecbna.org:8080/api/forum/topics/1 : Pour avoir la liste des topics de la catégorie 1
http://test.lecbna.org:8080/api/forum/categories/1 : Pour avoir les infos sur la catégorie 1

Ce que j'aurais fait, et ce qui je pense est plus clair :
http://test.lecbna.org:8080/api/forum : Liste les catégories avec leurs informations... Inutile de faire 1 + X appels (1 pour avoir les ID des catégories + une requête par catégorie => Ca bouffe un max de bande passante, tes headers HTTP sont plus fat que ta requête, et c'est pas forcement plus clair).

http://test.lecbna.org:8080/api/forum/1 : Informations sur la catégorie 1 détaillé
http://test.lecbna.org:8080/api/forum/1/topics : Liste les topics de la catégorie 1 (avec un système de pagination swag).
http://test.lecbna.org:8080/api/forum/1/topics/1 : Informations détaillé sur le topic 1
http://test.lecbna.org:8080/api/forum/1/topics/1/messages : Liste les réponses sur le topic
http://test.lecbna.org:8080/api/forum/1/topics/1/messages/1 : Information détaillé sur le message 1

Merci Ombre !
Je suis content d'avoir un peu de retours autre que l'interface

Voici ce que j'en pense :

1) Pourquoi le backend en C++.
La vrai raison, c'est que moi et Daminetreg, on connait très bien le C++ et qu'on est des extrémiste.
La question des performances est un corollaire plutôt anecdotique en toute franchise ^_^.

2) Concaténer les requêtes pour en faire moins.
Oui bien entendu, c'est prévu à moyen terme.
On fera cette optimisation dès qu'on sera un peu plus avancé.
On avance sur les fonctionnalités en premier lieu, quitte à faire les optimisations ensuite.
L'idéal serait de pouvoir faire une unique requète.

3) Systeme de "pages/réponse partielle"
Oui pourquoi pas quand on aura des milliers de topics et/ou qu'on utilisera des réponse partielles.

4) Pas de tableau dans les JSON → utiliser des objets.
Mouais, seulement si on fait de la pagination (#3).
Mais je n'ai pas compris l'avantage d'un objet lorsque je veux préserver l'ordre d'une séquence d'éléments.

5) Renommer certaines routes.
Pourquoi pas, tu fais ressortir l'encapsulation message → topic → categorie.
J'aimerais quand même garder des chemin assez court.
On peut pour certain chemins rajouter à la fin du texte non utilisé:
Exemple : http://test.lecbna.org:8080/api/forum/topics/1/2/Mon-super-topic

J'hésite en ce moment, à indexer les messages par seulement un entier (message_id) au lieu de 3 (category_id, topic_id, message_id)
et rajouter un niveau d'indirection dans les categories et les topics qui contiendraient une liste de topics et une liste de messages.
Mais les catégories nous permettent d'instaurer des droits (lecture/écriture).

C'est utile pour l'indexation sur les search engines.

Pour info, voici l'API actuelle :


  // categories
   router.get (R"(/forum/categories/(\d+)/?)",          &REST_server::get_category);
   router.get (R"(/forum/categories(/.*)?)",            &REST_server::get_categories_list);
   router.post(R"(/forum/categories/?)",                &REST_server::post_category);
   //router.del (R"(/forum/categories/(\d+)/)",         &REST_server::del_category);

   // topics
   router.get  (R"(/forum/topics/(\d+)/(\d+)(/.*)?)",   &REST_server::get_topic);
   router.get  (R"(/forum/topics/(\d+)(/.*)?)",         &REST_server::get_topic_list);
   router.post (R"(/forum/topics/(\d+))",               &REST_server::post_topic);
   //router.del  (R"(/forum/topics/(\d+)/(\d+)/)",      &REST_server::del_topic);

   // message
   router.get  (R"(/forum/messages/(\d+)/(\d+)/(\d+))", &REST_server::get_message);
   router.get  (R"(/forum/messages/(\d+)/(\d+)(/.*)?)", &REST_server::get_message_list);
   router.post (R"(/forum/messages/(\d+)/(\d+))",       &REST_server::post_message);
   router.del  (R"(/forum/messages/(\d+)/(\d+)/(\d+))", &REST_server::del_message);
   router.post (R"(/forum/messages/(\d+)/(\d+)/(\d+))", &REST_server::edit_message);

   // unread
   router.get  (R"(/forum/unread/?)",                   &REST_server::get_unread);
   router.get  (R"(/forum/unread/number)",              &REST_server::get_unread_number);

   // users
   router.get(R"(/forum/users/(\d+)/?)",                &REST_server::get_user);
   router.get(R"(/forum/users(/.*)?)",                  &REST_server::get_users_list);

   // groups
   router.get(R"(/forum/groups/(\d+)/?)",               &REST_server::get_group);
   router.get(R"(/forum/groups(/.*)?)",                 &REST_server::get_groups_list);

   // connection / inscription
   router.post(R"(/connection)",                        &REST_server::connection);
   router.post(R"(/inscription)",                       &REST_server::inscription);
   router.post(R"(/disconnection)",                     &REST_server::disconnection);
   //   unimplemented methods */

   // avatar
   router.post(R"(/avatar)",                            &REST_server::avatar);
[/code]


Si tu es intéressé, ça me plairait bien d'avoir quelqu'un avec qui bosser.
On utilise C++ pour le backend, javascript/Angular2 pour le front-end et cmake/git/gitlab pour la gestion de projet.
Si cela te dit (même si c'est juste pour jeter un petit coup d'oeil à la source) envoie nous un message et on t'inscrit sur le projet.

1) Ok, "MAIS" je pense que vous vous faites *****, il y a plein de language dédié au back end web qui font très bien leur taff sans passer par un mastodon comme C++

2) Une unique requête je dirais pas ça ! Le but c'est pas de ne pas faire de requête, mais juste de faire requête qui suivent une certaine logique.

3) Ca c'est un must have, la pagination c'est mieux de le penser en amont.

4) Non pas que ! C'est une bonne pratique technique aussi de bosser que avec des objets. Si tu prends angular 1 par exemple (je connais pas assez le 2 pour dire que ça marche pareille), dans le service $resource si tu déclare que ton service renvoie des "tableaux" et que tu fais poper une erreur sous forme d'objet (une erreur de ton API pas angular), angular va planter parce que l'erreur ne sera pas un tableau... Alors que si tu bosse toujours avec des objets même si c'est qu'un contenant pour ton tableau ça marche, et ça te coute rien.

5) Garder les chemins courts pour l'API tu t'en fou, ils sont cachés de l'utilisateur, faut juste les écrire sur angular, et mieux vaut la clarté.

Je sais pas si j'aurai beaucoup de temps à vous accordez mais si vous voulez de l'aide sur des sujets théorique ou front eventuellement de manière ponctuel (c'est mon métier le web depuis peu). Donc API / Front / Back end (pas en C++, mais je le connais pour l'avoir appris en cours... Mais bon, sans pratique, ect... spa ouf) ça me connaient.

ombre a écrit:

1) Ok, "MAIS" je pense que vous vous faites *****, il y a plein de language dédié au back end web qui font très bien leur taff sans passer par un mastodon comme C++

Avec les autres langages, on peut partir de plus haut, mais on monte moins vite. (Comprenne qui pourra)
Ne t'inquiète pas, il n'y a pas beaucoup de travail à faire sur le backend.
Pour exposer une simple api REST, c'est vraiment un jeu d'enfant.
Je suis d'accord que certains langages apportent des fonctionnalités rapidement (BDD, templates, ...) et que c'est assez satisfaisant de voir le travail se faire tous seul.
Mais comme on dit  : "L'informatique fait gagner beaucoup de temps, mais il faut d'abord prendre beaucoup de temps pour d'apprendre l'informatique" et j'aurais perdu mon temps à être performant dans quelque chose d'autre. (Déjà que j'ai appris Angular 1 & 2 ...)

ombre a écrit:

2) Une unique requête je dirais pas ça ! Le but c'est pas de ne pas faire de requête, mais juste de faire requête qui suivent une certaine logique.

Oui. On va garder des requête simple. Elles coexisterons avec des requêtes groupés aux endroits où il est importants de faire des optimisations.

ombre a écrit:

3) Ça c'est un must have, la pagination c'est mieux de le penser en amont.

Dans l'idéal, tu as raison. Mais je pense que cela peut-être fait plus tard.
J'ai peur de ne pas avancer assez vite et de me perdre.. Je préfère itérer rapidement sur les fonctionnalité.

ombre a écrit:

4) Non pas que ! C'est une bonne pratique technique aussi de bosser que avec des objets. Si tu prends angular 1 par exemple (je connais pas assez le 2 pour dire que ça marche pareille), dans le service $resource si tu déclare que ton service renvoie des "tableaux" et que tu fais poper une erreur sous forme d'objet (une erreur de ton API pas angular), angular va planter parce que l'erreur ne sera pas un tableau... Alors que si tu bosse toujours avec des objets même si c'est qu'un contenant pour ton tableau ça marche, et ça te coute rien.

Tu marque un point. (Ou alors je vérifie mes données à la réception.)

ombre a écrit:

5) Garder les chemins courts pour l'API tu t'en fou, ils sont cachés de l'utilisateur, faut juste les écrire sur angular, et mieux vaut la clarté.

Je sais pas si j'aurai beaucoup de temps à vous accordez mais si vous voulez de l'aide sur des sujets théorique ou front eventuellement de manière ponctuel (c'est mon métier le web depuis peu). Donc API / Front / Back end (pas en C++, mais je le connais pour l'avoir appris en cours... Mais bon, sans pratique, ect... spa ouf) ça me connaient.

Super! tu me dira ce que tu pense du front.
Cela ne t'engage à rien, ne t'inquiète pas.
Je vais faire le nécessaire.

Merci à toi !

ombre a écrit:

Pourquoi faire le back-end nouveau site web en C/C++ ? Si c'est une question de performance pour la question est dépassée.

Si j'avais eu le temps j'aurai aussi fait le frontend en C++.
En l'occurence c'est aussi des questions budgétaires et écologiques, j'aurai besoin de moins de serveurs pour faire tourner le site qu'avec un site en node/hack/php... Et d'ailleurs de serveurs moins puissant. Dois-je rappeler les économies que facebook a fait quand ils sont passés de php à HipHop for Php, je crois 80% de serveurs en moins.

Bien sûr notre communauté n'est pas facebook, mais si on peut jamais rien apporter de neuf dans des domaines qui semblent établis, alors on sert à rien en tant que programmeurs opensource. Il y a une différence entre faire un site web pour un client, et faire le site web d'une communauté de développeurs à mon avis.