👨🏽‍💼 🏈 👩🏻‍🔧 Seperti yang kami lakukan perancang obrolan bot berikutnya. Bagian 1 🎧 🧜🏼 👨🏿‍🚒

Hai Habromir! Tahun lalu tim dan saya habiskan untuk membuat startup Botlify Chatbot Constructor for Business kami, dan saya ingin berbagi dengan audiens tentang sejarah singkat proyek dan keputusan teknis yang dibuat. Dalam posting ini, saya akan mencoba untuk berkonsentrasi sebanyak mungkin pada detail teknis dan lebih dalam ke dalam produk dan bisnis, meskipun pada kenyataan bahwa dalam proyek ini peran saya jauh kurang terhubung dengan pengembangan dan teknologi. Materi ini didasarkan pada pengalaman pribadi saya, saya bukan pelatih pemula dan tidak berpura-pura menjadi programmer, manajer, arsitek, atau wirausaha yang baik. Kami adalah perusahaan pemula yang relatif muda dengan sedikit pengguna, sehingga tidak akan ada apa-apa tentang beban kerja dan masalah proyek besar. Di bawah potongan, saya akan memberi tahu Anda bagaimana proyek saya dimulai, pengembangan seperti apa yang kami tuju dan kesimpulan apa yang kami buat.

Nama saya Andrey, untuk beberapa waktu saya bekerja sebagai pengembang, terutama di PHP, lalu memimpin tim, dan kemudian sebagai direktur teknis di beberapa startup kecil, di mana saya jatuh cinta pada NodeJS. Tetapi kebetulan bahwa belakangan ini saya lebih cenderung menjadi wirausaha. Ini bukan startup pertama yang saya dirikan, dan bahkan startup pertama yang saya ikuti. Saya kebetulan bekerja di beberapa proyek sukses dan banyak kegagalan. Saya mendirikan lebih banyak lagi proyek yang gagal. Setiap kali, penyebab kegagalan benar-benar berbeda, serta tahapan di mana saya gagal, tetapi entah bagaimana saya menggunakan pengalaman ini dalam proyek ini.

Tujuan

Sebelum memulai cerita tentang proyek ini, saya ingin berbicara tentang tujuan apa yang kami kejar sejak awal, memulai petualangan ini. Bahkan, desainer kami mulai sebagai proyek kesayangan untuk mempelajari dasar-dasar manajemen produk, pengembangan pelanggan, memperoleh keterampilan manajemen baru, dan pengalaman dalam startup. Saya mendengar dan mencoba berkali-kali untuk menerapkan pendekatan Startan LEAN dan setiap kali ternyata benar-benar berbeda. Tentu saja, kami bermimpi membangun bisnis untuk hal ini dan menghasilkan uang yang baik, tetapi kami tidak menghibur diri dengan ilusi bahwa ini adalah cara yang sederhana dan singkat. Dan terlebih lagi, kami tidak mencoba membuat semacam WOW! -Inovasi. Rekan pendiri saya dan saya terus-menerus bekerja penuh waktu dan kami mengerti bahwa kami tidak akan bisa mencurahkan banyak waktu.Motivator utama justru kesempatan untuk menguasai bidang industri TI yang benar-benar baru dan menerapkan pengetahuan baru dalam praktik, dan pada saat yang sama menghasilkan uang.

Sebagai seorang programmer, saya sangat suka menggambar diagram kelas, urutan, diagram alur. Bagi saya, proses visualisasi itu sendiri adalah tahap dalam memahami masalah dan solusi, dan itu memungkinkan saya untuk mendapatkan gambaran besar tentang apa yang terjadi. Saat mengerjakan proyek berikutnya, saya kembali dihadapkan dengan kebutuhan untuk memasukkan widget dengan obrolan online di situs dan melihat solusi siap pakai apa yang ada di area ini. Jadi, di antara apa yang saya cari, saya menemukan platform yang memungkinkan tidak hanya membuat widget dengan obrolan online untuk situs tersebut, tetapi juga menyematkan bot obrolan di dalamnya. Saya berbicara dengan salah satu bot ini dan dia meninggalkan kesan yang baik bagi saya. Dan kemudian saya mulai mencoba membuat skrip chatbot berbeda yang dapat berguna dalam proyek saya. Fantasi mengalir di atas meja: janji dengan salon kuku,membantu membuat pilihan di toko online, menunjukkan tempat yang tepat dalam dokumentasi, menerima permintaan ke layanan dukungan. Apa yang saya tidak pikirkan.

