Myślę, że denerwuje mnie to pytanie, że sformułowałeś je i załadowałeś „faktami”, próbując uzyskać ostateczne „nie”.
Prawda jest taka, że możesz opracować aplikację App Engine, która replikuje funkcje Facebooka, Twittera lub Tumblr. Zakładając, że aplikacja jest dobrze napisana, będzie skalowana, aby obsługiwać setki milionów użytkowników. Głównym powodem, dla którego nie chcesz tego robić (co nie wydaje się być dla ciebie rozważaniem), jest koszt uruchomienia usługi tej wielkości w App Engine.
Nie widzę też, w jaki sposób wymienione przez Ciebie ograniczenia uniemożliwiłyby ci opracowanie takiej aplikacji.
Żądanie / odpowiedź HTTP
- Maksymalny rozmiar żądania: 10 MB - nieprawidłowy, podniesiony do 32 MB.
- Maksymalny rozmiar odpowiedzi: 10 MB - źle, zwiększono do 32 MB.
- jeśli tworzysz aplikację społecznościową, która często musi dostarczać strony większe niż 10 MB, prawdopodobnie robisz to źle. Ponadto, jeśli musisz dostarczyć zawartość większą niż 32 MB, możesz użyć magazynu obiektów blobstore dla plików do 2 GB.
- Nie możesz uzyskać dostępu do systemu plików. (zapomnij o zapisywaniu przesyłanych plików do systemu plików) - źle. Możesz czytać z lokalnego systemu plików oraz przesyłać i odczytywać / zapisywać pliki do magazynu blobstore.
- W żaden sposób Facebook, Twitter lub Tumblr nie pobierają plików użytkownika i kopiują je do folderu. To nie problem.
- Wszystkie żądania muszą odpowiedzieć w ciągu 10 minut, w przeciwnym razie GAE zgłosi DeadlineExceededException - źle. Właściwie to 30 sekund.
- Jeśli potrzebujesz więcej niż 30 sekund, aby dostarczyć wyniki do żądania użytkownika, prawdopodobnie robisz to źle.
- Każde zadanie crona musi zostać wykonane w ciągu 30 sekund - źle, to 10 minut.
- Jeśli nie możesz podzielić długiego zadania na 10-minutowe fragmenty, A: prawdopodobnie robisz to źle, a B: możesz teraz przenieść to zadanie do instancji Backend, która nie ma limitu czasu na żądania.
Zadania Crona nie mogą korzystać z funkcji zmniejszania mapy - nigdy nie używanej redukcji mapy, ale myślę, że wymaga to cytowania.
Każdy GET lub POST na innej stronie jest przerywany po 5 sekundach. Możesz go skonfigurować tak, aby czekał maksymalnie 10 sekund. (serwery pośrednie byłyby niezbędne do współpracy z Twitterem i Facebookiem wiele razy) - Prawda.
- Jeśli skierowane do użytkownika żądanie zewnętrznego interfejsu API trwa dłużej niż 10 sekund, prawdopodobnie dobrym pomysłem jest poinformowanie użytkownika o ponownej próbie. Jeśli nie jest to żądanie skierowane do użytkownika, możesz automatycznie ponowić zadanie, dopóki interfejs API nie odpowie.
- Klient nie może połączyć się z GAE przez FTP (tylko HTTP i HTTPS). - Prawdziwe
- Dlaczego to jest problem? Czy uważasz, że jakaś duża firma wdraża zmiany za pośrednictwem FTP?
- Brak https dla domen niestandardowych. Tylko dla domen twoja.app-id.appspot.com. - Prawdziwe.
- Ale to jest w planie.
- W przypadku napływu użytkowników pojawia się błąd „przekroczenie limitu” - połowa prawdy.
- Jeśli odpowiednio budżetujesz swoją aplikację, nigdy nie zobaczysz błędu przekroczenia limitu. Witryna Royal Wedding była hostowana w App Engine i otrzymywała 32 000 próśb na sekundę. Brak błędów przekroczenia limitu. Czy widziałeś kiedyś błąd wieloryba na Twitterze lub błąd nadmiernej pojemności na Tumblr? To zasadniczo ich błąd przekroczenia limitu.
Baza danych
- Zachowanie bazy danych nie jest takie samo w rozwoju lokalnym jak w rzeczywistych serwerach. - Fałszywe
- Jeśli masz na myśli, że uruchomienie magazynu danych na laptopie jest wolniejsze niż uruchomienie go w klastrze App Engine, to prawda, w przeciwnym razie wcale nie prawda.
- GQL. Nic więcej. - Fałszywe
- Większość programistów używa filtrów db do przeszukiwania magazynu danych. Ponadto można również powiedzieć, że MySQL zezwala na „SQL. Nic więcej”.
- Żadne zapytanie nie może pobrać więcej niż 1000 rekordów (jest do bani, jeśli chcesz pozwolić klientowi na kliknięcie przycisku „przejdź do trybu offline-teraz”) - Fałsz.
- Limit 1000 rekordów został zniesiony dawno temu. Poza tym pokaż mi stronę skierowaną do użytkownika na Facebooku, Twitterze lub Tumblr, która wymaga renderowania ponad 1000 rekordów.
- Jeśli potrzebujesz liniowego dostępu do ogromnej liczby rekordów, aby wykonać operację, nie masz szczęścia (systemy Google są masowo skupione)
- Nie jestem nawet pewien, o co tu chodzi. Większość osób uważa szybkość ogromnego klastra Google za ogromną zaletę systemu.
Maksymalny rozmiar wartości Memcache to 10 MB. - W rzeczywistości jest to 1 MB na pozycję memcache, tak samo jak każda inna implementacja memcache.
Nie można przeprowadzić prostego wyszukiwania tekstu - prawda.
- To funkcja na pokładzie. Większość dużych witryn nie wykonuje własnego indeksowania wyszukiwania tekstowego.
- Nie możesz dołączyć do 2 stołów. - Prawdziwe.
- Programiści App Engine muszą zmienić sposób myślenia z pojedynczego zapytania SQL z wieloma połączeniami na kilka mniejszych pojedynczych zapytań lub zdenormalizować dane, aby łączenia nie były potrzebne.
- Powolny (Musisz przeczytać o tym, jak oddzielić tabele za pomocą dziedziczenia, aby móc wyszukiwać w tabeli, uzyskać klucz, a następnie uzyskać jego element nadrzędny, aby uniknąć wydajności deserializacji) - ???
- wymagane tłumaczenie / cytowanie.
- Wyjątek czasu wykonania „Zbyt wielu indeksów” - True
- Istnieje ograniczenie liczby indeksów w jednej aplikacji. Widziałem jednak tylko aplikacje badań akademickich.
- Jednostka może mieć co najwyżej 5000 wartości właściwości w indeksie - Prawda
- Więc jeśli ktoś ma więcej niż 5000 przyjaciół, potrzebuje dwóch podmiotów w grupie przyjaciół.
- Kluczowe nazwy formularza
__*__(początek i koniec z dwoma podkreśleniami) są zastrzeżone i nie powinny być używane przez aplikację. - Prawdziwe
-- No i co z tego?
- Nazwy kluczy są ograniczone do 500 bajtów (chyba kodowane w UTF-8) - Prawda
- Znowu, więc co? Kluczowe nazwy nie służą do przechowywania powieści, lecz do jednoznacznej identyfikacji bytu.
Język
- python, java lub Go (wszystko inne musiałoby zostać przetłumaczone na te języki) - Połowa prawdy
- W rzeczywistości można również uruchomić dowolny język działający na JVM, w tym PHP i JRuby. Nie jestem pewien, dlaczego jest to problem, Python i Java to dwa potężne języki z dużą ilością dostępnych narzędzi, samouczków i doświadczonych programistów.
Problemy z serwerem
- Brak statycznego adresu IP (problemy z ograniczaniem przepustowości i limitami przy wywoływaniu interfejsów API stron trzecich) - połowa prawdy
- Większość interfejsów API stron trzecich jest świadoma App Engine i / lub ma związek z Google. Kilka razy Twitter przypadkowo zablokował App Engine i naprawiono go w ciągu kilku godzin.
- Każda aplikacja jest ograniczona do 3000 plików - połowa prawdy
- Jeśli naprawdę potrzebujesz więcej niż 3000 plików kodu dla swojej aplikacji internetowej, możesz skorzystać z importu zip (również być może robisz to źle).
- Brak kontroli nad systemem operacyjnym lub sprzętem, na którym działa aplikacja internetowa - Prawda
- App Engine to platforma jako usługa . Ludzie nie muszą się martwić o obsługę systemu operacyjnego lub sprzętu. Jest to kluczowa zaleta App Engine, a nie ograniczenie.