Ами, напротив.

Ето защо смятам за грешка преподаването на този Parse.com. Хората си мислят, че има писане на логика в SPA фронт енда.

В клиентското SPA приложение нямаш бизнес логика. Имаш само презентационна такава. Ако получиш еди какъв си респонс от сървъра, кой темплейт да лоуднеш и т.н. Това, което замества SPA фронт енд-а са View-тата примерно в едно ASP.NET MVC приложение или приложение написано, например, на Laravel. Останалата сървърна част на ASP.NET/PHP си остава.

Представи си следното стандартно (MVC?) приложение (написано на РНР и HTML);

mysite.com/users/authenticate (минава през controllers/users.php -> public function authenticate(); и лоудва views/users/authenticate.html):

view:

<?php if (!isset($_SESSION['isLogged'])) : ?>

<form method="POST">

    <input type="text" name="user" />

    <input type="password" name="pass" />

    <input type="submit" />

</form>

<?php else: ?>

<p> Welcome <?= $_SESSION['username']; ?> </p>

<?php endif; ?>

controller:

public function authenticate() {

     if ($_POST['username'] == 'Ivan' && $_POST['password'] == 'myPass') {

         $_SESSION['isLogged'] = 1;

         $_SESSION['user_id'] = 100;

         $_SESSION['username'] = 'Ivan';

     }

}

Страницата се презарежда при събмит, активира се authenticate() метода, проверява дали юзъра и пасса съществуват в базата чрез модела (в случая хардкоднати на Ivan/myPass) и създава сесия за този потребител. С if/else конструкция в HTML-а се появява формата за логин, ако не си логнат, или ако си логнат, ти пише "Welcome Ivan".

В един SPA апликейшън нещата ще са горе долу същите. Контролера обаче ще запише сесията в базата данни (токена, ид-то...) и ще го върне като json response за да може клиента да показва на сървъра, че потребителят е логнат. Това е наложащо само когато клиентското приложение и сървърнато са на различни сървъри. Ако са на един сървър може да действа ТОЧНО като в примера по-горе.

Submit бутона се заменя с нормален бутон. Закача му се event handler който при клик прави AJAX POST към контролера и... магията е готова. При успешно върнат токен от контролера без да се презарежда страницата се зачиства логин формата и се лоудва параграф с Welcome и името на потребителя. Цялата ти логика отново остава скрита в бекенда. Единствената клиентска логика, която потенциален хакер може да види е, че в темплейта пише "if(успешен респонс) скрий формата и покажи Welcome", което не е sensitive информация.

Аз само като леко допълнение да вметна че реалната благинка която ди дават REST api-тата не е единствено за SPA странички. Реално ти имаш един сървър някъде написан на php/c# и тн... а чрез тези api-та може да реализираш както SPA приложение така и да ги използваш и в мобилно приложение написано на Unity, Phonegap и други платформи а един ден когато решиш че ще интегрираш въпросното приложение да речем при смарт телевизорите ще използваш api-тата на следващата платформа на която си решил.

Да вметна и друго - подкрепям мнението на Иван за Parse.com че използването му на този етап е грешно защото хората остават с впечатлението че логиката стои в самия SPA App и се получава объркване ..

И аз да добавя нещо: Идеята на SPA е да спести някои процедури на сървъра, които биха могли да бъдат извършени при клиента. При обикновените приложения, сървъра приема заявки, обработва ги.... обработва html-а и ти го връща готов. Някога някой си е задал въпроса - "защо сървъра да прави тези неща за всеки един клиент, след като всеки клиент може да си ги прави сам за себе си?"... и се е стигнало до едно уникално решение - SPA.

В крайна сметка това много намаля трафика и разходите на сървъра. При обикновено приложение, когато направиш заявка, получаваш същия html, css и js отново и отново... браузъра ги прочита и render-ва отново и отново... При SPA нещата стоят другояче. Веднъж си получил html, css и js и вече знаеш какво да правиш с тях. Единственото ново нещо, което сървъра може да ти предложи, е един прост json, или xml или ... текст, който ти обработваш в клиентския браузър и променяш съдържанието. За да ти се смени текст-а в един <div>, не ти трябва да презареждаш всичко наново, а само сървъра да ти каже "това е новият текст, сам си го смени - няма да ти повтарям като папагал и да ти пращам едни и същи файлове всеки път (веднъж ти ги пратих, стига толкова), нито пък да си хабя енергията и да обработвам това, което ти сам можеш да си го обработиш".