Kemudian saya memanjat untuk melihat berbagai desainer dan hampir semua menawarkan saya untuk mengisi formulir, dan kemudian mengisi formulir, dan kemudian mengisi formulir lagi. Secara umum, buat bot dengan mengisi formulir. Sebagai hasilnya, itu sangat merepotkan bagi saya, saya terus-menerus kehilangan konteks tentang apa yang terjadi, saya harus kembali ke langkah sebelumnya untuk memulihkan konteks, dan tidak ada pertanyaan tentang pemikiran yang mudah melalui logika dan merancang skrip. Yah, saya pikir, saya akan mencoba terlebih dahulu untuk "merancang" bot saya di alat eksternal, dan kemudian saya akan mentransfernya ke platform yang diinginkan.

Dan di sini saya menemukan masalah pertama: Bagaimana menggambarkan dialog dengan bot sedemikian rupa sehingga jelas apa dan mengapa bot merespons dan pada saat yang sama memiliki seluruh urutan tindakan di depan itu sendiri?Pada awalnya, saya mencoba menggunakan xmind dan alat lain untuk membuat peta pikiran. Ternyata sesuatu seperti ini.

Pikirkan peta contoh chatbot

Kemudian menjadi jelas bahwa bot obrolan secara keseluruhan cukup baik dalam konsep menggambarkan keadaan dan transisi di antara mereka, ternyata cukup nyaman untuk dinavigasi di cabang percakapan bahkan di mana ada banyak dari mereka.

Hanya beberapa pesaing yang ditemukan menyediakan perancang bot visual. Bagi sebagian orang, itu lebih intuitif, bagi seseorang yang kurang, tetapi secara umum, konstruktor seperti itu bagi saya jauh lebih ramah pengguna. Menjadi menarik bagi kami untuk mencoba melakukan sesuatu yang serupa, kami ingin membuat alat yang dapat digunakan untuk membuat bot obrolan tanpa keterampilan pemrograman, cukup dengan menggambarkannya dalam bentuk diagram. Tentu saja, beberapa keterampilan teknis masih diperlukan, tetapi tidak jauh lebih sulit untuk membuat peta pikiran.

Bot adalah topik yang agak rumit dan besar, dan sumber daya kami sangat terbatas. Karena itu, sangat penting bagi kami untuk menyederhanakan keputusan kami sebanyak mungkin sehingga akan melihat pasar. “ Semakin cepat semakin baik ” - Saya tidak akan bosan mengulangi mantra ini dalam konteks startup.

AI & ML

Pertanyaan tentang kecerdasan buatan dalam bot obrolan masih terbuka untuk saya. Tetapi sekarang kita melanjutkan dari fakta bahwa kita adalah permulaan awal, kita tidak memiliki kompetensi dalam AI dan ML dalam tim dan kita telah sepakat bahwa kita hanya ingin menggambar diagram dan tidak menyiapkan dataset, melatih jaringan saraf dan itu saja. Saat ini, kami tidak menggunakan kecerdasan buatan dan pembelajaran mesin di bot kami . Mungkin suatu hari, di masa depan, ketika akan ada uang untuk itu.

Penting untuk dipahami bahwa bot yang sama dalam esensinya dapat dibuat sangat berbeda. Secara kasar, mungkin ada bot yang menulis: " Apa yang mau Anda lakukan? " Dan mengharapkan tanggapan sewenang-wenang dari pengguna dalam semangat: " Pelajari tentang borsch ", " Saya ingin memesan borsch ", "Pukul berapa sekarang?". Setelah menerima jawaban, bot mencoba untuk mengenalinya, menentukan niat dan memilih cabang yang tepat untuk pengembangan dialog. Tak perlu dikatakan, diberikan kesalahan ketik, berbagai bentuk dan ekspresi, ini bisa mahal.

Di sisi lain, kita dapat menggunakan pertanyaan tertutup ketika datang ke ini tentang memilih, misalnya, bot dapat menulis: " Apa yang ingin Anda lakukan? "dan menawarkan opsi:" Pelajari tentang borsch "," Order borsch "," Cari tahu waktu". Di satu sisi, pengguna kehilangan kebebasan bertindaknya, tetapi di sisi lain, kami tidak hanya menyederhanakan perhitungan secara signifikan, tetapi juga dapat lebih mudah mengelola konteks dialog dengan memutarnya ke arah yang benar. Kami lebih suka menggunakan pertanyaan terbuka dalam konteks mengumpulkan data teks pengguna: masukkan email , telepon, tulis pertanyaan Anda untuk didukung, dll.

Bot obrolan vs pria

