Блог

Я применял шаблон в некоторых небольших приложениях, над которыми я работал, какие следующие инструменты:

Интерфейс: ReactJS, Redux, Firebase (только для аутентификации) Серверная часть: узел с Express и библиотека для базы данных, которую я использовал (mysql или mongo)

Раньше поток был таким:

1. Загрузка страницы и проверка, если пользователь вошел в систему. Если да, извлеките данные приложения с помощью серверной части. Если нет, просто проверьте, не находится ли пользователь на защищенном маршруте, а затем позвольте ему перемещаться (создать учетную запись, сбросить пароль и т. Д.)
2. Когда происходит выборка и пользователь входит в систему, серверная часть отправляет все данные от этого пользователя (категории, магазины, продукты, профиль и любую другую информацию, позволяющую приложению работать плавно), поэтому при навигации не происходит непрерывной загрузки для извлечения каждого фрагмента данных. Это также происходит так, потому что это небольшой объем данных (в начале), скажем, может быть, 1 или 2 магазина по 15-20 товаров в каждом.
3. При обновлении данных, таких как изменение названия продукта, цены или любой мутации данных, интерфейс отправляет запрос на серверную часть, а затем обновление выполняется, и в качестве ответа на запрос отправляется ответ об успешном выполнении true / false.
4. Допустим, предыдущий шаг — это создание хранилища. Итак, интерфейс получает ответ об успешном завершении, а затем отправляет событие APPEND_STORE в redux store, чтобы перехватить новое хранилище с его данными (только ИДЕНТИФИКАТОР другие данные, созданные на серверной части, принимаются в качестве ответа на http-запрос, данные, которые были сгенерированы на интерфейсе, берутся из самого приложения) и добавляют его в массив stores, а затем снова устанавливают объект массива store.
5. Причина, по которой предыдущий шаг выполняется подобным образом, заключается в том, чтобы избежать того, чтобы серверная часть сначала выполняла обновление, а затем выполняла новый запрос, чтобы снова получить новый регистр (ej: создать новый запрос хранилища -> серверная часть создает хранилище и извлекает новый идентификатор -> серверная часть находит / запрашивает новый регистр с его идентификатором -> ответить на данные)

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

Я хотел бы знать наилучший подход для этого (или, по крайней мере, лучший подход из приведенных выше), чтобы реализовать его в более крупных приложениях для обработки большего количества пользователей и данных, которые со временем будут увеличиваться.

Основные вопросы:

1. Должен ли серверный сервер обрабатывать все данные и отправлять их во внешний интерфейс или должен отправлять минимальные данные, чтобы приложение могло запуститься, а затем отправлять в соответствии с требованиями навигации? Я также думал, что когда объем данных вырастет, отправьте фрагмент данных с ограничением в 10/20 регистров, чтобы сохранить тот же подход, но хотите знать стандартный / правильный способ его обработки.

2. Когда проверка данных завершается неудачей на серверной части, должна ли серверная часть отвечать кодом состояния OK с ключом success: «true / false» и дополнительными данными для обработки этого на интерфейсной части, или серверная часть должна отвечать кодом состояния ошибки?

3. Как я уже сказал, серверная часть отвечает только данными, созданными самой серверной частью (ID, дата создания и т.д.). Должен ли сервер отвечать только этим, или серверная часть должна создать новый запрос, чтобы получить полный регистр и отправить его в качестве ответа? Изначально этот подход использовался для оптимизации ресурсов (минимальное количество запросов и данных, отправляемых в ответ). Я также думаю, может быть, это глупый подход, потому что в современном мире много ресурсов, так что разница не должна влиять на производительность чего-либо. Кроме того, с этим ответом мое поведение в redux изменится. Есть ли у вас какие-либо комментарии также по этому подходу redux?

4. Можно ли сначала выполнить запрос к базе данных для обновления, а затем другой запрос для повторной выборки всех зарегистрированных? Я знаю, что базы данных создаются для обработки нескольких запросов, но я не знаю, есть ли какие-то недостатки, которые следует учитывать при выполнении подобных действий.

Действительно спасибо!