Jak skalowalny jest Parse? [zamknięte]

Rozważałem użycie Parse.com usługa dla mojego zaplecza, ale jestem sceptyczny co do jego skalowalności.

Czy tonaprawdę obsłuży kilka tysięcy jednoczesnych użytkowników? Jeśli nie, to czy ich dobry sposób na odejście od tego?

Author: Rob Caraway, 2012-07-01
Source

9 answers

Wiem, że pytanie może być stare, ale chciałem podać moje 2 centy dla innych, którzy mogą rozważać parse....

W najprostszych scenariuszach parse może działać dobrze. Jak tylko trzeba skalować do bardziej złożonych zapytań, ja osobiście nie znalazłem nic, ale bóle głowy.

  1. Zapytania są ograniczone do 1000 rekordów. Początkowo możesz myśleć, że nie jest to problem, dopóki nie zaczniesz zajmować się zapytaniami podrzędnymi i zdasz sobie sprawę, że dziwne dane są zwracane, ponieważ sub zapytanie odcina rekordy bez ostrzeżenia lub błędu. (Dla twojej wiadomości, domyślnie jest to 100 rekordów, chyba że określisz limit do 1000, więc problem jest jeszcze gorszy, jeśli nie zwracasz uwagi).

  2. Z jakiegoś dziwnego powodu istnieje ograniczenie liczby razy, które można wysłać zapytanie count w ciągu minuty. (a limit ten wydaje się być naprawdę niski). Bądź przygotowany, aby spróbować i przepustnicy kod, aby nie trafić ten limit, w przeciwnym razie błędy są wyrzucane.

  3. Zadania w tle nie są uruchamiane niezawodnie. Miałem ustawione zadanie w tle, aby uruchamiać się co 5 minut, a czasami zajmuje to 20 + min, zanim zadanie zacznie działać.

  4. Dużo czasu. To ten przyprawia mnie o zgagę. O. jeśli masz funkcję chmury, której przetwarzanie zajmuje trochę czasu, masz około 6 lub 7 sekund, aby to zrobić, lub cię odetnie.
    B. mam wrażenie, że w systemie panuje ogólna niestabilność. Okresowo napotykam problemy, które wydają się trwać około godzina lub tak, gdzie timeouts zdarzają się częściej(i ze stosunkowo prostymi funkcjami, które powinny wrócić natychmiast).

W pełni żałuję mojej decyzji o użyciu parse, i robię wszystko, co mogę, aby utrzymać aplikację przy życiu wystarczająco długo, abyśmy mogli uzyskać finansowanie, więc możemy przenieść się z platformy. Jeśli ktoś ma jakieś lepsze alternatywy dla parsowania, zamieniam się w słuch.

 75
Author: Robert Charest,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-06-17 00:04:26

[Edit: po trzech niesamowitych latach z zespołem, zdecydowałem się przejść dalej i nie jestem już Parse lub Facebook pracownika. Zespół jest w świetnych rękach i zrobił niesamowite rzeczy. Cały backend został przepisany w celu znacznego zwiększenia wydajności i niezawodności. Mapa Drogowa jest niesamowita i oczekuję wielkich rzeczy od zespołu. W momencie mojego wyjazdu, Parse zasilał ponad 600,000 wniosków i obsługiwał zadziwiającą liczbę próśb każdego dnia. Czy każdy Parse push to be wysłane do wyjątkowej osoby, mogą stworzyć czwarty co do wielkości kraj na świecie w jeden dzień. W przypadku przyszłej pomocy z Parse, proszę albo post pytania tutaj z parse.com tag lub post do grupy Google parse-developers.]

Pełne ujawnienie: jestem inżynierem analizy.

Parse obsługuje już tysiące aplikacji , nie mówiąc już o użytkownikach. Kiedy zakończyliśmy beta pod koniec marca, ogłosiliśmy ponad 10 000 aplikacji działających w trybie Parse z 40% wzrostem miesięcznie w stosunku do miesiąca. Parse jest zatrudniona przez światowej klasy zespół, wielu z wieloletnim doświadczeniem w big data i dużym natężeniu ruchu.

