Anticodeguy

Давно хотел рассказать про этот инструмент, но пока не подворачивался удобный случай до того, как я начал описывать проект Нутриклиники, потому что здесь Airtable служит отличным примером того, как можно использовать этот инструмент не совсем по прямому значению, но который очень сильно упрощает работу с данными. Airtable называют «Excel на стероидах» или такие прокаченные таблицы, которые можно конфигурировать абсолютно по-разному и делать это так, как тебе удобно, в том числе и с визуальной точки зрения. Одна из самых крутых фишек Airtable – то, что здесь таблица представляет собой не просто сетку, где у тебя есть ячейки, колонки и строки, как это сделано в привычных редакторах, например Google Spreadsheet и Microsoft Excel. Здесь одни и те же данные могут быть представлены в абсолютно разном виде: – в привычных нам строках и столбцах; – в формате календаря, что может быть удобно для планирования постов, публикаций, событий; – в виде галереи карточек примерно, как это выглядит в интернет-магазине; – в виде канбан-доски; это очень хорошо знакомо тем, кто работает с CRM-системами и или системами управления задач; – также можно всё это представить в виде таймлайна или временной линии, что удобно при планировании или визуализации каких-то протяжённых событий. И самое главное, что меня привлекает в этой платформе – это то, что все данные могут быть удобно и очень быстро отредактированы с помощью функций сортировки, группировки, фильтрации, подсветок и визуальных акцентов на различных типах данных, которые действуют «на лету», что позволяет работать с данными крайнюю быстро и удобно. Дальше подробненько расскажу про всё это и для чего же я использую Artable в Нутриклинике.

Ещё одним важным преимуществом Бабла перед другими конструкторами является гибкость возможностей настройки интеграции. Для этого существует отдельный плагин (надстройка) от самих разработчиков Bubble, который позволяет настраивать связи с другими системами посредством API, про который я рассказывал в одном из предыдущих постов. Напомню, что согласно нашей функциональной архитектуре весь контент хранится во внешней базе данных и не зависит от Бабла. Соответственно Bubble-приложение нужно научить тому, чтобы ходить в эту базу данных и забирать оттуда контент при запросе пользователя, например, когда он заходит в блог. И для этого я как раз применяю схему интеграции через API: подключаюсь к созданным через Directual методам и запрашиваю у них данные. Как это происходит. Когда ты заходишь в блог, Bubble отправляет запрос в заранее настроенный по заданному адресу метод и спрашивает у бэкэнда, который в данном случае работает на Directual, прислать ему набор постов для блога. Если, например, ты хочешь отфильтровать набор постов по тега, в этом случае тоже происходит запрос к серверу и API отдаёт тот набор постов, который соответствует выбранным тобой тегам. Затем, когда ты переходишь уже на конкретную страничку блога, выполняется ещё один Запрос к бэкенду, который вытягивает контент этого поста, то есть картинку (которая, кстати, лежит на ещё одном сервисе), текст, информацию о следующем и предыдущем постах и те же теги. Таким образом можно интегрировать любую другую систему, причём не только на предмет получения данных из внешней системы, но также и на отправку данных. Например, если мы делаем админку, где будем редактировать посты блога, то можно будет их отправлять прямо отсюда в базу данных, если на бэкэнде будет разработан соответствующий метод для получения и обработки этих данных и сохранение их в базу в нужном формате.

Адаптивный движок Bubble Следующим неоспоримым преимуществом Bubble является фишка, которая не так давно появилась в одном из глобальных обновлений платформы – это движок адаптивного дизайна или Responsive Engine. Он позволяет очень гибко и аккуратно настраивать всё, что касается адаптива страницы под различные устройства, начиная от узких экранов смартфонов до широкоформатных огромных современных мониторов или больших плазменных панелей, на которых нужно отображать контент создаваемого приложения. Редактор очень мощный и позволяет реализовать любые задумки с различным поведением, которые мы можем ожидать от адаптива: здесь и аккуратные переносы блоков на другую строку, и выравнивание их относительно друг друга по вертикали, по горизонтали, либо с наложением друг на друга, здесь и сжатие и растяжение в зависимости от ширины экрана, здесь и условия, при которых контент может отображаться или скрываться в зависимости от заданного размера и разрешения экрана. И самое главное, что всем этим очень удобно и тонко можно управлять с помощью довольно-таки небольшого количества настроек. Благодаря чему можно быть уверенным что каждая новая страница, которую ты делаешь на Бабле, будет выглядеть одинаково хорошо и будет одинаково удобно пользоваться как на мобильных устройствах, так и на десктопах. Конечно же, всё зависит от того, каким образом ты проектируешь сам интерфейс и насколько он дружелюбный по отношению к пользователю. Потому что даже профессиональная фотокамера в руках любителя не будет выдавать шедевры сама по себе. Здесь нужно ещё всё-таки приложение своих творческих способностей. Но Bubble в данном случае – это многофункциональный комбайн, который как раз представляет полную свободу действий и свободу реализации своих задумок (как про-камера). Всё, что было задумано в плане дизайна, включая адаптив, на нём можно реализовать, поэтому, когда речь заходит про более сложный дизайн, чем обычно требуется для рядовых сайтов, я практически сразу выбираю Bubble.

А теперь к плюсам Bubble И несомненно к ним относится визуальный редактор. И это конструктор в глубоком понимании этого слова. Чем хорош Bubble по сравнению, например, с Tilda, это тем, что здесь нет готовых блоков, которые ты можешь в каком-то ограниченном только наборе параметров редактировать. Но здесь есть минимально возможные элементы-кубики, такие как текст, изображение или просто графическая форма, из которых ты можешь сделать, в принципе, абсолютно любой дизайн, который был придуман, в том числе профессиональным дизайнером. Если разрабатывать дизайн под сайт, который будет сделан на Bubble, то можно себя вообще ни в чём не ограничивать, включая анимации, необычное поведение элементов, зависимость от пользовательского поведения и так далее. Всё, что может прийти в голову, в принципе, здесь можно будет реализовать. А если чего-то реализовать вдруг не получится стандартными кубиками конструктора, в наличии есть несколько вариантов развития событий. Первое – это написать и встроить свой скрипт, программный код на страницу и сделать это можно довольно-таки просто. И второе – пойти в магазин плагинов, где можно посмотреть огромное количество различных надстроек, которые упрощают разработку. Чтобы не придумывать велосипед с нуля, а взять готовое решение, ведь большая часть различных дизайнерских и программных задумок уже была кем-то реализована. В этом плане Bubble хорош тем, что он даёт свободу творить, свободу создавать такие странички и такие приложения, которые мы изначально задумали, причём это может быть как простейший сайт, так и какая-то сложная и многофункциональная корпоративная система с различными уровнями вложенности, административной панелью, дашбордами или какой-то другое интерактивное приложение, где задействовано здесь множество элементов интерфейса и все они между собой взаимосвязаны.

