Interface da Web com FastCGI ou com HTTP direto?

5

Vamos supor que eu queira (por diversão no início) brincar com uma nova idéia de DSL (domínio específico da linguagem). E eu realmente quero que o seu usuário [s] (provavelmente só eu no começo) interaja através de uma interface web. Eu provavelmente vou implementá-lo em C ++ (provavelmente usando o LLVM).

Devo usar uma biblioteca do servidor HTTP (como libonion ou microhttpd ) para falar diretamente HTTP ou devo usar FastCGI? Eu também poderia usar bibliotecas fazendo ambos cppcms ou wt ...

Em particular, estou percebendo que vários frameworks web recentes ( Opa , Ocsigen , ...) não tem nenhuma interface FastCGI, mas apenas uma HTTP .... (mas Ur / Web parece ter ambos)

Então, meu sentimento é que o FastCGI está realmente fora de moda ...

Alguma opinião sobre isso? Você conhece recentemente o projeto iniciado usando o FastCGI? (e o SCGI?)

    
por Basile Starynkevitch 08.12.2012 / 00:41
fonte

2 respostas

3

Algumas notas:

So my feeling is that FastCGI is really out of fashion....

Contar isso é como dizer que o TCP / IP está fora de moda em dias de HTTP.

O FastCGI é o protocolo entre o aplicativo da Web e o servidor da Web - no entanto, isso não significa que você precise usá-lo diretamente do seu aplicativo.

Should I use an HTTP server library (like libonion or microhttpd) to talk directly HTTP or should I use FastCGI? I could also use libraries doing both like cppcms or wt...

Veja se você quer desenvolver até mesmo um site simples, é muito difícil fazê-lo usando apenas o HTTP - há muitos fatores para lidar - é por isso que existem frameworks web que resolvem o problema para você, mais do que isso coisas como entrega de arquivos estáticos e algumas considerações de segurança são passadas para o servidor da Web e para a própria estrutura.

Então, eu recomendo que você use o framework Web como o CppCMS, que permite implementar facilmente o aplicativo da Web usando C ++ - então, basicamente, você trabalha com a lógica de ocupação, o resto do framework web faz por você.

E, como retorno, você recebe suporte dos protocolos HTTP, FastCGI, SCGI e pode usar o servidor da Web interno ou qualquer protocolo padrão do setor com um poderoso servidor da Web.

    
por 12.12.2012 / 08:47
fonte
2

Eu considerei muitas implementações, com diferentes tipos de métodos de conexão, e é assim que eu vejo a escolha.

Do ponto de vista do desenvolvedor, o FastCGI está fora de moda, da mesma forma que considerariam o C. a partir de uma perspectiva do desenvolvedor, realizar a tarefa pode ser feito de maneiras mais simples.

Do ponto de vista da implementação, o HTTP não é um substituto perfeito, no entanto, há sobreposição suficiente para que eles possam ser usados para solucionar os mesmos objetivos. MAS, na verdade, essa questão é sobre implementação e arquitetura, e não uma questão focada no desenvolvedor, então vou respondê-la do lado da engenharia de sistemas.

Apesar do que eu infelizmente li em blogs de desenvolvedores, o FastCGI PODE ser uma escolha melhor quando utilizado nas circunstâncias apropriadas. Ele separa uma grande preocupação complicada, que de outra forma deve ser implementada mais acima na pilha.

Por exemplo, Ele permite que você evite criar um servidor web robusto dentro do seu framework / idioma. Uma tarefa enorme se você realmente se preocupa com a qualidade, mas é muito factível se você se encaixar como a maioria. Por isso, ironicamente, é mais fácil enrolar tudo em uma bola de espaguete e depois separar essa parte de forma limpa. É por isso que muitos evitam o FastCGI, porque eles só poderiam implementá-lo quase que encapsulando o HTTP de qualquer maneira, devido a suas más arquiteturas.

Como você não foi mais detalhado sobre o quanto seu plano é ambicioso, não posso dar ótimas recomendações. Deixe-me sugerir algumas coisas para investigar, que não são o estilo de nó comum do python.

Leia sobre os detalhes da implementação de php-fpm

Se você quiser fazer mais um modelo de servidor, faça certo, leia sobre uwsgi

    
por 30.12.2015 / 19:42
fonte