Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 29
я просто не смог за час поднять MySQL локально
really? кажется это мог сделать любой эникейщик из времен LAMP
Подробностей уже не вспомню, но была ошибка, которою сходу устранить не смог. Поэтому просто с 0 развернул strapi, поставив галочку напротив mongodb. Тогда для меня большой разницы между этими БД не было, главное чтобы работало.
в 99% дистрибутивов это ставится как yum/apt install mysql/mysql-server. все что надо сделать. и 20 лет назад так же работало.
С высоты опыта всё кажется простым. Но суть статьи именно в трансформации мышления.
Когда ты всю жизнь мыслишь категориями npm install и import Component, необходимость конфигурировать базу данных вызывает ступор. Это сейчас я понимаю, что это базовые знания. А тогда это была магия.
И да, эникейщик бы справился быстрее. Но я не эникейщик, я инженер, который учился на своих ошибках. И эта ошибка стоила мне нервов и бессонных ночей, зато теперь я знаю цену своим решениям.
Просто вот именно в этот момент уже нужно было задуматься: "А достаточно ли у меня компетенций, чтобы сваять бэкенд? Если я даже СУБД развернуть не могу."
Видимо это было давно? На сегодняшний день Strapi поддерживает только реляционные БД
Хм, вполне нормальная история, "медленная база / быстрый кэш" - это самый обычный паттерн для бэкэнда. О деталях, конечно, можно подискутировать, но в целом все рамках средних по больнице. А так - все лажают по неопытности, не вижу причин посыпать голову пеплом или считать что бэк - это совсем отдельная сфера. Вы так говорите, будто война за производительность - это исключительно прерогатива бэка, но и там и там применим тот-же самый асимптотический анализ сложности, а это основа вообще для любого разработчика.
Теория одна – согласен, но «бытовое» применение отличается. Фронтенд чаще бьется за FPS и перерисовки, а бэкенд – за IO и память.
По моим наблюдениям, переключиться именно с фронта на бэк особенно сложно. Теряется привычная визуальная опора, меняется сама парадигма: от событийной модели UI к транзакциям и работе с данными.
Инерция мышления тут часто играет злую шутку: разработчики по привычке пытаются перенести UI-паттерны в бэкенд-архитектуру «один в один».
Я бы поспорил. На мой скромный взгляд, лучшие инженерные решения рождаются из пересечения компетенций, и в данном случае это именно фронт и бэк. Переносить какие-то паттерны и ментальные модели с фронта на бэк - не такая уж плохая идея, если вы знаете что делаете. И использование общей кодовой базы как и инструментов окружения - это ОЧЕНЬ ценный момент, чтобы от него просто отмахнуться. Помимо этого, бэк - это такая же сегментированная область, как и фронт и там и там вы можете встретить транзакции (как минимум IndexedDB) и большие данные летающие по вебсокетам в дэшбордах реального времени... как и генерацию статических ассетов на сервере, для которой не так важна максимальная оптимизация по IO. Развитие разработчика в сторону фуллстека - это никакая не ошибка, а самый правильный, на мой взгляд, путь для любого, кто хочет стать специалистом выше среднего.
Согласен про пересечение компетенций. Знать (а лучше уметь) всё – полезно.
Но давайте честно: сколько таких специалистов «выше среднего», о которых вы говорите? 5%? Моя статья про остальные 95%, которые приходят на бэкенд с ментальностью npm install и «оно само соберется».
Фронтендер привык думать категориями: «Как это выглядит? Быстро ли отрисовалось? Удобно ли пользователю?».
Бэкендер должен думать: «Что будет при параллельных запросах? Как это мигрировать через год? Выдержит ли база?».
Когда ты приходишь на бэк со старой «фронтендерской прошивкой», ты инстинктивно оптимизируешь не то. Ты делаешь красивый API, но забываешь про транзакции. Ты кешируешь всё подряд ради скорости, но получаешь неконсистентность данных.
Фуллстек – это круто, когда ты переключаешь этот тумблер в голове. А я его переключать даже не умел, просто не было соответствующего опыта. Я попал в те 95%.
Выглядит как история про неправильно спроектированные эндпоинты.
Вываливать все данные без пагинации, да еще и со всем вложенными сущностями - это уже не ок. Да еще и без оптимизации кверь (в джанге это select/prefetch_related)
e кластером на обычном 10G Ethernet. Думал: "ну API же, что сложного". Забыл про то, что GPU батчи создают неравномерную нагрузку, и при спайках трафика начались таймауты.
Redis спас вас, это правда. Но есть подводный камень с инвалидацией кэша. Если маркетолог обновляет контент, нужно сбросить кэш. У вас как это решено? Вручную или есть хуки на Strapi updates?
«Ну API же, что сложного» – это вообще девиз, который надо писать на надгробиях проектов. Батчи и спайки нагрузки – это как раз то, о чем фронтендер обычно не думает (у нас же Event Loop, оно само разрулится).
Про кэш:
Сначала хотел сделать «умную» инвалидацию через хуки Strapi (onUpdate -> clear cache). Но быстро понял, что задача усложняется связанными сущностями (обновил новость -> надо сбросить кэш списка новостей -> и кэш главной).
В итоге пришел к самому надежному (и стыдному) решению: кнопка «Сбросить» в админке. Маркетинг сам решал, когда им нужно обновить данные. И это сработало лучше любой автоматики)
Ой, да вы и фронтенд как попало делаете)
И иногда, чтобы стать настоящим фулстеком, нужно перестать думать, как декоратор, и начать думать, как инженер.
Достаточно просто начать думать, а не выдумывать всякую фантастически фэйковую поучительную нейрослопохрень.
Тут кто-то говорил, что нельзя разделять back и front, мол это всё одно и то же. Я абсолютно не согласен. Я, начинавший с бэкенд, пощупавший front понимаю, что можно на одном языке для back (например Python Django) построить фронт, как и наоборот. Это, с одной стороны, удобно, но ограничивает в некоторых специфичных кейсах.
Ну например, на языке фронта минимально что-то похожее на pytorch и других библиотеках ИИ (к примеру computer vision) вряд ли построить, а на языке бэкенд вряд ли можно построить что-то похожее на анимации и поведение в зависимости от действий пользователя, как это делает красивый классный Javascript в связке с CSS.
В общем и целом - и там и там инженеры, база одна, ОС одна, но как только коснись нюансов - пошло поехало
Перейдя с бекенда на фронт(некст), у меня возникает ощущение, что этот фреймворк проектировали верстальщики которые бэк в глаза не видели, у меня нет других оправданий того, что на многие моменты положен огромный болт.
Я заметил, что чертовски часто (на 5 коммерческих проектах из десятка на которых я работал за всё время) - люди начинают придумывать сописный конструктор, для сборки интерфейса из блоков. И что ещё интереснее - за все 5 проектов не было ни одного, где этот конструктор был бы оправдан бизнес целями и не обходился в обслуживании дороже, чем линейная разработка фичей.
Вот эту закономерность интересно было бы изучить)
История отозвалась не болью, а улыбкой)) но потом вспомнил, как я приходил к пониманию разницы бэк/фронт. Не так трагично, не через поломанный релиз, а просто на интуиции, что не может нода нормально отрабатывать на множестве запросов, иначе уже весь интернет сидел бы на такой "вкусняхе" вместо lamp & variations. Ну и то, что в реактивность фронта входил уже после статики сыграло свою роль, фактически стек бэка уже был
Вы придумали заново Backend Driven Ui, но слишком наивный. В этом нет ничего плохого, но это надо «докручивать» и странно, что вы сразу заразили (если я правильно понял) а не прогнали на тестовом стенде хотя-бы. Вот скорее всего проблема не в мышлении, а в том что это не проверено. Особенно на специально утрированных кейсах, которых у вас не будет, но вдруг…
Ну чел боже, ты с самого начала задумал проект как один большой костыль.
Я никогда бек не знал, взял за стек next.js (фронт + сео) + drizzle.orm (бд) + next.js server actions (для бека). С первого же раза написания Бека, написал ее практически идеальной, с нужными схемами и связями.
Хотя эндпоинты сводились к тому что просто записать-отдать, проект я написал в максимально сжатые сроки. Да и сервис не предназначается для высоконагруженного сервиса. Это просто сервис для строительной компании узкой специализации. Зато скорость разработки, качество (для своей задачи) и проще в деплое
Проблема в том что весь современный фронтенд такая же тормозная лажа. Потому что для фронтендеров кругом магия :)
Ну окей, вложенность сильная, рекурсивные запросы. А что, индексы не помогли? Почему запросы такими долгими были? Или там было прям очень много запросов одновременно? Имхо база справится спокойно, если корректно индексы настроить.
Знакомо, я как бек попадал разок на проект написанный фронтами, очень похоже
MongoDb, гигантские json-ы которые отдают ручки и они лежат прямо собранными в базе, поиск, по атрибутам прям сплошняком по этим сущностям внутри базы ...спасало только то что данных по счастливой случайности было не много...прям обнять и плакать..
Есть гипотеза, что "разница в мышлении" между фронтом и бэком — лишь следствие. Настоящая разница в мышлении — гораздо глубже. И корень проблемы лежит в отсутствии фундаментальной (математической и инженерной) подготовки. Или, скорее, культуры.
Всё остальное — лишь следствия. И даже "скучная теория" (по которой зачастую бездумно, но и даже так всё реже) гоняют на собесах — не такая уж скучная (если в теме) и даже не совсем теория (скорее, частные случаи настоящей теории)… Но судя по тому, куда движется образование, подобные описанном случаи — только цветочки. Скоро вообще имитация интеллекта подтянется, вот тогда только и начнётся всё самое интересное :)
Семь?
А вот я вспоминаю достаточно частые случаи у меня которые сводятся к:
открываю сайт на русском из ленты гугла на андроиде
сначала мы грузимся, секунд 5-7 (вообще белый экран или анимация чья то)
потом показываем капчу (в лучшем случае - уровня нажать галочка), причем врут что это для моей безопасности
открылось, можно начать читать - взлетает полноэкранный баннер,
затыкаешь его - еще снизу баннер занимающий немалую часть экрана и он не затакается
дизайн разумеется НЕ адаптивный(масштабирование жестом авторы сломали)
И в лучшем случае - ссылка уходит в телеграм-канал где у меня общая свалка с целью открыть с комьютера с нормальным экраном, каналом и полноценными блокировщиками
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я строил бэкенд с ментальностью фронтендера: история одного провала