Przyjmujemy Twój ruch z otwartymi ramionami; będziesz w towarzystwie wspaniałych zespołów, takich jak Band of the Day i Hipmunk. Jesteśmy tak pewni naszych usług, że zbudowaliśmy nasz system One Click Export , aby ludzie tacy jak Ty mogli wypróbować analizę bez ryzyka. Jeśli uważasz, że Parse nie spełnia Twoich oczekiwań dotyczących wydajności, chętnie odeślemy Ci wszystkie Twoje dane nienaruszone.

 35
Author: Thomas Bouldin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-05-31 21:25:02

Wybraliśmy Parse jako backend dla naszej aplikacji. Wniosek: nie.

Stabilność to katastrofa, wydajność to katastrofa, podobnie jak wsparcie (prawdopodobnie dlatego, że nie mogą ci naprawdę pomóc, ponieważ wszystkie problemy są nie odtwarzalne).

Uruchamianie nawet najprostszych funkcji może prowadzić do losowych przedziałów czasowych wewnątrz Parse (mówię o prostych wywołaniach logowania PFUser): 

Error: Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo=0x17e42480 {NSErrorFailingURLStringKey=https://api.parse.com/2/client_events, NSErrorFailingURLKey=https://api.parse.com/2/client_events, NSLocalizedDescription=The request timed out., NSUnderlyingError=0x17d10e60 "The request timed out."} (Code: 100, Version: 1.2.20)

Spotykamy timeouts na co dzień, i to jest z aplikacji, które testujemy z 10 użytkowników max!

To jest typowy, który wracamy cały czas, w zupełnie dowolnych momentach i niemożliwych do odtworzenia. Wywołanie funkcji kodu w chmurze, która wykonuje kilka zapytań i kilka wstawek: 

 {"code":124,"message":"Request timed out"}

Spróbuj tego samego 10 minut później i uruchamia się w mniej niż sekundę. Spróbuj ponownie 20 minut później, a wykonanie zajmie 30 sekund.

Ponieważ nie ma transakcji to naprawdę dużo zabawy przy przechowywaniu np. 3 obiektów w jednej funkcji kodu chmurowego, gdzie Parse decyduje o losowym wycofaniu funkcji po zapisaniu 2 z 3 obiektów. Świetnie, aby Twoja baza danych była spójna.

Te "najlepsze", które mamy tam, gdzie to. Pamiętaj, że są to rzeczywiste dane pochodzące z funkcji kodu w chmurze: 

 {"code":107,"message":"Received an error with invalid JSON from Parse: <!DOCTYPE html>\n<html>\n<head>\n  <title>We're sorry, but something went wrong (500)</title>\n  <style type=\"text/css\">\n    body { background-color: #fff; color: #666; text-align: center; font-family: arial, sans-serif; }\n    div.dialog {\n      width: 25em;\n      padding: 0 4em;\n      margin: 4em auto 0 auto;\n      border: 1px solid #ccc;\n      border-right-color: #999;\n      border-bottom-color: #999;\n    }\n    h1 { font-size: 100%; color: #f00; line-height: 1.5em; }\n  </style>\n</head>\n\n<body>\n  <!-- This file lives in public/500.html -->\n  <div class=\"dialog\">\n    <h1>We're sorry, but something went wrong.</h1>\n    <p>We've been notified about this issue and we'll take a look at it shortly.</p>\n  </div>\n</body>\n</html>\n"}

Rzeczy, które tu opisuję, nie są czymś, co zdarza się raz na niebieskim księżycu w naszym projekcie. Oprócz 500 błędów (które napotkałem dwa razy w miesiącu) wszystkie inne są widoczne na co dzień.

Więc tak, jest to bardzo łatwe do rozpoczęcia, ale musisz wziąć pod uwagę, że pracujesz na niestabilnej platformie, więc upewnij się, że masz swoje powtórzenia i wykładnicze systemy cofania się i działa, ponieważ będziesz tego potrzebować!

Najbardziej martwi mnie to, że nie mam pojęcia, co się stanie, gdy 20.000 osób zacznie używać mojej aplikacji na tym backendzie.

Edit:

W tej chwili mam to podczas robienia loginu PFUser: 

Error: Error Domain=PF_AFNetworkingErrorDomain Code=-1011 "Expected status code in (200-299), got 502" UserInfo=0x165ec090 {NSLocalizedRecoverySuggestion=<html><body><h1>502 Bad Gateway</h1>
The server returned an invalid or incomplete response.
</body></html>
, PF_AFNetworkingOperationFailingURLResponseErrorKey=<NSHTTPURLResponse: 0x16615c10> { URL: https://api.parse.com/2/get } { status code: 502, headers {
    "Cache-Control" = "no-cache";
    Connection = "keep-alive";
    "Content-Length" = 107;
    "Content-Type" = "text/html; charset=utf-8";
    Date = "Mon, 08 Sep 2014 13:16:46 GMT";
    Server = "nginx/1.6.0";
} }, NSErrorFailingURLKey=https://api.parse.com/2/get, NSLocalizedDescription=Expected status code in (200-299), got 502, PF_AFNetworkingOperationFailingURLRequestErrorKey=<NSMutableURLRequest: 0x166f68b0> { URL: https://api.parse.com/2/get }} (Code: 100, Version: 1.2.20)
Czy to nie wspaniałe?
 23
Author: Joris Mans,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-09-08 13:20:18

Jeśli piszesz małą / prostą aplikację (lub odrzucany prototyp) z małą lub bez logiki na zapleczu, to idź na to, ale dla czegoś większego / skalowalnego najlepiej tego unikać, mogę to powiedzieć z doświadczenia z pierwszej ręki. To wszystko brzmi dobrze z zarządzaniem użytkownikami, powiadomieniami push, abstrakcyjną pamięcią masową i tym, co nie, ale w końcu nie warto się kłopotać. Mianowicie rozwijałem backend dla aplikacji na Parse, klienci byli tak bardzo w nim, ponieważ brzmiało fajnie i obiecująco (silny marketing chyba), kupowane przez Facebook i co nie, ale kilka tygodni w produkcji zaczęły pojawiać się poważne problemy / ograniczenia z platformą, co powinno być prostą aplikacją okazało się koszmarem do rozwoju i skalowania.

Wynik / zakończenie projektu: - złamał okno czasowe dla stosunkowo prostej aplikacji-to powinno trwać 2-3 miesiące, to trwało prawie rok i nadal nie jest stabilny/niezawodny, gdybyśmy użyli niestandardowego stosu to byłoby zrobione wewnątrz okna czasu na pewno bo zrobiłem podobny projekt demo w 5-10 dni z niestandardowym stosem węzłów - stracili zaufanie klienta, teraz przerabiają aplikację z innym zespołem, który użyje niestandardowego stosu - stracił mnóstwo gotówki za złamanie okna czasowego i próby jego działania - zrobiłem tyle nadgodzin z tego powodu, że zaczęło się zastanawiać nad moim zdrowiem - nigdy nie używaj platformy / rozwiązania, które obiecuje mieć to wszystko, zawsze używaj niestandardowego/wypróbowanego stosu

Pierwsze były problemy ze stabilnością i stałą awaria platformy, taka jak przestoje serwerów i przypadkowe błędy, ale mają to wszystko rozwiązane( to było na początku-w połowie 2014 roku), ale następujące problemy pozostają: {]}

  • nie możesz debugować kodu, przynajmniej w tej chwili (istnieją sposoby, aby działał z dodatkowym serwerem węzłów i jakąś niejasną lib)
  • limity są śmieszne, skalowalna platforma, która może wykonać 50-60 żądań API na sekundę (lub więcej w zależności od subskrypcji), co nie jest tak niskie brzmi, dopóki nie zaczniesz testować szczepu, a kiedy go uderzysz, Twój kod będzie ciągle zawodził
  • wywołania API są mierzone w następujący sposób: wywołanie funkcji serwera (zadanie parsowania) - 1 wywołanie, odpytywanie bazy danych - 1 wywołanie, kolejne zapytanie (ponieważ nie mają Zaawansowanego/złożonego systemu zapytań, jeśli masz bardziej złożony schemat bazy danych, wkrótce zrozumiesz co mam na myśli) - 1 wywołanie, jeśli potrzebujesz uzyskać więcej niż 1000 zapytań zgadnij co-zapytanie ponownie, itp., query for count (musisz zrobić jest to osobne zapytanie), które jest nierzetelne (zwykle zwraca przybliżenie dla kilku tysięcy wpisów)
  • Tworzenie / zapisywanie ~1000+ prostych obiektów jest obciążeniem dla platformy / bazy danych, usuwanie 1000 lub więcej obiektów, tym bardziej, co jest śmiesznie szybkie dla normalnych baz danych, ale na parsowaniu zajmuje to zwykle 5-10 minut (jeśli sprawdzisz to dokładniej, usunie 20 obiektów na partię)
  • nie ma możliwości użycia większości pakietów npm (tylko czystych pakietów JS poprzez włączenie źródła bezpośrednio)
  • jeśli przejdziesz i poczytasz Fora parsowania, zobaczysz, że użytkownicy obniżają / palą zespół parsowania stale za brak funkcji platformy i muszą przeskakiwać przez obręcze dla arbitralnej implementacji logiki, takiej jak pobieranie losowych wpisów i podobnych rzeczy
  • obsługują integrację Stripe, ale jeśli chcesz użyć Paypal lub innej usługi płatniczej (zdecydowaliśmy się użyć Paypal, ponieważ ma znacznie lepsze wsparcie kraju nad Stripe) nie możesz sprawić, że będzie działać na Parse, dla Integracja Paypal musiałem użyć oddzielnego serwera, aby ją wyłączyć
  • nie ma łatwego sposobu na synchronizację użytkowników i rozwiązywanie problemów z współbieżnością, musisz użyć hacków i jakiejś zabawnej logiki, której nie użyjesz lub przyznasz, że używasz nowhere never
  • chcesz 100+, a co dopiero 1000 + jednoczesnych użytkowników, powodzenia w ciągnięciu tego
  • Gdy chcesz poznać liczbę wpisów w tabeli, możesz trafić na limit wywołania zapytania count, które jest śmieszne, nie udokumentowane i całkowicie śmieszne, a w końcu zwraca przybliżoną liczbę
  • modułowość jest obca platformie, funkcje, które wywołujesz ze swoich zadań, nie mogą trwać dłużej niż kilka sekund (myślę, że 7 sekund), a gdy weźmiesz pod uwagę czas zapytań, to z pewnością wydarzy się wiele bardziej złożonych zapytań i skomplikowanej logiki
  • możesz mieć coś takiego jak zadania Cron, ale nie mogą one trwać dłużej niż 15 minut (ze względu na niską wydajność platformy, jak wiele zapytań, które są bardzo, bardzo krótkie), są ograniczone do 2-3-4 jednoczesnych zadań w zależności od opłaty abonamentowej, i mają bardzo ograniczony/słaby system planowania na miejscu (np. nie można edytować go z kodu, jest bardzo ograniczony, więc musisz użyć hacków, aby uruchomić to samo zadanie w 2 dokładnie razy w ciągu dnia lub coś podobnego, nie można oglądać oszczędności czasu itp.)
  • Gdy pojawi się błąd na serwerze, może to być całkowicie mylące, sprawdź na forum, nie pamiętam nic z mojej głowy
  • powiadomienia Push są regularnie spóźnione nawet 20-30 minut