Argumen lain yang melarang pengguna berkomunikasi dengan bot dalam bentuk bebas adalah keyakinan bahwa bot obrolan tidak boleh "bermain" dalam diri seseorang. Menurut pendapat saya, ketika berkomunikasi dengan bot, seseorang harus memahami dengan jelas apa yang berkomunikasi dengan bot, tahu peluang apa yang dimilikinya dan bagaimana menggunakannya. Dan jika seseorang mengerti bahwa dia berkomunikasi dengan bot - apa gunanya komunikasi teks bebas? Adalah jauh lebih baik ketika chatbot menjadi asisten seseorang, dan bukan pengganti untuk itu dan tidak malu tentang hal itu, dan orang itu jelas memahami bahwa ia berkomunikasi dengan chatbot dan apa fungsinya. Dalam hal ini, komunikasi ternyata lebih efektif.

Proses

Saya penggemar udalenki. Jangan beri saya roti - izinkan saya mengumpulkan tim jarak jauh dan mulai bekerja dengannya. Saya nyaman bekerja dari jarak jauh sendiri, saya tahu bagaimana mengatur pekerjaan dan menemukan orang yang dapat bekerja secara mandiri dan efisien juga. Saya mengerti betul bahwa ini tidak cocok untuk semua orang, saya sepenuhnya setuju dengan ini, tetapi saya berpikir bahwa di masa depan yang cerah akan semakin banyak udalenki. Hanya saja, ekonomi bukan masalah pribadi. Karena ini adalah proyek saya dan saya memesan musik untuk itu - di sini, juga yang terpencil, ini meninggalkan jejak tertentu.

Pada awal mengerjakan proyek apa pun, saya menganggap sangat penting untuk mencoba memformalisasikan ide-ide saya sebanyak mungkin. Sementara ide belum menemukan bentuknya di atas kertas, dalam bentuk teks, catatan, gambar, tidak ada ide sama sekali. Pada saat yang sama, semua proses dalam tim harus sesederhana mungkin, alami dan secepat mungkin, komunikasi efektif. Anda tidak boleh menggunakan alat besar dan berat untuk mengelola tim Anda, seperti Jira atau Redmine, jika seluruh tim Anda adalah Anda dan teman Anda. Tetapi juga untuk tidak menggunakan apa pun juga, jika tidak semuanya akan dengan cepat keluar dari kendali dan kekacauan akan muncul, membatasi yang jauh lebih sulit daripada tidak membiarkannya. Bahkan di kepala satu orang kekacauan seperti itu dapat dibentuk sesuai dengan proyek, bukan bagi saya untuk memberi tahu Anda apa yang harus dikatakan tentang tim, bahkan jika hanya 2-3 orang.

Kami, seperti pemula yang sebenarnya, menggunakan Trello untuk mengatur tugas dan menyimpan tautan penting untuk proyek, dan ide-ide juga dilemparkan ke sana. Untuk dokumentasi bisnis, Google Documents , sementara yang teknis, dibuat cukup baik dalam penurunan harga dan dimasukkan ke dalam repositori yang sesuai. Komunikasi sepanjang hari - Telegram , dan untuk Google Hangouts harian . Stand-up harian adalah salah satu landasan keberadaan tim jarak jauh . Jika ini tidak ada, tidak ada tim, seseorang tentu mulai merasa kesepian, lelah, kesalahpahaman dan ketidakpuasan bertambah, tidak hanya mengendalikan situasi tetapi juga hubungan dalam tim hilang.

Dari sudut pandang proses pembangunan, Amerika juga tidak harus ditemukan. Kami menentukan panjang sprint, merencanakan sprint berdasarkan tujuan startup. Kami mengambil teka-teki dan memulai sosis. Tantangan baru adalah cabang baru di sistem kontrol versi favorit Anda. Apakah kamu sudah selesai? Kami mengeluarkan permintaan Tarik, tunggu sampai seseorang turun ke ulasan. Apakah ulasannya pergi? CI bekerja dengan baik? Kalau begitu, Anda dapat memegang segala sesuatu di cabang pengembangan, tunggu lampu hijau dari unit pengembangan dan perbarui server uji. Kode yang kami simpan di GitHub . Sampai pelanggan yang membayar pertama, ini adalah repositori terbuka untuk umum. Sebagai orang yang telah mencoba mempromosikan beberapa solusi open source di masa lalu, saya dengan tulus membenci setiap kali startup mulai bergetar untuk keamanan kode sebelum mulai menghasilkan uang.Jika Anda mencoba menyalin - ini adalah keberhasilan bisnis yang jelas . Tidak ada biaya untuk menutup repositori nanti. Dan bisnis, Anda tahu, dimakamkan, sebagai aturan, jauh dari kode. Saya memiliki akses ke kode banyak orang, termasuk produk yang sangat sukses, tetapi apakah ada baiknya mengatakan bahwa dengan memilikinya saya bahkan tidak akan mengulangi kesuksesan mereka? Untuk membuat kontainer Docker dan menjalankan autotest, kami memutuskan untuk mencoba Tindakan GitHub , untungnya, mereka memberikan akses awal. Secara umum, tayangan tetap cukup menyenangkan, kecepatan rakitan memuaskan. Satu-satunya hal yang tidak menyenangkan adalah pembaruan dengan kehilangan kompatibilitas dengan versi sebelumnya. Beberapa kali mereka dengan serius mengubah skema deskripsi tindakan dan harus mengkonfigurasi ulang semuanya. Tetapi kami tahu apa yang kami lakukan ketika kami setuju untuk mencoba produk dalam statusBeta .

