Шаблоны проектирования важны, но когда дело доходит до React и NodeJS, довольно много людей сталкиваются с проблемами, пытаясь заставить простое скелетоподобное приложение React беспрепятственно работать с простым (опять скелетоподобным) веб-сервером NodeJS, обычноЭкспресс. Двумя наиболее распространенными проблемами являются запуск webpack-dev-server в производстве и получение нарушений безопасности CORS при добавлении API.
Поэтому я опущу шаблоны проектирования (это может и, вероятно, следует рассмотреть позже, когдавыходя за рамки простых клиентских и серверных прототипов) и сосредоточиться на передовых методах. Я бы определил это следующим образом:
Наличие системы сборки для клиента, которая поддерживает производительность. Практически это означает стремление иметь наименьший размер для комплектов сценариев. Это достигается с помощью встряхивания дерева, выполняемого сборщиком, минимизации комплектов и сжатия в производственной сборке. Сжатия должны включать gzip и Brotli, последний дает ~ 19% уменьшение размера пакета по сравнению с gzip.
Возможность опционально разделить приложение React, которое представляет собой один монолитный SPA, на несколькоКаждый из них имеет свой собственный меньший пакет.
Наличие веб-сервера, который дополнительно повышает производительность за счет отключения кэширования для обычно небольших файлов .html, создаваемого сборкой React, и обеспечения долгосрочного кэширования для больших пакетов скриптов.
Удобство отладки. Практически это означает возможность отладки при разработке клиентского кода, работающего внутри браузера, и внутреннего кода NodeJS с использованием того же отладчика, что и один экземпляр VS Code. Плюс возможность поддержки Live Reloading. Также переключитесь с VS Code на Chrome DevTools для отладки клиентского кода. В производстве это означает возможность отладки минимизированного и сжатого пакета сценариев, используемого клиентом для воспроизведения проблемы, сообщенной этим клиентом. Опять же, используя VS Code или Chrome DevTools.
Не оставляйте места для проблем с CORS и не используйте webpack-dev-server в производстве.
Имейте тестовые случаи для клиента и бэкэнда, написанные на TypeScript, как и все остальное.
Реализация аварийного восстановления SPA в веб-сервере. Это означает, что сервер должен перенаправлять запросы на неизвестные страницы на целевую страницу SPA. Например, это поведение разрешено в webpack-dev-server с помощью параметра historyApiFallback, который существует специально для поддержки SPA. Поведение в случае отказа требуется для любого SPA, поскольку пользователь может видеть путь к любой внутренней странице на панели навигации иМожно либо перепечатать его вручную и нажать Enter, либо обновить браузер. В обоих случаях веб-сервер получает запрос на внутреннюю страницу SPA, о которой он не знает, и ответ с ошибкой 404 выглядит не очень хорошо для пользователя. Из соображений безопасности у запасного допуска должны быть свои пределы, и явно недопустимые запросы все равно должны вызывать ошибку.