Dowolny przykład: chcesz pobrać losowy element z ich bazy danych, Twoja aplikacja wykonuje połączenie do zadania, które go dostarczy (1 wywołanie API), zadanie zapytuje bazę danych, ale musisz wykonać 2 połączenia, najpierw aby uzyskać liczbę elementów (1 wywołanie API), a następnie drugie, aby uzyskać losowy element( 1 wywołanie API), jest to 3 wywołania API dla tej funkcjonalności, a przy 60 żądaniach na sekundę, 20 użytkowników może wykonać to połączenie w określonym czasie, zanim trafienie limitu żądań i platforma szaleje, po uwzględnieniu innych użytkowników przeglądających ekrany aplikacji i takie tam, zobaczysz, do czego to prowadzi...

Gdyby to było coś dobrego, czy Facebook, który kupił to wszystko, używając go nawet do niektórych swoich aplikacji? Proponuję 3 rzeczy: - po pierwsze-nie słuchaj parse guy, to jego platforma, więc musi go promować, słuchać ludzi, którzy używali go, aby zrobić coś za jego pomocą
- po drugie - jeśli potrzebujesz poważnego i skalowalnego platforma i nie chcesz iść w pełni niestandardowe, przejdź do Amazon Cloud services lub coś podobnego, który jest testowany i niezawodny - po trzecie-trzymaj się z dala od platformy, jeśli masz jakieś doświadczenie po stronie serwera, jeśli nie, to idź i zatrudnij backend dev do projektu, to będzie tańsze i dostaniesz działające rozwiązanie w końcu

 20