Так, с базами данных разобрались, мы их точно не будем делать на Bubble. А что же насчёт программной логики, то есть того, что происходит за кадром за кулисами визуала, который не видит пользователь? В Bubble есть встроенный редактор программной логики. Он называется Workflow или рабочий поток, который позволяет настраивать довольно простую линейную логику. Всё, что касается работы с визуальной частью сайта, то есть, например, условия, при которых появляется или исчезает элемент на странице, либо какие-то простенькие вычисления, здесь тоже можно делать. Обрабатывать различные события, такие как клики или взаимодействие с различными элементами интерфейса здесь прекрасно можно реализовать. Также здесь можно делать и обработку данных, то есть добавить запись в базу или редактировать записи в том случае, если они изменяются, и мы, например, настраиваем админку в Бабле. Но мы уже решили, что базы данных у нас на стороне Bubble не будет, поэтому в данном проекте это всё не применимо. Реализовать сложную ветвистую логику с несколькими условиями, которые идут параллельно и зависят друг от друга, реализовать на Bubble не получится в силу особенностей линейного редактора. Да, там можно ставить условия, можно из одного процесса вызывать другой, но получится в итоге сложная структура, которую непонятно как обслуживать, если вдруг там обнаружится ошибка. То есть инструмент рабочий, на нём действительно можно реализовывать некую логику, но, когда речь заходит про более комплексные системы, использовать его будет неудобно, либо трудозатратно. Исправить ошибку в таком линейном редакторе займёт много времени и большой и велик шанс поломать что-нибудь ещё. Благодаря этим аргументам в комплексе про построение базы данных на Bubble и реализацию программной логики, я отказываюсь от него на данном проекте, как от backend-системы. Я думаю, что достаточно рассказал про минусы. Дальше расскажу про позитивную сторону Bubble и то, чем он мне так сильно нравится и почему я его выбираю в качестве frontend системы для многих проектов.

Минусы Bubble как сервиса для построения БД Ещё один значительный минус для меня в сервисе Bubble – это то, что там нельзя удобно редактировать базу данных. Да, ты её можешь изначально настроить, но для того, чтобы внести изменения в какие-то данные напрямую, сделать это будет не так-то просто. Для этого подразумевается, что ты сделаешь отдельную админку и настроишь её таким образом, чтобы через неё можно было уже эту базу данных редактировать. Но на мой взгляд это абсолютно лишнее и ненужные затраты, так как некоторые сервисы, такие, например, как Airtable, предоставляют возможность прямого редактирования базы данных сразу из коробки, как только ты настроил все необходимые типы полей. Ещё одно важное замечание, которое имеет критическое значение для проекта Нутриклиника – это невозможность контролировать, где же находится база данных, где хранятся данные реально, но есть на каком сервере и где географически он находится. Так как необходимо соблюдать закон о защите пользовательских данных, нужно соответствовать определённым требованиям. То есть мы не можем, например, запускать проект и пользоваться данными, которые находятся, например, на европейских серверах или на серверах, расположенных в Северной Америке. И, наконец, ещё один стопор, который останавливает от использования Bubble в качестве системы для проектирования и создания базы данных – это отсутствие прямой возможности получать эти данные через API. Для этого придётся делать какие-то костыли, реализовывать логику через системы интеграции. Создать базу данных и сразу к ней достучаться из какой-то внешней системы просто так не получится. При этом заранее известно, что у нас ещё будет как минимум мобильные приложения, которое должны будут в эту же самую базу данных стучаться. Таким образом я собрал довольно много сильных аргументов против того, чтобы использовать Bubble, как полноценную backend-инфраструктуру на этом проекте.

Минусы Bubble как backend-платформы В первую очередь поговорим про базу данных, как основу для всей системы. Я не люблю, когда все яйца лежат в одной корзине. В данном случае подразумевалось бы, что у нас фронт-, бэк-логика и база данных находились в одном сервисе. И это достаточно рискованная затея, потому что если вдруг завтра Bubble каким-то образом станет недоступен в России, то мы тем самым рискуем потерять весь трафик и всё приложение разом. Во-вторых, сама база данных является неотъемлемой частью этого сервиса и если вдруг что-то пойдёт не так на стороне Бабла, то это тоже риск для интеллектуальной собственности, поэтому держать в ней критически важные для бизнеса и проекта данные я бы не хотел. Она, разумеется, подойдёт для оперативного хранилища или временного хранения данных, как промежуточный пункт, но не в качестве перманентного решения. Ну и наконец сам по себе редактор баз данных там не такой гибкий, как мне бы хотелось: он не позволяет настраивать те типы данных, которые мне нужны, не позволяет делать сложные связки, которые имеются в этом проекте. И сам редактор баз не заточен под сложные многоуровневые и связанные между собой объекты. То есть, если изначально проектируется такая комплексная система, то использовать в качестве системы для построения базы данных Bubble будет просто неудобно. Это я выяснил уже на практике, так как реализовывал на этом продукте несколько других проектов.

