Forum Programmation.web Applications Web en FCGI

Posté par  .
Étiquettes : aucune
2
18
mai
2010
Bonjour à tous,

Dans le web d'aujourd'hui, si l'on souhaite développer une application qui puisse être aisément déployée chez de nombreux hébergeurs mutualisés, on est souvent obligé d'opter pour du PHP/SQL, même si des langages comme Python ou Ruby ont tendance à se faire un peu plus courants.

Du coup, et comme je souhaiterais que mes futures applications puissent être aisément installées et déployées sans pour autant développer en PHP, j'aimerais partager avec vous quelques réflexions et vous poser les questions suivantes :
  1. Quand on développe en Python, un déploiement via le système de paquetages[1] (easy_install/pip) est souvent nécessaire. Si l'hébergeur mutualisé ne propose pas d'accès ssh avec la commande kivabien, nous sommes limités à la librairie standard et à ce qui est pré-installé sur le système. De fait, même si un langage comme Python se retrouve plus souvent disponible, il est aujourd'hui difficile de permettre à un vaste public de déployer une application web Python (et j'imagine qu'il en va de même pour Ruby et les Gems[2]), surtout à partir du moment où certains modules requièrent de la compilation. Ai-je faux ?

  2. Déployer une application Web écrite par exemple en C / C++ semble possible via (F|S)CGI[3] en de nombreux endroits, moyennant une pré-compilation sur l'architecture visée et que les dépendances, s'il y en a, soient disponibles. CGI ne semble pas une bonne option pour un site qui aurait un peu de visiteurs, mais il n'en va peut-être pas de même pour FCGI, qu'en pensez-vous ?
    Cela dit, de nombreux hébergeurs mutualisés parlant de CGI, espérer que l'installation et le déploiement d'une application Web de ce type soit bien pris en charge relève peut-être de l'utopie ?

  3. Par le biais des *CGI, est-il possible de lancer un exécutable de type ELF[4] ? Je pense dans ce cadre entre autres à Go qui génère ce type d'exécutable via ses compilateurs et dispose de quoi être lié à du FCGI.

Certains me rétorqueront peut-être qu'il vaut mieux déjà se contenter de faire une solution de qualitay répondant à des besoins concrets, et que ce n'est pas en choisissant les technologies de développement en fonction du parc existant qu'on fera évoluer ce parc, et ils auront sans aucun doute raison.

Si vous souhaitez défendre ce point de vue, si vous avez d'autres idées / solutions, n'hésitez surtout pas; je vous en remercie par avance.

1 : [http://pypi.python.org/pypi]
2 : [http://rubygems.org/]
3 : [http://fr.wikipedia.org/wiki/Common_Gateway_Interface]
4 : [http://en.wikipedia.org/wiki/Executable_and_Linkable_Format]
  • # Premiers éléments de réponses

    Posté par  . Évalué à 3.

    J'ai un peu avancé aujourd'hui face aux questions soulevées ici. Pour ceux que ça intéresse :

    - Le déploiement *CGI - Perl, Python... ou ELF si c'est possible - ne semble pas être la panacée car, en tout cas chez un certain nombre d'hébergeurs mutualisés, seul le CGI simple est disponible. En gros, il faut vraiment avoir peu de visiteurs pour que les performances restent acceptables.

    - Je me rends compte également que, dans le cas de Python, lorsque celui-ci est disponible via CGI, il s'agit encore bien souvent de la branche 2.4, arrivée en 2004 alors que la 2.5 a fait son apparition en 2006. Ceci est souvent dû aux dépôts de Debian Etch et / ou de CentOS/RHEL 5.x mais ça limite de plus en plus le choix des technologies à employer.

    Bref, dans le royaume du Web mutualisé et à bas prix, le PHP reste très souvent le roi. Une idée pourrait être de produire du PHP sans en écrire, comme avec haXe[1], le langage qui se compile vers un tas d'autres.

    [1] : http://haxe.org/doc/intro

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.