Введение
“Сможет ли ChatGPT заменить меня на работе?”. Вопрос ведь далеко не новый. Уже написана не одна статья на подобную тему, где разбирается, может ли быть заменен человек в контексте той или иной профессии. Поэтому сразу СПОЙЛЕР: нет, не может. По крайней мере пока… На начало 2023 года ChatGPT это пока еще инструмент в руках человека. Об этом кстати сам сервис постоянно говорит пишет.
Поэтому чтобы эта статья чуть меньше походила на кликбейт, далее разберем, чем же ChatGPT может помочь архитектору. Разберу, в каких случаях лучше использовать, а в каких - нет. А также попутно подсвечу причины, почему этот сервис нельзя рассматривать как полноценную замену человеку.
При аналогии со взрослением человека “чат” находится на стадии пяти годовалого ребенка. Поэтому повторю, что я оцениваю возможности чата только на текущий момент. Вероятно, что через несколько лет, а может и месяцев, результаты будут сильно лучше.
Статья основана исключительно на моих размышлениях и опыте использования ChatGPT.
![](https://habrastorage.org/getpro/habr/upload_files/0c8/daf/436/0c8daf43696d7f8ed8f65d790e48c17b.jpg)
Эээксперименты!
В процессе проектирования архитектор учитывает не только требования к самому решению, но и десятки окружающих факторов. Например, корпоративные стандарты архитектуры, сервисы и приложения, которые можно или нужно переиспользовать. Зачастую также приходится иметь дело с “легаси”. Тогда вероятные параллельные процессы миграции на целевые решения повлияют на итоговую архитектуру.
Чтобы проверить ChatGPT в деле предлагаю абстрагироваться от выше перечисленного и представить, что стоит задача спроектировать приложение с нуля. Например, для стартап-проекта. Чуть позже я поясню, почему предлагаю именно такой кейс.
Итак, представим, что стартап планирует “импортозаместить” сервис Miro. На вход получены вот такие скудные требования:
”Необходимо спроектировать онлайн сервис: доска для совместной работы. Доску можно будет использовать для мозгового штурма, отслеживания задач, подготовки дорожных карт и рисования диаграмм. Предполагается, что у сервиса будет по крайней мере 1 млн пользователей, и до 100 тысяч одновременно активных. Сервис должен иметь открытый API для интеграции с внешними сервисами. Некоторые из наших клиентов захотят установить приложение на собственные сервера.”
Для качественного результата потребуется проработать дополнительные вопросы. Например, изучить пользовательские сценарии (включая не только клиентов, но и администраторов), узнать будет ли сервис доступен только в России, и какие возможности интеграции требуется предоставить внешним приложениям и т.д. Но чтобы описать доменную модель, определить первичный состав компонентов приложения и подготовить верхнеуровневую архитектуру, кажется, хватит и этого.
Пример проектирования с ChatGPT
Прежде, чем показать результаты совместного проектирования с ChatGPT, сделаю короткое отступление. С сервисом я взаимодействовал на английском языке. Причина простая: скорость его работы на английском и русском отличается по моим субъективным впечатлениям раз в 10. Не в пользу работы на русском. При этом качество ответов на русском в половине случаев оставляет желать лучшего. Не стал тратить время на то, чтобы разобраться почему. Могу только предположить, что в базе данных "чата" информации для на английском значительно больше чем на русском.
Ниже будут приведены выдержки общения с ChatGPT как переводе на русский из Google Переводчика, так и на английском в виде скриншотов. Смотрите любой удобный Вам вариант. Сразу прошу строго не судить мой английский. Я взаимодействовал с ChatGPT так, как бы хотел бы это делать подобным сервисом при решении рабочих задач.
Обработка первичных требований
Начнем с того, что дадим ChatGPT посмотреть на изначальные требования. В ответ “чат” дает общие рекомендации для верхнеуровневой архитектуры приложения. Там содержатся общие предложения по составу и возможным технологиям, которые подойдут для большинства проектов. Отсутствует конкретика, но это нормально на таком раннем этапе проектирования.
На русском
Запрос
Необходимо спроектировать онлайн сервис: доска для совместной работы. Его можно будет использовать для мозгового штурма, отслеживания задач, подготовки дорожных карт и рисования диаграмм. Мы предполагаем, что у сервиса будет по крайней мере 1 млн пользователей, и до 100 тысяч одновременных активных. Сервис должен иметь открытый API для интеграции с внешними сервисами. Некоторые из наших клиентов захотят установить его локально
Ответ ChatGPT
С учетом вышеперечисленных компонентов можно предложить следующую схему построения онлайн-доски для совместной работы:
Интерфейсное приложение: интерфейсное приложение будет разработано с использованием современных веб-технологий, таких как React, Redux и WebSockets. Приложение будет разработано для обеспечения быстрого и отзывчивого пользовательского интерфейса с обновлениями в реальном времени и функциями совместной работы.
Серверное приложение: внутреннее приложение будет разработано с использованием масштабируемого языка программирования, такого как Node.js, Python или Java. Приложение будет разработано для обработки большого количества одновременных пользователей и транзакций с упором на производительность и масштабируемость.
База данных: база данных будет разработана с использованием базы данных NoSQL, такой как MongoDB, Cassandra или Couchbase. База данных будет предназначена для обработки большого объема данных и обеспечения быстрого и надежного доступа к данным. База данных будет секционирована и сегментирована для обеспечения высокой доступности и масштабируемости.
API: API будут разработаны с использованием архитектуры RESTful с JSON или XML в качестве формата данных. API будут защищены с помощью аутентификации OAuth 2.0 или JWT для обеспечения безопасного доступа к данным. Версии API будут поддерживаться для обеспечения обратной совместимости и обеспечения стабильного интерфейса для внешних служб.
Развертывание: онлайн-доску можно развернуть в облаке с помощью таких сервисов, как AWS, Google Cloud Platform или Microsoft Azure. В развертывании будут использоваться технологии контейнеризации, такие как Docker и Kubernetes, для обеспечения масштабируемости и высокой доступности. Для локального развертывания онлайн-доску можно упаковать в контейнер Docker и развернуть в частном облаке или на локальных серверах.
Безопасность: онлайн-доска будет использовать стандартные методы обеспечения безопасности, включая шифрование данных, контроль доступа и аутентификацию пользователей. Онлайн-доска будет разработана в соответствии с отраслевыми стандартами, такими как HIPAA, GDPR и SOC 2.0. Для обеспечения безопасности онлайн-доски будут проводиться регулярные аудиты безопасности и сканирование уязвимостей.
Следуя приведенной выше схеме системы, мы можем создать масштабируемую, надежную и безопасную онлайн-доску для совместной работы, которую может использовать большое количество пользователей с функциями совместной работы в реальном времени и интеграцией API для сторонних сервисов.
На английском
Запрос
Ответ ChatGPT
Доменная модель
Следующим шагом будет логично попросить “чат” описать доменную модель. Это поможет понять, на сколько искусственный интеллект (далее ИИ) в целом понял контекст изначального запроса. С результатами можно ознакомиться ниже. От себя скажу, что в целом он сформировал неплохой базис и правильно понял суть проектируемого приложения.
Следующим шагом будет логично попросить “чат” описать доменную модель. Это поможет понять, на сколько искусственный интеллект (далее ИИ) понял контекст изначального запроса. С результатами можете ознакомиться ниже. Видно, что ChatGPT правильно понял суть проектируемого и предложил соответствующую модель.
На русском
Запрос
опиши доменную модель приложения
Ответ ChatGPT
Модель предметной области онлайн-доски для совместной работы будет состоять из следующих сущностей и их взаимосвязей:
Пользователь: этот объект представляет пользователей приложения. Пользователи могут создавать доски и управлять ими, добавлять других пользователей и сотрудничать с ними, а также выполнять различные действия с элементами доски. У каждого пользователя будет уникальное имя пользователя и пароль, а информация о его профиле будет храниться в базе данных.
Доска: этот объект представляет доску, созданную пользователями. На доске может быть несколько элементов, включая мозговой штурм, отслеживание задач, дорожные карты и схемы проектирования системы. Каждая доска будет иметь уникальный идентификатор, и к ней смогут получить доступ пользователи, получившие разрешение от создателя.
Элемент доски: этот объект представляет элементы доски, такие как заметки, задачи и диаграммы. Каждый элемент будет иметь уникальный идентификатор и может быть связан с доской. Элементы доски могут создаваться, редактироваться и удаляться пользователями, получившими разрешение от создателя.
Соавтор: этот объект представляет пользователей, которым было предоставлено разрешение на совместную работу на доске. Соавторы могут просматривать, редактировать и комментировать элементы доски, а создатель доски может добавлять или удалять их.
Внешняя служба: этот объект представляет внешние службы, которые можно интегрировать с онлайн-доской. Внешняя служба может получить доступ к данным доски с помощью API-интерфейсов, предоставляемых онлайн-доской, и может выполнять различные действия с элементами доски.
Отношения между этими сущностями можно резюмировать следующим образом:
Пользователь может создавать несколько досок и может быть соавтором на нескольких досках.
Доска может иметь несколько элементов доски, и каждый элемент доски может быть связан только с одной доской.
У доски может быть несколько соавторов, и каждый соавтор может быть связан с несколькими досками.
Внешняя служба может получить доступ к данным доски с помощью API-интерфейсов, предоставляемых онлайн-доской.
В целом, доменная модель онлайн-доски для совместной работы предназначена для поддержки нескольких пользователей, досок и элементов с функциями совместной работы в реальном времени и интеграцией API для сторонних сервисов.
На английском
Запрос
Ответ ChatGPT
Кстати, можно представить результат в разных вариантах. Например, с использованием PlantUML:
Доменная модель в PlantUML
@startuml
class User {
+username: string
+password: string
+email: string
+firstName: string
+lastName: string
+createBoard(): void
+addCollaborator(boardId: int, collaboratorId: int): void
+removeCollaborator(boardId: int, collaboratorId: int): void
}
class Board {
+boardId: int
+name: string
+description: string
+createBoardElement(elementType: string): BoardElement
+addCollaborator(collaboratorId: int): void
+removeCollaborator(collaboratorId: int): void
}
class BoardElement {
+elementId: int
+elementType: string
+content: string
+createSubElement(subElementType: string): BoardElement
}
class Collaborator {
+collaboratorId: int
+username: string
+email: string
}
class ExternalService {
+serviceId: int
+name: string
+description: string
+apiKey: string
+createBoardElement(boardId: int, elementType: string): BoardElement
}
User "1" -- "" Board
Board "1" -- "" BoardElement
Board "1" -- "" Collaborator
ExternalService "1" -- "*" BoardElement
@enduml
Выбор архитектурного стиля
Дальше стоит задача выбрать архитектурный стиль. “Чат” вполне ожидаемо предложил использовать микросервисы. И проблема тут не в том, считаю ли я это правильным. А в том, что я еще сам не знаю, подходят ли в данной ситуации микросервисы, потому что пока не известны переменные, которые могут повлиять на выбор. Какими ресурсами располагает проект? Какие у сроки разработки? Доступны ли будут автоматизированные средства деплоя, сервисы логирования (журналирования), и управления ключами и сертификатами? Это еще без учета рекомендаций из прекрасной статьи Мартина Фаулера “Сначала монолит”. Также надо понимать цели заказчика. Например, если цель - сделать MVP за неделю, то микросервисы (в составе, который далее предложит “чат”) тут не подойдут. Кто-то скажет, что тогда тут вероятно и архитектор не нужен. И я буду согласен. Но только этого никак не узнать, кроме как задавая вопросы. Как раз то, что ChatGPT пока не умеет спрашивать вопросы, и есть одна из причин, почему “чат” не может самостоятельно выполнять обязанности архитектора решений или многих других профессий. Об остальных причинах поговорим позже.
На русском
Запрос
какой архитектурный стиль должен быть использован для бэкенда
Ответ ChatGPT
Для серверного приложения онлайн-доски для совместной работы подходит архитектурным стилем будет архитектура микросервисов. Архитектура микросервисов — это стиль распределенной архитектуры, который включает в себя разбитие монолитного приложения на небольшие независимые сервисы, которые можно разрабатывать, разворачивать и масштабировать независимо друг от друга. Каждый сервис в микросервисной архитектуре отвечает за определенную функциональность, и взаимодействует с другими сервисами, используя облегченные протоколы, такие как HTTP/REST или очереди сообщений. Архитектура микросервисов предлагает несколько преимуществ для онлайн-приложений, включая:
Масштабируемость: каждый микросервис можно масштабировать независимо, что позволяет приложению для обработки большого количества пользователей и запросов.
Отказоустойчивость: сбой одного микросервиса не влияет на другие микросервисы. Обеспечение доступности приложения.
Гибкость: каждый микросервис можно разрабатывать, тестировать и развертывать независимо друг от друга. Позволяет команде быстро проводить итерации и инновации.
Модульность. Каждый микросервис автономен, его можно развивать и поддерживается отдельной командой, что может улучшить ремонтопригодность и масштабируемость приложения.
Интеграция. Архитектура микросервисов позволяет легко интегрироваться с другими сервисами и системами, что делает его подходящим для открытых требований APIприложение.
В целом, архитектура микросервисов является подходящим архитектурным стилем для серверной части онлайн-доски для совместной работы, учитывая ее масштабируемость, отказоустойчивость, гибкость, модульность и возможности интеграции.
На английском
Запрос
Ответ ChatGPT
Архитектура бэкенда
Допустим, решили сразу делать микросервисы. Теперь проработаем, какие компоненты, включая микросервисы, нужны в приложении, и как они будут взаимодействовать. Пока что ChatGPT не отклоняется от первоначальной задумки и предлагает реализовать по микросервису на каждую сущность, которые были выделены на шаге определения доменной модели. Также предлагается использовать API шлюз, реляционную базу данных и брокер сообщений. Пока все логично.
На русском
Запрос
Хорошо. Подготовь детальный дизайн серверного приложения
Ответ ChatGPT
Конечно, вот подробный дизайн внутреннего приложения для онлайн-доски для совместной работы с использованием архитектуры микросервисов:
Сервис пользователей: этот микросервис будет обрабатывать аутентификацию пользователей, регистрацию и управление профилями. Он будет хранить пользовательские данные в базе данных и предоставлять API-интерфейсы REST для внешнего приложения и других микросервисов для доступа к информации, связанной с пользователем.
Сервис доски: этот микросервис будет заниматься созданием доски, управлением и совместной работой. Он будет хранить данные платы в базе данных и предоставлять REST API для интерфейсного приложения и других микросервисов для доступа к информации, связанной с платой.
Сервис элементов доски: этот микросервис будет заниматься созданием, управлением и совместной работой элементов доски, таких как заметки, задачи и диаграммы. Он будет хранить данные об элементах платы в базе данных и предоставлять API-интерфейсы REST для интерфейсного приложения и других микросервисов для доступа к информации, связанной с элементами платы.
Сервис соавторов: этот микросервис будет управлять соавторами на доске. Он будет хранить данные о соавторах в базе данных и предоставлять API-интерфейсы REST для интерфейсного приложения и других микросервисов для доступа к информации, связанной с соавторами.
Интеграция внешних сервисов. Этот микросервис будет обеспечивать интеграцию внешних сервисов с онлайн-приложением. Он предоставит API-интерфейсы для внешних сервисов для безопасного и контролируемого доступа и изменения данных платы и элементов платы.
Шлюз: этот микросервис будет выступать в качестве шлюза API для внешнего приложения и других микросервисов для доступа к внутренним сервисам. Он будет обрабатывать маршрутизацию запросов, аутентификацию и ограничение скорости.
Message Broker: этот компонент будет отвечать за асинхронную связь между микросервисами. Он будет использовать очередь сообщений, такую как Apache Kafka, для обеспечения надежной доставки сообщений и разделения микросервисов.
База данных: внутреннее приложение будет использовать масштабируемую и надежную базу данных, такую как PostgreSQL или MySQL, для хранения данных о пользователях, досках, элементах доски и соавторах.
Аутентификация и авторизация: внутреннее приложение будет использовать стандартные отраслевые протоколы аутентификации и авторизации, такие как OAuth2 или JWT, для защиты API пользователей и микросервисов.
Развертывание: серверное приложение будет развернуто в облачной инфраструктуре, такой как AWS, Azure или Google Cloud Platform, для обеспечения масштабируемости, доступности и надежности. Микросервисы будут развертываться с использованием технологии контейнеризации, такой как Docker, и управляться с помощью Kubernetes.
В целом, этот внутренний дизайн с использованием архитектуры микросервисов обеспечит масштабируемую, надежную и гибкую инфраструктуру онлайн-доски для совместной работы с простой интеграцией с внешними сервисами и возможностью обработки большого количества пользователей и запросов.
На английском
Запрос
Ответ ChatGPT
Углубимся в детали
С этого момента буду пропускать некоторые этапы, чтобы не захламлять статью скринами и переводами.
Далее я спросил о возможности использования внешнего сервиса аутентификации, на что ChatGPT предложил использовать популярный сервис Auth0. Для российских пользователей правда этот сервис с недавних пор недоступен. Здесь сложно сказать, учитывал ли бы “чат” мое географическое положение, если была возможность взаимодействовать с ним без VPN. Возможно, он и предложил бы использовать другое решение. Тем не менее можно уточнить запрос и попросить найти сервис, который будет доступен на той или иной территории.
Затем я попросил ChatGPT объединить сервисы Доски и Соавторов. Причина: в нашем выдуманном случае информация о соавторах нужна будет только при загрузке доски. С этого момента ИИ почему-то “поплыл”. При обновлении состава приложения были забыты два компонента (сервис Элементов доски и брокер сообщений), которые сервис сам же и предложил использовать во время проработки архитектуры бэкенда. Правда после напоминания последовало моментальное исправление. Но тем не менее это уже звоночек, что требуется перепроверять ответы.
На русском
Запрос
Хорошо. Давай тогда объединим их. Пожалуйста, обновите дизайн системы
Ответ ChatGPT
Конечно, вот обновленный дизайн системы, в котором сервисы Board и Collaborators объединены в один сервис:
Как видите, функциональность Collaborators теперь интегрирована в Board Service, а не является отдельным микросервисом. Этот дизайн уменьшает количество микросервисов и упрощает общую архитектуру, но при этом обеспечивает необходимую функциональность для совместной работы на досках.
Основные компоненты обновленной конструкции системы следующие:
Клиентское приложение: внешнее приложение, которое позволяет пользователям взаимодействовать с системой, создавать и изменять доски, а также сотрудничать с другими пользователями.
Шлюз API: точка входа для всех внешних запросов к системе, которая направляет запросы в соответствующие микросервисы.
Служба доски: микрослужба, отвечающая за управление данными доски, включая создание, обновление и удаление досок. Этот сервис также включает в себя функцию Collaborators, позволяющую пользователям сотрудничать на досках с другими пользователями.
База данных: хранилище всех данных доски и пользователей, включая метаданные доски и профили пользователей.
Служба аутентификации: SaaS-решение для аутентификации, регистрации и управления профилями. Эта служба используется для аутентификации пользователей и управления профилями пользователей, но пользовательские данные по-прежнему хранятся в базе данных, управляемой службой пользователей.
Пользовательская служба: микрослужба, отвечающая за управление пользовательскими данными, включая хранение и извлечение профилей пользователей, управление ролями и разрешениями пользователей, а также отслеживание действий пользователей.
Благодаря этому обновленному дизайну системы функции Board Service и Collaborators теперь объединены, но User Service по-прежнему необходим для управления пользовательскими данными, включая аутентификацию пользователей и управление профилями.
На английском
Запрос
Ответ ChatGPT
“Забывчивость” ChatGPT
В процессе “чат” несколько раз забывал различные детали и договоренности. Поделюсь еще одним примером.
Итак, углубимся в детали реализации сервиса Элементов доски. Помимо прочего, ChatGPT предложил для API сервиса использовать только REST. Так как планируется реализовать онлайн доску для совместной работы, пользователи должны получать обновления в реальном времени. На вопрос, будет ли достаточно использовать только REST, сервис тут же ответил, что действительно хорошо было бы использовать WebSockets. Однако тут же после просьбы описать API сервиса, идея использовать WebSockets забылась. В ответ было получено описание только REST ресурсов. Только после второго напоминания и просьбы описать API с использованием спецификации Asyncapi я получил то, что хотел.
На русском
Запрос
опиши то же самое, используя нотацию asyncapi
Ответ ChatGPT
asyncapi: 2.0.0 info: title: Board Element Service API version: 1.0.0 description: AsyncAPI specification for the Board Element Service API channels: boardElementsCreated: description: Channel for board elements created on a board subscribe: summary: Subscribe to board element creation events operationId: subscribeToBoardElementsCreated message: payload: $ref: "#/components/schemas/BoardElement" boardElementsUpdated: description: Channel for board elements updated on a board subscribe: summary: Subscribe to board element update events operationId: subscribeToBoardElementsUpdated message: payload: $ref: "#/components/schemas/BoardElement" boardElementsDeleted: description: Channel for board elements deleted from a board subscribe: summary: Subscribe to board element deletion events operationId: subscribeToBoardElementsDeleted message: payload: $ref: "#/components/schemas/BoardElementDeletedMessage" components: schemas: BoardElement: type: object properties: id: type: string description: The ID of the board element type: type: string description: The type of the board element content: type: string description: The content of the board element x: type: number description: The x-coordinate of the board element y: type: number description: The y-coordinate of the board element width: type: number description: The width of the board element height: type: number description: The height of the board element color: type: string description: The color of the board element font_size: type: number description: The font size of the board element created_by: type: string description: The ID of the user who created the board element updated_by: type: string description: The ID of the user who last updated the board element created_at: type: string description: The timestamp of when the board element was created updated_at: type: string description: The timestamp of when the board element was last updated BoardElementDeletedMessage: type: object properties: id: type: string description: The ID of the board element that was deleted message: type: string description: A message indicating that the board element was successfully deleted
На английском
Запрос
Ответ ChatGPT
Архитектурные решения
Не хочу превращать статью в критику ChatGPT. Так как цель не в критике, а в том, чтобы разобраться для решения каких задач он будет полезен, а для каких нет. Поэтому вот пример, где сервис предложил осознанные и логичные решения.
В качестве СУБД для сервиса Элементов доски им была предложена NoSQL база данных DynamoDB. При этом были приведены понятные доводы. Добавлю для полного контекста: ранее в переписке с “чатом” было решено использовать AWS, в качестве облачной платформы для нашего приложения.
На русском
Запрос
какую базу данных мы можем использовать для сервиса элементов доски
Ответ ChatGPT
Для службы Board Element Service нам потребуется база данных, которая может обрабатывать большой объем операций чтения и записи, а также поддерживать высокий уровень параллелизма. Поскольку мы разрабатываем на AWS, хорошим вариантом будет использование Amazon DynamoDB.
DynamoDB — это полностью управляемая служба базы данных NoSQL, обеспечивающая быструю и предсказуемую производительность с плавной масштабируемостью. Он предназначен для рабочих нагрузок с малой задержкой, большими объемами и высокой пропускной способностью, что делает его идеальным выбором для нашего варианта использования.
DynamoDB предоставляет возможность создавать таблицы с ключами разделов и ключами сортировки, которые можно использовать для индексирования и запроса данных. Это позволит нам эффективно хранить и извлекать данные элементов платы на основе их идентификаторов или других атрибутов. DynamoDB также предоставляет возможности автоматического сегментирования, репликации и резервного копирования, которые помогут обеспечить надежность и доступность данных.
Мы также можем использовать потоки DynamoDB для захвата изменений в данных элементов платы и публикации их в потоке. Затем этот поток можно использовать для запуска последующей обработки или для уведомления клиентов об изменениях в режиме реального времени.
В целом DynamoDB — это мощная и гибкая служба базы данных, которая может удовлетворить высокие требования к масштабируемости и производительности нашего онлайн-приложения.
На английском
Запрос
Ответ ChatGPT
Но впечатлило другое: после моего предложения использовать графовую БД, ChatGPT настоял на использовании DynamoDB и привел разумные аргументы. Более того, ответ мог бы быть занесен в документацию как полноценный ADR о выборе СУБД.
На русском
Запрос
хороший ли вариант использовать вместо этого какую-нибудь графовую базу?
Ответ ChatGPT
Использование графовой базы данных может быть хорошим вариантом, если модель данных приложения сильно взаимосвязана и включает сложные отношения между сущностями. Однако для случая использования онлайн-доски с такими элементами, как карточки, контрольные списки и комментарии, база данных NoSQL на основе документов, такая как DynamoDB, может подойти лучше.
Основное преимущество использования базы данных на основе документов заключается в том, что она позволяет создавать гибкую и динамичную схему, которая хорошо подходит для различных типов данных, которые могут быть связаны с элементами доски. Например, элемент карты может иметь такие атрибуты, как заголовок, описание, срок выполнения, метки и вложения, каждый из которых может иметь разные типы данных и структуры.
Напротив, графовые базы данных оптимизированы для управления сложными отношениями и выполнения запросов между взаимосвязанными объектами. Хотя это может быть полезно для определенных случаев использования, это может быть не нужно или неэффективно для приложения онлайн-доски, которое в основном включает управление и совместную работу над отдельными элементами.
При этом, если требования к приложению включают расширенные запросы и анализ взаимосвязей между элементами доски или между пользователями, хорошим вариантом может стать графовая база данных, такая как Amazon Neptune. Однако для этого потребуется другая модель данных и, возможно, более сложная реализация, чем база данных на основе документов.
На английском
Запрос
Ответ ChatGPT
Этот момент наводит на мысль, что чем ниже слой абстракции, чем конкретнее вопрос и ближе к “земле”, тем больше пользы приносит ChatGPT. Сервису проще отвечать на вопросы о выборе технологии или архитектуре API или решать задачи генерации кода. Поэтому как раз для формулирования ADR по такого рода вопросам сервис может стать надежным помощником.
Поиск информации
Ни для кого не новость, что ChatGPT отличный инструмент для поиска информации. На мой взгляд, это пока сильнейшая сторона сервиса, где допускается минимальное количество ошибок. “Чат” может избавить от минут, а иногда и даже часов, серфинга интернета, чтения спецификаций и т.д.
Например, для того, чтобы узнать поддерживает ли AWS API Gateway функцию агрегации API, понадобился всего один запрос. Дополнительно я получил описание нескольких полезных сценариев использования этого облачного шлюза.
На русском
Запрос
может ли Amazon API Gateway агрегировать API?
Ответ ChatGPT
Да, Amazon API Gateway предоставляет возможность объединять несколько API и представлять их клиентам как единый API. Эта функция называется агрегацией API шлюза API.
Агрегация API Gateway API позволяет создать единую конечную точку API, которая интегрируется с несколькими серверными API или сервисами, такими как функции Lambda, конечные точки HTTP или сервисы AWS. Вы можете использовать API Gateway для преобразования и сопоставления входящих запросов и исходящих ответов с серверными API или службами, а также для выполнения проверок аутентификации и авторизации.
Агрегация API шлюза API может быть полезна в различных сценариях, например, когда вы хотите:
Объедините функциональность нескольких API или сервисов в единую конечную точку. Предоставьте клиентам унифицированный API, который абстрагирует базовую сложность внутренних API или сервисов. Собирайте данные из нескольких источников и возвращайте их клиентам в одном ответе. Реализуйте архитектуру микрослужб, в которой каждая микрослужба имеет собственный API, но клиенты взаимодействуют с помощью единого унифицированного API. В контексте онлайн-приложения доски мы можем использовать агрегацию API шлюза API для создания единой конечной точки API, которая объединяет функциональные возможности службы элементов доски, службы совместной работы и службы пользователя, как описано в моем предыдущем ответе.
На английском
Запрос
Ответ ChatGPT
А может у ChatGPT все таки получится работать за меня?
Архитектор редко сталкивается с задачей построить информационную систему с нуля без каких-либо ограничений. Зачастую задачи проектирования ставятся в условиях существующего ИТ-ландшафта, возможно какого-то “легаси”, ограничений технологического стека и требований корпоративной архитектуры.
Изначально план эксперимента с ChatGPT был амбициозней. Я хотел решить задачу с объемным контекстом. Однако столкнулся с двумя большими трудностями.
Во-первых, сложно этот контекст поместить в память “чата”. Становится понятно, что все детали сразу и не вспомнишь. Можно конечно же это делать по ходу решения задачи, но тогда взаимодействие превращается в постоянные поправки предложений, которые дает ChatGPT, и постоянное добавление новых ограничений. На это уходит так много времени, что перестает помогать и начинает мешать.
Во-вторых, “чат” продолжает забывать и смешивать информацию из интернета и из того контекста, который в него пытаются поместить. И чем больше ограничений вносится, тем ниже качество ответов. Предполагаю, причина разнице объемов и весов между данными, на которых обучался ChatGPT, и теми, что загружены при решении конкретной задачи.
Также необходимо понимать, что в компании есть информация, которая может оказаться чувствительной, но требуется для проектирования. То есть распространять её попросту нельзя, иначе эксперт ИБ (информационной безопасности) "по голове не погладит". ChatGPT в свою очередь при регистрации сообщает, что полученная от пользователя информация может быть доступна третьим лицам. Конечно этот момент можно проигнорировать, так как сотруднику ИБ будет сложно установить или проверить факт передачи чувствительных данных в ChatGPT. Но это на страх и риск каждого.
Чтобы такие сервисы как ChatGPT могли быть официально использованы в корпоративном мире ИТ, нужно выполнения как минимум двух условий:
Появление сервиса, который устанавливается внутрь изолированного контура компании;
Наличие способа обучить ИИ на базе знаний этой компании. При этом источников информации может быть много. Например, корпоративный Вики (прим. Confluence), различные письма и материалы из электронной почты, виртуальные доски (прим. Miro) и другие.
Поэтому пока ChatGPT лучше рассматривать скорее как консультанта или помощника, который может упростить жизнь, но не более.
Подводим итоги
Кажется очевидным, но стоит подчеркнуть, что ChatGPT это большой скачок вперед для человечества. Сервисы, построенные с использованием ИИ, уже уверенными шагами входят в нашу повседневную жизнь. Скоро мы будем воспринимать их как данность. Так было и будет со всеми другими “прорывными” технологиями.
Что касается использования “чата” для задач архитектора, то тут “палка о двух концах”. Думаю, что Вы по итогу прочтения предыдущих разделов уже успели самостоятельно сформулировать для себя первые выводы. Далее я обозначу преимущества и недостатки, которые показались самыми важными. Ваши же мысли буду рад обсудить в комментариях.
Преимущества
Удобство поиска информации. При этом ChatGPT не только отвечает на поставленный запрос, но и снабжает дополнительной релевантной информацией. На выходе пользователь получает не кучу статей, а “краткое содержание” всего объема данных, к которому есть доступ у сервиса и еще немного “сверху”. Это определяющее отличие от простого запроса в браузере;
Проведение сравнений нескольких технологий. Умение "чата" учитывать контекст, дает возможность генерировать почти полноценный ADR, а не прямолинейное сравнение характеристик, как на маркетплейсе;
Формирование шаблонов, чек-листов и т.д. Здесь все понятно: подходы к описанию решений во многих организациях похожи, структура приложений из одной отрасли тоже скорее всего будет также схожа. Поэтому ChatGPT запросто выполняет такие задачи: у него есть куча других примеров.
Недостатки
“Чат” не умеет задавать вопросы. А для любого архитектора это критичной навык, без которого невозможно выявить необходимые требования и детали. При первоначальной постановке задачи заказчик может многое упустить или посчитать неважным. В то же время любая упущенная деталь может быть важна при для архитектуры;
ChatGPT пока испытывает проблемы при работе внутри конкретного контекста. Чем больше привносишь деталей, чем больше итераций взаимодействия, на каждом из которых принимается новое решение или изменяется принятое ранее, тем чаще возникают ошибки или что-то забывается;
Проблема коммерческой тайны. Ни один эксперт ИБ не одобрит передачу чувствительных данных в ChatGPT, так как они автоматически становятся доступными третьим лицам, как минимум, разработчикам "чата". Поэтому ждем когда появятся хотя бы корпоративные лицензии, но вряд ли они будут доступны в России в ближайшее время.
Итого
В начале 2023 года ChatGPT находится на ранней стадии своего становления. При этом развивается он интенсивно: 14 марта 2023 компания OpenAI выпустила улучшенную версию сервиса, которая называется Chat-4. Утверждается, что ответы стали точнее, снизился процент нерелевантной и нецензурной информации. Поэтому будем наблюдать за развитием ChatGPT и других подобных сервисов. А также ждать появления новых возможностей и расширения границ уже существующих.
Технологии как ChatGPT, при правильном использовании, могут помочь выполнять больше работы с лучшим результатом, но с меньшими усилиями. Ведь это мечта каждого, согласитесь?
Спасибо
Спасибо за потраченное время.
Буду рад Вашей обратной связи по поводу статьи в комментариях.