Dari hari-hari pertama, secara harfiah, dari mengembangkan halaman arahan untuk pengujian permintaan, kami mencoba untuk merilis setidaknya seminggu sekali dan menguji setidaknya satu hipotesis. Pada awalnya, hipotesis lebih global, kami mencoba menemukan berbagai masalah, target audiens, dan mengembangkan proposal. Tetapi semakin jauh produk berkembang, semakin tidak mendunia dan esensi itu sendiri cenderung tidak berubah. Proyek dimulai dari awal, dengan halaman pendaratan biasa, lalu di atas lutut kami membuat klien demo bot obrolan, yang masih menggantung di halaman utama kami. Demo ini dapat mereproduksi dialog yang diprogram secara ketat dan melayani kami sebagai demonstrasi dari apa yang dapat dilakukan pada konstruktor kami - hasil dari pekerjaannya, dan bukan konstruktor itu sendiri. Kuncinya adalah kita berasumsi bahwa bisnis tidak akan datang kepada kita untuk perancang bot,tetapi untuk beberapa hasil, keuntungan yang akan ia berikan. Kami ingin menuangkan secangkir kopi kepada pelanggan kami, yang dibuat oleh mesin kopi kami, alih-alih menunjukkan mesin kopi itu sendiri. Mudah ditebakmembuat secangkir kopi jauh lebih cepat dan lebih murah daripada mengumpulkan mesin kopi . Dipandu oleh prinsip ini, kami memutuskan untuk membuat demo klien terlebih dahulu, terutama karena dengan sejumlah alat yang sudah jadi kami butuh waktu tidak lebih dari dua malam, termasuk pengembangan skenario dialog.

Ketika kami melihat minat dari pengunjung pendaratan dan konversi tambahan yang dihasilkan oleh demo kami, kami memutuskan bahwa kami akan melangkah lebih jauh. Saya ingat bahwa rilis konstruktor pertama kami adalah formulir pendaftaran dengan formulir masuk, setelah itu pengguna dibawa ke halaman dengan permintaan maaf dan janji untuk memberi tahu ketika sesuatu yang lain berfungsi. Saya melakukan form login dan registrasi ratusan kali dalam hidup saya dan saya bahkan tidak bisa berpikir bahwa di sini kita akan segera menemukan banyak masalah.Sekitar 60% dari pengguna pertama tidak bisa menyelesaikan proses pendaftaran . Untuk siapa tombol tidak berfungsi, untuk siapa surel tidak datang, untuk siapa ada yang lain. Pada awalnya, saya merasakan gagasan melepaskan hanya beberapa bentuk dengan cukup skeptis, tetapi pandangan pertama pada Yandex.Metrica menjelaskan bahwa itu adalah keputusan yang tepat. Kesadaran bahwa pengguna berperilaku berbeda dari yang Anda inginkan, dan terkadang cara yang menurut Anda bahkan tidak bisa, memiliki dampak besar pada semua yang kami lakukan selanjutnya. Sebagai hobi, saya menghabiskan beberapa kali seminggu di beberapa jam di browser web hanya menonton bagaimana pengguna menggunakan kerajinan kami.

Jadi, sedikit demi sedikit, kami menambahkan fungsionalitas ke gagasan kami dan sampai pada produk yang masih memiliki nilai tidak hanya bagi kami, tetapi juga bagi pengguna kami, beberapa di antaranya bahkan membayar kami uang. Dalam jangka panjang, kami tidak mengerti apa yang kami inginkan, seperti apa produk kami nantinya. Satu-satunya hal yang kami pahami saat itu adalah bahwa kami tidak mengerti apa-apa dan berada dalam kondisi ketidakpastian.

Hasil

Eksperimen ini membawa saya dan tim saya ke investasi malaikat dari teman, keluarga, kategori bodoh, dibangun oleh MVP, penjualan pertama, pengalaman hebat, banyak kegembiraan dan kekecewaan. Kami belum menjadi bisnis yang sebenarnya, tetapi kami berusaha untuk menjadi satu. Dan ketika saya mengatakan ini, maksud saya bahwa kita masih mencari model bisnis yang berkelanjutan dan kecocokan pasar-produk. Sekali lagi kami berencana untuk mencari konsep produk yang tepat, pelanggan kami, pasar kami.

Tujuan awal tidak tercapai sama sekali, tetapi proyek tumbuh dari hobi rumah dan berubah menjadi pekerjaan penuh waktu, dan tanggung jawab muncul kepada investor, pengguna, dan karyawan. Tentu saja, proyek ini memiliki banyak masalah, baik secara konsep maupun teknis, tetapi tidak ada yang tidak dapat diselesaikan dan kami berencana untuk terus bekerja.

Sebelum memulai bagian yang lebih teknis dari karya saya, mungkin ada baiknya menceritakan secara singkat tentang apa yang memungkinkan produk Anda lakukan.

Kelola chatbots di akun Anda
Editor obrolan visual
Kontrol akses ke bot obrolan (akses pengeditan, akses publik)
Kemampuan untuk mempublikasikan bot obrolan di web (widget, tertanam, layar penuh)
Pengaturan chatbot (desain, nama, metrik, posisi widget, dll.)
Dukungan untuk mengintegrasikan chatbots dengan layanan eksternal melalui permintaan GET dan POST
Analisis dialog bot
Manajemen akun
Model Berlangganan, Manajemen Berlangganan

Arsitektur

Sekarang, dengan mengetahui latar belakang, tujuan, gagasan, dan prinsip-prinsip yang memandu kami dalam pengembangan, saya dapat mulai memberikan gambaran umum tentang bagaimana semua ini bekerja. Karena pilihan awal kami adalah membuat chatbots untuk situs dan chatbots layar penuh, seperti app.botlify.io/bot/5de53dbf9b9bae002b319600 , jelas bahwa sebagian besar pekerjaan akan berada di sisi frontend. Akibatnya, bagian depan pekerjaan pada klien dibentuk menjadi daftar tugas dan Daftar Keinginan yang bermakna:

Buat / temukan perpustakaan klien, semacam "mesin" untuk bot obrolan di browser yang memahami instruksi json yang diterima dan memelihara dialog dengan pengguna.
Buat aplikasi untuk mengedit bot node, yang akan menyimpan daftar node dan tautan di antara mereka di beberapa objek-json (atas dasar mana perpustakaan klien akan melakukan dialog).
, , , - . , , , . , , , ..

, , . id , :

<script defer src="https://app.botlify.io/botlify.min.js"
    onload="Botlify({ bot: '5de53dbf9b9bae002b319600', type: 'widget'})"
</script>

, , ( )

Seluruh logika dialog mulai dari membuat obrolan bot (simpul dan koneksi) hingga bekerja secara langsung dengannya di klien web ditangani oleh frontend. Peran backend adalah tentang mengelola akses, langganan, buletin, pemberitahuan, dan menyimpan data yang dikirimkan dari banyak klien web.

Paling depan

Untuk bagian depan, kami menggunakan Reactjs . Kami mengemas semua yang ada di Docker (kami membuat dan mendorongnya ke dalam wadah nginx), kode pada Github dalam repositori pribadi, untuk CI kami menggunakan Tindakan Github . Kami meluncurkan kontainer di server VPS biasa dengan skrip bash sederhana. Untuk mempermudah pengembangan UI perlu Blueprint .

Web — javascript , - . json -, . -(, , , , , .).
Web — javascript . id , , Web- .
— , . json, -. , «» , — -.
Akun Pengguna - aplikasi web untuk mengelola akun, langganan, dan bot Anda.
Panel administratif adalah aplikasi web untuk administrator. Manajemen pengguna, bot, langganan, dasbor dengan analitik.

Diagram di bawah ini menunjukkan komponen-komponen frontend dan bagaimana mereka berinteraksi satu sama lain. Webclient dan editor bot hanya digunakan dalam konteks aplikasi lain, sedangkan jika editor hanya digunakan dalam aplikasi kami, maka klien web juga dapat digunakan oleh klien kami sebagai modul web. Saat membangun proyek, paket dengan Webclient dan Editor ditambahkan ke Dashboard dan aplikasi Admin. Selain itu, modul web dibangun menggunakan webpack untuk pengiriman ke pengguna.

MVP 1. Klien Web

Sebagai startup, kami selalu berusaha untuk mencapai hasil maksimal menggunakan sumber daya minimum. Tampak bagi saya bahwa langkah yang cukup logis untuk MVP pertama adalah penciptaan klien web dari sudut pandang yang mewakili "wajah produk", menunjukkan hasil karya desainer, dan bukan proses menciptakan bot - secangkir kopi, bukan mesin kopi. Untuk meminimalkan waktu pengembangan solusi, kami memutuskan untuk mencari perpustakaan yang sesuai dengan permintaan kami dan, tiba-tiba, ditemukan! lucasbassetti.com.br/react-simple-chatbot adalah komponen reaksi yang memenuhi hampir semua kebutuhan kita!

Komponen ini menyarankan untuk menjelaskan logika chatbot dalam bentuk serangkaian langkah-langkah, membaca nilai yang dimasukkan oleh pengguna, menyesuaikan tampilan, memvalidasi data, dan tampak cukup fleksibel untuk memulai. Uraian langkah paling sederhana terlihat seperti ini:

<ChatBot
      steps={[
        {
          id: '1',
          message: 'What is your name?',
          trigger: '2',
        },
        {
          id: '2',
          user: true,
          trigger: '3',
        },
        {
          id: '3',
          message: 'Hi {previousValue}, nice to meet you!',
          end: true,
        },
      ]}
    />

Kami mulai dengan mencoba cara ini untuk membuat chatbot yang mempresentasikan proyek kami, yang peta pikirannya ada di layar di awal artikel. Tentu saja, menggambarkan secara manual json tersebut ternyata agak merepotkan, dan saya harus menulis banyak fungsi khusus, tetapi secara umum proses ini memberikan pemahaman tentang bagaimana komponen bekerja, bagaimana mencapai hasil yang diinginkan dengan itu.

Selanjutnya, kolega saya menyesuaikan penampilan, membuat beberapa opsi tampilan, dan kami membuat contoh dengan sebuah tempat pangkas dan pameran Van Gogh. Anda bahkan mungkin memperhatikan bahwa kami bahkan tidak memikirkan optimasi gambar. Ya, itu dan tidak perlu. Dalam proses kerja, kami telah membentuk perkiraan visi tentang bagaimana klien akan bekerja dan kami mulai mencari solusi untuk perancang sendiri untuk mengambil keuntungan dari pengeditan visual sesegera mungkin.

MVP 2. Konstruktor

Berdasarkan apa yang kami lihat ketika bekerja dengan klien, kami membuat kesimpulan umum bahwa bot dapat memiliki beberapa jenis tindakan: mengirim sesuatu, menunggu tindakan pengguna, mengirim permintaan ke layanan eksternal. Untuk editor bot yang layak, kami memutuskan untuk membatasi diri pada blok:

Mulai - unit teknis yang memulai sesi baru
Akhir - blok mengakhiri sesi
Pesan - setelah mencapai blok, bot mengirimkan pesan yang ditentukan di badan blok
— . ,

Diasumsikan bahwa blok-blok itu akan saling berhubungan dengan panah, atau garis. Semua blok kecuali blok "Mulai" memiliki satu port input (soket). Banyak jalur dapat terhubung ke port input, menghubungkan unit dengan yang lain. Semua blok kecuali blok End memiliki dari satu ke beberapa port output. Port keluaran menentukan kontrol blok mana yang ditransfer setelah logika blok saat ini selesai.

