Comments 10
Вообще выдавать ограничение за свободу это не правильно ("Запрет - это как раз свобода"©). Выбор фреймворков в экосистеме платформы или языка - это как раз свобода, кто-то их использует, кто-то нет. А не делать фреймворки, оправдывая это тем, что они "зло" - это пахнет выдачей желаемого за действительное.
Но ни в коем случае не могу ни опровергнуть, ни подтвердить тот факт, что фреймворки - это зло.
Обычно не использование фреймворка заканчивается изобретением своего собственного фреймворка, если проект разрастается. С которым в конце-концов так же приходится бороться.
Если учесть то, что стандарты веба никто толком не знает - получаются очень часто очень топорные решения. К примеру, видел тысячи проектов на Го, которые отдают в браузер и не удосужились сделать HEAD и OPTIONS роуты. Необходимость вручную думать про CSRF, XSS, правильные роуты в соответствии с REST (которые тоже никто не знает)... А во фреймворке это из коробки, он за тебя позаботился.
Из-за кажущейся свободы начинается полный зоопарк с http codes и error handling в API, структуры папок в которых надо вникать 2 недели после смены проекта, зоопарк решений для конфигурации.
То же самое относится к SQL - тысячи проектов с конкатенацией строк для запросов SQL, каша из функций, raw sql без какого-либо порядка в миграциях и дата-миграциях.
Дикий запад PHP в его худшие годы.
И ради чего? Чтобы "гипотетически" не сражаться с фреймворком, причем на том этапе где все и так начинают переписывать, рефакторить, разбивать на микросервисы?
Автор исходной статьи имел ввиду немного другое.
Приведу пример:
Допустим стоит задача разработать небольшой REST c n-ручками. В Golang есть выбор:
Можем взять сервер из стандартного пакета net/http;
Если понимаем, что нагрузка будет очень большая - можем посмотреть в сторону fasthttp/fiber и тд.
Идем дальше, нужен конечно routing:
Если скучно - можно написать самому? и как раз решать все нюансы с HEAD/OPTIONS/CSRF/XSS и тд;
Можно воспользоваться отдельными модулями для данной задачи - httprouter/gorilla и тд.
Куда ж без логирования - отдельный модули logrus/zap и тд.
Продолжаем, необходимо добавить метрики Prometeus + Tracing = берем отдельные модули
Нужно нам JWT - опять добавляем модуль + различные middelware.
Куда же без БД?:
Любим ORM - идем в GORM (использовать или нет ORM - это отдельный вопрос);
Хотим все контролировать и не боитесь SQL - sqlx.
Миграция - отдельный модуль или вообще можно использовать специализированное решение для этого https://flywaydb.org.
Таким образом, мы собираем нужный функционал из отдельных модулей - которые специализированно решают свою конкретную задачу. Лишних зависимостей в сервисе не будет при таком подходе. Я привел лишь примерный набор модулей - каждый сам выбирает нужное себе.
Обычно такие решения потом перерастают в корпоративный framework cо своей структурой и допиливаются под нужды организации (если мне память не изменяет - так как раз происходит в Авито).
И говорить:
Дикий запад PHP в его худшие годы.
С таким утверждением - не согласен, так как это уже работает в больших организациях)
Так же стоит отметить - что в Golang есть проекты, которые могут в той или иной мере подходить под определение framework:
Подход описанный автором - я не защищаю, а пытаюсь просто донести его основную мысль.
Если Вам комфортно работается c framework'ом и Вы не чувствуете проблем - то ок)
Главное: чтобы Ваша привычка к framework`у и его приятной экосистеме не привело к такому сценарию, что при реализации фичи - такого функционала не окажется в framework'е и Вы просто разведете руками и скажете нельзя сделать.
Вы забыли упомянуть об использовании Query-Builder’ов а-ля Squirrel, которые однозначно имеют право на жизнь!
А вот судя по ошибками, с которыми я столкнулся в GORM’е, на которых нет ответа, а Issue как висели без ответа, так и висят — я бы очень много раз настоятельно бы подумал еще раз, прежде чем его использовать в проекте, особенно если будет множество сложных, кастомных типов данных, которые необходимо будет брать из базы нестандартными запросами
К сожалению, велосипедостроение интересно и увлекательно, когда у вас "молодой развивающийся коллектив" который пилит никому не нужный стартап на чистом энтузиазме разработчиков, которым ввиду молодости и восторженности просто интересно кодить и строить архитектуру приложения с нуля. Бизнес так не работает - не может себе позволить риски связанные с безопасностью, со сроками, с незаменимостью сотрудников, имеет требования по документированию и так далее. Вы вполне можете ожидать, что человек имеющий в портфолио Spring более-менее безболезненно и быстро вольется в ваш Spring проект, поэтому такого специалиста вы и будете искать. На это будет заточен ваш HR и онбординг. Вам не надо чтобы Вася, наваявший ответственный модуль, пришел к вам за неделю до мерджа и сообщил, что он прочитал новый учебник и всё надо срочно пределать. Вам не надо, чтобы ваши сотрудники, вместо того, чтобы писать код срались какой подход лучше
Когда Ваш проект станет более сложным и Вы уже знаете - как Ваши
библиотеки работают вместе, Вы легко можете начать его рефакторинг.
Вот-вот, будет у вас бесконечный рефакторинг, а не развитие проекта.
Я не знаю что у вас за нагрузка, но обычно проблема фреймворков - не в том, что они не выдерживают нагрузку. Может для проекта мирового масштаба - это да - проблема. Но в России таких проектов очень мало, я думаю, что даже Wildberries и Ozon с их 100 миллионами посетителей в месяц могут позволить себе писать на фреймворке, а не на нативном go. Может не hot point точку куда делаются прямо все запросы, но очень много своих сервисов - могут (сервис оплаты, сервис личного кабинета, сервис доставки и т.д.).
Основная проблема фреймворков, что либо он забрасывается (или уходит из мейнстрима и все начинают писать на другом фреймворке) или выходит v2, v3, которые "ну надо переписать весь проект, потому что v2 это совсем другой фреймворк, полностью не совместимый с первой версией".
Пример фреймворка из Go: Gorilla Mux, раньше, когда я изучал Go мы прям изучали конкретно этот - популярный на тот момент фреймворк. Он прям был популярен, нам прям говорили - вот будете знать что нужно на рынке труда. А теперь - The Gorilla project has been archived, and is no longer under active maintainenance.
Для обработки HTTP goswagger очень понравился, жаль что он только OAS 2.0 поддерживает.
The Best Golang framework: no framework?