Тогда вам нужно научиться предотвращать временные парадоксы!

TL; DR: полный стек - это не код. Это о мышлении.

Ваша команда и вы только что развернули ваше приложение в производственной среде. Кажется, что все чувствуют облегчение. Но перед тем, как сегодня начнется большая вечеринка, кто-то спросит: «Сколько у нас сегодня посещений?»

Ответ на этот вопрос - одно число. Но для получения этого числа требуется приложение с полным стеком! Прежде чем мы начнем разработку этого приложения, давайте поработаем немного.

Начнем с определения «сегодня». Я не шучу!

«Легко», скажете вы? «Это период с 00:00 (или 0:00) до 23:59 (или 23:59) текущего дня, месяца и года». Это правильно!

Как вы измеряете «сегодня»?

«Это тоже легко. Я использую JavaScript Date класс. Следующий фрагмент распечатывает текущую дату. Мы можем использовать это прямо в нашем веб-приложении! »

const datestring = (d) => {
  return d.getFullYear()
    + "-" + (d.getMonth()+1)
    + "-" + d.getDate();
console.log(datestring(new Date()))

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

Каковы последствия работы с местным временем посетителей?

Давайте рассмотрим разницу между новозеландским киви и гавайским тюленем-монахом.

Киви - ранняя пташка, которая встает в 12 часов утра и заходит в ваше приложение. Сейчас 12 часов утра по новозеландскому стандартному времени (NZST).

Тюлень похож на поздно вставшего, который заходит на вашу страничку в 11 часов вечера. Это 11 часов вечера того же дня по гавайскому стандартному времени (HST).

NZST на двенадцать часов раньше UTC, то есть на десять часов раньше HST. Таким образом, 12:00 HST - это на 22 часа позже 12:00 NZST. Кроме того, печать посетила ваше приложение в 23:00. Это на 23 часа позже 12 часов утра. В целом тюлень посещает вашу страницу на 45 часов позже, чем киви. Но засчитывается в тот же день!

Что делать, если киви и тюлень посещали ваше приложение одновременно. Тюлень только что пообедал в воскресенье в 11 часов утра (HST). Kiwi только что позавтракал в 9 утра (новозеландское время), в следующий понедельник! Эти одновременные посещения добавят к счету двух разных дней!

Вы разогрелись? Поговорим о временном парадоксе!

Маркетинговая команда запускает новую кампанию. Конечно, они хотят ориентироваться на развивающиеся рынки Дальнего Востока. Объявления запускаются с 9 утра понедельника по японскому стандартному времени (японское стандартное время, +9 часов до всемирного координированного времени).

Кампания пользуется огромным успехом и становится вирусной. Распространяется по всему миру. Вы также получаете много визитов от клиентов из США.

Но подождите, сейчас 8 часов вечера в предыдущее воскресенье в Нью-Йорке (EDT, -4h до UTC). Сейчас 17:00 в предыдущее воскресенье в Лос-Анджелесе (PDT, -7h до UTC). Ваше приложение получает много посещений за день до начала кампании!

Вы видите следствие до причины… странно. Не правда ли? Не теряйтесь в временных парадоксах!

Как нам избежать временного парадокса?

«Просто выберите один часовой пояс для всех посещений, глупец», - скажете вы?

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

«Вы здесь что-то не так делаете», - говорите вы? Вы снова правы! Но проблема не в коде! Это связано с тем мышлением, которое я применил.

Я применил чистую фронтенд-перспективу.

Вы слышите backend-разработчиков? «Никогда не доверяйте интерфейсу!» Они не оскорбительны. Эта фраза означает, что вам нужно внимательно относиться к данным, которые вы получаете от внешнего интерфейса.

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

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

Давайте для разнообразия применим внутреннюю перспективу?

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

Мы можем использовать следующий код непосредственно на нашем сервере:

const datestring = (d) => {
  return d.getFullYear()
    + "-" + (d.getMonth()+1)
    + "-" + d.getDate();
console.log(datestring(new Date()))

Да, это тот же код, что и выше. Но есть огромная разница в смысле и подтексте. Теперь возьмем местное время сервера. Это одинаково для всех посетителей.

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

Мы предотвращаем временные парадоксы.

Не называйте меня сочувствующим серверной части. Потому что я не такой. Я сейчас это докажу.

Вернемся к нашему вопросу: «Сколько у нас посещений сегодня?»

Что, если бы это число имело значение не только для нас, разработчиков? Что, если это важно и для наших посетителей? Допустим, мы предоставляем услуги бронирования. Например, Airbnb или платформа для бронирования отелей. Мы хотим показать количество посещений определенного места или отеля сегодня.

Давайте посмотрим на нашем бэкэнде. Наше внутреннее время - UTC (+0). Когда наша новозеландская киви посещает наше приложение в 11:00 (NZST, +12 к UTC), она видит вчерашнюю статистику. Потому что время бэкенда - 11 часов вечера по всемирному координированному времени. В результате количество посещений сегодня велико. Затем, в полдень в Новой Зеландии, наш бэкэнд-счетчик меняет дни. Когда киви возвращается на страницу позже в тот же день, она видит число ниже, чем раньше. В тот же день!

Это плохой пользовательский опыт, не так ли? Технически ваши подсчеты могут быть верными. Но верны ли они в данном контексте? Удовлетворяют ли эти подсчеты цели? У всех посетителей Kiwi во второй половине дня будет ощущение, что в приложении мало трафика. Или что отели не пользуются большим спросом. Если бы они посетили приложение после полуночи (NZST), они увидели бы гораздо больше. Поверили бы они, что отель пользуется таким высоким спросом сразу после полуночи?

«Вы здесь что-то не так делаете», - говорите вы? И еще раз, вы правы! Проблема все еще не связана с кодом! Это связано с тем мышлением, которое я применил.

Я применил чисто внутреннюю перспективу.

Если вы хотите стать разработчиком Full-Stack React Developer, вам нужно перестать думать как фронтенд-разработчик или бэкэнд-разработчик. Вам нужно начать думать как разработчик полного цикла.

Разработчик полного стека использует все инструменты из своего набора инструментов. Это и серверная часть!

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

Когда мы отображаем наши данные, мы можем использовать контекст нашего интерфейса. Где сейчас и когда находится наш посетитель? Имея под рукой необработанные данные, мы можем подсчитать количество сегодняшних посещений с точки зрения NZST для Kiwi. И мы можем подсчитать количество сегодняшних посещений с точки зрения HST для тюленя.

Ни киви, ни тюлень не увидят сброс счетчика в течение дня. Мы могли бы даже принять во внимание часовой пояс, в котором находится отель на посещаемой странице. Если нам понравится.

Full-stack позволяет нам достичь большего, чем может достичь чистый интерфейс или чисто серверное решение! Но это требует от нас мыслить вне зоны комфорта. Нам нужно выходить за рамки привычного распорядка. И нам нужно критически относиться к тому, чего мы хотим достичь. Потому что чем больше у нас власти, тем больше у нас ответственности.

Вы все еще думаете, почему вам следует заниматься разработкой полного цикла?

Вы можете получить первую главу бесплатно в React-Architect.



Как создать и развернуть полнофункциональное приложение React
Дополните свое приложение React Express.js и DynamoDB. medium.com





Который час?
Разработайте свои собственные мировые часы с помощью React codeburst.io



Ресурсы

Хотите узнать больше? Вот список некоторых из моих предыдущих сообщений: