Удобно ли будет организовать PHP клиент для RestFull API (SPA)?

Question

[nepster-web]

Читал про это дело в частности про вопрос SPA application, авторизация и что рендерить backend'y?

Для себя вообще определил несколько минусов при подходе чистый js + rest full:
- теряем возможность работы с куки и сессиями
- не очень удобно и не привычно работать с JS MVC
- сео оптимизация.
- везде нужно тягать токен туда сюда

Собственно есть мысли в такую сторону:
- RESTFULL api server (отдельный проект)
- и к нему можем написать клиент на любом php фраэмворке в классическом виде. Разница в том, что вся логика в апи, а модели из себя представляют только запрос-ответ к рест апи.
Получается нет никаких проблем.

Собственно у кого есть опыт в этом деле, разъясните пожалуйста что к чему. Гайды не интересны, интересен именно ваш практический опыт.

Comments

[Viktor Vsk]

Получается нет никаких проблем.

Только пара небольших - дублируется код (скорей всего) и юзер ждет 2 запроса, время которых, естественно, суммируется

По таком схеме, например, очень давно работает www.tecdoc.de/ru/home.html
Самому интересно, есть ли реальный успешный опыт с таким процессом у кого-то

[nepster-web]

Виктор Ablebeam: ну смотрите, Rest Api хорошо кэшируется и мы можем обойти DNS (делать запрос вне домена по ip или вообще внутри сети), тем самым сократить время отклика. Но зато появляется штатное удобство.

[nepster-web]

Виктор Ablebeam: меня еще смущает момент с обменном временного токена и авторизацией через соц сети, без сервера.

Answer 1

[Сергей Протько]

теряем возможность работы с куки и сессиями

Ну не совсем, с куками вы все так же можете работать и через куки хранить сессии, другое дело что это в 99% не нужно. А токены - JWT решает все проблемы.

не очень удобно и не привычно работать с JS MVC

Привыкните, учитывая то что JS MVC это то, чем должно быть MVC.

сео оптимизация

Тут есть варианты:
- гугловский краулер поддерживает JS нынче, на счет остальные не вкурсе.
- генерация снапшетов (phantomjs например) и Ajax crawling
- server-side рендринг, актуально при втором пункте.

везде нужно тягать токен туда сюда

Большая часть фреймворков делают это прозрачно для разработчика, так что это то же самое что туда-сюда тягать куки.

и к нему можем написать клиент на любом php фраэмворке в классическом виде

Почитайте про гексагональную архитектуру, например. HTTP API и классический WEB UI это лишь два интерфейса к одной и той же логике, которая инкапсулирована в сервисы. Разница лишь в том, как DTO из сервисного слоя будет юзаться для формирования представления (будь то json или html).

https://www.youtube.com/watch?v=ajhqScWECMo - вот вам посмотреть на досуге.

Comments

[nepster-web]

Сергей Протько вопрос на миллион. Почему JWT, а не oauth2 ?

[Сергей Протько]

nepster09: потому что oauth2 это стандарт авторизации, я его использую если у меня есть один сервер авторизации на несколько приложений, а JWT это стандарт для формирования токена и только, просто для него есть все готовое и под бэкэнд и под фронтэнд, да и удобно. OAuth2 всеравно обычно юзают вместе с Bearer токенами, так что можно OAuth2 + JWT, тут как говорится как хотите.

[nepster-web]

спасибо. Щас попробуем и то и то реализовать. К сожалению по видео если я 2% пойму будет здорово.

[Сергей Протько]

nepster09: на ютубе есть субтитры (автоматически распознанные но суть вы должны понять), так же там довольно простые примеры кода, по которым все наглядно видно.

[Сергей Протько]

nepster09: короче основная мысль в том, что контроллеры становятся тонкими, их задача перевести из формата представления (REST, HTTP, RPC, MQ или еще чего) в единый формат приложения, DTO, имутабельный объект который нужен для переправки данных между слоями. Тогда нет никаких проблем с тем что бы сделать одновременно и WEB и REST и что угодно.

[Сергей Протько]

nepster09: а ну и проблема версионизации API решается так же легко.

[nepster-web]

Сергей Протько: там в задаче rest api должен быть ну прямо отдельным проектом.
Я не понимаю еще почему все косо смотрят на отдельный php клиент, если это тоже самое, как например если бы вы использовали сторонний сервис у себя в проекте, например гугл апи.

Идея такая:
Rest APi

и к нему отдельные клиенты:
web клиент
desktop клиент
android клиент
ios клиент
и тп.

[nepster-web]

Сергей Протько: еще момент разграничения. Приходит новый разработчик, и получает работу например только над клиентом. Все остальное для него открыто только по средствам апи

[Сергей Протько]

nepster09: ну как вам сказать, этот подход практикуют, только используют вещи поэффективнее (MQ), а REST API должно быть так же в таком случае отдельным приложением использующим основное через MQ.

[Сергей Протько]

nepster09: вы поймите, REST для взаимодействия между бэкэндами крайне не эффективен, если сравнивать со штуками типа MQ через какой RabbitMQ или кафку, которые сами разруливают маршрутизацию сообщений и т.д. Это позволяет добиться изоляции отдельных сервисов и сегрегировать ответственность. А то что вы предлагаете сделать, это как бы так же вариант, использовать HTTP как интерфейс к приложению, но это чуть более чем странно, учитывая что можно построить взаимодействие ежду UI-layer и Application layer по старинке.

[nepster-web]

Сергей Протько: вы имеете ввиду очередь ? Если да, то причем тут она ?

[Сергей Протько]

nepster09: общение между компонентами систем делают обычно через очередь сообщений. Ну мол один сервис запихнул в очередь "сделай мне эту хрень" а какой-то воркер подобрал, сделал и через pub/sub они обменялись результатами. Это позволяет добиться большей производительности системы и большей гибкости, так как мы не зависим от конкретного воркера. В случае с rest мы должны знать кто будет делать дела, а в случае с MQ нам без разницы, лишь бы сделали. Ну и прослоек меньше.

[nepster-web]

Сергей Протько: понял, спасибо, пошел разбираться

[Сергей Протько]

nepster09: почитайте про микросервисы