Author: Davor Badrov,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-02-07 22:02:30

Spędziłem dzień patrząc na parse.com a oto moja obecna opinia oparta na tym, co znalazłem(proszę pamiętać ,że mam tylko bardzo krótkie doświadczenie w rozwijaniu z SDK jak dotąd)..

Parse.com wyraźnie ma kilka bardzo atrakcyjnych pozytywów, dlatego znalazłem się patrząc na to, ale ze względu na debatę będę koncentrować się na krytycznym jako wielkie pozytywy są wymienione na ich stronie internetowej. (Dobrze zrobione parse.com za próbę rozwiązania tak wielkiego problem!)...

  • w referencjach, Hipmunk jest największą nazwą, jaką powiedziałbym. Jest wymieniony jako aplikacja, która korzysta z części danych SDK. Bez zbliżania się do deweloperów Hipmunk, Nie wiem na pewno, ale nie wyobrażam sobie, aby przechowywali wszystkie swoje dane w parse.com Chmura.
  • po wypróbowaniu i przeglądaniu większości wymienionych aplikacji. Żadna nie wyróżnia się jako bardzo zależna od zaplecza serwera, więc nie mogę zrozumieć, czy skalowalność została rozwiązane za pomocą parse.com na podstawie tego.
    • [[5]}strona podaje 40 000 aplikacji i liczy. Czuję (ale nie wiem), że w oparciu o Galerię aplikacji, ta liczba jest oparta na ilości aplikacji w ich bazie użytkowników, a nie na prawdziwych aplikacjach produkcyjnych na żywo w sklepach z aplikacjami. Galeria aplikacji miałaby znacznie więcej wielkich nazwisk, gdyby wiele aplikacji używało parse.com.

