C'est là que le service api123.io arrive à la rescousse!

Ce service est capable de:

1. Récupérer votre repository GIT (comme GitHub ou Bitbucket);
2. Créer la documentation Javadoc de votre code;
3. Publier la documentation en ligne.

De plus, grâce aux hooks, ce processus prend place automatiquement chaque fois que vous poussez (push) des modifications dans le repository GIT.

Créer un projet

Pour créer un projet, il suffit de remplir:

• le nom du projet,
• l'URL du repository GIT (par exemple https://github.com/google/guava.git)
• et le dossier dans lequel se trouve le code Java (par exemple guava/src ou alors src/main pour les projets maven)

Créer le hook sur GitHub

Sur la page du projet api123.io, se trouve le lien à utiliser pour le hook.

Pour ajouter ce hook à votre projet GitHub, il faut aller sur Settings puis Webhooks & services

Ensuite cliquer sur Add webhook, et dans le formulaire qui apparaît, indiquer:

• Payload URL: le lien du hook api123.io
• Content type: application/json
• Secret: laisser vide
• Just the push event.

C'est fait! Lors du prochain push votre documentation sera créée automatiquement et mise en ligne. Il ne reste plus qu'à partager le lien sur votre wiki, homepage etc.

Certaines de ces fonctionnalités, telles les servlets, ont clairement pour but de rendre les applications web PHP plus performantes. Cependant, comme le serveur lui-même est écrit en PHP, on peut s'attendre à ce qu'il soit à priori moins performant que d'autres serveurs classiques, comme Apache ou Nginx, qui sont eux écrits en langage C.

Voici, en chiffres, la comparaison entre appserver.io et Apache...

Le but du test est de comparer la réaction de appserver.io et Apache lors d'un test de charge sur une application web simple, et qui n'a pas été optimisée pour appserver.io.

Setup

Les tests ont été réalisés sur un serveur virtuel (VPS) single core avec 1GB de RAM. L'OS est Ubuntu 14.04 serveur.

L'application web utilisée pour les tests est un site WordPress avec quelques plugins supplémentaires et une centaine de posts

Les requêtes ont été générées avec Apache JMeter. Celui-ci simule 20 utilisateurs qui effectuent chacun 243 requêtes chaque serveur devra donc, le plus rapidement possible, servir un total de 4860 requêtes.

Résultats

Le tableau ci-dessous donne les statistiques du temps de réponse, en ms.

On remarque clairement que, sans optimisation particulière, appserver.io est en moyenne 25% plus lent que Apache2.

En l'état actuel, appserver.io ne peut donc pas être considéré comme un remplaçant pour Apache. Par contre, ses autres caractéristiques, comme les persistence containers, les servlets, la file de message (message queue) ou le service timer (semblable à cron) en font un candidat à considérer pour les applications sur mesure.

Il intègre dans ce but une série de fonctionnalités inédites:

• Entièrement multi-thread pour plus de performance;
• Supporte les servlets;
• File de messages (message queue) intégrée;
• Service timer (cron) intégré;
• "Persistence container" intégré et distribué (typiquement pour stocker les données de session).

Installation

Sur Ubuntu 14.04:


wget https://github.com/appserver-io/appserver/releases/download/1.0.6/appserver-dist_1.0.6-37.deb7_amd64.deb
wget https://github.com/appserver-io/appserver/releases/download/1.0.6/appserver-runtime_1.0.7-74.deb7_amd64.deb
sudo dpkg -i appserver-runtime_1.0.7-74.deb7_amd64.deb
sudo dpkg -i appserver-dist_1.0.6-37.deb7_amd64.deb


Et pour installer les éventuelles dépendances:


sudo apt-get install -f


appserver.io est maintenant installé dans /opt/appserver. La commande suivante permet de configurer le serveur pour le développement:


sudo /opt/appserver/server.php -s dev
sudo service appserver restart


Le serveur appserver.io est maintenant accessible à l'adresse http://localhost:9080

Servlets

L'utilisation des servlets est une fonctionnalité qu'on retrouve généralement dans les serveurs d'applications Java (Tomcat etc.).

Dans la plus-part des serveurs web PHP (Apache mod_php, PHP-FPM,...), l'entièreté du code nécessaire pour construire la page est évalué à chaque requête. Tous les les objets sont donc également instanciés puis détruits à chaque requête. Dans le cas d'applications complexes, cela représente un énorme gaspillage de ressources, et un énorme ralentissement.

Au contraire, dans le cas des servlets, un seul objet est instancié au démarrage du serveur. Lors de chaque requête, la méthode correspondante est appelée (généralement doGet pour les requêtes GET et doPost pour les requêtes POST). Typiquement, lors de l'instanciation de la servlet, on exécute toutes les tâches lourdes de configuration (bootstraping) qui sont communes à toutes les requêtes.

L'inconvénient: comme l'objet servlet est créé uniquement lors du démarrage du serveur, il faut redémarrer celui-ci après chaque modification du servlet.

Pour créer une servlet appserver.io:


cd /opt/appserver/webapps/

# Créer un dossier pour notre application
mkdir myapp
cd myapp


Les servlets doivent se trouver dans le dossier WEB-INF/classes et doivent suivre le standard PSR-0:


mkdir -p WEB-INF/classes/Me/MyApp
cd WEB-INF/classes/Me/MyApp


On peut enfin créer la servlet:

nano IndexServlet.php
<?php
namespace Me\MyApp;
// Doit correspondre au nom du répertoire !!

use AppserverIo\Psr\Servlet\Http\HttpServlet;

/**
 * @Route(name="index", urlPattern={"/index.do", "/index.do*"})
 */
