17. Двухзвенная архитектура
"Толстый" клиент
высокие требования к производительности клиента
работа в разных окружениях
высокие требования к серверу (если он один), как
следствие плохая масштабируемость
21. Требования
Возникла большая нагрузка, понадобилось делать
кеширование
Возникла сложная логика урлов, утяжеляющая БД
Понадобилось заменить клиент или добавить другой с
отличающимся функционалом (к сайту добавить
мобильное приложение)
23. Разделение на звенья
Основной принцип - каждое отдельное звено
можно заменить не меняя другие
Например:
замена или добавление клиента
замена БД
изменение фронтенда (например замена
шаблонизатора)
28. REST
Универсальный интерфейс доступа к ресурсам и их
изменения. В случае веба HTTP методы запроса
указывают на тип взаимодействия.
GET /book/117 – получение ресурса
POST /create/book?title=...&... – создание ресурса
DELETE /book/117 – удаление ресурса
UPDATE /book/117?title=... – редактирование ресурса
29. REST
Важные особенности
• кеширование (на уровне протокола или сервера)
• stateless (нет промежуточной информации на
сервере)
• возможность использования между любыми двумя
звеньями (клиент-фронтенд-бэкенд)
34. Семантика запросов
Существуют разные подходы к предмету запросов
вызов больших методов ("ручек"), которые хорошо
знают конечную структуру страниц
вызов более мелких методов API со стороны бэкенда
35. Большие методы
Знают что надо, например getIndexPage
Плюсы - скорость
В чем выигрыш по скорости?
36. Большие методы
Знают что надо, например getIndexPage
Плюсы - скорость
экономия на общении фронтенд-бэкенд (по сути это
двухзвенная архитектура)
меньше нагрузка на базу данных
37. Большие методы
Минусы
Теряется гибкость разработки, при любом изменении
требуется работа специалиста бэкенд и фронтенд
Упомянутые недостатки двухзвенной архитектуры -
если добавится (изменится клиент) надо делать новые
ручки
38. Backend API
Делаем небольшие ручки на каждый тип ресурсов (REST
или RPC)
Теряется скорость, добавляется гибкость.
39. Итоги: выбор архитектуры
Все исходит из задачи
По сути звеньев можно выделить сильно больше
клиент - http-сервер - фронтенд - управление базой
данных - база данных
плюс балансеры для распределения нагрузки
40. Выбор архитектуры
Важно, что разделение на части позволяет
специализировать людей, проводить независимые
изменения, масштабировать команду
41. Выбор архитектуры
Важно, что разделение на части позволяет
специализировать людей, проводить независимые
изменения, масштабировать команду
Скорость разработки важна, по сути это эффективность
нашей работы
42. Выбор архитектуры
Важно, что разделение на части позволяет
специализировать людей, проводить независимые
изменения, масштабировать команду
Скорость разработки важна, по сути это эффективность
нашей работы
Но иногда задача диктует требования, решение которых
приводит к усложнению жизни разработчиков