Некоторые пользователи сети спросили: «Я слышал, что разделение фронтенда и бэкенда позволяет фронтенд-персоналу сосредоточиться на фронтенде, а бэкэнд-персоналу сосредоточиться на бэкенде, но если проект относительно простой и над ним работает всего несколько человек, есть ли смысл разделять фронтенд и бэкенд?

Сегодня мы пригласили 4 передовых и внутренних инженеров технологии на основе Дао, в сочетании с их собственным опытом работы над проектом, чтобы поделиться с вами некоторымиИх краткое изложение фактического опыта фронтенда и бэкенда небольших проектов., надеюсь, что смогу вам помочь.

01 Сямэнь Технология - Никуи

Требуется ли для небольшого проекта разделение клиентской и серверной частей, зависит от того, какой метод может «выполнить текущие бизнес-требования в кратчайшие сроки и с наименьшими затратами».

Бессмысленно говорить об этом в отрыве от реальной сцены, ведь выбор технической архитектуры должен служить делу.

Насколько мал этот небольшой проект? Как долго длится его жизненный цикл? Является ли это временной системой, которая будет существовать только в течение очень короткого периода времени, или в обозримом будущем она может расшириться до более крупных проектов? Сколько технических специалистов поддерживает этот небольшой проект? Что это за технические работы? Это все моменты, которые нужно учитывать.Требуется ли для небольшого проекта разделение клиентской и серверной частей, зависит от того, какой метод может «выполнить текущие бизнес-требования в кратчайшие сроки и с наименьшими затратами».

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

Конечно, вернемся к настройке фона, выбор по-прежнему зависит от реальной ситуации разработчиков вашей команды. Например, если у разработчика всего один PHP-инженер, и он не знаком с современными front-end фреймворками, он обычно разрабатывает PHP-страницы, а HTML/PHP/JS смешиваются между собой. усилить разделение переднего и заднего конца.

Однако из приведенного выше примера описания можно обнаружить, что ситуация, когда передний и задний концы не разделены, уже является относительно устаревшим способом производства. Сегодня, основываясь на опыте автора, даже если это школьная студия, чтобы начать бизнес, они изо всех сил стараются завершить проект за счет совместной работы нескольких технических специалистов. Даже если один человек разрабатывает несколько заданий одновременно, метод организации кода в основном отделен от фронтенда и бекенда. Хотя чрезмерное проектирование является запретным местом в архитектуре, было достаточно практики, чтобы доказать его превосходство с точки зрения разделения внешнего и внутреннего компонентов.

В качестве фронтенда веб-фреймворки Node.js, с которыми я столкнулся, представляют собой все принципы проектирования разделения фронтенда и бэкенда и даже классический язык, который не разделяет фронтенд и бэкэнд. , Laravel, один из самых популярных веб-фреймворков на PHP, также рекомендуется использовать современный интерфейсный фреймворк Vue.js для завершения разработки страницы. Причина в том, что сложность современных фронтенд-технологий, от инженерной архитектуры на стадии разработки до различных мер по оптимизации для повышения производительности страницы, не подходит для сопряжения с бэкендом.

Таким образом, наш вывод остается прежним: необходимость разделения клиентской и серверной части зависит от того, какой метод может «удовлетворить текущие потребности бизнеса с наименьшими затратами времени и средств». Конечно, учитывая реальную ситуацию, разделение front-end и back-end — более общий, продвинутый и разумный способ.

Иными словами, более популярный метод разработки приложений, интегрированных в облако, кажется, противоречит разделению клиентской и серверной частей, но на самом деле основные принципы остаются теми же. С помощью Serverless фронтенд-инженеры могут получить права на более глубокую обработку данных за счет сосредоточения внимания на интерфейсном интерфейсе пользователя, который в некоторой степени является более эффективным методом разработки. Что касается параллелизма, расширения, эксплуатации и обслуживания сервера и т. д., которые больше ориентированы на серверную часть, то решать их остается на усмотрение бессерверного контейнера. Это также практика разделения фронтенда и бэкэнда. Автор считает, что в небольших проектах можно смело пробовать облачную разработку.

02 Технология Сямэнь - Истребление Тысячи

От пользователя Независимо от того, отделены ли интерфейс и сервер от трех аспектов опыта, эффективности разработки и эффективности эксплуатации и обслуживания.

Я думаю, что в большинстве случаев разделение клиентской и серверной части лучше, чем отсутствие разделения.

Далее я проанализирую, отделены ли интерфейс и сервер от трех основных сценариев: взаимодействие с пользователем, эффективность разработки и эффективность эксплуатации и обслуживания.

Пользовательский опыт

Если вы делаете систему заказов магазина, самые основные требования пользователей к системе — это красивый интерфейс и быстрая скорость загрузки. Для таких проектов, которые сосредоточены на интерфейсных эффектах, если используется традиционный интегрированный интерфейс и серверная часть проекта, если нет профессиональных программистов на стороне сервера, обычные программисты на стороне сервера не могут реализовать сложную логику взаимодействия с интерфейсом через JSP. , А добавив к нему богатые темы и динамические эффекты, есть большая вероятность, что пользовательский интерфейс нарисован Porsche и разработан Xiali. Вы можете представить себе стиль сайта 10-летней давности. С точки зрения скорости загрузки, т.к. все ресурсы размещаются на стороне сервера, для первой загрузки нет кеша браузера, а нужно загружать большое количество js, css и статических ресурсов, что на сегодняшний день практически неприемлемо, даже если ресурсы размещены на сервере Ngnix, нет возможности добиться максимального ускорения. Если используется режим разработки с разделением фронтенда и бэкенда, то фронтенд-проект отвечает за фронтенд.С точки зрения интерфейсного взаимодействия можно напрямую использовать существующие фронтенд-скаффолдинги.Уже есть UI-фреймворки разработанные специальными дизайнерами в отрасли на выбор, все из которых реализованы богатые динамические эффекты и сложные взаимодействия, которые можно импортировать одним щелчком мыши. С точки зрения скорости загрузки ресурсы фронтенда высвобождаются и развертываются отдельно, которые можно предварительно разогреть и ускорить через cdn.

Если вы работаете над проектом инструмента, который вызывается только из пользовательского интерфейса на стороне сервера, основное требование пользователя к системе — способность понимать и успешно работать.Для такого проекта, который фокусируется на результатах на стороне сервера, если функция изменяет вероятность ниже, вы можете использовать интегрированный режим разработки внешнего и внутреннего интерфейса, а скорость разработки - онлайн! Одна система решает все проблемы.

Если проект фокусируется на внешнем взаимодействии, лучше всего использовать разделение внешнего и внутреннего интерфейса.Если проект фокусируется на серверных функциях без сложных взаимодействий, интеграция внешнего и внутреннего интерфейса происходит быстрее. Его серверная часть представляет собой базовую логику оформления заказа и оплаты.Очевидно, что реализовать интерфейсные страницы, требующие сложных взаимодействий, на основе традиционной модели JSP, объединяющей интерфейс и серверную часть, сложно.При преобразовании терминала в jsp сложность реализации функции уже очень высока, а эстетика не может быть гарантирована, что предъявляет высокие технические требования к фронтенду. Вторая трудность заключается в беглости: фронтенд и бэкенд интегрированной страницы загрузки проекта нужно загружать на сервер через Nginx, а при отсутствии кеша трафика при первом посещении может потребоваться загрузка статических ресурсов несколько раз. , Загрузка страницы очень медленная, и сервер не может решить эту проблему. Если вы решите разделить интерфейс и серверную часть, страницу внешнего интерфейса можно реализовать напрямую, используя существующие каркасы внешнего интерфейса.Различные отличные интерфейсные фреймворки поддерживают большинство компонентов пользовательского интерфейса, интегрируя динамические эффекты, стили и взаимодействия, а также привязка наборов данных на стороне сервера. Вот и все. С точки зрения скорости загрузки внешние ресурсы могут быть ускорены CDN для достижения быстрой загрузки. Конечно, если вы разрабатываете инструментальный проект для внутреннего использования, логика фронтенда проста и изменений мало, может быть эффективнее использовать интеграцию фронтенда и бэкенда.

Для проектов, ориентированных на фронтальные эффекты, рекомендуется разделить фронтенд и бэкенд.

