demo chatroom
1.0.0
go+iris+jwt+mysql+xorm+viper, ruang obrolan sederhana yang praktis untuk proyek iris, dengan login, registrasi, obrolan pribadi, dan obrolan grup.
Pertama, lihat pengenalan front-end di bawah dokumen ini untuk mengetahui cara mengoperasikannya (karena energi yang terbatas, UI tidak terlalu ramah pengguna).
Akses alamat demo. Jika status ikon kecil di atas normal, Anda dapat mengaksesnya. Mungkin memasuki keadaan tidak aktif dan perlu menunggu beberapa detik.
Proyek saat ini hanya menulis adaptasi terkait mysql, tetapi dengan menggunakan xorm, tidak sulit untuk mendukung database lain. Bisa saja, tapi tidak perlu Hahaha, kalau malas menjalankannya sendiri, lihat saja di URL demo. Jika Anda tertarik Tidak ada yang memiliki mysql sekarang.
Saya awalnya ingin mendukung sqlite, sehingga tidak perlu mengkonfigurasi parameter database, tetapi mengingat kompilasi sqlite di bawah windows memerlukan konfigurasi lingkungan gcc, yang lebih merepotkan, tetapi tidak ada efek startup yang cepat, dan itu tidak lengkap , jadi database lain tidak didukung untuk saat ini (suatu hari nanti Tambahkan lebih banyak jika Anda punya waktu).
Jadi proyek hanya perlu mengkonfigurasi parameter berikut
git clone https://github.com/JabinGP/demo-chatroom.git
cd demo-chatroom
// 复制config.toml.example 为 config.toml 并填写数据库信息，或者可选修改端口号
go run main.go Defaultnya adalah port 8888. Setelah startup, akses http://localhost:8888
Saya menggunakan react, tetapi saya tidak menggunakan kerangka UI. Banyak detail kecil yang tidak dilakukan dengan baik. Antarmuka dibuat sesuai dengan ukuran ponsel. Jika Anda membuka komputer, Anda dapat membuka f12 .Mari kita selesaikan. Fokusnya adalah pada tujuan terakhir.
Kotak obrolan menyetel jendela untuk menggulir ke bawah secara otomatis, tetapi API disediakan oleh React dan ditemukan tidak kompatibel di banyak browser.
Setelah registrasi, kembali secara manual dan pilih login. Nama merah di kotak pesan adalah untuk pidato publik, dan nama abu-abu adalah untuk obrolan pribadi pidato publik. Setelah ditentukan, hanya pengguna terkait yang dapat melihat informasi tersebut.
Nama pengguna Anda ditampilkan di kotak biru. Klik untuk keluar secara langsung.
Format api didasarkan pada desain yang tenang, dan fungsi login diselesaikan menggunakan jwt. Banyak antarmuka memerlukan status login, dan JWT perlu dibawa saat meminta. Untuk detailnya, silakan lihat praktik jwt dari golang iris Selain itu nyaman untuk pengujian. Waktu validitas penerbitan JWT hanya diatur selama 20 menit. Perlu login lagi.
Format permintaan api sama dengan antarmuka umum. Get menggunakan Params, dan Post, Put, Delete, dll. menggunakan Json di Body untuk meneruskan parameter.
Format pengembalian cukup kontroversial. Saya telah menelitinya selama beberapa waktu. Beberapa orang menganjurkan penggunaan kode status 200 http lengkap dan menambahkan kode ke konten pengembalian untuk mengidentifikasi kesalahan, seperti ini:
// 注册错误时
// http status 200
{
"code" : 40001 ,
"msg" : "注册用户名非法"
} // 注册成功时
// http status 200
{
"code" : 200 ,
"msg" : "成功" ,
"data" : {
"username" : " JabinGP " ,
"id" : 3
}
}Yang lain menganjurkan penggunaan kode status http lengkap untuk menunjukkan kesalahan:
// 注册错误时
// http status 400
{
"msg" : "注册用户名非法"
} // 注册成功时
// http status 200
{
"username" : " JabinGP " ,
"id" : 3
}Faktanya, kedua pendekatan di atas memiliki kelebihan dan kekurangannya masing-masing:
Berdasarkan situasi di atas, saya akan menggabungkan keduanya:
Jika berhasil, kembalikan kode status http 200
// 注册成功时
// http status 200
{
"username" : " JabinGP " ,
"id" : 3
}Ketika kegagalan terjadi, pilih beberapa kode status yang umum digunakan untuk menyatakan kesalahan, 400 (kesalahan permintaan), 500 (kesalahan internal server), 404 (tidak ditemukan), 401 (kegagalan otentikasi), klasifikasikan kesalahan secara kasar, lalu kembali Sesuaikan a kode, pesan, dan detail dalam data untuk mewakili penyebab kesalahan secara detail:
// 注册失败
// http status 400
{
"code" : 6 ,
"msg" : "数据检验失败" ,
"detail" : "用户名已存在"
} // 登录失效
// http status 401
{
"code" : 8 ,
"msg" : "未认证登录" ,
"detail" : " Token is expired "
}Setelah kombinasi ini, panggilan balik yang berhasil berhasil, dan tidak perlu menulis res.data.data. Panggilan balik kesalahan hanya menangani kesalahan, yang dapat dinilai dari kode status http, dan dapat dikodekan lebih lanjut, pesan, dan dirinci. . untuk menangani kesalahan.
Daftar apinya seperti berikut. Ganti localhost dengan mike.jabingp.cn atau bisa langsung request ke backend demo:
| Fungsi | Metode permintaan | alamat |
|---|---|---|
| Dapatkan token masuk | POS | http://localhost:8888/v1/login |
| Temukan pengguna | MENDAPATKAN | http://localhost:8888/v1/user |
| daftar | POS | http://localhost:8888/v1/user |
| Pengguna memodifikasi informasi sendiri | MELETAKKAN | http://localhost:8888/v1/user |
| Pengguna mengirim pesan | POS | http://localhost:8888/v1/message |
| Pengguna mendapat informasi | MENDAPATKAN | http://localhost:8888/v1/message |
| Pengguna memperoleh informasi token | MENDAPATKAN | http://localhost:8888/v1/token/info |
Parameter permintaan terperinci dapat dilihat di dokumentasi tukang pos-api di ruang obrolan demo.
Atau lihat kode sumbernya. Parameter permintaan dapat dilihat di model/reqo dan parameter respons dapat dilihat di model/reso
AJAX bukan pilihan terbaik untuk fungsi chatting lebih baik, tapi saya diminta untuk menggunakan AJAX jadi saya tidak memilih yang terakhir.
Bagian depan proyek ini relatif sederhana karena hanya digunakan sebagai demo.
Bahasa Inggris saya kurang bagus, dan kode komentarnya dalam bahasa Inggris hanya karena saya terlalu malas untuk mengganti metode input.
Ini adalah pertama kalinya saya menggunakan go untuk mengembangkan proyek web, dan ini juga pertama kalinya saya menggunakan reaksi untuk menulis front-end. Karena front-end tidak terlalu memperhatikan struktur proyek (xjbx), saya tidak akan melakukannya meletakkan kode sumber. Saya mengkompilasi proyek dan memasukkannya ke dalam folder aset agar mudah dibaca. Ini sangat buruk, tetapi dapat dimulai bersama dengan backend memengaruhi. Jika saya masih punya waktu, saya akan mempertimbangkan untuk menulis versi minimalis dalam bahasa asli untuk referensi semua orang.
Ini adalah pertama kalinya saya menggunakan ORM untuk mengoperasikan database. Rasanya sangat sulit untuk digunakan. Saya lebih suka menulis SQL dengan tangan. Ada banyak efek yang diinginkan dan saya tidak dapat menemukan solusi setelah membaca dokumen untuk waktu yang lama. Saya akan mempertimbangkan untuk menggunakan SQLX untuk merekonstruksinya nanti.
Baru-baru ini, saya menjadi lebih tertarik pada Go, dan saya menerima tugas untuk menulis ruang obrolan sederhana. Saya menemukan bahwa saat ini hanya ada sedikit praktik proyek di iris, hanya beberapa contoh tingkat HelloWorld, jadi saya memutuskan untuk menggunakan Go untuk melakukannya. , dan kemudian menjadikannya sumber terbuka untuk referensi bersama. Tentu saja Cara merancang struktur proyek sepenuhnya berdasarkan pengalaman pengembangan saya yang terbatas. Tolong berikan pendapat Anda yang berharga tentang aspek apa pun yang tidak masuk akal.
Proyek ini memiliki persyaratan sebagai berikut
Fungsi login kali ini diimplementasikan menggunakan JWT . Kelebihan dan kekurangan JWT dan Session tidak akan dibahas secara detail.
Berbasis AJAX adalah suatu keharusan untuk semua proyek pemisahan front-end dan back-end, jadi fungsi ini tidak akan terlalu banyak dibahas. Fokusnya di sini adalah tidak ada penyegaran.
Logika operasi pengguna adalah mengirim data di ruang obrolan, dan kemudian data dikirim keluar. Antarmuka obrolan harus menampilkan data yang dikirim sendiri dan memperbarui data yang dikirim oleh orang lain secara real time.
Front-end dan back-end berkomunikasi melalui AJAX. Pengiriman data front-end dan pengiriman data back-end dapat dinyatakan sebagai
Apa masalahnya disini? Masalahnya adalah front end hanya dapat memulai permintaan secara aktif, dan back end hanya dapat menerima permintaan. Artinya, pesan terbaru tidak akan pernah bisa dikirim secara aktif dari backend ke frontend secara real time. Pesan terbaru hanya dapat disimpan di backend terlebih dahulu, lalu menunggu frontend memulai permintaan sebelum backend dapat mengembalikan data.
Karena backend tidak memiliki kemampuan untuk secara aktif mengirim pesan ke frontend, solusi bagi pengguna untuk mendapatkan data terbaru adalah frontend mengatur timer每隔一段比较短的时间就请求一次后台接口（轮询） , sehingga data dapat terus diperbarui.
Front end telah memutuskan untuk menggunakan AJAX untuk melakukan polling secara teratur pada antarmuka latar belakang untuk mendapatkan data terbaru demi data real-time, interval polling akan小于1s , ini akan membawa masalah lain. Di bawah permintaan yang sering terjadi, backend tidak boleh mengirimkan semua data setiap saat. Salah satunya adalah efisiensi transmisi jaringan dan biaya lalu lintas yang disebabkan oleh ukuran data; Penilaian front-end terhadap data baru berarti bahwa back-end harus mengembalikan data yang belum diterima oleh front-end setiap saat. Masalahnya adalah - bagaimana back-end mengetahui informasi apa yang telah diterima front-end?
Hal ini memerlukan penggunaan自增主键. Front-end hanya perlu membawa最后的消息的主键yang diterima oleh front-end setiap kali membuat permintaan. berulang dan meningkat secara otomatis, kita dapat dengan mudah mengetahui rasionya. Data dengan kunci primer yang besar adalah data yang belum diterima oleh front end.
bahasa
bingkai
penyimpanan data
teknologi
Karena penggunaan kerangka ORM database Xorm, tabel berikut dibuat secara otomatis dan dilengkapi dengan bidang
xxxxxx_at
Berdasarkan persyaratan di atas, dua tabel, users dan messages dirancang.
Bidang kunci
Struktur tabel database
| Bidang | Jenis | Batal | Kunci | Bawaan | Tambahan |
|---|---|---|---|---|---|
| PENGENAL | orang besar(20) | TIDAK | PRI | BATAL | kenaikan_otomatis |
| nama belakang | varchar(255) | YA | BATAL | ||
| kata sandi | varchar(255) | YA | BATAL | ||
| jenis kelamin | orang besar(20) | YA | BATAL | ||
| usia | orang besar(20) | YA | BATAL | ||
| minat | varchar(255) | YA | BATAL | ||
| dibuat_at | tanggalwaktu | YA | BATAL | ||
| diperbarui_di | tanggalwaktu | YA | BATAL | ||
| dihapus_at | tanggalwaktu | YA | BATAL |
Bidang kunci
Struktur tabel database
| Bidang | Jenis | Batal | Kunci | Bawaan | Tambahan |
|---|---|---|---|---|---|
| PENGENAL | orang besar(20) | TIDAK | PRI | BATAL | kenaikan_otomatis |
| pengirim_id | orang besar(20) | YA | BATAL | ||
| penerima_id | orang besar(20) | YA | BATAL | ||
| isi | varchar(255) | YA | BATAL | ||
| waktu_kirim | orang besar(20) | YA | BATAL | ||
| dibuat_di | tanggalwaktu | YA | BATAL | ||
| diperbarui_di | tanggalwaktu | YA | BATAL | ||
| dihapus_at | tanggalwaktu | YA | BATAL |
Struktur berikut ini berdasarkan pengalaman pribadi. Jika ada yang tidak pantas, mohon berikan masukan Anda yang berharga.
pojo
Mudah dimengerti, ini adalah entitas yang berkorespondensi dengan database, tetapi tidak memerlukan korespondensi satu-ke-satu dengan field database.
reqo (objek permintaan), reso (objek respons)
Saat membuat permintaan melalui antarmuka yang berbeda, parameter yang dapat dibawa dan data respons juga berbeda, sehingga entitas permintaan dan entitas respons yang sesuai dirancang untuk setiap antarmuka.
Berikut ini adalah pemahaman pribadi saya
Pengendali
Tanggung jawab utama adalah menerima parameter permintaan, mengubahnya menjadi reqo, melakukan verifikasi parameter permintaan sederhana (definisi pribadi saya adalah verifikasi yang tidak ada hubungannya dengan database, seperti non-null, non-zero), hubungi fungsi lapisan Layanan untuk mendapatkan hasil pojo, dan konversi hasil pojo dienkapsulasi dan dikembalikan dalam reso.
Melayani
Tanggung jawab utamanya adalah untuk merangkum lebih lanjut antarmuka lapisan Dao dan menyediakan antarmuka umum untuk dipanggil oleh Pengontrol. Data yang dikembalikan dapat berupa pojo. Verifikasi data perlu dilakukan di Layanan, seperti (menambahkan pengguna baru, memverifikasi apakah nama pengguna diulang).
Dao
Pada dasarnya, metode di sini berhubungan langsung dengan pernyataan SQL tanpa verifikasi apa pun. Data yang diterima dianggap dapat diandalkan (telah diverifikasi oleh parameter lapisan Pengontrol dan Layanan), dan data yang dikembalikan dapat berupa POJO.
