Комментарии 50
0) Где собственно решается проблема высоконагруженного проекта?
1) Почему не монолит? У него есть только недостатки? Он не может работать под нагрузкой?
2) Почему RoadRunner?
3) Почему ReactJS?
4) Почему выбор только между MySQL & PostgreSQL?
5) Почему вообще для frontend именно REST API (как насчет GraphQL например)?
6) Что там с service-to-service communication?
7) Почему CycleORM?
… т.п.
PS. ссылка на репозиторий выдает 404
Пример который можно посмотреть и пощупать —
bitbucket.org/rumatakira/api-example/src/master.
Исправь ссылку на эту bitbucket.org/rumatakira/sampleapi/src/master. Та у тебя не рабочая.
Абстрактные классы без единой абстракции (AbstractCitiesApi кажется может быть просто заменен интерфейсом, зачем в конструктор что-то передавать — не понятно, оно не используется)
Наследник этого абстрактного класса CitiesApi переопределяет этот конструктор, выкидывая нафиг хоть какой-то DI через сервис контейнер (пусть и переданный напрямую) и используя include, КАРЛ! в 2020 году include в конструкторе! И так в каждом классе…
В коде фигурируют слова ORM, но вся работа с БД идет на массивах (хотя вроде бы даже есть типа модельки). Запросы формируются и выполняются напрямую в контроллерах
$userPassword = (key_exists('userPassword', $body)) ? $body['userPassword'] : date_default_timezone_get();Вот это отдельный прикол, даже если забить на ручную работу с данными запроса.
Половина статьи про генерацию из сваггера, но при этом в коде контроллеров не используются ни сами модели, ни валидация на основании схемы, ничего из этого.
Сделайте меня развидеть это, пожалуйста!
Прощу прошения, но в стате опсок, помарокъ, и пропущеных придлогов больши чем палезной информацыи.
Сложно хотя бы в Ворд запихать статью перед публикацией для прочистки подобного?
— архитектуру для высоко нагруженных проектов
— Когда проект еще в самом начале, и не то, что бизнес логика
— но и сама бизнесмодель
И это только первый абзац… Имхо, не в клавиатуре дело…
Ну а по поводу альма-матерей, думаю, некоторые из здесь присутствующих вполне себе пединституты поназаканчивали, что вообще не помешало им стать программистами, например, или электромонтерами.
Скажем, если вы публично опубликовали свою заметку, вы должны были заранее понимать, что «привязываться» будут. Если вы были к этому неготовы — у меня для вас плохие новости…
Микросервисы в данном примере это зло:
- вместо одного приложения вы предлагаете писать два (бекенд и фронтенд)
- вместо одного специалиста надо нанимать двух (бекендщик и генератор нечитаемой лапши на JS)
- вместо монолита, в котором можно кликами перемещаться по функциям и увидеть весь путь обработки запроса — писать микросервисы, между которыми кликами перемещаться невозможно
- отладка усложняется
- строк кода будет больше, так как добавляются накладные расходы
- предлагаете какие-то файлы копировать руками, ну и уродство, можно же наоборот, генерировать swagger из кода.
- если один монолит на PHP потреблял, условно, 50 Мб, то теперь 20 микросервисов потребляют по 50 Мб — в 20 раз выше стало потребление памяти
- если раньше была 1 БД, то теперь у вас 20 БД
- разворачивать всю эту систему сложнее и тяжелее, нужен суперкомпьютер, чтобы с ней работать
- накладные расходы на передачу данных между микросервисами выше, потому все будет тормозить
Вместо простых jQuery-скриптов предлагаете писать огромное приложение на Реакте с применение уродливого Redux, который все данные хранит в гигантских нетипизированных массивах? Вот так достижение. Не проще ли навести порядок в jQuery-скриптах?
Вообще, когда я слышу про реакт и SPA, мне вспоминаются тормозные приложения вроде сбербанка онлайн или киви. Которые с прелоадерами и долго грузятся. А ведь могли бы отдавать готовую, отрендеренную на сервере, страницу за 200 мс.
ввести нового программиста в команду было очень сложно, ибо не все рождаются Энштейнами.
Ну так в микросервисах и реакте еще сложнее будет разбираться. Кода там будет не меньше, просто он будет дальше разбросан. Вы только все утяжелили и усложнили и ничего не добились.
Разделить бизнес модель на сервисы и микросервисы, и не поднимать для этого весь БеЛаЗ, а обслуживать запросы микросервисов буквально в пару строк кода — самый банальный пример: похожие товары
Неверно. Вам придется поднимать все микросервисы, так как они все используются в проекте и без какого-то из них он может не работать. И если "Белаз" ел условные 50 Мб, то орава из 20 микросервисов по 50 Мб съест в 20 раз больше памяти.
Далее, если получение данных требует выполнить 10 шагов, то их в любом случае придется выполнить, хоть в монолите, хоть в микросервисе и переход на микросервисы не ускорит работу алгоритма. Как можно это не понимать?
Далее, как вы собрались писать сервис "похожие товары", если ему для работы нужна база данных с товарами, которая принадлежит сервису "товары"? Вы опять пишете чушь, невозможно сделать отдельными микросервисы "товары" и "похожие товары" — они должны быть в одном микросервисе, так как работают с одними и теми же данными.
Ваша статья — это просто неграмотная статья теоретика, который себе почему-то вообразил, что микросервисы будут работать лучше и быстрее, и не понимает, что это не так. Запомните, микросервисы используют в больших командах с большим количеством рабочей силы, чтобы эти рабочие сидели каждый в своей песочнице и не мешали другим, а не потому что они якобы быстрее и якобы легче.
страницу за 200 мс
Я с вами в основном согласен, но сервер должен отдавать страницу за 50мс максимум, 200мс это время за которая обычно спа делает запрос, полностью обрабатывает и рендерит.
Просто потом из готового YAML сгенерировал полностью рабочий и даже с middleware сервер.Как человек, который попался на это, предупреждаю, БЕГИТЕ, ГЛУПЦЫ. Все типовые шаблоны серверов на PHP у openapigenerator — лютое днище, местами вплоть до полной неюзабельности. Как пример в одном из шаблонов:
— модели DTO, у которых все поля private, при этом нет ни сеттеров/геттеров ни параметров конструктора.
— нельзя использовать насколько AuthMiddlware на одном роуте (хотя по стандарту можно)
— DI-интерфейс, который как бы по PSR, но при этом не совместим ни с чем
— «карта маршрутов» намертво зашиваемая в сервис-маршрутизатор
— есть механизм десериализации запроса, который используется в автотестах, но НЕ используется в основной библиотеке.
— код написан под PHP 5.3, поэтому возможности TypeHinting не используется вообще никак.
— ещё куча вещей, которые как бы есть, на по факту лучше бы их не было.
Если вам так хочется это использовать, лучше напишите свой шаблон, на это уйдёт меньше времени, чем разбираться со стоковыми.
PS: Всё выше сказанное не касается клиентов (они на всех языках в целом OK) и других языков, т.к. не проверял в бою.
Какое же г-вни-щe кругом цветет как в отрасли, так и в головах.
А этот незабываемый стиль повествования:
«в моем API под капотом %фреймворк% и %перечень_аббривиатур_непонятной_х% поддерживающих стопицоты стандарт %имя_разработки% обернутых в докер и %еще_куча_слов%»
и обязательно вставить про какие-нибудь параллельные вычисления, нейросети, высокую нагруженность и квантовое животноводство…
А по факту — очередная пустышка, которая слеплена хз как, без документирования. И на какой-нибудь хелловорлд тянущая десятки мегабайт всякой хрени. До жути костыльная и по любому поводу превращающаяся в тыкву.
Зачем нам думать, оптимизировать, разбираться в основах. Мы натянем сову на глобус!
Больше фреймворков богу фреймворков!
примерно такие вот основные тенденции.
Да нормально отлаженное приложение и фронт и бэк, написанное спагетти кодом на какой-нибудь 5 php будет лучше справляться с нагрузкой, чем стопицот ваших модных фреймворков.
Вы серьезно предлагаете отказаться от SPA и генерить html на сервере? Но не кажется ли вам, что такие проекты могут поддерживаться исключительно fullstack-разработчиками, потому что в них фронтенд и бэкенд зачастую переплетены? Минусы такого подхода заключаются в том, что один разработчик должен и серверный язык знать, и в базах данных круто шарить, и хорошо понимать фронтенд-разработку, а также хорошо верстать. Не существует разработчика, который может на сильном уровне освоить все эти технологии. На это просто не хватит времени. В SPA сайтах можно распределять обязанности между разработчиками разных направлений, где каждый хорошо знает именно свою специализацию.
сайт гуглом индексируется медленно
Эта проблема давным-давно решена. Есть NextJS, который без проблем осваивается и прикручивается к React-проектам. Всё отлично Гуглом индексируется. И не только Гуглом, кстати, потому что поисковому краулеру в таком случае JS выполнять не нужно. Минус только в том, что SSR, говорят, достаточно медленный, но никто не запрещает результат рендеринга класть в кеш.
Вместо простых jQuery-скриптов
Что касается jQuery, то какой смысл использовать вообще эту библиотеку в 2020? Большая часть её функциональности поддерживается браузерами по умолчанию. Где, вы, кстати, видели простые jQuery-скрипты? Обычно это неподдерживаемая и нечитабельная лапша кода, которую писал условный Вася фуллстек-разработчик, который даже про замыкания в JS не слышал, потому что больше бэкендер.
Минусы такого подхода заключаются в том, что один разработчик должен и серверный язык знать, и в базах данных круто шарить, и хорошо понимать фронтенд-разработку, а также хорошо верстать.
Что-то вы утрируете. На примере симфонии: бекенд разработчик занимается бекендом, фронтенд — шаблонами, стилями и JS. И действует такое же распределение обязанностей, только у фронта twig вместо React/Vue/Angular/etc
В не идеальных условиях настройка react приложения может занять гораздо больше или как минимум не меньше времени чем настройка проекта на laravel например. Тут на мой взгляд сравнивать бесполезно. В идеальных условиях все же используется CI/CD и никто не париться с настройками окружения.
По теме топика, нужно понимать — где, когда и для чего нужно разделять бек и фронт, или пилить все на микросервисы. Генерация из swagger конечно круто, но гораздо эффективней разработать документацию, написать самому и просто поддерживать доку в актуальном состоянии. А еще лучше использовать Postman, потому что сразу можно писать тесты, но это дело вкуса.
может занять гораздо больше или как минимум не меньше времени чем настройка проекта на laravel например
Но это же не так. Если фронтендер разворачивает привычный ему джавоскриптовый проект, ему не нужен интерпретатор php/python, не нужен Redis/Memcache, не нужны очереди и конфиги сервера, не нужны базы данных и дампы. Вместо запросов к серверу он использует заглушку, а всё остальное ему не нужно. Тем более, что есть для этого готовые решения, которые позволяют сделать заглушку сервера на основании того же OpenAPI (Swagger). Это в разы проще, чем поднимать у себя сервер, являясь фронтенд-разработчиком, разве нет?
В идеальных условиях все же используется CI/CD и никто не париться с настройками окружения
Для деплоя проекта на сервер — используется. Но это никак не поможет фронтенд-разработчику развернуть проект на своём компьютере для работы.
Генерация из swagger конечно круто, но гораздо эффективней разработать документацию, написать самому и просто поддерживать доку в актуальном состоянии.
Вообще-то нет. И руками Swagger мало кто пишет — этот тип документации генерится на основании кода. Вот пример для Symfony. Есть аналог и для Django, скажем. Писать руками и поддерживать в актуальном состоянии куда тяжелее и дольше, чем просто генерить. Тем более много вы видели проектов, которым больше 5 лет, и у которых документация, написанная руками, находится в актуальном состоянии? Я — ни одного. А вот из Swagger генерить проекты (в обратную сторону) — это лишнее, согласен.
И руками Swagger мало кто пишет
Ну про мало кто я бы тоже не говорил. Мы, например, давно пользуемся spec first подходом и я думаю это актуально во многих крупных проектах. Когда все заинтересованные стороны сначала обсуждают спеку, которая, понятное дело, написана руками, т.к. кода еще нет, а только потом начинают разработку (копаем с нескольких сторон сразу).
Это достаточно удобно когда есть микросервисы и распределенная разработка в них.
Но да, это другие подходы к разработке, поэтому может быть не так широко распространено в открытых источниках.
На практике чтобы с этим работать, фронтендеру зачастую нужно у себя локально разворачивать весь проект целиком со всякими докерами
Да вы что. А проект с микросервисами, что, разворачивать не требуется? Тоже требуется, только вместо одного приложения там их 20 штук, и нужен суперкомпьютер, чтобы это все не тормозило.
Вы предлагаете усложнить жизнь бекендщику, которому вместо одного простого приложения теперь нужен докер и суперкомпьютер. И ради чего? Ради какого-то инвалида-фронтендщика, не умеющего пользоваться шаблонизатором? Выгнать этого инвалида и взять нормального, если он не хочет изучать шаблонизатор.
И насчет "заглушек" — кто их будет писать и поддерживать? Бекендщик что ли? Ему некогда, он делом занят. Проще взять фронтендщика, который умеет пользоваться шаблонизатором, чем возиться с микросервисным монстром.
И работают SPA медленно. Твиттер, киви, сбербанк — все тормозят.
И насчет «заглушек» — кто их будет писать и поддерживать
Нет, их сделает для себя фронтендер. Заглушка — это просто json-объект, имитирующий ответ от сервера и всё. Там нечего писать, это работа на 10 минут. Кроме того есть автоматические заглушки, которые работают на основании OpenAPI документации, выше я ссылку оставлял — это ещё проще. С этим вообще никаких проблем нет совершенно.
Выгнать этого инвалида и взять нормального, если он не хочет изучать шаблонизатор
Опять-таки вы говорите о другом. Чтобы фронтендер мог пользоваться шаблонизатором и верстать, ему нужно у себя локально развернуть бэкенд и в базу залить дамп. И сложность тут именно в этом, потому что далеко не все фронтендеры это могут сделать.
И работают SPA медленно
Vk, Facebook — это тоже SPA. Медленно работают? По-моему, нет. А вот Bitbucket — не SPA, а лагает весьма заметно.
Но это же не так. Если фронтендер разворачивает привычный ему джавоскриптовый проект, ему не нужен интерпретатор php/python, не нужен Redis/Memcache, не нужны очереди и конфиги сервера, не нужны базы данных и дампы.
Если разработчик (любой) разворачивает новый проект, ему достаточно запустить одну команду — vagrant up, docker-compose up или просто поднять виртуалку/сервер из снапшота, так же одной кнопкой.
Для деплоя проекта на сервер — используется. Но это никак не поможет фронтенд-разработчику развернуть проект на своём компьютере для работы.
Есть достаточно команд, где на локальной машиной разработка не происходит. У меня в одной из команд инстанс для разработки разворачивался автоматически после первого коммита.
Вообще-то нет. И руками Swagger мало кто пишет — этот тип документации генерится на основании кода.
Тут ниже (выше) уже написали и я согласен. Часто документация пишется вперед и поддерживать ее на самом деле не так сложно.
Когда разработка идет полностью параллельно, например при "spec first", фронт в самом начале используется мок сервер который предоставляет Swagger или Postman. Не зависимо где он пишет. Я ответил ровно наш комментарий где вы написали
Если фронтендер разворачивает ПРИВЫЧНЫЙ ему джавоскриптовый проект
Это подразумевает что он его досконально знает, у него есть готовые кофиги и т.п. Запуск в две команды — склонировать скелетон и запустить сервак. То же самое с любым современным php фреймворком.
Если мы говорим про полностью новый проект, как написал выше, настройка вынесенного фронта займет не меньше времени чем настройка бекенда(под этим мы подразумеваем какой нибудь монолит с шаблонизатором).
Вот как раз для эффективного разделения фронта и бэка полезно писать спеку API. Я, как лид, написал и раздал подкомандам бэка и фронта на реализацию.
фронтендеру зачастую нужно у себя локально разворачивать весь проект целиком со всякими докерами (или установкой PHP/Python и всей обвязки на локальную машину вручную) и разворачиванием дампов базы
Ужас какой — пнуть скрипт и подождать…
Скрипт не работает? Ну это просто бекендер просто плохо работу сделал…
Под Виндой и МакОСю скрипт тоже будет работать
Контейнеризация, де факто, стала универсальным инструментом на подобные случаи. Какой-нибудь docker-compose вполне себе инструмент. Если фронтендер не юзает docker-подобные инструменты — он сам себе злой буратино и ленивая жопа.
На небольших проектах элементарного docker'а хватит за глаза, конфиг пишется за час — просто потрать, сэкономишь миллион времени. На больших проектах деплой рабочей среды — тоже вполне себе задача, и ей заниматься надо, документировать, сопровождать.
нда, батенька.
бизнеслогика (взаимоотношения с базой данных)
… и стало очень грустно
А остальные будут огрызаться на комментаторов и не станут принимать критику адекватно.
ну так напишите статью — с вашими семью годами опыта должно быть не сложно.
и комментарии проверять больше не будут, да и покажете другим — вот как надо. а то не мешки ворочать все горазды.
автор статьи написал хоть что-то. я с ним не согласен, мягко говоря, но он потратил время и благодаря этому повилась статья, где в комментариях люди пишут интересные идеи и общепринятые практики.
напишите и вы — либо вы пополните хабр интересной статьей, либо в комментариях почитаем почему так делать не стоит.
Поэтому пока без генераторов, зато удобно и понятно, пишу апишки на комете: github.com/gotzmann/comet
Я сравниваю с тулингом Ламоды, там много поверх го-сваггера наработано, там действительно удобно вести разработку в парадигме specification first
В идеале конечно надо потратить время и адаптировать шаблон под ваши нужды (и не менять сгенерированный им код после). SOLID в полный рост на самом деле. Нужно написать такой шаблон генерации, в который можно будет потом вставить свою бизнес-логику без изменений результата генерации
Когда меняется сваггер-спека и перегенерится проект — убивает все прошлые наработки.
Вы, может быть, невнимательно доку прочли… Оно генерит набор файлов — эндпоинты, валидация и т.д. и т.п. И один из сгенеренных файлов — инициализация — генерится только в том случае, если этот файл отсутствует. Там методы определения мидлварин и биндинг апи-методов к вашему сервису. Эти «прошлые наработки», например, не убиваются.
У меня не получилось генерить то, к чему я привык в Ламоде :) Может, привык к хорошему.
Т.е. в качестве альтернативы вы предлагаете все делать «ручками»? Ок.
Не согласен на компромисс когда поправив спеку на 10% придется переписать условно 20% и добавить еще 30% кода чтобы все снова заработало
Собственно, поправить спеку и не делать ничего вообще — не бывает. Если вы спеку правите, видимо, что-то должно измениться, иначе нафига ее вообще правили? А по процентам — странная какая-то у вас пропорция. Если вы перепишете спеку на 10%, инициализацию вы перепишете ровно на те же 10%. Какой объем правок понадобится в собственно в сервисе для того, чтобы заработала новая функциональность — это штука явно ортогональная объему исправлений в спеке.
Создание современного API на PHP в 2020 году