Szukam źródeł do nauki pisania programów FastCGI od zera. Najlepiej w języku C++ lub C, ponieważ właśnie tego używam. Znalazłem jak dotąd to:
http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ap_guide.htm
Pewien jesteś? To jest technologia z lat 90’. W zasadzie wyszła już z użycia. Jest mnóstwo mniej lub bardziej dedykowanych technologii webowych, zdecydowanie lepiej destosowanych do budowania rozwiązań tego typu - PHP, Ruby On Rails, ASP.NET (MVC), Python…
Znasz coś lepszego (czyt. szybszego, bo na tym mi zależy)? PHP to właściwie też technologia lat 90’.
Szybszego w czym? Co chcesz zrobić? W jakiej postaci? WWW, Web Service? Niewiele jest rzeczy, gdzie użycie C/C++ da Ci zdecydowany przyrost wydajności (niskopoziomowe odwołania, raczej nieużywane na serwerach webowych) - bardzo dużo zależy też od użytego kompilatora. Jeśli już to możesz napisać w nim backend. Frontend webowy stworzyłbym w technologii do tego przystosowanej, z wygodnym wsparciem obsługi żądań, sesji, autoryzacji, ciasteczek, OData, Rest, … itp. itd.
Podane przez Ciebie PHP faktycznie jest chyba jakoś z końca lat 90’, tyle że od tego czasu cały czas się rozwija. FastCGI, czyli jak rozumiem przetwarzanie surowych żądań HTTP nie za bardzo.
Najbardziej podchodzi to pod serwis. Właściwie CGI i inne twory o tym zastosowaniu to już właściwie back-end. Wszystkie programy odpowiedzialne za przetwarzanie danych na serwerze będą w C++ i programy odpowiedzialne za komunikację będą najpewniej wymagały jakiejś łączności z nimi. Zależy mi na stabilności, wydajności i bezpieczeństwie, system musi szybko odpowiadać na zapytania. Z tych powodów zdecydowałem się używać C++ także do tego.
PHP zwyczajnie wolniejsze od C++, a służy do pisania skryptów CGI. FastCGI co prawda jest stare, ale jednak nowsze od CGI i dużo szybsze, ponieważ odpada czas potrzebny na tworzenie procesu.
Oczywiście jestem otwarty na inne propozycje.
Sam dopiero ogarniam temat, ale wydaje mi się że rozwiązaniem dla Ciebie będzie serwer REST zaimplementowany w C++, co najważniejsze technologia na topie a nie wymarła, ewentualnie na wymarciu.
Sam dopiero powoli ogarniam temat REST i single page application, więc za bardzo nie pomogę. Mniej więcej chodzi o to że zaczytujesz wszystkie pliki (szablony strony HTML, CSS, JS) i później za pomocą JS pobierasz dane z serwera RESTowego i podstawiasz je w odpowiednie szablony i wyświetlasz.
Trochę mieszasz pojęcia. REST i SPA to dwie różnie rzeczy.
REST to architektura usług webowych, bez związku z prezentacją. Klientem może być cokolwiek - strona webowa, aplikacja, inna usługa, …
W skrócie chodzi o to, aby tym żądania HTTP i adres URL odpowiadał temu co chesz robić (w przeciwieństwie do np. SOAP gdzie wszystko jest zakodowane w XML’u i zależy od metody którą wołasz).
Np. HTTP GET na /produkty - powinno zwrócić listę (np. JSON) wszystkich produktów
Ale czy SPA nie korzysta z REST przy pobieraniu danych? SPA to część po stronie klienta REST to część serwerowa. Przynajmniej ja to tak rozumiem.
Może korzystać, ale nie musi. REST to w uproszczeniu jedynie architektura budowania żądań (przez URL’e i typ żądania HTTP). Nie jest to konkretna technologia, ani standard.
Np. HTTP GET http://mojastrona.com/dodajNowegoKlienta.php?nazwa=nowy_klient już nie jest “REST”, a przecież nie ma żadnych przeszkód aby użyć takie wywołania w aplikacja SPA, czy jakiejkolwiek innej.
Yhm, rozumiem. Ale to w takim razie jak nazwać serwer który zwraca dane w json lub xml i obsługuje sesje post i get? Zasada działania przecież jest podobna do rest z tą różnicą że jest on rozbudowany o dodatkowe mechanizmy.
kowgli może umiałbyś wytłumaczyć czym się różni rest od restful web services i czy to to samo co restful. Niby mniej więcej wiem jaka jest różnica, ale nie jestem pewny czy dobrze zrozumiałem bo jedyne wyjaśnienia są na stackoverflow, ale tak wyjaśnione że nie wiem czy dobrze zrozumiałem.
Jest to po prostu web service, tyle że nie spełnia wymagań architektury REST. Czy jest gorszy, mniej funkcjonalny? Nie.
REST wymaga np. aby dodawanie nowych danych było robione przez HTTP PUT, usuwanie przez HTTP DELETE itp. Niektóre technologie webowe, np. Web Service w Ruby On Rails albo ASP.NET MVC Web API domyślnie sugerują/wspierają taką architekturę. Nie ma jednak obowiązku jej implementacji.
REST to model architektury. RESTful Web Service to web service, który implementuje tę architekturę.
Tu (http://rest.elkstein.org/)) jest to w miarę prosto wytłumaczone. Lub tu (https://en.wikipedia.org/wiki/Representational_state_transfer).
Czy w takim razie nie da się zbudować SPA w oparciu o serwer REST? Przecież to ode mnie zależy jakiego typu wywołania będą w SPA.
Ogólnie zastanawiam się czym dziś jest REST, bo praktycznie na każdym kroku mamy coś “ala” REST API, ale często dodaje się wywołania GET lub POST. Chyba tylko amazon ma takie w 100% REST API. W ogóle rzadko kiedy możemy zastosować REST taki jakim powinien być czyli bezstanowy, wydaje mi się że często potrzeba sprawdzić uprawnienia nawet przy pobieraniu danych np za pomocą jakiegoś client_key_api. Więc czy przypadkiem REST już w tej chwili nie ewoluował?
Oczywiście ja się zgadzam z tym co do tej pory napisałeś. Chcę po prostu podyskutować i podpytać się trochę tak teoretycznie - nie trzymając się ściśle samej definicji.
No to mi zrobiliście mętlik w głowie. Teraz to już sam nie wiem co robić.
Co sądzicie wykorzystaniu API?
Ale jakim?
Chodzi mi ogólnie o komunikację użytkownika z serwerem, używając API danego serwera. Trzeba się wtedy pomęczyć ze stworzeniem programu, ale daje to najlepsze efekty jeżeli chodzi o szybkość i możliwości kontroli. Wiadomo, że traci się wtedy przenośność, ale jeżeli trzymamy się jednego serwera to nie ma problemu.
W moim przypadku jest to NginX.
To co ty chcesz w końcu robić? Aplikacje internetową czy nie?
Aplikację internetową z dwoma klientami - stroną internetową i programem GUI. Do tego na serwerze ma chodzić cały czas program przetwarzający dane z bazy.
//Chyba coś mi się pomyliło
No to nie masz za bardzo możliwości tworzenia własnego api, bo tak czy siak musisz zaimplementować HTTP do obsługi strony www i tak, a więc nie ma sensu robić api tylko dla aplikacji. Komunikację pomiędzy serwerem a klientem (aplikacją) też możesz zrealizować przez http dzięki czemu wspierasz tylko jeden sposób komunikacji po stronie serwera.
We własne api można się bawić w momencie gdy piszesz własną aplikację i własny serwer.
Oczywiście pisząc api mam na myśli to co ty (chyba) a nie to co api oznacza w praktyce. Czyli pisząc api mam na myśli protokół komunikacji.
Ogólnie z twoich wypowiedzi można wywnioskować, że masz małe pojęcie o pisaniu aplikacji sieciowych i komunikacji między nimi, nie wiesz nawet do końca jak wygląda komunikacja takiego serwera ze stroną WWW. Dlatego proponowałbym ci zajęcie się czymś bardziej realnym. Zamiast bawić się w C++ i własną implementację serwera użyj jak php lub nodejs do stworzenia serwera, stwórz stronę, aplikację bazującą na np. webkit’cie, a gdy będziesz już to ogarniał i się douczysz w tedy pobawisz się w optymalizację aplikacji. Jeśli jednak od razu potrzebujesz czegoś niskopoziomowego to proponuję ci zlecić to komuś bo mam wrażenie że polegniesz albo zrobisz to za kilka lat.
Sam nie podjąłbym się pisania czegoś takiego bo mam za małą wiedzę, mam w planach pomysł który miałby bazować na podobnym rozwiązaniu, ale cały czas się uczę by móc go zrealizować.
I tu dobrze trafiłeś.
Pojęcie mam małe i dopiero zaczynam. Ogarniam właściwie tylko podstawy podstaw i HTML z CSS na średnim poziomie (robiłem statyczną stronę w ramach szkolnego projektu, nawet nie wyszło źle). Teraz chcę się zabrać właśnie za aplikację internetową. Tak więc zacząłem czytać i chyba przeczytałem nie to co trzeba, albo źle to zrozumiałem. Potrzebuję niskopoziomowego od razu, ponieważ na tym bazuje projekt. PHP czy node.js musiałbym dopiero poznać, więc trochę to mało sensowne rozwiązanie, skoro mam ostatecznie używać czego innego. Tak więc mam zamiar uczyć się tworzenia aplikacji internetowych z użyciem C++. Może to nie najłatwiejsza droga, ale powinienem ogarnąć (potrzebuje tylko źródeł). Nikomu tego nie zlecę. Ten projekt jest w połowie, jeżeli nie w większości jest dla nauki. Zapewne nie uda mi się od razu, ale i tak czegoś się nauczę i przy następnej próbie zajdę dalej. Zacząłem go realizować na poważnie już ok pół roku temu od pisania części programu(ów), które mają przetwarzać dane. Teraz jestem w trakcie trzeciego podejścia, ale dzięki dwóm poprzednim poznałem już dość dobrze C++ i teraz mam już ok. 1.5 k linii kodu prawie gotowych do użytku. Projekt jest duży i jeżeli skończę za 2 lata, to będę zadowolony. Tak więc ja też się uczę, ale trochę inaczej do tego podchodzę.
Jak na razie tyle w moim projekcie jest pewne: baza - PostgreSQL, programy - C++, połączenia bazy i programów - libpqxx, OS - Linux, serwer - NginX, GUI programu klienta - Qt, klient WWW - HTML z CSS, później trochę wodotrysków w JS. Teraz zostaje mi połączenie klientów z serwerem.
Czytałem, że dość prosto można napisać własny moduł do NginX’a. Wydaje mi się, że to będzie najlepsze rozwiązanie. Co o tym sądzisz? Znalazłem już dość rozbudowany poradnik:
http://www.evanmiller.org/nginx-modules-guide.html
Jeżeli znasz jakieś dobre źródła, które mogłyby mi pomóc realizacji któregokolwiek elementu projektu, to prosiłbym o linki.