Эффективность разработки

Проекты, которые интегрируют front-end и back-end, имеют лишь небольшое преимущество в сервисных проектах с простым взаимодействием front-end интерфейса и низкой частотой изменений, потому что ядром таких проектов является сервис, а front-end — это только сервис. вход вызова, который чуть более продуктивен, чем интерфейс вызова почтальона. Простой интерфейс, нет необходимости вкладывать средства во внешний персонал, и сервер можно легко разработать. В этом сценарии использование jsp имеет самые низкие затраты и высочайшая эффективность.

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

Сценарии применения интерфейсной и внутренней интеграции очень ограничены.Любой проект, требующий взаимодействия с интерфейсом, должен разрабатываться таким образом, чтобы разделить интерфейс и серверную часть.

Эффективность эксплуатации и обслуживания

Front-end и back-end являются интегрированными проектами, front-end и back-end полностью связаны, и одно развертывание может реализовать одновременный запуск front-end и back-end, но как только сервер не работает, страница переднего плана не может быть отображена, затрагивая всех пользователей, и итерации сервера и интерфейса должны быть перевыпущены.Нет гарантии, что интерфейс и сервер не повлияют друг на друга, что увеличивает риск итерация.

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

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

03 Технология Сямэнь - три с половиной

На самом деле на практике Приходите, разделение тоже очень быстрое, попробуйте и вы узнаете.

Вывод первый:

Основываясь на существующих интерфейсных и серверных технологиях и возможностях эксплуатации и обслуживания, даже если это небольшой проект, рекомендуется разделить интерфейс и серверную часть; конечно, если технология не была зрелой 10 лет назад разделение фронтенда и бэкэнда также было лучшим способом быстрого запуска проекта.

Поговорим о том, что такое небольшой проект

1. Проект с коротким циклом разработки (запуск в течение двух дней)?
2. Проект с коротким временем обслуживания (этот проект используется срочно в этот раз и не будет использоваться в следующий раз)?
3. Проекты с простыми функциями (всего лишь простой запрос к базе данных, в будущем изменений спроса не будет)?

Основной вопрос заключается в сравнении стоимости небольших проектов?

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

Далее поговорим о преимуществах разделения.

1. Следует упомянуть проблему сопряжения; разделение фронтенда и бекенда естественным образом проясняет границу взаимодействия/разработки между двумя сторонами, а также JSON-ориентированную стыковку данных.
2. Затраты на совместную отладку значительно снижаются, передняя и задняя части могут разрабатываться параллельно, а определение проблемы происходит быстрее и яснее.
3. Более высокая ремонтопригодность и удобство для последующего рефакторинга
4. читабельнее и т.д.

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

04 Технология Сямэнь - прожорливый

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

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

Обычно фронтенд и бэкэнд сосредотачиваются на разных проблемах и решают их. фокусируется на логике данных и фокусируется на бизнес-логике.Упомянутая стабильность — это все.

Таким образом, необходимость разделения зависит от требований и частоты реализации проекта, а также от степени воздействия на проект.

В общих реальных бизнес-сценариях разработка с разделением клиентской и серверной части обычно является лучшим выбором:

1. Одновременная разработка может снизить риск задержек доставки
2. Полностью интерфейсный и документированный, что снижает затраты на понимание и общение между обеими сторонами
3. Заранее понимать риски и трудности проекта и иметь более четкие психологические ожидания
4. техническое обслуживание, техническое обслуживание, техническое обслуживание

Во-первых, в проектах с участием более чем одного человека помощник может получить больше времени на разработку, что, безусловно, является наиболее эффективным способом снижения риска задержки. Во-вторых, разделение фронтенда и бэкенда может лучше решить дилемму зависимости.Различные инструменты или документы могут использоваться для выполнения их соответствующего прогресса разработки.Самое главное, что после разделения фронтенда и бэкенда , используемые технологии не ограничены в реализации и выборе. Принесите удобство для последующего обслуживания.

Эпилог

В большинстве случаев разделение front-end и back-end является более общим, продвинутым и разумным способом. Как вы думаете? Оставьте свой опыт и мнения в разделе комментариев~