Comments 7
Ещё интересный вариант в плане упрощения разработки — javascript(front) -> javascript-api(back), он же — прокси с валидацией в настоящий бэкэнд -> бэкэнд.
Собственно фронтэнд и бэкэнд полностью разделены, при этом использование JS в качестве прокси позволяет существенно снизить затраты на валидацию полей(собственно, объёмная часть АПИ и составляет корректная валидация и нормальные ошибки), т.к код для валидации един. Ну и там всякие разные бонусы, типа можно клиенту отдавать сразу готовый html(в совершенно идиотском случае если JS у человека не работает), что в случае с graceful degradation не должно особо отразиться на функциональности.
Собственно фронтэнд и бэкэнд полностью разделены, при этом использование JS в качестве прокси позволяет существенно снизить затраты на валидацию полей(собственно, объёмная часть АПИ и составляет корректная валидация и нормальные ошибки), т.к код для валидации един. Ну и там всякие разные бонусы, типа можно клиенту отдавать сразу готовый html(в совершенно идиотском случае если JS у человека не работает), что в случае с graceful degradation не должно особо отразиться на функциональности.
Действительно ли это будет упрощение разработки? Мы и понятие API вводим, и отдельный сервер-прокси на JS, код по сборке все этого счастья на клиенте. На первый взгляд кажется, что кол-во кода ощутимо увеличится, в довесок к введению новых сущностей. Не очень понятен профит, который мы получим, пойдя на такие трудозатраты.
Не путаете понятие «упрощение архитектуры» с «упрощением разработки»? Архитектура, понятное дело, слегка усложнится, т.к появляется дополнительный слой. Но по факту этот самый слой не видно(в идеальной ситуации, когда никаких задержек и ошибок этот слой не несёт) т.к вся его суть — провалидировать данные и пустить дальше, в ответе вернуть ответ от «настоящего бэкэнда».
Хз, возможно это чисто субьективно, но в текущем проекте я работаю на пару с бэкэнд-прогером и у нас веб приложение -> апи -> чёрный ящик бэкэнда(с моей стороны). Так вот, этот самый бэкэнд-прогер вместо того что бы заниматься своими обработчиками и бизнес-логикой, плюс чисто бэкэндовыми вещами(оптимизация нагрузки, стабильность и т.д) пишет всякую муть вроде валидации поступающих данных и корректными ответами на неправильные данные. Кроме того, всё это я уже написал на своей стороне, что бы обычный клиент не пропихнул левые данные. Правда на текущий момент мы всё же не ввели этот слой, т.к сроки поджимают, а изначально не задумывались. Но чисто как мыслительный эксперимент — решает текущие проблемы, с которыми мы сталкиваемся.
PS и трудозатраты не увеличиваются. По факту эта фича внедряется в любой бэкэнд, просто вместо запросов на index.php(к примеру) запрос пойдёт на урл, за который отвечает node.js, а после — в зависимости от реферера — пойдёт на нужное апи в «настоящий» бэкэнд. Одна функция, по факту.
Хз, возможно это чисто субьективно, но в текущем проекте я работаю на пару с бэкэнд-прогером и у нас веб приложение -> апи -> чёрный ящик бэкэнда(с моей стороны). Так вот, этот самый бэкэнд-прогер вместо того что бы заниматься своими обработчиками и бизнес-логикой, плюс чисто бэкэндовыми вещами(оптимизация нагрузки, стабильность и т.д) пишет всякую муть вроде валидации поступающих данных и корректными ответами на неправильные данные. Кроме того, всё это я уже написал на своей стороне, что бы обычный клиент не пропихнул левые данные. Правда на текущий момент мы всё же не ввели этот слой, т.к сроки поджимают, а изначально не задумывались. Но чисто как мыслительный эксперимент — решает текущие проблемы, с которыми мы сталкиваемся.
PS и трудозатраты не увеличиваются. По факту эта фича внедряется в любой бэкэнд, просто вместо запросов на index.php(к примеру) запрос пойдёт на урл, за который отвечает node.js, а после — в зависимости от реферера — пойдёт на нужное апи в «настоящий» бэкэнд. Одна функция, по факту.
А API от бэкенда торчит наружу (в Интернет) в вашем проекте?
Ну да. Можно посылать запросы к /api/название_апи, и чисто теоретически — написать свой фронт-энд, с преферансом и поэтессами.
Но в случае с прокси-прослойкой до «реального» бэкэнда не достучаться напрямую, только через проксю.
Но в случае с прокси-прослойкой до «реального» бэкэнда не достучаться напрямую, только через проксю.
Дык о чём я и говорю! Во фронт-енде по понятным причинам нужны валидации. В публичном API по тем же самым причинам — тоже нужны те же самые валидации. А затем, возможно, и на бекенде. Но заодно в API мы предусматриваем случай «бекенд недоступен», а во фронт-енде: «API недоступен». Всё это влечёт за собой дополнительный код, который я и назвал усложнение\удорожание процесса разработки.
Похоже мы просто друг друга не понимаем.
АПИ, по факту — это просто способ дёрнуть нужный функционал в бэкэнде(вот по такой вот ссылке находится такая функция, она принимает такие запросы с такими параметрами и возвращает такой ответ), это не конкретный модуль, это всего лишь способ получить нужный функционал. Теперь, вместо того что бы дёрнуть функционал напрямую — мы перенаправляем(на сервере, не на клиенте) все вызовы либо в общий модуль, занимающийся КОНКРЕТНО валидацией поступивших данных, либо в кусок кода на JS, который отвалидирует данные и отправит дальше, в «настоящий» back-end. Валидация этого плана — чисто формальная фича, типа «вот это поле — должно быть телефоном, вот это — мылом, а вон то — обязательно к заполнению». Если эта валидация проходит — дальше на такую фигню данные валидировать не нужно. При этом напрямую, в обход валидации на JS — до бэкэнда не достучатся.
Для чего такие сложности? Для того что бы реализовать фронт, провалидировать форму до отправки, а потом, на доверенном участке — провалидировать форму после отправки. Код един для фронт- и бэк-, просто бэку мы доверяем, а фронту — не очень. Код не пишется в итоге, он копипаститься с недоверенного на доверенное место.
По факту — это и становится «новым» апи, потому что все запросы проходят через него, и дальше — в быстрый и надёжный бэкенд.
В итоге схема остаётся прежней — фронт -> апи -> бэкэнд, всё методы остаются прежними и по такой ссылке остаётся необходимый функционал, просто данные проходят через призму валидации.
В итоге в схеме функционирования ничего не меняется, кроме того что появляется прослойка на JS, созданная для того что бы ускорить разработку бэкэнда.
Похоже что Вы просто рассматриваете АПИ как отдельный модуль, через который «ходят» запросы. В этом проекте АПИ(по крайней мере со взгляда фронт-энд разработчика, я не лезу в бэкенд вообще и для меня он просто чёрный ящик с доками) — просто ссылки по которым доступен определённый функционал, он выполняет только одну какую то свою функцию и функционирует независимо от других модулей, расположенных по другим ссылкам(на сколько мне известно). Т.е теоретически может отвалиться одна половина сайта, но исправно работать другая.
PS даже хз как ещё более подробно написать, дальше уже наверное нужно статью с примерами накатать.
АПИ, по факту — это просто способ дёрнуть нужный функционал в бэкэнде(вот по такой вот ссылке находится такая функция, она принимает такие запросы с такими параметрами и возвращает такой ответ), это не конкретный модуль, это всего лишь способ получить нужный функционал. Теперь, вместо того что бы дёрнуть функционал напрямую — мы перенаправляем(на сервере, не на клиенте) все вызовы либо в общий модуль, занимающийся КОНКРЕТНО валидацией поступивших данных, либо в кусок кода на JS, который отвалидирует данные и отправит дальше, в «настоящий» back-end. Валидация этого плана — чисто формальная фича, типа «вот это поле — должно быть телефоном, вот это — мылом, а вон то — обязательно к заполнению». Если эта валидация проходит — дальше на такую фигню данные валидировать не нужно. При этом напрямую, в обход валидации на JS — до бэкэнда не достучатся.
Для чего такие сложности? Для того что бы реализовать фронт, провалидировать форму до отправки, а потом, на доверенном участке — провалидировать форму после отправки. Код един для фронт- и бэк-, просто бэку мы доверяем, а фронту — не очень. Код не пишется в итоге, он копипаститься с недоверенного на доверенное место.
По факту — это и становится «новым» апи, потому что все запросы проходят через него, и дальше — в быстрый и надёжный бэкенд.
В итоге схема остаётся прежней — фронт -> апи -> бэкэнд, всё методы остаются прежними и по такой ссылке остаётся необходимый функционал, просто данные проходят через призму валидации.
В итоге в схеме функционирования ничего не меняется, кроме того что появляется прослойка на JS, созданная для того что бы ускорить разработку бэкэнда.
Похоже что Вы просто рассматриваете АПИ как отдельный модуль, через который «ходят» запросы. В этом проекте АПИ(по крайней мере со взгляда фронт-энд разработчика, я не лезу в бэкенд вообще и для меня он просто чёрный ящик с доками) — просто ссылки по которым доступен определённый функционал, он выполняет только одну какую то свою функцию и функционирует независимо от других модулей, расположенных по другим ссылкам(на сколько мне известно). Т.е теоретически может отвалиться одна половина сайта, но исправно работать другая.
PS даже хз как ещё более подробно написать, дальше уже наверное нужно статью с примерами накатать.
Sign up to leave a comment.
API First архитектура или рассуждения на тему: толстый сервер против тонкого