привет~ дорогие наблюдатели, привет всем~ Давненько я не писал статьи, и был занят полным разделением фронтенда и бекенда для внутренней платформы визуализации данных. Первоначальный проект былVueОдностраничное приложение , доступ после рефакторингаNodeВ качестве промежуточного слоя достигается полное разделение передней и задней частей.
Поскольку проект относительно прост, стоимость не слишком высока. Далее будет кратко представлен используемый технологический стек и преимущества после разделения, с акцентом наNodeНемного подумайте о разделении передней и задней частей.
задний план
Примерно в конце ноября прошлого года он присоединился к новому владельцу и занял всего лишьВнутреннесистема анализа данных. Конечно, новобранец хочет добиться каких-то достижений.После изменения пользовательского интерфейса и оптимизации некоторых функций обнаруживается, что производительность страницы по-прежнему относительно низкая. После расследования установлено, что интерфейс получения данных не кэшируется и не основан наRESTfulДа, кеширование в браузере вообще не работает. В этот период внутренний интерфейс также был изменен, а внешний код был значительно изменен.
Основываясь на том факте, что студенты, изучающие back-end, не знакомы с механизмом front-end, у меня также есть менталитет упрощения работы в будущем.катать пол несколько разПосле этого руководитель отдела дал согласие на доступNodeв качестве промежуточного слоя.
Технический отбор
После подтверждения доступаNodeПосле этого первое, что нужно сделать, это технический отбор.Nodeобычно вExpress,Koaа такжеEggвыбрано. При использовании промежуточного программного обеспечения личные предпочтенияKoa, поэтому мы должныExpressПопрощайтесь.EggвKoaСтрогие ограничения были наложены на написание кода, структуру каталогов и т. д.
Во время отбора я бесчисленное количество раз обсуждал с фронтенд-лидером, считает онEggСлишком много ограничений и плохая масштабируемость.Если в нижней части фреймворка есть баги, с ними сложно бороться, поэтому предпочитают использоватьKoa. Такие опасения разумны, однако с текущими проектами маловероятно, что какая-либо функциональность превыситEggпри условии, вместоEggПредоставленные функции могут значительно снизить затраты на строительство и обслуживание проекта. Что касается ограничений, лично я считаю, что это хорошо и в определенной степени решает проблему организации кода при разработке с несколькими людьми.
После тщательного рассмотрения я решил использоватьEggтак какNodeс кадр.
Разделение заработка
Поскольку проект не очень сложный, процесс доступа проходит гладко. Беда только в том, что сроки строительства относительно сжатые, поэтому его делят на два этапа: первым подключается первый этапNode, все запросы на стороне страницы перенаправляются в том виде, в каком ониJava, возвращенный результат пересылается на сторону страницы как есть. На втором этапе интегрируется и оптимизируется интерфейс сбора данных для повышения производительности. После завершения доход остается объективным, и для демонстрации результатов публикуются две фотографии.
Производительность исходной страницы (все запросы Post):
доступNodeПроизводительность той же страницы (обращенной к методу Get):
Видно, что будь то объем загрузки данных или время отклика и другие показатели, затраты времени сокращаются. Конечно, это построено на доступеNodeПозже я сравнил интерфейс с такими мерами, как интеграция и оптимизация кеша. Если это первый визит, производительность среды INTRANET WIFI компании будет немного хуже, чем оригинальная производительность, а общее время загрузки будет немного выше, чемJavaПрямо менее 50 мс. Я также использовал Chrome для имитации слабой сетевой среды, которая отнимает много времени иJavaВ основном то же самое.
И опыт разработки намного комфортнее, чем раньше, что считается доступнымNodeЦель, поставленная перед: после доступа производительность будет улучшена на 30% при поддержке тех же функций; за то же время разработки будут выполнены те же требования, но с лучшим опытом разработки и лучшей производительностью страницы.
Подводя итог, можно сказать, что все внешние оптимизации основаны на шаблоне и данных, необходимых для получения шаблона.Angular,Reactа такжеVueОдностраничные приложения, созданные с помощью других фреймворков, решают проблему шаблонов, и мы больше не можем позволить серверной части перемещать наши шаблоны. Однако получение необходимых данных по-прежнему зависит от бэкэнда.Многие одностраничные приложения достаточно сложны, чтобы взаимодействовать друг с другом.Если вам все же нужно поддерживать сложную логику для получения и интеграции данных, это все равно головная боль. Поэтому дополнительный уровень доступаNodeЗаниматься сбором и интеграцией данных, делать все возможное для оптимизации интерфейса запроса на стороне страницы и позволять стороне страницы сосредоточиться на взаимодействии — это очень полезно, когда созреют условия.
думать
Если только для продвиженияNode, в этой статье следует подробно описать описанные выше шаги, и она должна заканчиваться после резюме, что согласуется с практическими статьями многих старших братьев (конечно, я недостаточно хорош~). Однако в ходе обсуждения с двумя лидерами я благодарю их заNodeЯ скептически отнесся к технологии и поднял много интересных вопросов, объединив свои размышления, я организовал их в форме вопроса и представил всем.
Зачем доступ
Nodeв качестве среднего слоя, а текущий уровень компанииPHPКакая разница?
нет разницы! Факты говорят,Nodeсможет сделатьPHPТо же самое можно сделать. Тогда проблема превращается вNodeКаково значениеPHPперейти к плануNode?
Я думаю, что серверная служба в основном стабильна, и настройка бизнеса не будет особенно частой. Для фронтенда частая корректировка бизнеса — обычное дело, если фронтенд и бэкенд связаны вместе, часто выпускать бэкенд не вариант. При этом требования к структурам данных и степени детализации контроля над ними тоже достаточно разные. хорошо написанPHPСтуденты, которые хорошо пишут на фронтенде, не обязательно хорошо пишут на фронтенде, а студенты, которые хорошо пишут на фронтенде, не обязательно хорошо пишут.PHP. Для профессиональных областей это должны делать профессиональные люди.Пусть внешний интерфейс контролирует весь шаблон и данные, от которых шаблон зависит, что очень помогает улучшить качество проекта. Шучу, бэкенд просто возится с базой данных, плюясьjsonЭто хорошо, просто возьмите данные в интерфейсе и вырежьте страницу.
Кроме того, если внешний интерфейс хочет получить доступSSRтакие функции, какNodeдействительно лучше, чемPHPЕсть много преимуществ, и это можно рассматривать как прокладывание пути для будущей работы.
доступ
NodeНасколько улучшится производительность?
Не обязательно улучшение или даже снижение. Эта проблема была обнаружена, когда я тестировал производительность страницы после завершения первого выпуска. При тестировании,NodeПомимо пересылки всех запросов как есть, добавляется кэш согласования, но время отклика медленнее.
Перед доступом (для почтового запроса):
После доступа (для запроса Get):
Обычно при получении данных около 10 КБ, если кеш согласования попадает, он возвращает 304, пропуская процесс загрузки, который должен быть быстрее. Через точки узнайNodeДля пересылки запроса требуется дополнительно 10 мс, но в среде Wi-Fi внутренней сети компании общее время загрузки составляет менее 160 мс.
таким образом введенNodeНе обязательно будет улучшение производительности, но произойдет потеря производительности из-за введения еще одного слоя. Во входящих проектах или проектах с приемлемой производительностью повышения производительности недостаточно, чтобы стать точкой доступаNodeключевая причина. Другими словами, доступNodeПосле этого невозможно сделать скачок в производительности приложения, пока запросы на стороне страницы не будут оптимизированы.
я прав в этом вопросеNodeОтправная точка изменения отношения, начиная с безмозглого доступа к поддержкеNodeК диалектическому рассмотрению это приводит и к последующим вопросам.
доступ
NodeКаковы недостатки?
Чем мощнее внешний интерфейс, тем больше ответственности он означает. Например, это могло бытьJavaЕсли вы делаете защиту безопасности, она может упасть доNodeВ конце концов, это более незнакомая область для большинства продвинутых студентов.
Стоимость ввода и вывода тоже спорные вещи, в конце концовNodeНезависимо от того, насколько близко к переднему концу, это всегда домен заднего конца. Фронтенд и бэкенд идеи разные, если вы используете фронтенд мышление для написания бэкенда, вы можете написать очень плохой код, который в некоторых случаях повлияет на производительность и утечки памяти в худшем случае. доступNodeПосле слоя это стало бредом, и я считаю, что все не хотят этого видеть.
после всегоNodeЭто относительно новая территория для многих компаний. Хотя доступ может быть известенNodeЕсть много преимуществ, но как получить доступ и что он может делать после доступа, может быть неясно. Как легко подключиться с наименьшими затратамиNodeВ то же время максимальное повторное использование существующей архитектуры также сопряжено с множеством проблем.
В таком случае нет
NodeПрименимые сценарии?
имеют. Как упоминалось ранее,NodeСмысл в том, чтобы позволить внешнему интерфейсу управлять шаблоном и данными, от которых зависит шаблон.Вы также можете рассмотреть эти два аспекта. Если взаимодействие со страницей относительно сложное, а упор делается на SEO, доступ в это времяNodeКак средний уровень, я думаю, что это лучшая практика.
Второе — непрерывная эволюция архитектуры бэкенда.После перехода на микросервисы фронтенд чувствует, что фрагментация интерфейса стала приносить много хлопот, поэтому ему стоит подумать о доступе.Nodeинтегрированный интерфейс.
В общем, когда получить доступNode, немного похоже на то, когда представитьReduxилиVuex. Когда вы чувствуете беспокойство, пока вы знаете, что есть этот вариант, вы, естественно, захотите его использовать.
резюме
Подводя итог, в следующем сценарии я думаю, что доступNodeлучшая практика:
- Сосредоточьтесь на SEO и сложных взаимодействиях.
- Серверная часть является микросервисной, а передняя часть должна интегрировать интерфейс.
- Передовые проекты требуют использования новейших технологий, таких как
SSR,PWAЖдать.
Если это только проблема производительности, введитеNodeНе обязательно улучшение, и его необходимо анализировать в соответствии с реальной ситуацией. Что касается дизайна внутреннего интерфейса, слишком уродливого, возвращаемая структура данных не соответствует внешнему использованию и т. Д., В случае небольшого масштаба приложения, по сути, можно общаться с внутренним интерфейсом. запретить учащимся доступNodeНе обязательно лучшая практика и должна быть продумана.
Однако твердо противостоять нежеланию менять существующую структуру только потому, что существующая структура относительно знакома, и всегда держаться за неверное решение, а не решать его. Я всегда считал, что пока это правильно, каким бы сложным ни был процесс, он должен двигаться в правильном направлении.
Вышеизложенное является небольшим личным мнением, спасибо всем зрителям за то, что увидели это. Легче сказать, чем сделать, надеюсь, эта статья будет вам полезна~ Спасибо!