Выбор платформы для сайта Начнём с простого (казалось бы) – с сайта. Сайт можно построить на конструкторах, как я уже говорил много раз об этом, например на Tilda. Но, изначально мы закладывали сюда не просто функциональность сайта, который можно читать, но и функциональность полноценного приложения. Подразумевалось, что у нас на сайте после регистрации пользователю будет доступен чат-бот на основе искусственного интеллекта, который станет интерактивным помощником в борьбе с онкологией. Именно поэтому и для того, чтобы в дальнейшем упростить развитие сайта и сделать возможным добавление в него новых функций без задней мысли о том, что это может быть сделать сложно, либо для этого понадобятся какие-то костыли, я выбрал платформу Bubble для решения этой задачи. Платформа Bubble позиционирует себя как полноценный no-code комбайн, такой многофункциональный, где можно реализовать как фронтовую часть, то есть то, что видит пользователь визуально (всё, что касается работы в браузере), так и программную логику, то есть хранить данные, преобразовывать их, редактировать, совершать разные манипуляции. В принципе, Bubble действительно подходит для этого. Там есть возможность создать свою базу данных, настраивать программную логику. Но именно здесь есть некоторые ограничения, которые меня останавливают для использования системы Bubble как backend-системы в данном проекте. И далее я расскажу, какие минусы я вижу в Bubble, как в backend-системе.

Заглянем под капот Нутриклиники Пользователь работает с мобильным ил web-приложением. Это то, с чем он взаимодействует, frontend (фронетенд). То, что он не видит и где на самом деле происходим вся магия и подковёрные игры – это backend (бэкенд), который состоит из связки нескольких систем. Directual, который я уже упоминал ранее, включает в себя базу данных и программную логику работы с этими данными. Здесь же хранится вся база знаний. Для того, чтобы было удобнее работать с некоторыми данными, которые требуют визуального анализа, либо быстрой редактуры, я использовал Airtable. Про него я уже упоминал в предыдущей серии постов, но подробно не рассказывал, что это такое. Думаю, здесь я тоже уделю ему достаточно внимания. Также у нас есть Firebase для того, чтобы осуществлять аутентификацию пользователей в мобильных приложениях. Пока не бери в голову, что это такое, а просто запомни, что эта штука нужна для того, чтобы можно было войти в приложение. Ну и зарегистрировался там перед этим, разумеется. Ну и, наконец, есть ещё одна система, которая представляет собой чат-бот на основе искусственного интеллекта, который помогает подобрать правильную диету, образ действий во время лечения и решает другие вопросы в помощь онкобольным. Для этого мы используем платформу Twin 24.

➡️No-code кейс Нутриклиники Начинаю новую серию постов, в которой буду рассказывать про архитектуру проекта Нутриклиника, который я уже упоминал ранее в постах. И сегодня покажу, из чего состоит комплекс систем, на которых работает проект. Сразу скажу, что она сделала полностью на no-code решениях. Кроме мобильных приложений есть ещё веб-приложение с чат-ботом на основе искусственного интеллекта, которое даёт рекомендации по питанию для больных онкологией. На этот раз я не буду мучить тебя процессом построения архитектуры, а сразу из места в карьер расскажу, из чего же она состоит. Как она выглядит, можешь увидеть на картинке, прикреплённой к этому посту. Итак, у нас есть мобильные приложения iOS и Android, которые построены на платформе FlutterFlow. Ранее, в другой серии постов я уже писал про этот инструмент. С точки зрения пользователя у нас ещё существует сайт или веб-приложение. Я его так называю, потому что это не просто сайт, а полнофункциональное приложение с интерактивным чат-ботом, аутентификацией и другими функциями, перечень которых впоследствии будет расширяться. Приложение построено на платформе Bubble. Это инструмент, который заслуживает отдельного внимания, про него я обязательно еще расскажу в дальнейшем, но пока можешь взять на заметку, что это штука, которая позволяет реализовать практически любой «фронт», то есть всё, что можно делать в браузере. Завтра расскажу про то, что находится под капотом пользовательских интерфейсов в виде сайта и мобильных приложений.

🤨 Ну что, вот и первые разборки в области авторского права с участием искусственного интеллекта подъехали. Итак, что мы имеем. Художницу Кристину Каштанову, которая создала целый комикс с помощью Midjorney, нагенерив изображения для него и опубликовала свою работу как художественное произведение. Дальше она подала заявку на регистрацию авторского права на это произведение в бюро авторского права США. Сначала было ей выдали авторское право полностью, но затем решили отозвать своё решение. Статью опубликовал портал The Varge, где приведена ссылочка на письмо, которое было отправлено юристу Каштановой. В этом письме сказано, что она «является автором текста произведения, а также отбора, согласования и организации текстовых и визуальных элементов произведения», но изображения в нём «не являются продуктом за авторством человека». И, соответственно, те авторские права, которые изначально были выданы, теперь отозваны. Там же есть пояснения о том, что при регистрации самого произведения, сведений о том, что была использована Midjorney для генерации изображений в этом комиксе, не было. То есть свидетельство было выдано на основании неточной и неполной информации, поэтому его и отозвали. Сама Кристина, разумеется, была расстроена таким решением и сейчас, судя по её посту в Instagram, продолжает изучать варианты с помощью своего адвоката и разобраться вместе с бюро авторского права с тем, что «отдельные изображения, созданные Midjorney, являются прямым выражением её творчества и тем самым подлежат защите авторским правом». Очень интересный прецедент и любопытно посмотреть, чем же всё закончится. Но это уже наши с вами реалии. Будущее наступило, господа.

Что такое webhook В одном из предыдущих постов я упомянул про webhook (вебхук), который использовался для того, чтобы собирать данные пользователей, которые они отправляют при заполнении формы на сайте. Давай разбираться, что же это такое. Hook в переводе с английского – это крючок, на который мы ловим рыбу, то есть какие-то данные от пользователя, либо данные, отправляемые при определённых событиях. Представь, что ты сидишь в ресторане, тебе уже принесли еду и ты важно трапезничаешь. И вдруг у тебя появляется непреодолимое желание срочно заказать десерт после второго блюда. Но это ресторан не топовый мишленовский, где за тобой пристально наблюдают официанты и знают, когда к тебе нужно подойти, а где работают такие ленивые ребята, и пока их сам не позовёшь, они к тебе никогда не подойдут. Но у тебя на столе есть очень клёвая штука – звоночек, позвонив в который, ты сразу обратишь на себя внимание и официанты поймут, к какому столу нужно подойти и выяснить, чего же ты желаешь. Вот нажатие на этот самый звонок и есть, по сути, вызов вебхука. Дальше, когда к себе подходит официант, тебе нужно загрузить его информацией, то есть передать ему название конкретного блюда, которое ты хочешь на десерт. Данные в webhook обычно передаются в формате JSON (джейсон), который включает названия параметров и их значения. Например, параметр – блюдо и его название – чизкейк. Итак, тебе подошёл официант, ты загружаешь его данными «блюдо = чизкейк» и он уходит его готовить (не сам конечно, он же ленивый). То есть дальше уже происходит некий другой процесс, который запрограммирован в этой системе. И вот эта вся связка звоночек + сам официант, который умеет принимать данные и есть, по сути, webhook. Это программный код с определённым «крючком» – адресом в сети, на который можно отправить данные. При этом ты можешь делать это не обязательно по расписанию, а именно тогда, когда тебе этого захочется. Например, в описанном кейсе с сайтом кинофестиваля, это происходит каждый раз, когда пользователь регистрируется на киносеанс.

