@Denioo

Что идет вначале Frontend или Backend?

Доброго времени суток.
Опыта в командной разработке нет, и поэтому интересно очень сильно узнать как оно работает в web программировании. Сам для себя я выбрал направления Backend.
Интересно узнать у Backend разработчиков как они взаимодействуют с Frontend разрабами? Ну например frontend сначала верстают сайт, а backend наполняют его логикой, или как?
Возможно вопрос глупый, но опыта работы в команде нет, и поэтому отсюда такие вопросы, летом планирую пойти в команию на стажировку по направлению backend хочется все разузнать как все работает.
  • Вопрос задан
  • 5019 просмотров
Решения вопроса 4
GavriKos
@GavriKos
Сначала идет ТЗ. Потом - протоколы взаимодействия. А потом - уже все равно, хоть одновременно и веб и фронт. Это в сферическом идеале.
Ответ написан
Комментировать
Moskus
@Moskus
Никакой стандартной последовательности нет.
Разработка может происходить параллельно и в любом порядке. В некоторых случаях, когда верстка делается на шаблонах, разработчики backend могут даже и не видеть frontend до момента первого запуска.
Ответ написан
Комментировать
AleksandrB
@AleksandrB
Совсем недавно вывел "Hello world"
Обычно работа идет параллельно. Фронтендер, если не готов бэк, может делать запросы к файлам на сервере, предварительно записав туда информацию. Если работа фронта стоит без бэка, фронт просит бэк сделать нужный метод, сам принимается за другой.
Никто никогда время не тянет, а то бы теряли громадные деньги.
В компании тебе все объяснят и о фронте ты думать практически не будешь.
Ответ написан
Комментировать
Robur
@Robur
Знаю больше чем это необходимо
Как договоритесь. Главное - чтобы работа шла эффективно.
В одном проекте сначала полгода можно пилить бек, потом за недельку фронт, в другом наоборот, в третьем нужна постоянная коммуникация и держать друг друга в курсе каждый день, и изменения могут быть первичны и в беке и во фронте.
Это если в команде хороший профессиональный уровень и взрослые люди, которые понимают зачем они там собрались. В реальной жизни можно встретить всякое, вплоть до истерик по поводу кто кому чего "должен" - и пока вы в конкретную команду не попадете, не узнаете заранее.

Так же есть разные специалисты - если это хороший фуллстек, и проект позволяет, то ему не составит труда пойти во фронт и бек и сделать сразу все что нужно. Если это монорепа это может быть вообще один коммит.

Так же есть разные методологии и подходы, например не разделение на фронт и бек команды а разделение на фича-команды. Когда одна команда пилит сразу и фронт и бек и что там еще нужно чтобы выкатить фичу в релиз.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@kolserdav
Как fullstack с 10 летним стажем, из них 7 лет в качестве хобби на PHP; HTML, CSS, JQuery и 3 года профессионально NodeJs; ES6, ReactJs, NextJs ++ Typescript, SCSS я сделал для себя вывод:

При современных требованиях:


При условии, что и там и там используются стандартные наборы библиотек, т.е. на беке например не нужно прикручивать какую-нибудь сишную библиотеку или на фронте не нужно пилить какой-нибудь особенный видеоплеер, то фронт в проекте, всегда раза в два, как минимум, сложнее, чем бек, это даже с учётом того, что все расчеты, которые без лишнего запроса можно сделать на беке - делаются на беке.

Чем фронт сложнее бека:


1. Разные среды исполнения. Сервер один и он под боком, а браузеров много и они где-то там.

2. Пользовательский фактор. На сервере управляется проверкой входных данных запроса, а на фронте надо учитывать всё: пользователь нажал Отправить и до прихода ответа нажал Создать страница перерисовалась, а ответ с Отправить не нашёл нужного блока (пример так себе, но неожиданное поведение пользователя учитывать нужно).

3. Логгирование. На сервере легко записывать в лог. На фронте придется делать авто отправку отчёта об ошибке на сервер, а промежуточные данные писать в sessionStorage и прикладывать к отчёту. А необработанные исключения на фронте ещё сложней ловить, почти невозможно или очень дорого.

4. Творческий фактор. На сервере всё сурово, отработал и гуляй, главное безопасно обработать данные. На фронте, помимо данных, часто некоторые визуальные эффекты вызывают неоднозначные эмоции, приходится их мять туда-сюда искать оптимальный вид чтобы не раздражать пользователя. А отсюда ещё вытекают дополнительные сложности по сдаче своего кода владельцу.

5. Требования к чистоте кода. Если на сервере будет неиспользуемый метод, то он будет занимать несколько килобайт памяти на диске и всё. А на фронте это плюс те самые килобайты к весу каждой первичной загрузки.

6. Жизненный цикл скрипта. На сервере всего две стадии: инициализация и запрос. На фронте сложнее и основных три: инициализация (подгрузка значений), рендеринг (отрисовка и навешивание обработчиков), эффект (внесение изменений с учётом дополнительных значений). Но это далеко не всё, если на сервере каждый компонент (API, роут), в плане жизненного цикла, изолирован от других, то на фронте ввиду его особенностей почти все компоненты являются вложенными в другие компоненты, поэтому, например: рендеринг дочерних компонентов может влиять на жизненный цикл родительских. Пример написан под влиянием React, поэтому термины могут подойти не везде, но всё равно, при любых методиках, вложенность компонентов, с пересекающимся жизненным циклом, на фронте всегда привносит дополнительные требования к безопасности.

Бекенд халява?


Конечно же нет! Бекенд это ответственнейшая часть приложения в плане обеспечения безопасной обработки и хранения данных. Но, как правило, основы безопаcности данных закладываются один раз при проектировании архитектуры, а далее просто наследуются. Также сложностями бекенда являются расчёты, сортировки, фильтры, запросы к сторонним ресурсам, вызовы сторонних сервисов. Плюс помимо взаимодействия, ещё сама архитектура базы данных чаще всего лежит на плечах бекендеров. Но это всё приятная рутина, в отличие от чудесных приключений на фронте)) Мне нравится разнообразие, поэтому я фуллстек. Надоедает засиживаться на чём-то одном.

P.S.:

По поводу "сложности библиотек", на мой взгляд, тут не зависит от края приложения.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы