Bagaimana semuanya dimulaiSiksaan yang idealTeknologi dan cara mereka tidak unikBagaimana cara menyimpan dan di mana?Tidak hanya untuk menyimpan, tetapi juga untuk mencariIni adalah SEO samarCdn segalanya untuk kitaUntuk meringkasBagaimana semuanya dimulai
Saya ingin berbagi sejarah setengah tahun kami dalam menciptakan layanan online untuk mencari dan memesan perjalanan hak cipta di seluruh dunia. Saat membuat artikel ini, tujuannya adalah untuk berbicara tentang pengalaman menciptakan solusi kami sendiri dari awal dan masalah dan tantangan yang kami temui di sepanjang jalan, jadi jangan menilai dengan ketat.
Untuk memulainya, layanan seperti apa itu, dan mengapa perlu untuk membuatnya. Untuk waktu yang lama, tim kami mengerjakan berbagai proyek besar untuk klien bisnis. Ini adalah portal untuk bank, perusahaan, kepemilikan besar, serta sistem manajemen dokumen. Secara alami, bekerja dengan segmen seperti itu menyiratkan kepuasan dari lingkaran sempit karyawan yang tertarik dan tidak selalu berakhir dengan penggunaan yang panjang dan sukses.
Ada beberapa alasan untuk ini: kurangnya pemahaman tentang proyek pada tahap awal, keinginan untuk menghemat uang dan mendapatkan peralatan yang paling lengkap, mengubah persyaratan pada tahap akhir tanpa revisi ketentuan dan anggaran. Seperti yang Anda lihat, kepuasan dari proyek di kedua sisi, setelah kondisi seperti itu, sangat sulit untuk dicapai.
Jadi, setelah semua pengalaman ini, kami memutuskan untuk mencoba sendiri di pasar, di mana umpan balik dari klien cepat, Anda memahami minat pada produk secepat mungkin dan melihat penggunaan layanan Anda setiap hari.
Ternyata, hari-hari tenang kami telah berakhir!
Siksaan yang ideal
Hal pertama yang perlu dilakukan adalah memunculkan ide tentang apa yang ingin kita berikan agar bermanfaat yang tidak ada di pasaran dan yang akan dirasakan dan diharapkan. Kami memiliki beberapa sampel seperti itu dan selama dua bulan pertama kami terlibat dalam percobaan untuk menemukan masa depan. Seperti yang dapat Anda pahami, ada juga masalah dengan teknologi, karena itu perlu untuk membuat maket berfungsi dalam waktu sesingkat mungkin, memeriksa operabilitasnya dan terus-menerus memperbaiki atau mengulanginya lagi.
Pada awalnya, beban teknologi yang kami miliki tidak terlalu jQuery dan C # (yang kami gunakan dalam proyek sebelumnya). Alat-alat ini tidak memungkinkan kami untuk dengan cepat dan fleksibel memenuhi tantangan. Untungnya, kami telah mempertimbangkan pendekatan baru untuk pengembangan klien dan server. Pilihan kami jatuh pada Angular 2 dan Node.js. Solusi ini memungkinkan kami untuk dengan cepat membentuk komponen dan modul yang dapat kami modifikasi dalam waktu sesingkat mungkin (pada hari kami dapat mengulanginya dua atau tiga kali).
Kami sampai pada kesimpulan bahwa setiap komponen harus sekecil mungkin dan terintegrasi ke dalam komponen dan modul lainnya. Jadi, dalam proses percobaan, kami mengumpulkan cukup templat yang memungkinkan untuk mengumpulkan berbagai tata letak yang berfungsi.
Tetapi jika kami menemukan alat dengan cukup cepat dan dalam pertempuran semakin banyak keterampilan kami (saya akan segera melihat Google untuk membantu Anda, tetapi jangan lupa tentang tutorial video), maka pertanyaan lain muncul di mana menyimpan data. Tetapi saya akan membicarakan hal ini nanti, dan sekarang kembali ke ide itu sendiri.
Vektor utama dari layanan kami yang kami tuju untuk mengatur perjalanan, Anda akan segera mengatakan bahwa di waktu kami ada banyak situs dan layanan untuk perjalanan, ditambah banyak agen perjalanan yang sama dan saya setuju dengan Anda. Tapi, pertanyaannya adalah bagaimana mengubah sikap wisatawan rata-rata untuk beristirahat dan memberinya kesempatan untuk mendapatkan set tayangan maksimum dan merasakan pendekatan individual kepada orang yang dicintainya.
Kami memahami bahwa rencana ambisius seperti itu tidak dapat diselesaikan dengan satu layanan atau dengan satu solusi tunggal, tetapi kami selalu harus memulai dari suatu tempat. Dan sekarang, setelah menetapkan diri dengan tujuan utama, kami mulai mencari batu bata pertama itu, yang akan berfungsi sebagai dasar dari solusi masa depan kami. Setelah pencarian yang panjang, kami menemukan ide layanan, yang sekarang ingin saya bicarakan.
Apa ini
Singkatnya, ini adalah UBER untuk pelancong. Bayangkan Anda adalah seorang pelancong berpengalaman yang telah melakukan perjalanan ke banyak tempat menarik di seluruh dunia dan benar-benar ingin berbagi pengalamannya, baik, dan dapatkan uang. Dan di sisi lain, seorang turis yang bosan dengan liburan Turki dengan berbaring di pantai dan makan dan minum. Dan orang-orang ini perlu disatukan. Jadi kami memutuskan untuk membantu orang-orang ini menemukan satu sama lain.
Layanan ini adalah pasar di mana wisatawan yang berpengalaman dapat mendaftar untuk merancang tur mereka dan menyediakannya untuk massa wisatawan masa depan.
Teknologi dan cara mereka tidak unik
Bagaimana cara menyimpan dan di mana?
Seperti yang sudah saya tulis, setelah memilih alat untuk membuat layanan, muncul pertanyaan memilih gudang data. Tentu saja, selama bertahun-tahun kita telah terbiasa dengan database relasional dan SQL Server pada khususnya. Namun, sebuah platform diperlukan untuk konfigurasi minimal di awal dan upaya minimum dengan dukungan lebih lanjut, serta kemampuan untuk meningkatkan dalam pengembangan layanan kami dan pertumbuhan pengunjung.
Jadi, dalam proses pencarian, solusi ditemukan yang mencakup semua persyaratan kami, itu adalah Firebase Realtime Database. Layanan ini membantu kami memecahkan masalah penyimpanan data, hosting, layanan otentikasi, pergudangan untuk menyimpan data statis. Plus, layanan ini berada di bawah sayap Google, yang pada gilirannya memberi kami bonus bagus, karena menyediakan perpustakaan terpisah untuk bekerja dengan Angular 2 dan nyaman dan cepat. Tapi hal paling keren yang kami punya adalah RealTime Database di luar kotak. Sensasi pertama kami benar-benar fantastis.
Sekarang kami tidak harus terus-menerus membuat permintaan ke layanan, memantau relevansi data pada klien, tunggu sampai data tiba di klien (well, saya perhatikan, Angular juga membantu kami). Kami mengkonfigurasi semua ini di suatu tempat dalam sehari dan kemudian mulai secara langsung membuat layanan kami, tanpa terganggu oleh masalah infrastruktur. Saya harus segera mengatakan bahwa selama proses pengembangan kami tidak mengeluarkan sepeser pun untuk layanan ini, karena versi dasarnya gratis dan cukup untuk pengembangan, pengujian dan eksperimen.
Tidak hanya untuk menyimpan, tetapi juga untuk mencari
Jadi, segera setelah beta pertama siap, muncul pertanyaan dalam memfilter data, dan kami menyadari kerugian pertama di Firebase. Ternyata, proses pengambilan sampel data untuk sejumlah besar kondisi sama sekali tidak didukung. Dimungkinkan untuk memilih data dengan hanya satu syarat, atau untuk mengumpulkan beberapa nilai dalam satu bidang dan kemudian menyaringnya. Pendekatan ini tidak cocok untuk kami, dan kami kembali mencari solusi.
Tentu saja, kami tidak menolak Firebase, karena minus ini tidak tumpang tindih dengan banyak keuntungan yang diberikan oleh layanan ini. Untungnya, kami memiliki pengalaman menggunakan Google Big Query, yang kami dapatkan dalam proses penelitian kami, dan kami memutuskan untuk menerapkannya. Nilai tambah pertama adalah bahwa Google, yang kedua - kueri SQL asli dan favorit dan biaya rendah untuk memiliki 1TB data per bulan secara gratis.
Sekali lagi, semuanya menjadi jelas dan dapat dimengerti, mereka menulis layanan pengiriman data dan berhasil mengacaukannya ke Fungsi Cloud. Saya lupa mengatakan bahwa Firebase juga menangani backend, Anda dapat menulis pemicu Anda sendiri di Nodejs dan menggantungnya di acara apa pun di database, serta pada permintaan http.
Seperti yang Anda lihat, proses mencari solusi dan pendekatan telah menjadi tugas sehari-hari bagi kami, karena hampir setiap hari kami dihadapkan dengan tantangan baru yang perlu ditangani dengan cepat.
Kami tidak punya waktu untuk bersantai dan dengan tenang terus menciptakan layanan kami ketika pengujian grup fokus dimulai, dan kami menyadari bahwa pengguna terbiasa mengganti filter dengan sangat cepat dan ingin segera melihat hasil pekerjaan mereka. Persyaratan seperti itu memaksa kami untuk meninggalkan Big Query dan mencari sesuatu yang baru. Karena Big Query memberi kami kecepatan respons maksimal 2 detik, dan ini dengan jumlah data minimum. Di sini, tentu saja, tidak ada yang salah untuk mereka, karena layanan ini dimaksudkan untuk memproses informasi dalam jumlah besar, dan bukan untuk reaksi cepat terhadap sekelompok permintaan yang berurutan.
Akibatnya, kami memilih Penelusuran Elastis. Produk ini memungkinkan kami membuat mesin pencari cepat, penyaringan kami mulai memenuhi persyaratan pengguna kami. Saya tidak akan memberi tahu banyak di sini, karena produk ini mulai mendapatkan popularitas dan ada informasi yang cukup tentang itu. Satu-satunya hal yang ingin saya perhatikan adalah bahwa untuk produk ini Anda memerlukan mesin virtual yang perlu di-host di suatu tempat. Fitur ini menyediakan Google dan Microsoft, jadi pilihan ada di tangan Anda. Mengkonfigurasinya semudah menggunakan sumber daya bitnami. Kami memilih Azure untuk diri kami sendiri, pilihan ini bukan karena fitur teknologi, tetapi lebih karena faktor pihak ketiga).
Ini adalah SEO samar
Dan sekarang layanan sedang berjalan, platform sedang dikembangkan dan semuanya tampak baik-baik saja, kami berjuang untuk masa depan yang cerah. Tapi, ini mengangkat masalah mempromosikan layanan kami dan masalah SEO utama. Saya tidak pernah berpikir bahwa pertanyaan ini mungkin tidak akan dikerjakan oleh pencipta Angular. Ternyata, Aplikasi Halaman Tunggal sangat lemah dalam menyediakan fitur ini, dan jujur, itu tidak sama sekali. Ya, Anda dapat menjahit data statis menjadi tag meta dan ketika Anda mem-bypass Crowl atau ketika berbagi memberikan informasi yang sama, ya, entah bagaimana itu salah dan tidak efektif. Setelah berselancar di Internet, kami menemukan layanan yang luar biasa, yang merupakan bagian dari Angular 4, Angular Universal. Setelah membaca deskripsi, kami menyadari bahwa inilah yang kami butuhkan dan sia-sia kami memarahi pengembang kerangka kerja.
Sebuah epik dimulai dengan mengacaukan kebahagiaan ini untuk proyek kami, saya perhatikan bahwa pada saat itu sekitar 10 modul besar telah ditulis dan sekitar 12 paket npm pihak ketiga digunakan. Konfigurasi pertama dari proyek bersih berjalan dengan sempurna, berkat manual di Internet, dan semuanya tampak mulai. Selain itu, kami memutar semua bagian server pada Fungsi Cloud yang sama dari Firebase. Nah, sekarang kita harus mencoba kode pertempuran, dan kemudian ada masalah. Pertama, ternyata, semua paket npm pihak ketiga harus mendukung Angular 4, dalam kode di sisi server Anda tidak dapat menggunakan jendela variabel, dokumen, dll., Men-debug semua kebahagiaan ini tidak realistis.
Saya tidak akan menggambarkan semua siksaan kami dengan layanan ini, karena itu banyak dan menyakitkan. Saya akan mengatakan satu hal, kami tidak mengatasinya, saya tidak tahu atau tidak sepenuhnya memahaminya, atau hanya masih lembab dan tidak siap untuk penggunaan produktif. Secara umum, terserah Anda untuk memutuskan siapa yang bisa berhasil, tetapi kami memutuskan untuk berhenti di situ. Akibatnya, sebuah layanan ditulis yang mendengarkan semua permintaan http dan mengembalikan permintaan index.html, tetapi sebelum itu, melemparkan meta tag yang diperlukan ke dalamnya. Hasilnya, ternyata baik dan selama 3 bulan penerbangannya sudah normal. Omong-omong, kami menyimpan semuanya di Azure juga untuk semua faktor pihak ketiga yang sama.
Cdn segalanya untuk kita
Dan di sini lagi beberapa waktu stabilitas, dan pekerjaan yang relatif tenang. Dan tidak ada yang mengira bahwa kejutan itu menanti kita dari Facebook. Suatu hari ternyata berbagi di FB tidak berhasil. Awalnya kami berpikir bahwa ini adalah karena pengetatan kebijakan keamanan di FB, kemudian dengan pemblokiran IP, tetapi kami tidak menemukan alasannya. Dihubungi untuk mendukung FB dan Firebase, tetapi masing-masing menendang yang lain.
Satu-satunya hal yang telah kami tentukan adalah bahwa masalahnya ada di url untuk gambar-gambar yang kami simpan di toko Firebase, dan url itu, saya katakan segera, sangat spesifik di sana. Kami memutuskan untuk mentransfer semua konten statis ke Azure juga, dan saya akan memberi tahu Anda keputusan ini benar, karena kecepatan unggah foto telah meningkat, dan Anda dapat mengelola semua ini dengan lebih fleksibel dan transparan.
Untuk meringkas
Saat ini, kami sudah berada di bulan ke 3 yang produktif, kami terus meningkatkan dan memperluas fungsionalitas. Untuk kontrol versi, tentu saja kami menggunakan Git, kami secara bertahap akan mengotomatiskan build dan deploy. Kami mendapat sekitar 450 kunjungan unik baru per hari, ada peningkatan hingga 1000 pengguna. Dan itu semua berhasil.
Apa yang ingin saya rangkum dari semua yang telah dikatakan:
- Tidak perlu mencoba menyelesaikan semua masalah yang muncul dalam proyek Anda karena satu layanan atau satu teknologi.
- Cobalah untuk mengembangkan modul universal agar lebih fleksibel di masa depan.
- Pilihan penyedia layanan cloud adalah murni masalah pribadi, karena secara umum mereka semua menyediakan serangkaian layanan yang sama. Pertanyaannya tetap pada harga dan preferensi Anda.
- Rancang solusi Anda sehingga Anda dapat bermigrasi di antara penyedia layanan dan teknologi yang berbeda, atau setidaknya pikirkan strategi untuk langkah yang mungkin.
- Nah, jangan takut untuk bereksperimen.