Какая обычная простейшая архитектура php-бэкенда для SPA?

Question

[identifier classname]

Изучаю тему проектирования бд.

Допустим есть некое обычное клиентское приложение которое использует на бекенде обычную базу данных.
Понимаю что обычно на сервере и на клиенте приложения делают используя фреймворки, но речь не о них.

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

Пока понимаю что есть три основных типа данных -
- документы (готовые страницы для просмотра)
- JSON
- медиафайлы

Также понимаю что эти данные можно хранить в различных моделях: сетевая иерархическая реляционная многомерная обьектная
И еще понимаю что надо разделять права для участников и владельца.

Answer 1

[ThunderCat]

90% данных в спа предающихся с бэка на фронт в жсон. Запросы к бэку уходят по достаточно стандартным роутам а ля CRUD ну и + типа названия объекта: user, item, file, точнее наоборот: user/edit, image/add или что-то типа такого.
На бэке обычно тоже достаточно простые готовые методы CRUD, + специфические на всякие админки и свистохотелки. Обычно создается объект запрошенного типа, с ним производятся операции, на фронт выдается результат в жсоне. Ничего магического.

Также понимаю что эти данные можно хранить в различных моделях: сетевая иерархическая реляционная многомерная обьектная

В целом это ничего не меняет для архитектуры в комплексе - запрос с фронта - создали объект - отработали действие прописанное в запросе - отдали результат на фронт.

И еще понимаю что надо разделять права для участников и владельца.

RBAC или ACL, пока больше ничего толкового не придумали.

Comments

[identifier classname]

А для какого процента приложений достаточно простого хранилища типа ключ:значение?
Подобного localForage например.

И бывают ли бэкенды выдающие не json а только документы?

[ThunderCat]

identifier classname:

А для какого процента приложений достаточно простого хранилища типа ключ:значение? Подобного localForage например.

Сложно сказать. От структуры данных зависит. Как можно заранее сказать? Только описав юзекейсы и расписав архитектуру.

И бывают ли бэкенды выдающие не json а только документы?

Это должны быть очень специфичные задачи, но не вижу проблем с этим.

[identifier classname]

ThunderCat: допустим есть учебная задача сделать простой универсальный бэкенд на котором возможно делать максимально большой спектр приложений типа тостера или хабра или жж... и бд свою самописную хочу сделать.

Какие минимальные характиристики должны быть?
Просто у меня нет опыта разработки на заказ
Какой минимум функционала нужен?

Прошу ответить поподробнее.

[ThunderCat]

identifier classname: создать список объектов которые будут в проекте, на каждый сделать свой CRUD, это в принципе покрывает 99% задачи. Как всегда, проблемы и нюансы возникают по ходу выполнения, без опыта проектирования вы навряд ли определите это заранее. Например, есть чат или комменты древовидной структуры, по тз комммент можно удалить, как при этом будет меняться дерево зависимостей постов в комментариях? И таких нюансов со связанными объектами масса.