2009-09-23 12 views
15

OK, spójrzmy na to nieco łagodniej: Czy dziedzictwo cgi (common gateway interface) jest stare?Czy cgi nie żyje?

tak? Nie?

W jakich okolicznościach projekt rozpoczynający się dzisiaj (taki, który nie musi oddziaływać ze starszymi systemami lub bibliotekami), należy użyć cgi?

+0

Obrazy generowane komputerowo? Powiedziałbym, że nadal są dość często używane;) – Aistina

+0

Interfejs wspólnej bramki – flybywire

+4

le CGI est mort! Vive le FCGI! – beggs

Odpowiedz

10

To naprawdę dalekie od śmierci. Pomimo kosztów ogólnych, wiele wirtualnych firm hostingowych używa teraz języka PHP jako CGI ze względów bezpieczeństwa, ponieważ może być używane z suEXEC. suEXEC oznacza, że ​​twoje skrypty są uruchamiane pod rzeczywistymi uprawnieniami użytkownika Unix, a zatem są ograniczone przez separację uprawnień systemu operacyjnego. Jest to bardziej niezawodny model bezpieczeństwa niż specyficzna dla PHP alternatywa open_basedir.

Ponadto, CGI to prosty i dość uniwersalny interfejs, którego obsługa nigdy nie wychodzi z serwerów sieciowych. Wiele nowszych interfejsów, takich jak FastCGI i SCGI, dziedziczy sposób, w jaki CGI przekazuje nagłówki HTTP i inne zmienne do aplikacji internetowej iz powrotem. Nawet SAPI na PHP naśladuje to zmienną $_SERVER. Więc CGI nie odejdzie, jest po prostu budowane.

+2

Równie dobrze można uruchomić FastCGI poprzez suexec, lub za pośrednictwem menedżera procesów, który jest całkowicie niezależny od serwera WWW, i wbudowane jest wsparcie PHP dla FastCGI. Ale nie patrzę na to, co robi dzielony hosting wskaźnik przyszłej drogi. :) – hobbs

0

CGI nie bardzo dobrze nadaje się do wysokiej wydajności.

Ale moja rada to zignorować to, napisać dla języka lub biblioteki, która obsługuje wiele SAPI, a następnie użyć tego, co najlepiej pasuje do każdej sytuacji.

+0

Wydajność nie jest tutaj problemem. Głównym problemem jest to, że trudno jest używać trwałych obiektów, ponieważ twój proces zawsze umiera. –

1

Co z tym, który wymaga ekstremalnej wydajności obliczeniowej?

+0

CGI nie jest tak dobre dla wydajności. –

+3

CGI (niezbyt szybki CGI) generalnie nie nadaje się do działania, ponieważ nie będzie optymalizacji pod kątem wyświetlania w Internecie (ponieważ najprawdopodobniej zostaną napisane językiem zaprojektowanym przez Internet). Jednakże, jeśli twój CGI jest intensywnie obliczany przy niewielkiej interakcji (mniejszy dostęp do sieci, ale więcej obliczeń), CGI napisany przez skompilowany do ojczystego język z pewnością się sprawdzi. Dlatego używam słowa "wydajność obliczeniowa". Ale znowu ten rodzaj zadań jest rzadki. – NawaMan

1

Nie jest całkiem martwy. Ale fcgi wygląda na znacznie lepsze podejście. Choć oficjalnie nie jest wspierany przez, powiedzmy, Apache. Musisz użyć modów pobocznych, aby zmusić go do działania.

+0

... co jest dość poważnym problemem, biorąc pod uwagę odsetek serwerów internetowych, na których działa apache. – Thomi

+0

lighttpd staje się coraz bardziej popularne dzięki – Roch

8

Legacy? Absolutnie. Nie żyje? Cóż, chodzi o wsparcie dla życia. Wątpię, czy naprawdę "umrze" w dającej się przewidzieć przyszłości. Wciąż możesz używać CGI do pisania małego skryptu o nazwie very, jeśli masz serwer bez żadnych innych środków do uruchamiania aplikacji webowej i jesteś zbyt leniwy, aby go skonfigurować.

Co to jest inny powód? Może masz program, który przecieka pamięć lub zasoby jak sito, ale mimo to musisz go uruchomić, więc upewnij się, że wszystko jest oczyszczone, kończąc proces każdego żądania ...

Ale poważnie, na rzeczy to naprawdę jest kwestia sprawa, myślę, że korzyści płynące z przeniesienia się do dowolnego systemu z trwałymi procesami przeważają nad kosztami całkiem sporo. Z mojego doświadczenia wynika również, że piszę lepiej zorganizowany kod, ponieważ inicjalizacja, która wymaga ładnej, modularnej aplikacji, przekłada się na "niedopuszczalny czas uruchamiania" w środowisku CGI.

1

Nie uznałbym również CGI za martwego. W końcu jest obsługiwany przez wszystkie główne serwery internetowe.

Jednym z powodów niewymienionych przy uruchamianiu projektu CGI może być ochrona własności intelektualnej. Na przykład możesz zdecydować się na napisanie programu CGI w C++ i pozwolić klientowi zainstalować aplikację na serwerze, który nie jest przez ciebie kontrolowany.

Być może Twój dotychczasowy produkt ma wiele firm wdrożonych jako biblioteki. (.dll, .so .lib. .a itp.) W tym przypadku może być rzeczywiście szybsze na rynku, aby trzymać się c/C++ podczas wdrażania interfejsu internetowego.

Może pracujesz w sklepie Delphi? Jeśli 10 na 10 inżynierów w twoim sklepie napisze Delphi, pisanie twojej nowej aplikacji w PHP może nie być Twoją najszybszą drogą do wprowadzenia na rynek.

Więc, krótko mówiąc, wiele zmiennych wchodzą w grę przy podejmowaniu decyzji co do korzystania tech dla ciebie nowy produkt w tym:

  • Kto jest twoim klientem?
  • Jaki jest Twój punkt wyjścia?
  • Jakie są Twoje zasoby i zasoby?
  • Co lubisz?
  • Do czego potrzebne jest twoje oprogramowanie?
  • W jaki sposób zostanie wdrożona aplikacja?
Powiązane problemy