demo chatroom
1.0.0
go+iris+jwt+mysql+xorm+viper — простой чат для проекта iris, включающий вход в систему, регистрацию, приватный и групповой чат.
Во-первых, взгляните на введение в интерфейс ниже этого документа, чтобы узнать, как с ним работать (из-за ограниченной мощности пользовательский интерфейс не особенно удобен для пользователя).
Доступ к демонстрационному адресу. Если состояние маленького значка выше нормальное, вы можете получить к нему доступ. Он может перейти в спящее состояние, и вам придется подождать несколько секунд.
Проект на данный момент пишет только адаптации, связанные с mysql, но с помощью xorm несложно поддерживать другие базы данных. Это можно сделать, но это не обязательно. Ха-ха-ха, если лень запускать самому, просто посмотрите. по URL-адресу демо-версии. Если вам интересно, MySQL сейчас ни у кого нет.
Я изначально хотел поддерживать sqlite, чтобы не было необходимости настраивать параметры базы данных, но учитывая, что компиляция sqlite под Windows требует настройки среды gcc, что более хлопотно, но эффекта быстрого запуска нет, и он просто неполный. , поэтому другие базы данных на данный момент не поддерживаются (когда-нибудь добавьте больше, когда у вас будет время).
Таким образом, в проекте необходимо настроить только следующие параметры:
git clone https://github.com/JabinGP/demo-chatroom.git
cd demo-chatroom
// 复制config.toml.example 为 config.toml 并填写数据库信息，或者可选修改端口号
go run main.go По умолчанию используется порт 8888. После запуска перейдите по адресу http://localhost:8888
Я использовал реакцию, но не использовал UI framework. Многие мелкие детали выполнены не очень хорошо. Интерфейс сделан по размеру мобильника. Если открыть компьютер, то можно открыть f12. Давайте обойдемся без этого.
В окне чата окно автоматически прокручивается вниз, но API предоставляется React и оказывается несовместимым со многими браузерами. Эту проблему можно решить с помощью браузера Chrome.
После регистрации вручную вернитесь и выберите логин. Красное имя в окне сообщения предназначено для публичного выступления, а серое имя — для приватного чата. В красном поле можно указать имя получателя. Если не указано, используется значение по умолчанию. публичное выступление. После указания информацию смогут видеть только соответствующие пользователи.
Ваше имя пользователя отображается в синем поле. Нажмите, чтобы выйти напрямую.
Формат API основан на restful дизайне, а функция входа выполняется с использованием jwt. Многие интерфейсы требуют статуса входа, и при запросе необходимо передавать JWT. Кроме того, это так. удобно для тестирования. Срок действия выдачи JWT установлен всего на 20 минут. Необходимо повторно войти в систему.
Формат запроса API такой же, как и общий интерфейс. Get использует Params, а Post, Put, Delete и т. д. используют Json в теле для передачи параметров.
Формат возврата довольно спорный. Я изучал его некоторое время. Некоторые люди рекомендуют использовать полный код состояния 200 http и добавлять код к содержимому возврата, чтобы определить ошибку, например:
// 注册错误时
// http status 200
{
"code" : 40001 ,
"msg" : "注册用户名非法"
} // 注册成功时
// http status 200
{
"code" : 200 ,
"msg" : "成功" ,
"data" : {
"username" : " JabinGP " ,
"id" : 3
}
}Другие рекомендуют использовать полные коды состояния http для обозначения ошибок:
// 注册错误时
// http status 400
{
"msg" : "注册用户名非法"
} // 注册成功时
// http status 200
{
"username" : " JabinGP " ,
"id" : 3
}На самом деле, оба вышеперечисленных подхода имеют свои плюсы и минусы:
Основываясь на приведенной выше ситуации, я объединим два:
В случае успеха верните код состояния http 200.
// 注册成功时
// http status 200
{
"username" : " JabinGP " ,
"id" : 3
}При возникновении сбоя выберите несколько часто используемых кодов состояния для обозначения ошибки: 400 (ошибка запроса), 500 (внутренняя ошибка сервера), 404 (не найден), 401 (ошибка аутентификации), примерно классифицируйте ошибку, а затем верните команду Настроить код, сообщение и подробности в данных, чтобы представить подробную причину ошибки:
// 注册失败
// http status 400
{
"code" : 6 ,
"msg" : "数据检验失败" ,
"detail" : "用户名已存在"
} // 登录失效
// http status 401
{
"code" : 8 ,
"msg" : "未认证登录" ,
"detail" : " Token is expired "
}После этой комбинации успешный обратный вызов считается успешным, и нет необходимости повторно записывать res.data.data. Обратный вызов ошибки обрабатывает только ошибки, о которых можно судить по коду состояния http и которые можно дополнительно закодировать, msg и. подробное описание ошибок.
Список API выглядит следующим образом: Замените localhost на mike.jabingp.cn или вы можете напрямую запросить демонстрационный сервер:
| Функция | Метод запроса | адрес |
|---|---|---|
| Получить токен входа | ПОЧТА | http://localhost:8888/v1/логин |
| Найти пользователей | ПОЛУЧАТЬ | http://локальный хост:8888/v1/пользователь |
| зарегистрироваться | ПОЧТА | http://локальный хост:8888/v1/пользователь |
| Пользователи сами изменяют информацию | ПОМЕЩАТЬ | http://локальный хост:8888/v1/пользователь |
| Пользователь отправляет сообщение | ПОЧТА | http://localhost:8888/v1/сообщение |
| Пользователь получает информацию | ПОЛУЧАТЬ | http://localhost:8888/v1/сообщение |
| Пользователь получает информацию о токене | ПОЛУЧАТЬ | http://localhost:8888/v1/токен/информация |
Подробные параметры запроса можно посмотреть в документации postman-api демо-чата.
Или просмотрите исходный код. Параметры запроса можно просмотреть в model/reqo , а параметры ответа — в model/reso
AJAX — не лучший выбор для функции чата, лучше использовать WebSocket, но меня попросили использовать AJAX, поэтому я не выбрал последнее.
Интерфейс проекта относительно прост, поскольку он используется только в качестве демо-версии.
Мой английский не очень хорош, и комментарии к коду на английском только потому, что мне лень переключать метод ввода.
Это первый раз, когда я использую go для разработки веб-проекта, а также впервые использую React для написания внешнего интерфейса. Поскольку внешний интерфейс не уделяет особого внимания структуре проекта (xjbx), я не буду. выкладываю исходный код, компилирую проект и кладу в папку assets для удобства чтения. Он очень убогий, но его можно запустить вместе с бэкендом. Фронтенд отдельно запускать не нужно, так удобнее посмотреть. эффект. Если у меня еще будет время, я рассмотрю возможность написания минималистской версии на родном языке для всеобщего ознакомления.
Когда я впервые использовал ORM для работы с базой данных, мне было очень сложно его использовать. Я предпочитал писать sql вручную. Было много желаемых эффектов, и я не мог найти решение, просматривая документы в течение долгого времени. Возможно, позже я рассмотрю возможность использования sqlx для реконструкции.
Недавно я стал больше интересоваться Go, и мне было поручено написать простой чат. Я обнаружил, что на данный момент в iris мало практик проектов, только несколько примеров уровня HelloWorld, поэтому я решил использовать для этого Go. , а затем открыть исходный код для взаимного использования. Конечно, Как спроектировать структуру проекта, полностью основано на моем ограниченном опыте разработки. Пожалуйста, выскажите свое ценное мнение по любым необоснованным аспектам.
Этот проект имеет следующие требования
На этот раз функция входа реализована с использованием JWT . Преимущества и недостатки JWT и Session не будут подробно обсуждаться.
Использование AJAX является обязательным для всех проектов разделения внешнего и внутреннего интерфейса, поэтому эта функция не будет обсуждаться слишком подробно. В чем сложность?
Логика работы пользователя заключается в отправке данных в комнату чата, а затем данные отправляются. Интерфейс чата должен отображать отправленные данные и обновлять данные, отправленные другими, в режиме реального времени.
Интерфейсная и серверная части взаимодействуют через AJAX. Данные отправки внешнего интерфейса и данные отправки внутренней части могут быть выражены как.
В чем здесь проблема? Проблема в том, что передняя часть может только активно инициировать запросы, а задняя часть может только принимать запросы. Это означает, что последние сообщения никогда не могут быть активно отправлены из серверной части во внешний интерфейс в режиме реального времени. Последние сообщения можно сначала сохранить только во внутренней части, а затем дождаться, пока внешний интерфейс инициирует запрос, прежде чем серверная часть сможет вернуть данные.
Поскольку серверная часть не имеет возможности активно отправлять сообщения во внешний интерфейс, решение для пользователей по получению последних данных состоит в том, чтобы внешний интерфейс установил таймер每隔一段比较短的时间就请求一次后台接口（轮询） , чтобы данные могут постоянно обновляться.
Интерфейсная часть решила использовать AJAX для регулярного опроса фонового интерфейса для получения последних данных. Для получения данных в реальном времени интервал опроса будет小于1s , это приведет к еще одной проблеме.При таких частых запросах серверная часть не должна каждый раз передавать все данные. Одна из них — это эффективность передачи данных по сети и стоимость трафика, вызванная размером данных. Решение внешнего интерфейса о новых данных означает, что серверная часть должна возвращать данные, которые внешний интерфейс не получил каждый раз. Проблема в том, как серверная часть узнает, какую информацию получил внешний интерфейс?
Для этого необходимо использовать自增主键сообщения. Интерфейсному интерфейсу необходимо переносить только最后的消息的主键полученного внешним интерфейсом, каждый раз, когда он делает запрос, поскольку первичный ключ не является. повторяя и автоматически увеличивая, мы можем легко узнать соотношение. Данные с большим первичным ключом — это данные, которые интерфейсная часть еще не получила.
язык
рамка
хранение данных
технология
Из-за использования платформы ORM базы данных Xorm следующие таблицы генерируются автоматически и содержат поле
xxxxxx_at.
На основании вышеизложенных требований были спроектированы две таблицы: users и messages .
Ключевые поля
Структура таблицы базы данных
| Поле | Тип | Нулевой | Ключ | По умолчанию | Дополнительный |
|---|---|---|---|---|---|
| ИДЕНТИФИКАТОР | биинт(20) | НЕТ | ПРИ | НУЛЕВОЙ | auto_increment |
| имя пользователя | варчар(255) | ДА | НУЛЕВОЙ | ||
| пароль | варчар(255) | ДА | НУЛЕВОЙ | ||
| пол | биинт(20) | ДА | НУЛЕВОЙ | ||
| возраст | биинт(20) | ДА | НУЛЕВОЙ | ||
| интерес | варчар(255) | ДА | НУЛЕВОЙ | ||
| создано_at | дата и время | ДА | НУЛЕВОЙ | ||
| обновлено_at | дата и время | ДА | НУЛЕВОЙ | ||
| удалено_at | дата и время | ДА | НУЛЕВОЙ |
Ключевые поля
Структура таблицы базы данных
| Поле | Тип | Нулевой | Ключ | По умолчанию | Дополнительный |
|---|---|---|---|---|---|
| ИДЕНТИФИКАТОР | биинт(20) | НЕТ | ПРИ | НУЛЕВОЙ | auto_increment |
| идентификатор_отправителя | биинт(20) | ДА | НУЛЕВОЙ | ||
| идентификатор_приемника | биинт(20) | ДА | НУЛЕВОЙ | ||
| содержание | варчар(255) | ДА | НУЛЕВОЙ | ||
| время отправки | биинт(20) | ДА | НУЛЕВОЙ | ||
| создано_at | дата и время | ДА | НУЛЕВОЙ | ||
| обновлено_at | дата и время | ДА | НУЛЕВОЙ | ||
| удалено_at | дата и время | ДА | НУЛЕВОЙ |
Следующая структура основана на личном опыте. Если есть что-то неуместное, пожалуйста, дайте нам свой ценный отзыв.
поджо
Как легко понять, это сущность, соответствующая базе данных, но не требующая однозначного соответствия с полями базы данных.
reqo (объект запроса), reso (объект ответа)
При выполнении запросов через разные интерфейсы параметры, которые могут передаваться, и данные ответа также различаются, поэтому для каждого интерфейса разрабатываются соответствующий объект запроса и объект ответа.
Ниже приводится мое личное понимание
Контроллер
Основная ответственность — принять параметры запроса, преобразовать их в reqo, выполнить простую проверку параметров запроса (мое личное определение — это проверка, не имеющая ничего общего с базой данных, например, ненулевая, ненулевая), вызвать функция уровня службы для получения результата pojo, а преобразование результата pojo инкапсулируется и возвращается в reso.
Услуга
Основная ответственность заключается в дальнейшей инкапсуляции интерфейса уровня Dao и предоставлении общего интерфейса для вызова контроллера. Возвращенные данные могут быть проверены в Службе, например (добавление новых пользователей, проверка наличия). имя пользователя повторяется).
Дао
По сути, метод здесь напрямую соответствует оператору SQL без какой-либо проверки. Полученные данные считаются надежными (они проверены параметрами слоев контроллера и сервиса), а возвращаемые данные могут быть POJO.