Итак, полная серия постов про кейс переноса системы регистрации на киносеансы: Часть 1. Постановка задачи Часть 2. Функции системы Часть 3. Дополняем список функций Часть 4. Функциональная архитектура AS IS (как есть) Часть 5. Дополняем архитектуру функциями Часть 6. Завершаем архитектуру системы AS IS Часть 7. Начинаем прорабатывать новую архитектуру системы Часть 8. Строим финальную архитектуру системы Часть 9. Добавляем уведомления

Финальный штрих Последний элемент, который я добавил в эту, систему – это уведомления о регистрации пользователей. В прошлом никаких уведомлений администрации фестиваля не приходило, то есть, они в принципе не знали о том, как идёт прогресс регистрации, кроме того, что могли просто зайти в таблицу Airtable и посмотреть, сколько там уже накопилось регистраций. А теперь им приходят уведомления в специально созданный для этого Telegram-канал, в который публикуется сообщение каждый раз, когда кто-то проходит регистрацию. Вся необходимая информация о пользователе и сформированный код отправляется в этот канал. Таким образом, администратор может воспользоваться как админкой, построенной на базе Directual, так и просто заглянув в Telegram, который всегда под рукой и, воспользовавшись поиском, например, по имени пользователя, сразу найти, а какой же код ему принадлежит. Итак, мы выполнили первоначально поставленную задачу, то есть теперь система полностью работает на сервисах, которые можно оплачивать российскими картами или со счёта юрлица и она полностью отвечает тем требованиям, которые мы к ней предъявляем с точки зрения функциональности. И вся эта штука построена полностью на no-code решениях. И для внесения каких-то изменений, корректировок или настроек обычно тратятся буквально считанные минуты, что позволяет сильно экономить время и, в случае необходимости, вносить изменения прямо на лету, если вдруг администрация фестиваля заметит, что чего-то не хватает или что-то работает не совсем так, как ожидалось. Этим постом завершаю серию про решение этой задачки ещё раз напишу списком все посты, которые в неё входили и напомню, что все они также доступны в статье Teletype, где я собираю ссылки на все свои прошлые публикации. Напиши обязательно в комментариях, если нужно что-то ещё более детально объяснить, на чём-то остановиться более подробно, и что из этого тебе может быть интересным или полезным. Ну а мне, как всегда, важно получить от тебя обратную связь.

Строим финальную архитектуру системы Итак, всё, что было на прошлой схеме со знаком вопроса, мы заменяем на систему Directual и вот таким образом теперь будет выглядеть наша функциональная архитектура между сайтом и SMS Aero, который отправляет финальное сообщение с подтверждением регистрации пользователю. У нас появляется одна система, которая включает в себя и интеграционный слой и базу данных с CRM-системой. В ней администратор может работать и проверять зарегистрировавшихся пользователей, и эта же система может генерировать код и давать команду на отправку SMS в систему SMS оповещений. Ну и разумеется, в первую очередь, она будет принимать данные формы регистрации, так как позволяет сделать это через собственный интеграционный слой. То есть, создав базу данных на этой системе, мы можем настроить так называемый webhook (вебхук, позже расскажу, что это такое), который будет принимать эти данные с каждой регистрации пользователей. А после каждой регистрации всё будет происходить по нашему процессу: будет генерироваться код из уникального идентификатора пользователя, далее будет отправляться вместе с командой на отправку в SMS Aero, пользователь получит SMS, администратор проверит принадлежность кода пользователю на входе на фестиваль в админке, которая как раз является частью этой системы. Таким образом у нас не просто получилось заменить системы на те, которые можно будет оплатить без проблем, но и значительно упростить всю архитектуру, уменьшив количество участников этой цепочки. Чем меньше, тем проще и, как правило, надёжнее всё это дело работает, потому что следить за тремя системами в данном случае намного проще, чем за четырьмя, да и вероятность отказа с уменьшением количества систем тоже уменьшается. Завтра расскажу об ещё одной полезной фишке, которую я добавил в эту систему. Как думаешь, чего не хватает?