Parse.com jest to bardzo nowa koncepcja, i bardzo różne nawet do swoich najbliższych rywali. Więc bez konkretnych dowodów na to, jak skalowalne i stabilny (i cała reszta) to jest, to jest bardzo trudne dla dewelopera w projekcie, aby rozważyć zobowiązanie się do niego, ponieważ istnieje zbyt wiele w stawce.

 11
Author: Eurig Jones,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-10-30 21:47:48

Przeprowadziłem testy dla własnej odpowiedzi na podobne Pytanie i może być bardzo, bardzo szybko. Jednak wyniki mogą zależeć od szczegółów wdrożenia...

Test porównał Android SDK z Androidem za pomocą natywnego stosu HTTP wykonującego połączenia Parse/REST...

Szczegóły Testu:

Środowisko testowe-najnowsza wersja Androida na 10-miesięcznym telefonie przez szybkie połączenie WIFI.

( upload 63 zdjęć gdzie avg filesize=80K )

Test 1 z wykorzystaniem wynik android SDK = powolna wydajność

Test 2 przy użyciu natywnych połączeń REST przez Androida wynik = Vert FAST

-- EDIT -- jak tu jest ciekawie....

Jeśli chodzi o http thruput , parse SDK (android) i wydajność, może być tak, że parse.com nie zoptymalizowała wydajności w sposób, w jaki implementują AsyncTask() Androida w analizie.android SDK? Jak praca wymagała 8 min. na parse.sdk można zrobić w 3 sekundy na zoptymalizowanym REST, Framework DIY ( patrz linki dla szczegóły dotyczące realizacji), naprawdę Nie wiem. Jeśli parse nie naprawił ich implementacji SDK od czasu testów porównawczych, to prawdopodobnie nie chcesz, aby ich domyślne SDK asnyctask robiło cokolwiek zbliżającego się do rzeczywistego obciążenia w sieci.

 11
Author: Robert Rowntree,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-07-21 22:50:19

