Подробнее
Фронтендер, которого хвалят за красивую страничку.
1 mjC ] Хй i h toi í»]i]"Til
TTîTïïïïïïTîïï * 11 И a 7|i_j
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Картинку рисовал пользователь. Тут скорее не фронтенд, а именно сама HTML веб морда, дезигн, который видит юзер. А в самом коде пиздец, что на фронте, что на бэке. На фронте, думаю, похуже будет.
Ну, с этим я согласен, и плюс вам в карму. Скажем так, я работаю с такими глубинами глубин того, что работает везде, потому что наша электроника практически везде, что Кракен нервно охуевает от увиденного кода... и мы тоже, бо ну его нахрен к этому прикасаться... а мы прикасаемся в костюмах химической защиты, но работаем, дай нам БГ силы разгрести эти авгиевы конюшни :))
Ты украл мой комментарий.
Если фронты готовы работать за похвалу - штош. Кто я такой, чтобы судить их.
А мне, пожалуйста, оплату в грязных зелёных бумажках.
Бэкэндеру не приходится сраться с дизайнером за вон тот блок, который дизайнер нарисовал чтобы угодить привередливому клиенту, а реализовать его хуй знает как. Или не приходится объяснять что fullhd видео играющее на главном блоке на фоне - не лучшая идея с десятком слайдеров внутри слайдеров. И что вот этот блок из картинок выглядит красиво, но реализовать его нормально нереально.
Более того, в проектах с VUE/Angular и прочих это ФРОНТЭНДЕР пляшет под дудку БЭКЭНДЕРА чтобы выводить товары и прочую шляпу.
Как фуллстек, я хотел бы поплакать над первой частью сообщения и не согласиться со второй. Какие поля в макете нарисовали, то и отдаёшь (ну с поправками на GraphQL, который слегка упрощает задачу). Иногда ещё что-то доотдавать приходится, если фронт не простой, а с элементами бизнес-логики.
По третьей части сообщения - поскольку меня перекашивает в бэкенд, у меня обе части картинки выглядят как подводная.
Эта хуйня, которая тебе фронтендеру позволяет не ходить к бэкендеру и спрашивать названия полей. Эта хуйня, которая позволяет тебе генерить строго типизированные клиенты на твоём любимом typescript. Эта хуйня, которая позволяет тебе заказывать только нужные поля, а не весь объект со 100500 полями, из которых тебе нужен только id и title.
Там несколько сложнее всё, конечно. Грубо говоря, ты описываешь схему с типами данных, например "Пользователь", "Публикация". Для типов данных описываешь поля, например, "имя пользователя", "аватар" для "пользователя" и "название", "тело", "дата" для "публикации". Для каждого поля пишешь функцию, которая это поле может вернуть. На фронте, таким образом, ты можешь запросить, например сразу "пользователь.имя пользователя", "публикация.название", "публикация.дата", одновременно не вытаскивая в запросе ненужные "пользователь.аватар", "публикация.тело" и получая всё нужное, чтобы, например в списке статей это нарисовать.
как это противоречит мои словам?
этой хуйней пользуются только фронтенщики жаба скриптеры которые подумали что они бекендеры и юзают для написание простых сайтов
А я противоречил?
Для простых случаев как раз таки проще REST делать.
Вот про случаи использования, я бы сказал, что самый частый случай, который я встречал лично и про который мне рассказывали коллеги - это натянуть GraphQL поверх какого-нибудь древнего бэкенда, поскольку в нём уже настолько дохрена эндпойнтов (и полей в них), что какой-то ещё всунуть уже становится проблемой, а реализация какой-нибудь хитрой фичи на фронте требует отправить 10-20 запросов на сервер, что нихрена не быстро, особенно если сервер ещё и кучу лишних данных собирает/присылает.
Ни разу не вебер, прошу кэпа. Ведь на каждый возможный запрос, например, юзера, товаров, хз чего, нужно сделать какой-то обработчик в бэке, который сходить в базу и вытащит данные. Нельзя же автоматически делать запрос в базу на основе graphql с фронта, ведь это небезопасно, как я понимаю. А если с фронта придет "пользователь.покупки", то это какой-то джойн нужно делать.
Это не небезопасно, это дырень размером с галактику в безопасности.
Другое дело, что очень много где это неважно, исходя из принципа Неуловимого Джо. Очередной говносайт заказа очередной поебени просто ни малейшего смысла взламывать.
Ну естественно обработчики (resolvers) отдают, а не GraphQL. Бэкенд не куда не девается. GraphQL (дёргание одного эндпойнта с разными полями запроса для получения разных данных) - это замена механизма API (дёргание разных эндпойнтов для получения разных данных).
Бедняги бекендеры, не дали им поработать над вёрсткой для арабского, с юзерами IE и устаревшими файерфоксами, и мамкиными менеджерами у которых "где-то вёрстка поехала, пойди посмотри".
Так-то на беке тоже хватает ебейшего легаси, которое тоже надо саппортить. Лично сталкивался с банковским Ынтерпрайзом, которому было около 15 лет, это еще та бездна анального угнетения.
С бэком хотя бы уверен в каком окружении и на какой версии будет выполняться код, а не как на фронте что Array.sort может вернуть разный результат на разных браузерах(хром/файрфокс), в сафари CSS по-другому работает и вёрстка плывёт, на мобильном сафари что-то работает криво. IE вообще ад.
И вот это всё ещё на порядок тяжелее тестить, например JEST это синтетические тесты, было что утилита из lodash импортируется по-разному в тесте и в браузере, тест зелёный но в браузере не работает, в браузере работает но тест красный.
Плюс всё сложно с автоматизированными тестами для Сафари или IE, так что или ограничиться хромом и фаерфоксом или это отдельный гемор с селениумом/внешним сервисом.
Так что никогда не можешь быть уверен ни в чём.
Поинтегрируйся с банковской легаси системой, которая старше тебя и писана на Коболе, дружок-пирожок. На которой чуть более чем дохуя логики, в которой 1000+ таблиц с ебанейшими названиями полей а-ля ADVBO2.
интегрироваться это определенный скоуп работ. Ну да ты пострадаешь денёк-месяцок, потом сделаешь фасады и будешь жить спокойно (или уволишься - нафиг тебе такой проект надо?)
а на фронте куча работы всегда и везде, при чём, альтернатива коболу из 80-х там тоже есть в виде лапши из jquery и первого ангуляра.
Отличный комментарий!