class IndexServlet extends HttpServlet {
  // Le nom de la classe doit correspondre au nom du fichier!

  protected $value;

  public function init(ServletConfig $config) {
    parent::init($config);

    // Et ici, on initialise tout ce qui doit l'être
    // Spécialement si c'est lourd à calculer!!
    $this->value = "Hello";
  }


  public function doGet($servletRequest, $servletResponse) {
    $servletResponse->appendBodyStream("Ceci était long à calculer " . $this->value);
  }
}
 

Après avoir redémarré le serveur, la servlet sera visible à l'adresse

http://localhost:8090/myapp/index.do

Attention, en réalité ce n'est pas la même instance du servlet qui est utilisée à chaque requête, mais bien une copie. Les servlets ne peuvent donc pas être utilisées pour la communication entre les requêtes. L'exemple ci-dessous ne fonctionnera donc pas:


namespace Me\MyApp;

use AppserverIo\Psr\Servlet\Http\HttpServlet;

/**
 * @Route(name="index", urlPattern={"/index.do", "/index.do*"})
 */
class IndexServlet extends HttpServlet {

  protected $value = 0;


  public function doGet($servletRequest, $servletResponse) {
    $servletResponse->appendBodyStream("Nombre de visites: " . $this->value);
    $this->value++;
  }
}
 

Lors de chaque requête $this->value vaudra 0 car c'est une copie du servlet original qui est utilisée...

Templates

Les servlets sont donc extrêmement puissants pour le bootstrapping de l'application. Pour générer la page elle-même, mieux vaut utiliser des templates. Pour comparer avec le modèle MVC, la servlet sert alors de controller, et le template est la vue.


<?php

namespace Me\MyApp;

use AppserverIo\Psr\Servlet\Http\HttpServlet;

/**
 * @Route(name="index", urlPattern={"/index.do", "/index.do*"})
 */
class IndexServlet extends HttpServlet
{

    public function doGet($servletRequest, $servletResponse)
    {
        // récupérer les valeurs à afficher
        $servletRequest->getContext()->setAttribute("NAMES",
            array("Harry", "Hermione", "Ron"));

        // calculer le chemin complet vers le template
        $template = "templates/index.phtml";
        $webappPath = $servletRequest->getContext()->getWebappPath();
        $pathToTemplate = $webappPath . DIRECTORY_SEPARATOR . $template;

        if (!file_exists($pathToTemplate)) {
            throw new \Exception('Requested template not found: ' . $pathToTemplate);
        }

        // créer la page
        ob_start();
        require $pathToTemplate;
        $servletResponse->appendBodyStream(ob_get_clean());
    }
}
 

Et créer le template:

nano /opt/appserver/webapps/myapp/templates/index.phtml
<!DOCTYPE html>
<html lang="en">
<head>
    <title>appserver.io exemple</title>
</head>

<body>
    <h1>Example app</h1>
    <table class="table table-hover">
        <tr><th>Name</th></tr>

        <?php foreach ($servletRequest->getContext()->getAttribute("NAMES") as $name): ?>
        <tr><td><?php echo $name ?></td></tr>
        <?php endforeach; ?>

    </table>
</body>
</html>
 

Lorsqu'on souhaite instancier un objet, on doit en réalité appeler une fonction qui construit l'entièreté de l'objet:


function Animal(nom) {
  this.nom = nom;

  this.toString = function() {
    return "Je m'appelle " + this.nom + "!";
  }
}

var chat = new Animal('Tigrou');
alert(chat.toString());
 

Cette méthode est cependant très gourmande en mémoire RAM: chaque instance de la classe Animal contient la valeur de chaque attribut (normal), mais également la définition de chaque méthode, alors que celles-ci sont les mêmes pour chaque instance!

Pour éviter ce gaspillage, il faut recourir aux prototypes. Les prototypes sont similaires au mot clé static en Java ou PHP: ils indiquent à Javascript que cette définition est commune à tous les objets (de cette "classe").


function Animal(nom) {
  this.nom = nom;
}

Animal.prototype.toString = function() {
  return "Je m'appelle " + this.nom + "!";
}

var chat = new Animal('Tigrou');
alert(chat.toString());
 

Cette fois-ci, l'inconvénient est que la définition de la classe est complètement séparée entre le constructeur qui définit les attributs de l'objet, et les prototypes pour chaque méthode. La plus-part des frameworks javascript proposent donc une méthode pour définir une classe. Dans le cas de jQuery, il s'agit de Class.create():


var Animal = Class.create({
  init: function(nom) {
    this.nom = nom;
  },

  toString: function() {
    return "Je m'appele " + this.nom + "!");
  }
});

var chat = new Animal('Tigrou');
alert(cat.toString());
 

Pour l'essentiel, une requête JSON-RPC est très semblable à une requête AJAX: elles sont toutes les deux transmises en utilisant le protocole HTTP. Cependant, la spécification JSON-RPC 2.0 ajoute quelques contraintes. Par exemple, la requête doit comporter un champ jsonrpc et un champ id.

Si un client jQuery doit accéder à un serveur JSON-RPC, le code à utiliser est donc le suivant:


<script src="//ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js"></script>
<script>
    $(document).ready(function() {

        $.ajax({
            url: 'http://localhost:8080/RPC2',
            data: JSON.stringify({
                jsonrpc: '2.0',
                method: 'add',
                params: [1400, 2100],
                id: "jsonrpc"}),
            type: "POST",
            dataType: "json",

            success: function(data) {
                alert("Résultat : " + data.result);
            },

            error: function(err) {
                alert("Erreur: " + err);
            }
        });
    });
</script>