Большинство современных приложений (одностраничные веб-приложения, мобильные приложения и т. д.) состоят из двух частей:
Для соединения фронтенда и бэкенда обычно используется веб-API (REST, GraphQL и т. д.), что требует разработки API-клиента на фронтенд-стороне и API-сервера на бэкенд-стороне.
Имеем следующую архитектуру:
Благодаря архитектуре без API интерфейс может взаимодействовать с серверной частью без необходимости создания веб-API. Бэкэнд предоставляет функции (или методы), которые интерфейс может вызывать напрямую, и разработчику больше не нужно беспокоиться о URL-путях, методах HTTP или кодах состояния.
Конечно, поскольку фронтенд и бэкенд работают в разных средах, между ними обязательно есть API-клиент и API-сервер, но они больше не входят в сферу ответственности разработчика. Уровни API обрабатываются библиотекой или платформой.
Итак, архитектура без API выглядит так:
Удаление слоев API не только уменьшает объем кода, который должен написать разработчик, но и повышает качество за счет уменьшения разброса кода и дублирования знаний.
Растущее число библиотек и фреймворков позволяют реализовать архитектуру без API.
Продукт | Тип продукта | Тип API | Реальное время | Мобильная поддержка | С |
---|---|---|---|---|---|
Метеор | Рамки | процедурный | Да | Да | 2012 год |
Лейр | Библиотека | Объектно-ориентированный | На дорожной карте | Да | 2019 год |
Блиц.js | Рамки | процедурный | Нет | На дорожной карте | 2020 год |
тRPC | Библиотека | процедурный | В бета-версии | Да | 2021 год |
Телефунк | Библиотека | процедурный | На дорожной карте | Да | 2021 год |
Взносы приветствуются.
Прежде чем внести свой вклад, прочтите кодекс поведения и выполните поиск в системе отслеживания проблем, чтобы узнать, обсуждалась ли ваша проблема ранее.
Чтобы внести свой вклад, создайте форк этого репозитория, зафиксируйте изменения и отправьте запрос на включение.
Массачусетский технологический институт