Начинаем прорабатывать новую архитектуру системы Напомню, что нам нужно заменить Integromat и Airtable такими сервисами, которые можно будет оплачивать российскими картами или со счёта юрлица. Соответственно, нам нужно что-то, что могло бы в себе содержать базу данных и использоваться как CRM-система и что-то, что позволит реализовать интеграционный слой. Здесь на помощь приходит знание рынка no-code решений и тех продуктов, которые на нём представлены. Если ты его знаешь, то в принципе, можешь сразу прикинуть, а что же может заменить ту или иную систему. На текущий момент мне неизвестны сервисы, которые позволяли бы полноценно заменить собой Airtable и Integromat в отдельности. Если ты знаешь такие примеры, то напиши, пожалуйста, в комментариях, возможно, что-то пока не попало в мою картину мира. Но, насколько мне известно, российского аналога Airtable или Integromat пока нет. Также здесь, конечно же, помогает опыт работы с такими системами, понимание тех возможностей, которые они предоставляют. Если я работал с тем или иным сервисом и хорошо его знаю, то, разумеется, я могу сказать, что на нём можно реализовать. Не буду здесь долго тянуть: на нашем рынке есть такая система, созданная российскими разработчиками – это Directual (Дирекшуал), которая относится к классу систем backend-as-a-service (бэкенд как сервис), и она представляет собой полновесное решение для построения базы данных, интеграционного слоя и программной логики. Зная возможности системы Directual, можно попробовать прикинуть, каким образом будет выглядеть эта функциональная архитектура и всё ли получится реализовать с помощью этого сервиса. Если да, то мы сможем приступить к следующему этапу – уже непосредственно разработке и переносу логики на новую архитектуру.

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

​​Продолжаем разбирать функциональную архитектуру системы в том виде, как она есть сейчас AS IS Четвёртая по счёту функция из нашего списка – это функция администрирования заявок сайта. И Airtable предоставляет эту возможность. То есть это не просто база данных, система позволяет просматривать эти данные, их по-разному структурировать, сортировать, фильтровать, искать нужные записи и всячески играться с ним. То есть, по сути, это два в одном – база данных и своего рода админка. Как минимум, для функция проверки заявок с сайта и сверки кода, который нам показывает посетитель на входе, она точно подходит. Следующее – генерация уникального кода. Так как Airtable достаточно хорошо автоматизирован, то мы можем использовать её и для этой функции тоже. На каждую запись система генерирует уникальный идентификатор, то есть код, по которому мы можем однозначно вычленить нужную нам запись в этой базе. Представь, что ты нумеруешь посетителей сайта числом, начиная с нуля и до бесконечности. То есть одному посетителю будет присвоено число 25, другому 301 и ты всегда можешь точно сказать по этому номеру, сверив его с таблицей, кто ему принадлежит. Это и есть уникальный идентификатор. Главное, не присвоить одно и то же число двум разным людям, тогда он точно будет уникальным. Ну а в нашем случае за уникальность автоматически следит система. И поэтому, чтобы не городить ничего лишнего, никаких лишних костылей, можем просто использовать эти идентификаторы, взять из них первые четыре символа и использовать их в качестве кода, который мы будем отправлять в SMS. Так я это и делаю в данной архитектуре. Так, как идентификаторы уникальные, то совпадение даже по первым четырем символам на достаточно больших выборках крайне маловероятно. И на самом деле, даже если к нам придут два разных человека с одинаковым кодом, в этом нет, ничего страшного, потому что у нас будут две записи, в которых мы увидим и первого и второго человека с одним и тем же кодом. То есть я знаю, что система их так сгенерировала. И мы можем спокойно пропустить их на фестиваль. То есть здесь какой-то пересылки быть не может, потому что пользователь уже зарегистрирован в нашей системе, и мы можем его найти. Другое дело, если придут два человека с одинаковым кодом и одного из них не будет в базе. Тогда к нему будут вопросы, как он получил этот код.