Setelah pemeriksaan singkat dari solusi yang tersedia, kami memutuskan Rete.js (https://rete.js.org) Saya berkenalan dengan dokumentasi, contoh-contoh dan menemukan di dalamnya segala yang perlu kami mulai. Mereka bahkan memiliki contoh hanya dengan bot obrolan, yang merupakan pemicu terakhir

Rete . . , — , JSON

Semua node dapat berisi nama, input, output, dan kontrol. Masing-masing pintu masuk dan keluar harus berada di sebelah kiri dan di sebelah kanan simpul (untuk simpul khusus mungkin ada pengecualian). Mereka diwakili oleh soket dan mungkin memiliki nama. Untuk input, kami mengizinkan jumlah koneksi yang tidak terbatas (Anda dapat mencapai node dalam banyak cara), untuk output kami membatasi diri hanya untuk satu koneksi, namun, tidak seperti soket input, beberapa blok memiliki banyak soket output.

Rete.js dibangun sedemikian rupa sehingga fungsinya diperluas dengan membuat node, kontrol, komponen kustom, yang memungkinkan kami untuk mendapatkan gambar yang ingin kami lihat dengan cepat, dan untuk itu saya berterima kasih kepada pencipta Rete ! Tentu saja, salah satu yang paling penting adalah editor yang sudah jadi!

Seperti yang tertulis didokumentasi :

Editor adalah area dengan simpul dan koneksi di antara soketnya. Opsi berikut tersedia:

Interaksi dengan ruang kerja (pemindahan, penskalaan) dan manajemen simpul (pemindahan, penambahan, penghapusan)
Tampilan koneksi, node, input / output dan kontrolnya
Menangani Acara Editor
Skema impor / ekspor dalam format JSON
Memperluas fungsi dengan plugin
Kustomisasi ruang kerja, node dan koneksi

Setelah menyulap sedikit dengan Rete dan mempelajari dalam contoh yang lebih detail, kami berhasil membangun sesuatu yang memungkinkan kami untuk membuat dan menghapus blok “mulai”, “akhir”, “pesan”, “input keyboard”. Pada output, kami menerima json dengan deskripsi node, soket, dan garis yang menghubungkannya.

Salah satu versi editor yang pertama

Sudah sesuatu, tetapi ini tidak cukup, karena klien web kami tidak mengerti json ini. Dia membutuhkan semacam miliknya sendiri, dengan deskripsi langkah-langkah. Diputuskan untuk menanamkan konverter dari satu format json ke yang lain di klien.

Json transformer

Utilitas menerima NodesMap, disusun oleh editor, sebagai input, dan mengembalikan StepsMap yang dipahami klien. Kode seluruh transformator membutuhkan lebih dari 100 baris, tergantung pada jenis simpul dan data di dalamnya, langkah yang sesuai dibuat, memicu fungsi, dan satu set instruksi (tindakan) yang harus dilakukan dalam langkah ini. Ada instruksi yang menyimpan variabel dalam status chatbot, ada yang mengganti variabel dalam teks, atau mengirim permintaan ke server kami.

Setelah mengikat komponen bersama-sama, kami mulai menguji alat yang dihasilkan. Bahkan tanpa backend, itu sangat mengasyikkan. Kami membuat dialog di editor dan memasukkan json ke klien melalui alat dev, dan sebagai hasilnya kami mendapat bot yang mengatakan bagaimana kami membutuhkannya! Dia juga tahu bagaimana cara menyimpan variabel dan menggunakannya, sial! Sensasi luar biasa dari kemenangan pertama ... Mosaik dari perangkat aplikasi kami sudah praktis terbentuk di kepalaku, kami mendapatkan sesuatu yang mengerjakan prinsip-prinsip yang ingin kami gunakan di masa depan. Kami punya kerangka tertentu di mana itu tetap membangun "daging". Dan yang paling penting - menjadi jelas bagaimana melakukan ini:

Ubah editor, tambahkan jenis simpul yang diinginkan
Kami mengajarkan json transformer untuk mengubah simpul baru menjadi langkah baru
Kami mengajarkan klien untuk bekerja dengan langkah baru

Di sisi lain, itu perlu untuk mulai terlibat dalam akun pribadi pengguna sehingga dimungkinkan untuk membuat bot, menyimpannya, mengelola dan kami memutuskan untuk berkonsentrasi pada hal ini agar dengan cepat menunjukkan kepada pengguna bukan konsep, tetapi produk.

Akun pengguna

Pustaka di atas melakukan fungsi tertentu yang terkait dengan pembuatan logika chatbot (editor), interpretasinya atau reproduksinya (klien). Masalah penyimpanan data, kemampuan untuk memuat bot yang dibuat, mengelolanya dan mengatur properti yang tidak terkait dengan logika tetap terbuka dan aplikasi seharusnya telah menyelesaikannya untuk pengguna. Berbekal blueprintJS, kami membuat sketsa prototipe akun pribadi yang memungkinkan untuk mendaftar dan membuat beberapa bot. Ketika Anda mengklik bot untuk membuat seseorang harus jatuh ke editor dengan bot baru, dan ketika Anda mengklik kartu bot di editor dengan bot ini. Kami memutuskan untuk mempercayakan fungsi memuat dan menyimpan bot melalui API backend kami ke lapisan ini agar editor bot tidak bergantung pada backend.

Aplikasi akun pengguna dapat mengunduh paket editor dan mentransfer data siap untuk ditampilkan. Aplikasi ini juga mengelola formulir untuk mengatur properti bot (nama, kunci api, avatar, pengaturan publikasi), dan memungkinkan Anda untuk melihat statistik. Untuk memungkinkan pengguna untuk segera melihat hasil editor, kami menambahkan klien web ke kantor pengguna, yang kami berikan skema json bot, ia menafsirkannya dalam langkah-langkah dan memainkannya di tab "pratinjau". Secara umum, ini adalah panel admin yang sangat klasik dengan beberapa komponen menarik (editor bot dan klien web), saya pikir banyak yang melakukannya. Tetapi pada tahap ini menjadi sangat tidak nyaman untuk mengembangkan aplikasi kita.

Awalnya, bagi kami itu ide yang bagus untuk mengandung komponen produk dalam repositori yang berbeda dan kami tidak melihat masalah khusus dalam hal ini. Namun, dengan cepat menjadi jelas bahwa menjaga repositori tetap up to date adalah masalah, belum lagi kebutuhan untuk menari dengan rebana ketika berkembang, karena mereka sampai batas tertentu saling tergantung. Dan mengingat bahwa kami hanya memiliki satu pengembang penuh waktu, pendekatan ini sangat menarik. Dan penyebaran apa pun berubah menjadi cabang neraka di bumi karena perbedaan dalam perakitan dan publikasi perpustakaan, aplikasi, masalah kompatibilitas mundur. Oleh karena itu, dangkal, tetapi bukan kesimpulan yang paling tidak berguna: alokasi modul yang prematur dapat lebih berbahaya daripada membantuSaya sudah diyakinkan tentang ini berkali-kali di backend, dan di sini saya datang lagi, tetapi di depan. Ya, dan saya tidak melewatkan kesempatan di backend: =)