Wielką atrakcją Parse (i podobnych SaaS) jest to, że możesz zaoszczędzić dziesiątki tysięcy na kosztach rozwoju zaplecza. Biorąc pod uwagę, że back-end jest często najdroższym aspektem aplikacji internetowej; że ból głowy jest nagle puf .

Problem z analizowaniem i większością (wszystkich) SaaS polega na tym, że region, moc, pamięć, przepustowość, skalowalność, progi, alerty i różne akcje są poza Twoją kontrolą.

To samo z Shopify. To świetny Saas z kompleksową kontrolą nad produktami, zamówieniami, zapasami i estetyką-ale zero kontroli nad maszyną. Tak więc dzisiejszy SaaS nie różni się zbytnio od godaddy. Niezmiennie przeceniają lub maksymalizują swoje maszyny, aby zarabiać pieniądze; a Ty utknąłeś, jeśli naprawdę zależy ci na wydajności kopania w dupę. Nie można nawet kupić tego poziomu usług.

Chciałbym coś co najmniej tak potężnego i wszechstronnego jak konsola AWS. Większość techników wie i akceptuje, że Heroku i Parse są hostowane na AWS. Kogo to obchodzi. Więc pobieraj więcej za dodaną usługę, ale nie odmawiaj dostępu do tych krytycznych narzędzi niskiego poziomu, które sprawiają, że witryna i aplikacja oraz wrażenia użytkownika są zing. / Align = "left" /

W każdym razie w odpowiedzi na pytanie:

Parse API to prosty JSON. Możesz więc wypompować dane w tym samym formacie JSON, jakiego oczekuje aplikacja analizująca.

Możesz nawet wykorzystać ich PFObject (iOS). W pewnym momencie, wszystkie te Highlevel API idzie do wspólne żądanie/odpowiedź HTTP. Dobra rzecz w ogólności resta oznacza common-of-the-shelf; rzeczy takie jak http, url, ciągi i utf. Nie ma tu funky Orb.

 8
Author: Gabe Rainbow,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-07-30 20:21:45

Parse świetnie jest zacząć od szczególnie pomocniczych funkcji / funkcji dotyczących zarządzania użytkownikami. Ale zacząłem napotykać problemy ..

Długie czasy wykonywania / ping, limit 1000 obiektów włącznie z zapytaniami podrzędnymi, brak centrów danych w Europie (o ile wiem)

To byłaby Boska Platforma, gdyby mogli rozwiązać problemy z wydajnością i stabilnością. Jakoś żałuję, że się z nim rozwijam, ale umieściłem 5000 + linijek kodu, więc będę się go trzymał.

Może powinni oddzielić swoje Aplikacje DEV i środowiska PROD apps i Zezwalaj tylko na aplikacje PROD po pewnym nadzorze lub stwórz inne środowisko z tylko płatnymi klientami?

Jesteśmy w 2014 roku, serwery $20/miesiąc mogą obsługiwać nieoptymalizowane strony internetowe (60 nie buforowanych zapytań db na stronie głównej) z 1 milionem odwiedzin/miesiąc, to nie powinno być takie trudne!

 5
Author: EralpB,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-10-14 11:36:49

Jest ok dla prototypowania aplikacji, zwłaszcza jeśli deweloper iOS / Android nie wie, jak zbudować backend DB/API samodzielnie.

To wcale nie jest w porządku, jeśli chodzi o tworzenie aplikacji z logiką, która wymaga zapytań bardziej złożonych niż: 

SELECT * FROM 'db' WHERE 'column' = 'value' LIMIT 100;

Powiązane zapytania i łącza wewnętrzne nie istnieją na Parsie. I powodzenia w aktualizacji / usuwaniu rekordów 320 000, jeśli potrzebujesz (to numer, z którym teraz pracuję).

Jedyną rzeczą, która jest naprawdę przydatna, jest obsługa użytkowników poprzez SDK. Gdybym mógł znaleźć dobre dokumenty lub nawet samouczek, jak obsługiwać / tworzyć użytkowników za pomocą aplikacji IOS/Android za pomocą Django i DRF / Tastypie, natychmiast konwertuję wszystko, co jest rozwijane w naszej firmie, aby z tego korzystać.

 2
Author: Andrey Shipilov,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-03-12 08:12:43