Salah satu rekan saya mengumpulkan keinginannya menjadi kepalan tangan dan menggabungkan semuanya menjadi repositori mono yang dikelola dengan lerna . Sekarang satu - satunya repositori front-end kami dibagi menjadi beberapa paket: admin, klien, common, dashboard, editor, web-module. Mereka mungkin memiliki perakitan yang berbeda di dalam, tetapi lerna memungkinkan mereka untuk terhubung dan memperbarui ketergantungan antar paket. Setelah itu, pengembangan dan penyebaran frontend menjadi jauh lebih cepat dan mudah, semuanya langsung tersedia, tetapi masih terbagi.

Setelah membuat kabinet, kami menghabiskan beberapa waktu pada blok baru di editor dan pemrosesan mereka oleh klien:

— . ( ),
— -
Email — email

Saya tidak punya banyak informasi tentang panel admin dan modul web, semuanya sangat standar di sana. Biarkan saya perhatikan saja bahwa panel admin tidak boleh dilakukan sebelumnya . Kami memilikinya, tetapi tidak ada yang menggunakannya, karena secara pribadi tidak sulit bagi saya untuk melihat semua yang menarik minat saya segera dalam database. Tidak ada humaniora yang membutuhkan panel admin kami di tim, dan menjaganya agar tetap terbaru pada dasarnya sedikit lebih murah daripada mempertahankan akun pengguna. Seiring waktu, dasbor sederhana ditambahkan di sana, menampilkan pembayaran, pendaftaran baru, dan kunjungan aplikasi, tetapi informasi ini tidak sebanding dengan pengembangan seluruh admin. panel dengan tabel, formulir, dan otentikasi terpisah

Hasil?

Kami dapat membangun prototipe dan halaman arahan dengan sangat cepat. Ya, itu sama sekali tidak seperti yang dibayangkan banyak orang dengan kedok MVP. Tetapi hanya beberapa malam setelah ide muncul, kami dapat mulai menunjukkannya kepada orang-orang dan mengujinya. Halaman arahan yang berbeda, iklan, teks dalam bot - kita bisa menguji dan mencari. Saya sangat merekomendasikan bahwa siapa pun yang terlibat dalam pengembangan startup berpikir tentang bagaimana menyelesaikan sesuatu secepat mungkin. Kami membuat produk pertama yang mengekstraksi nilai dalam waktu sekitar tiga bulan, dan kemudian proses peningkatan yang lebih bertahap dimulai. Tentu saja, sekarang kami memiliki lebih banyak blok di dalam konstruktor, kami menambahkan validasi, tipe data, GET dan permintaan POST, banyak dari setiap desain dan pengaturan tampilan, tetapi Anda dapat memulai tanpa semua ini, yang kami lakukan.

Seiring waktu, sistem mulai menjadi lebih kompleks dan berkembang, dan saya bahkan tidak mampu menggambarkan dengan cermat segala sesuatu yang sebenarnya terjadi. Mulai dari yang kecil, segala sesuatunya menjadi rumit seiring waktu, bila perlu. Setiap komponen tambahan dapat menghasilkan biaya yang sangat tinggi karena tidak hanya diperlukan untuk membuat dan mengintegrasikan, tetapi juga untuk mendukung, menguji, mendokumentasikan, menyebarkan, memantau, memperkenalkan anggota tim lain untuk itu. Mungkin Anda tidak perlu repot dengan antrian di RabbitMQ, jika sebelumnya tidak ada antrian di aplikasi Anda. Kemungkinan besar, solusi berdasarkan teknologi yang sudah ada akan cukup untuk memulai. Setiap komponen baru adalah biaya tambahan untuk integrasi, operasi, pengujian, dukungan, dokumentasi, penyebaran, dll., Dll.

Saya harap pengalaman saya akan bermanfaat bagi setidaknya seseorang. Untuk waktu yang lama saya mencoba mencari tahu hub mana yang menentukan ini, tetapi saya tidak mengerti. Beri tahu saya jika ada baiknya menulis bagian kedua di mana saya ingin berbicara sedikit tentang backend, layanan eksternal, dan rencana pengembangan

Seperti yang kami lakukan perancang obrolan bot berikutnya. Bagian 1