Titik akhir API adalah URL spesifik yang bertindak sebagai titik masuk ke layanan tertentu atau fungsi dalam suatu layanan.

Melalui titik akhir API, aplikasi klien dapat berinteraksi dengan server dengan mengirimkan permintaan (terkadang bahkan dengan data dalam bentuk muatan) dan menerima respons darinya.

Biasanya, setiap titik akhir dapat dipetakan ke satu fitur di dalam server.

Basis data SQL (atau basis data relasional sebagaimana juga dikenal) mengandalkan skema (atau struktur) yang telah ditetapkan sebelumnya untuk datanya. Setiap kali Anda mendeskripsikan rekaman atau tabel di dalam basis data, Anda melakukannya melalui formatnya (nama dan kolom).

Dalam kasus basis data NoSQL, tidak ada skema, jadi tidak ada struktur yang telah ditetapkan sebelumnya untuk data. Anda biasanya memiliki kumpulan rekaman yang tidak wajib memiliki struktur yang sama, meskipun secara konseptual rekaman tersebut mewakili hal yang sama.

Agar suatu API menjadi RESTful (yang artinya mematuhi pedoman REST), API tersebut harus:

• Perlu mengikuti arsitektur klien-server (yang dilakukan semua layanan berbasis HTTP).
• Harus menyediakan antarmuka yang seragam yang berarti:
  • Harus ada cara untuk mengidentifikasi sumber daya satu sama lain melalui URI (Identifikasi Sumber Daya Unik).
  • Harus ada cara untuk memodifikasi sumber daya melalui representasinya.
  • Pesan harus bersifat deskriptif sendiri, artinya setiap pesan harus memberikan informasi yang cukup untuk memahami cara memprosesnya.
  • Klien yang menggunakan API harus dapat menemukan tindakan yang tersedia untuk sumber daya saat ini menggunakan respons yang disediakan dari server (ini dikenal sebagai HATEOAS atau Hypermedia sebagai Mesin Status Aplikasi).
• Harus stateless, yang berarti setiap permintaan ke server harus berisi semua informasi untuk memproses permintaan tersebut.
• Sistemnya mesti berlapis, artinya klien dan server tidak harus terhubung langsung satu sama lain, mungkin ada perantara, tetapi hal itu tidak boleh memengaruhi komunikasi antara klien dan server.
• Sumber daya harus dapat di-cache oleh klien atau server.
• Secara opsional, server dapat mengirim kode ke klien untuk dieksekusi (dikenal sebagai “Kode Sesuai Permintaan”).

Protokol HTTP sangat terstruktur dan terdiri dari serangkaian langkah yang terdefinisi dengan baik:

• Buka koneksi. Klien membuka koneksi TCP ke server. Port yang digunakan adalah port 80 untuk koneksi HTTP dan 443 untuk koneksi HTTPS (aman).
• Kirim permintaan. Klien sekarang akan mengirim permintaan HTTP ke server. Permintaan tersebut berisi informasi berikut:
  • Metode HTTP . Bisa salah satunya (misalnya GET, POST, PUT, DELETE, dll).
  • URI (atau Uniform Resource Identifier). Ini menentukan lokasi sumber daya di server.
  • Versi HTTP (biasanya HTTP/1.1 atau HTTP/2).
  • Seperangkat header. Header ini berisi data tambahan yang terkait dengan permintaan; berikut adalah daftar lengkap header HTTP yang dapat digunakan.
  • Isi opsional. Bergantung pada jenis permintaan, Anda juga ingin mengirim data, dan data tersebut dikodekan di dalam isi permintaan.
• Permintaan diproses oleh server. Pada tahap ini, server akan memproses permintaan dan menyiapkan respons.
• Kirim respons HTTP kembali ke klien. Melalui saluran terbuka, server mengirimkan kembali respons HTTP. Respons tersebut akan berisi elemen-elemen berikut:
  • Versi HTTP.
  • Kode status. Ada daftar kode status potensial yang menjelaskan hasil permintaan.
  • Satu set header dengan data tambahan.
  • Isi opsional, seperti halnya permintaan, isi respons bersifat opsional.
• Koneksi ditutup. Ini biasanya merupakan langkah terakhir, meskipun dengan versi protokol yang lebih baru, ada pilihan untuk membiarkan saluran tetap terbuka dan terus mengirimkan permintaan dan respons bolak-balik.

Dari sudut pandang pengembang backend, pertimbangan berikut harus diperhatikan saat menangani unggahan file, apa pun bahasa pemrograman yang Anda gunakan:

• Lakukan validasi sisi server. Pastikan ukuran file Anda berada dalam kisaran yang diinginkan, dan file tersebut berjenis yang dibutuhkan. Anda dapat memeriksa panduan OWASP ini untuk keterangan lebih rinci.
• Gunakan saluran yang aman. Pastikan pengunggahan berkas dilakukan melalui koneksi HTTPS.
• Hindari benturan nama. Ganti nama berkas dengan memastikan nama berkas baru tersebut unik dalam sistem Anda. Jika tidak, hal ini dapat menyebabkan kesalahan aplikasi karena tidak dapat menyimpan berkas yang diunggah.
• Simpan metadata tentang berkas Anda. Simpan di basis data Anda atau di tempat lain, tetapi pastikan untuk melacaknya, sehingga Anda dapat memberikan informasi tambahan kepada pengguna. Selain itu, jika Anda mengganti nama berkas demi keamanan dan menghindari benturan nama, lacak nama berkas asli jika berkas perlu diunduh kembali oleh pengguna.

Sebagai pengembang backend, kami harus memikirkan jenis pengujian yang ada di luar sana.

• Pengujian unit: Selalu ingat untuk hanya menguji logika yang relevan melalui antarmuka publik kode Anda (hindari pengujian metode privat atau fungsi yang tidak dapat diakses di dalam modul Anda). Fokus pada logika bisnis dan jangan mencoba menguji kode yang menggunakan layanan eksternal (seperti basis data, disk, atau apa pun di luar bagian kode yang Anda uji).
• Pengujian integrasi: Uji titik akhir penuh melalui antarmuka publiknya (titik akhir HTTP sebenarnya) dan lihat bagaimana titik akhir tersebut terintegrasi dengan layanan eksternal yang digunakannya (yaitu basis data, API lain, dll.).
• Pengujian beban/pengujian kinerja: Anda mungkin juga ingin memeriksa bagaimana endpoint baru berperilaku di bawah tekanan berat. Ini mungkin tidak diperlukan tergantung pada API yang Anda gunakan, tetapi sebagai aturan praktis, ini adalah hal yang baik untuk dilakukan di akhir fase pengembangan sebelum merilis endpoint baru ke prod.

Berikut ini adalah ikhtisar tingkat tinggi tentang cara kerja manajemen sesi untuk aplikasi web:

• Sesi dibuat. Hal ini terjadi saat pengguna pertama kali berinteraksi dengan sistem (selama proses log-in). Backend aplikasi Anda akan membuat ID sesi unik yang akan disimpan dan dikembalikan ke pengguna untuk digunakan dalam permintaan berikutnya.
• Penyimpanan informasi sesi. Data sesi perlu disimpan di suatu tempat. Baik di dalam memori, atau di dalam basis data, data tersebut perlu diindeks berdasarkan ID sesi dari poin sebelumnya. Di sini, opsi terbaik adalah menggunakan basis data (idealnya seperti Redis dengan kinerja I/O tinggi) sehingga layanan dapat diskalakan secara independen dari data sesi.
• ID sesi dikirimkan ke klien. Cara yang paling umum untuk melakukan ini adalah melalui cookie. Backend dapat menyiapkan cookie dengan ID sesi dan frontend dapat membacanya dengan aman dan menggunakan ID tersebut sesuai kebutuhan.
• Klien mengirimkan ID sesi. Setelah ID dibuat, aplikasi klien akan mengidentifikasi dirinya dengan backend menggunakan ID ini pada setiap permintaan.
• Mengakses data sesi di backend. Backend akan mengakses data sesi yang tersimpan menggunakan ID sesi yang diterima dari klien.
• Sesi ditutup. Setelah beberapa saat, atau mungkin melalui tindakan pengguna, ID sesi akan dihapus, yang akan menyebabkan data sesi hilang (atau dihapus dari DB). Ini secara efektif mengakhiri interaksi antara klien dan server sebagai bagian dari sesi yang ada.

Ada beberapa cara untuk menangani versi API, tetapi yang paling umum adalah:

• Menyimpan versi di URL: Baik sebagai atribut URL (misalnya /your-api/users?v=1) atau sebagai bagian dari URL (misalnya /v1/your-api/users). Dalam kedua situasi tersebut, versi tersebut terlihat jelas oleh pengembang yang menggunakan API.
• Menggunakan header khusus: Pilihan lainnya adalah memiliki header khusus (seperti api-version) di mana pengembang harus menentukan versi API yang ingin mereka gunakan.

Ada banyak cara untuk melindungi basis data relasional Anda dari serangan injeksi SQL, tetapi berikut ini tiga cara yang sangat umum.

• Pernyataan yang disiapkan dengan kueri berparameter. Ini mungkin cara yang paling efektif karena dilakukan oleh pustaka atau kerangka kerja, dan yang harus Anda lakukan hanyalah menulis kueri dengan meninggalkan tempat penampung untuk tempat data seharusnya berada, lalu, di tempat terpisah, berikan data sebenarnya.
• Gunakan ORM (Object-Relational Mapping). Kerangka kerja ini memungkinkan Anda untuk mengabstraksikan interaksi dengan basis data Anda dan membuat kueri SQL untuk Anda, dengan mempertimbangkan semua masalah keamanan di sekitar interaksi tersebut.
• Melarikan diri dari data. Jika Anda ingin melakukannya secara manual, Anda dapat menangani pelarian karakter khusus yang dapat merusak cara Anda menyusun kueri SQL. Menyimpan daftar karakter yang masuk daftar hitam untuk diloloskan dalam situasi ini merupakan ide yang bagus, sehingga Anda dapat menelusurinya secara terprogram.

HTTP, secara desain, merupakan protokol stateless, artinya setiap permintaan bersifat unik dan tidak terkait dengan permintaan sebelumnya, bahkan dari klien yang sama.

Hal ini memengaruhi layanan web backend dengan memaksa mereka untuk menerapkan solusi manajemen status mereka sendiri jika fitur tersebut diperlukan.

Ini adalah metode virtualisasi ringan untuk mengemas aplikasi dan dependensinya, memastikan lingkungan yang konsisten di berbagai sistem.

Ini sebenarnya bermanfaat untuk pengembangan backend karena menyediakan isolasi dan portabilitas dengan menyederhanakan proses penerapan dan mengurangi konflik antara versi dan konfigurasi perangkat lunak.

Ada banyak cara untuk mengamankan API, berikut adalah beberapa yang paling umum:

• Tambahkan metode autentikasi, seperti OAuth, JWT, Token pembawa, autentikasi berbasis sesi, dan lainnya.
• Gunakan HTTPS untuk mengenkripsi transfer data antara klien dan server.
• Konfigurasikan kebijakan CORS yang kuat untuk menghindari permintaan yang tidak diinginkan.
• Siapkan logika otorisasi yang kuat, untuk memastikan klien hanya mengakses sumber daya yang dapat mereka akses.

Cara yang paling umum untuk meningkatkan aplikasi backend selama lonjakan lalu lintas adalah dengan memiliki beberapa contoh aplikasi di belakang penyeimbang beban, dan ketika lonjakan lalu lintas terjadi, cukup tambahkan lebih banyak contoh aplikasi.

Ini dikenal sebagai penskalaan horizontal dan berfungsi paling baik ketika aplikasi backend tidak memiliki status.

Jika aplikasi backend yang sedang di-debug berada di mesin pengembangan lokal, solusi sederhananya adalah menggunakan IDE itu sendiri. Sebagian besar IDE modern, seperti IntelliJ, Eclipse, dan lainnya memiliki kemampuan debugging terintegrasi.

Namun, jika aplikasi backend berada di server, Anda harus menggunakan teknik lain, seperti pencatatan log, yang dapat Anda lakukan dengan pustaka pencatatan log. Atau, Anda dapat menggunakan alat yang lebih kompleks seperti JProfiler atau NewRelic.

Triknya di sini adalah mengikuti praktik terbaik dan standar pengkodean seperti:

• Modularitas.
• Mengikuti konvensi penamaan.
• Menambahkan komentar kode.
• Melakukan perbaikan secara berkala untuk menjaga agar utang teknis tetap terkendali.
• Menjaga pesan penanganan kesalahan tetap konsisten di seluruh platform.
• Melakukan pengujian unit pada semua kode tertulis.

Anda dapat menggunakan fungsi pencarian teks lengkap asli dari suatu basis data, seperti MySQL, Postgre atau bahkan ElasticSearch.

Namun, jika Anda ingin menerapkannya sendiri, langkah-langkahnya adalah:

• Melakukan praproses data teks yang akan dicari dan menormalkannya dengan menerapkan tokenisasi, stemming, dan menghilangkan kata henti.
• Lalu, terapkan indeks terbalik, dengan cara menghubungkan setiap kata unik dengan rekaman yang memuat kata itu.
• Buat UI pencarian dan normalkan masukan dari pengguna dengan cara yang sama seperti data teks dinormalisasi.
• Lalu, cari setiap kata dalam basis data.
• Urutkan hasil dengan menerapkan logika penilaian berdasarkan berbagai aspek, seperti frekuensi kata.

Pilihan terbaik di sini adalah menggunakan kerangka kerja pemrosesan batch seperti Hadoop atau Spark. Kerangka kerja tersebut sudah siap untuk memproses sejumlah besar data secara paralel.

Antrean pesan dalam sistem terdistribusi dapat bertindak sebagai komponen inti dari arsitektur reaktif. Setiap layanan dapat memicu dan mendengarkan peristiwa yang datang dari antrean. Dengan demikian, saat peristiwa tiba, layanan tersebut dapat bereaksi tanpa harus secara aktif meminta tanggapan dari layanan lain.

Selama skenario beban tinggi, ada beberapa hal yang dapat dilakukan pengembang untuk meningkatkan kinerja koneksi basis data:

• Menggunakan kumpulan koneksi untuk menggunakan kembali koneksi mengurangi waktu yang dibutuhkan untuk membuat koneksi baru.
• Menyeimbangkan beban lalu lintas basis data (kueri) antara sekelompok basis data akan membantu mendistribusikan beban.
• Bahkan mengoptimalkan kueri Anda dapat mengurangi waktu yang Anda gunakan pada setiap koneksi, membantu Anda mengoptimalkan penggunaan sumber daya dan meminimalkan waktu yang Anda habiskan pada setiap koneksi aktif.

Ada beberapa pertimbangan yang perlu diperhatikan saat menyiapkan jalur Integrasi Berkelanjutan dan Pengiriman Berkelanjutan:

• Menggunakan kontrol sumber sebagai pemicu untuk seluruh proses (misalnya git). Alur kerja untuk layanan backend Anda harus dijalankan saat Anda memasukkan kode ke cabang tertentu.
• Pilih platform CI/CD yang tepat untuk kebutuhan Anda, ada banyak di luar sana seperti GitHub Actions, GitLab CI/CD, CircleCI dan banyak lagi.
• Pastikan Anda memiliki pengujian unit otomatis yang dapat dijalankan di dalam jalur ini.
• Penerapan otomatis seharusnya terjadi hanya jika semua pengujian berhasil dijalankan, jika tidak, jalur akan gagal, mencegah kode yang rusak mencapai lingkungan mana pun.
• Gunakan repositori artifak seperti JFrog Artifactory atau Nexus Repository untuk menyimpan layanan yang berhasil dibangun.
• Terakhir, pertimbangkan untuk menyiapkan strategi pengembalian apabila terjadi kesalahan dan versi akhir layanan yang diterapkan rusak.

Dalam skenario ini, Anda harus mempertimbangkan poin-poin berikut:

• Terapkan kluster server yang semuanya akan bertindak sebagai cache terdistribusi. Terapkan proses sharding data untuk mendistribusikan data secara merata di antara semua server cache dan pastikan proses tersebut menggunakan algoritma hashing yang konsisten untuk meminimalkan reorganisasi cache saat server bergabung atau meninggalkan kluster.
• Tambahkan replikasi cache untuk memiliki redundansi data jika terjadi kegagalan, dengan cara itu, cache terdistribusi Anda juga toleran terhadap kesalahan.
• Pembatalan cache merupakan keharusan pada solusi caching apa pun, karena data Anda akan menjadi basi jika Anda tidak sering memperbaruinya.

Hal ini sangat bergantung pada tumpukan teknologi Anda dan tugas-tugas latar belakang yang sedang dilakukan. Oleh karena itu, ada banyak pilihan:

• Menggunakan task queue seperti RabbitMQ atau Amazon SQS. Ini akan memungkinkan Anda memiliki pekerja di latar belakang sebagai proses sekunder sementara aplikasi Anda terus berjalan.
• Ada kerangka kerja pekerjaan latar belakang seperti Celery untuk Python atau Sidekiq untuk Ruby .
• Anda juga dapat mengandalkan cron job jika Anda mau.
• Jika bahasa pemrograman Anda mengizinkannya, Anda juga dapat menggunakan thread atau pekerja untuk menjalankan tugas ini di latar belakang tetapi dalam aplikasi yang sama.

Untuk jenis aplikasi ini, Anda harus membedakan antara "data yang tidak aktif" dan "data yang sedang dalam perjalanan". Yang pertama menjelaskan data Anda saat disimpan dalam basis data Anda (atau penyimpanan data apa pun yang Anda miliki). Dan yang terakhir (data yang sedang dalam perjalanan) menjelaskan data Anda saat sedang berpindah-pindah antara layanan backend atau bahkan antara server dan klien.

Untuk “data dalam transit”, Anda harus memastikan bahwa koneksi terjadi di dalam saluran yang aman dan terenkripsi seperti HTTPS.

Dan untuk “data yang tidak aktif” gunakan algoritma enkripsi yang kuat seperti AES , RSA atau ECC dan pastikan untuk menyimpan kunci terkait di tempat yang aman, seperti di dalam alat manajemen rahasia khusus atau layanan manajemen kunci (KMS).

Webhook adalah panggilan balik HTTP yang ditentukan pengguna, yang dipicu oleh peristiwa tertentu di dalam suatu sistem. Webhook terutama digunakan untuk memberi tahu tentang hasil tugas asinkron yang bertahap untuk menghindari koneksi HTTP yang terbuka.

Mengenai implementasi webhook, pertimbangkan hal berikut:

• Definisi peristiwa. Pastikan untuk menentukan dengan tepat peristiwa apa yang akan memicu pesan ke webhook dan jenis muatan yang terkait dengan peristiwa tersebut.
• Pembuatan titik akhir. Berdasarkan langkah sebelumnya, tentukan titik akhir HTTP yang dapat menangani permintaan yang diharapkan (terutama dengan bagian payload). Dengan kata lain, jika Anda menerima data dalam permintaan webhook, pastikan untuk membuat titik akhir sebagai titik akhir POST, jika tidak, Anda dapat menggunakan titik akhir GET.
• Keamanan. Ingatlah untuk menerapkan beberapa bentuk tindakan keamanan di sekitar titik akhir webhook Anda sehingga tidak dapat dieksploitasi.

Berikut ini adalah pertimbangan utama yang perlu diperhatikan:

• Catat hanya apa yang Anda butuhkan dan apa yang Anda katakan kepada pengguna akan catat. Ingatlah bahwa untuk mematuhi GDPR, Anda harus meminta persetujuan pengguna untuk mengumpulkan data mereka, dan Anda harus menentukan titik data aktual yang Anda kumpulkan. Jadi, fokuslah pada hal tersebut dan jangan pada yang lain.
• Amankan data Anda. Sebagai bagian dari peraturan, Anda harus memastikan data Anda aman saat dikirim dan disimpan. Ada audit keamanan rutin yang harus dilakukan untuk memastikan keamanan tetap tinggi.
• Pengguna memiliki hak atas data yang Anda ambil, jadi pastikan Anda memberi mereka titik akhir atau layanan yang tepat untuk membacanya, mengeditnya, atau bahkan menghapusnya jika mereka mau.

Untuk permintaan web yang memicu proses yang berjalan lama, opsi terbaik adalah menerapkan arsitektur reaktif. Ini berarti bahwa saat layanan menerima permintaan, layanan akan mengubahnya menjadi pesan di dalam antrean pesan, dan proses yang berjalan lama akan mengambilnya kapan pun ia siap melakukannya.

Sementara itu, klien yang mengirimkan permintaan ini menerima respons langsung yang menyatakan bahwa permintaan tersebut sedang diproses. Klien itu sendiri juga dapat dihubungkan ke antrean pesan (atau melalui proxy) dan menunggu peristiwa "siap" dengan muatannya di dalamnya.

Untuk menerapkan pembatasan laju, Anda harus mengingat poin-poin berikut:

• Tetapkan batasan Anda. Tetapkan dengan tepat jumlah permintaan yang dapat dibuat klien. Hal ini dapat diukur dalam permintaan per menit, per hari, atau per detik.
• Pilih strategi pembatasan. Pilih algoritma pembatasan laju, seperti penghitung jendela tetap, jendela log geser, keranjang token, atau keranjang bocor. Anda dapat membaca lebih lanjut tentang algoritma ini di sini .
• Simpan penghitung Anda di suatu tempat. Gunakan penyimpanan data cepat (seperti Redis) untuk melacak jumlah permintaan atau stempel waktu untuk setiap klien.
• Setelah batas tercapai, coba tanggapi dengan kode status standar , seperti 429 yang menunjukkan ada “Terlalu Banyak Permintaan”.

Jika Anda ingin mengembangkannya lebih jauh, Anda dapat mempertimbangkan untuk menggunakan API Gateway yang sudah ada yang menyediakan fungsi ini atau mempertimbangkan untuk menambahkan dukungan untuk lonjakan lalu lintas secara tiba-tiba agar tidak memberikan penalti kepada klien yang sedikit melampaui batas sesekali.

Cara hebat untuk memantau kinerja aplikasi backend adalah dengan menggunakan sistem Manajemen Kinerja Aplikasi (APM) seperti New Relic, AppDynamics atau bahkan Dynatrace.

Itu akan melacak kinerja aplikasi Anda dan memberikan wawasan tentang hambatan yang mungkin Anda alami dengan upaya minimum dari Anda.

Layanan mikro adalah gaya arsitektur perangkat lunak yang memungkinkan Anda menyusun aplikasi backend sebagai kumpulan layanan independen, yang masing-masing bekerja untuk kebutuhan bisnis tertentu.

Jika Anda ingin menguraikan monolit menjadi serangkaian layanan mikro, Anda harus mengingat poin-poin berikut:

• Mulailah dengan mengidentifikasi batasan logis monolit Anda. Logika internalnya akan menangani berbagai tanggung jawab dan jenis sumber daya. Temukan batasan di antara keduanya untuk memahami di mana satu layanan dimulai dan layanan lainnya berakhir.
• Tentukan layanan Anda berdasarkan batasan dari poin sebelumnya dan mulailah memisahkan kebutuhan data juga. Baik ke dalam beberapa tabel atau bahkan basis data individual kapan pun diperlukan.
• Mulailah melakukan refaktor monolit secara bertahap dan mengekstraksi logika yang diperlukan untuk setiap layanan mikro individual ke dalam proyeknya sendiri.

Setelah selesai, monolit asli Anda tidak akan diperlukan lagi, dan semua layanan mikro Anda akan memiliki jalur penyebaran dan repositori kodenya sendiri yang independen.

Cara terbaik untuk menangani dependensi API di sistem backend adalah dengan memanfaatkan versi API. Melalui praktik sederhana ini, Anda dapat memastikan bahwa sistem Anda benar-benar menggunakan API yang tepat, meskipun ada beberapa versinya.

Hal ini juga memungkinkan Anda memiliki beberapa sistem backend menggunakan versi berbeda dari API yang sama tanpa risiko ketidakkonsistenan atau pembaruan yang merusak sistem Anda.

Konsistensi akhir adalah model konsistensi yang digunakan dalam komputasi terdistribusi. Model ini menjamin bahwa setiap informasi yang ditulis ke dalam sistem terdistribusi akan menjadi konsisten (artinya semua server akan memiliki versi data yang sama) pada akhirnya, berbeda dengan model lain yang menjamin konsistensi langsung.

Untuk sistem backend, ini berarti ada kebutuhan untuk sinkronisasi data antara semua bagian sistem terdistribusi dan terlebih lagi, ada potensi kebutuhan untuk menyelesaikan konflik data, jika bagian berbeda dari sistem Anda menangani versi berbeda dari rekaman data yang sama.

Proksi terbalik adalah server yang berada di depan beberapa server lain dan mengalihkan lalu lintas ke server web tersebut berdasarkan aturan logika yang berbeda. Misalnya, Anda dapat memiliki dua server web, satu untuk pelanggan bisnis Anda dan satu lagi untuk karyawan Anda.

Anda dapat mengonfigurasi proxy terbalik untuk mengalihkan lalu lintas ke satu atau yang lain tergantung pada nilai header yang dikirim dalam permintaan atau URL sebenarnya yang diminta.

Ini sangat berguna dalam pengembangan backend karena memungkinkan Anda melakukan banyak hal berbeda, misalnya:

• Menyeimbangkan beban lalu lintas antara beberapa instansi layanan backend yang sama.
• Berikan lapisan keamanan ekstra dengan menyembunyikan lokasi layanan backend dan menangani serangan, seperti DDoS.
• Ia dapat menyimpan konten dalam cache, sehingga mengurangi beban server pada server web Anda.
• Memungkinkan Anda untuk mengganti layanan backend tanpa memengaruhi URL yang diakses publik.

Dalam skenario aplikasi dengan beban seimbang, masalah utama dengan status sesi adalah jika sistem backend menangani data sesi dalam memori, maka permintaan berikutnya dari klien yang sama harus mendarat di server yang sama, jika tidak, data sesi akan terfragmentasi dan tidak berguna.

Ada dua cara utama untuk menyelesaikan masalah ini:

• Sesi lengket: Ini memungkinkan Anda mengonfigurasi penyeimbang beban untuk mengalihkan permintaan dari klien yang sama ke server yang sama setiap saat. Kelemahannya adalah lalu lintas tidak selalu terdistribusi secara merata di antara semua salinan layanan backend Anda.
• Penyimpanan sesi terpusat: Solusi ini melibatkan pengambilan data sesi di luar layanan backend Anda ke penyimpanan data terpusat yang dapat diakses oleh semua salinan layanan Anda. Hal ini memudahkan penyeimbang beban, tetapi memerlukan logika tambahan dan lebih banyak "komponen yang bergerak".

Terserah Anda dan persyaratan teknis spesifik Anda untuk menentukan strategi mana yang paling cocok untuk Anda.

Replikasi basis data menyiratkan replikasi data di beberapa instans basis data yang sama. Dalam skenario ini, biasanya ada satu basis data yang bertindak sebagai induk bagi semua klien yang menghubungkannya, dan sisanya bertindak sebagai "budak" yang hanya menerima pembaruan tentang data yang diubah/ditambahkan.

Dua implikasi utama dari hal ini dalam toleransi kesalahan adalah:

• Sebuah klaster basis data dapat mengatasi masalah pada server induk dengan mempromosikan salah satu server slave tanpa kehilangan data apa pun dalam proses tersebut.
• Slave dapat digunakan sebagai server baca-saja, meningkatkan jumlah permintaan baca yang dapat dilakukan pada data tanpa memengaruhi kinerja basis data.

Strategi biru-hijau melibatkan dua lingkungan produksi yang identik, salah satunya melayani lalu lintas nyata sementara yang lain bersiap-siap untuk diperbarui dengan rilis berikutnya atau hanya diam, menunggu untuk digunakan sebagai cadangan.

Teorema CAP menyatakan bahwa basis data terdistribusi tidak dapat memberikan lebih dari dua jaminan berikut secara bersamaan:

• Konsistensi Data: Artinya, setiap pembacaan selalu mengembalikan hasil operasi penulisan terkini. Hal ini sangat relevan dalam model ini karena kita berurusan dengan beberapa server dan data perlu direplikasi hampir seketika untuk menjamin konsistensi.
• Ketersediaan: Artinya setiap permintaan akan selalu menerima respons yang valid.
• Toleransi partisi: Sistem terdistribusi terus beroperasi dan berfungsi tanpa kehilangan data bahkan selama pemadaman jaringan sebagian.

Misalnya, jika sistemnya konsisten dan sangat tersedia, sistem tersebut tidak akan mampu menahan pemadaman jaringan parsial. Sebaliknya, jika sistemnya sangat tersedia dan toleran terhadap partisi, sistem tersebut tidak akan dapat memastikan konsistensi data secara langsung.

Dua aspek utama yang perlu dipertimbangkan saat mengelola migrasi skema, terutama di lingkungan CD adalah:

• Lacak migrasi skema Anda di dalam kontrol versi. Simpan versi file ini dengan kode Anda, karena ada hubungan langsung antara versi tersebut.
• Gunakan alat migrasi otomatis seperti Flyway atau Liquibase untuk menyederhanakan proses dan menjaganya tetap standar.

Untuk REST API, Anda dapat memanfaatkan kata kerja HTTP dan menentukan operasi idempoten menggunakan kata kerja yang pada hakikatnya idempoten, seperti GET, PUT, dan DELETE.

Atau Anda selalu dapat menerapkan logika berbasis kunci secara manual untuk menghindari pengulangan operasi yang sama beberapa kali jika kunci yang diberikan oleh klien selalu sama.

Pada tingkat yang sangat tinggi, langkah-langkah yang diperlukan untuk menerapkan solusi SSO adalah:

• Memilih penyedia identitas, seperti Okta atau Keycloack .
• Setiap aplikasi kemudian akan terintegrasi dengan penyedia Identitas dari langkah sebelumnya menggunakan protokol SSO standar, seperti SAML, OpenID atau lainnya.
• Untuk akses pengguna pertama, aplikasi akan terhubung dengan IdP dan mengautentikasi pengguna, lalu mendapatkan token akses sebagai balasannya.
• Kemudian selama permintaan berikutnya, aplikasi akan memvalidasi token yang disediakan melalui IdP.

Arsitektur penangkapan dan pemrosesan data waktu nyata memerlukan komponen-komponen berikut:

• Gunakan layanan penyerapan data yang dapat diskalakan seperti Kafka atau AWS Kinesis yang kompatibel dengan salah satu dari banyak protokol standar IoT (seperti MQTT atau CoAP).
• Memproses data melalui mesin pemrosesan waktu nyata seperti Apache Flink atau Spark Streaming.
• Simpan data di dalam danau data yang dapat diskalakan, idealnya sistem yang kompatibel dengan deret waktu seperti InfluxDB .

Jika Anda ingin mendukung sinkronisasi data waktu nyata, Anda harus menemukan cara untuk membuat saluran komunikasi yang stabil dan efisien antara perangkat dan menemukan cara untuk memecahkan potensi konflik sinkronisasi data saat beberapa perangkat mencoba mengubah rekaman yang sama.

Jadi, untuk saluran komunikasi, Anda dapat menggunakan salah satu dari berikut ini:

• Saluran dua arah berbasis soket yang memungkinkan pertukaran data secara real-time.
• Menggunakan model pub/sub untuk mendistribusikan data secara efisien di antara beberapa perangkat. Anda dapat menggunakan sesuatu seperti Redis atau Kafka untuk yang satu ini.

Untuk resolusi konflik data, Anda dapat menggunakan algoritma seperti Transformasi Operasional (OT) atau Tipe Data Replikasi Bebas Konflik (CRDT).

Manfaat:

• Skalabilitas: layanan mikro dapat diskalakan secara independen satu sama lain.
• Fleksibilitas teknologi: Anda dapat menggunakan tumpukan teknologi yang berbeda tergantung pada kebutuhan khusus setiap layanan mikro.
• Penerapan yang lebih cepat: layanan mikro dapat diterapkan secara individual, meningkatkan kecepatan Anda dalam menyampaikan perubahan pada produksi.

Kekurangan:

• Arsitektur yang terlalu kompleks. Dalam beberapa situasi, arsitektur berbasis layanan mikro dapat menjadi terlalu rumit untuk dikelola dan diatur.
• Debugging: Mendebug masalah dalam arsitektur berbasis layanan mikro bisa jadi sulit karena data mengalir melalui beberapa layanan selama satu permintaan.
• Overhead komunikasi: Dibandingkan dengan pendekatan monolitik, komunikasi antara layanan mikro bisa jadi terlalu rumit.

• Pertama-tama Anda harus memahami tujuan dan menyiapkan lingkungan pengujian. Idealnya, lingkungan Anda akan sangat mirip dengan produksi.
• Rancang dan laksanakan pengujian Anda dengan alat yang telah Anda pilih (seperti JMeter , LoadRunner , atau lainnya).
• Mulailah meningkatkan beban pengujian secara bertahap sambil memantau performa dan stabilitas sistem Anda.
• Optimalkan API backend Anda dan kembali ke langkah pertama untuk mendesain ulang pengujian Anda lalu coba lagi hingga Anda puas dengan hasilnya.

Untuk mendefinisikan strategi ini, Anda perlu mendefinisikan elemen-elemen berikut:

• Batas ukuran yang akan memicu pengusiran cache jika terlampaui.
• Strategi pemantauan untuk menentukan apakah strategi penggusuran berjalan dengan baik atau perlu penyesuaian.
• Mekanisme pembatalan cache.
• Dan kebijakan penggusuran, yang bisa berupa salah satu dari berikut ini:
  • LRU (Least Recently Used): Mengusir item yang paling jarang diakses.
  • LFU (Least Frequently Used): Hapus item yang paling jarang diakses.
  • FIFO (First-In, First-Out): Keluarkan item berdasarkan urutan penambahannya.
  • Acak: Pilih item yang akan dikeluarkan secara acak.
  • TTL (Time-To-Live): Barang kedaluwarsa setelah waktu tertentu.

ID Korelasi adalah pengidentifikasi unik yang ditambahkan pada permintaan yang dilakukan pada arsitektur terdistribusi untuk memudahkan pelacakan permintaan di seluruh arsitektur. Ingatlah bahwa biasanya, saat permintaan masuk ke sistem backend terdistribusi, data dari permintaan tersebut melewati beberapa layanan web sebelum menghasilkan respons.

Hal ini memudahkan untuk memahami perjalanan yang dilalui setiap permintaan untuk men-debug setiap potensi masalah atau kendala kinerja.

Penguncian optimis adalah strategi yang:

• Mengasumsikan konflik jarang terjadi dan tidak sering terjadi.
• Memungkinkan akses data serentak.
• Memeriksa apakah ada konflik sebelum melakukan komitmen.
• Cara ini paling baik digunakan pada skenario banyak membaca dan sedikit menulis.

Penguncian pesimistis , di sisi lain, adalah strategi yang:

• Mengasumsikan konflik sangat umum terjadi.
• Mengunci data dan mencegah akses bersamaan.
• Memegang kunci ini selama berlangsungnya transaksi.
• Paling cocok untuk skenario penulisan tinggi atau ketika integritas data sangat penting.

Ada banyak cara untuk mencegah kebuntuan dalam transaksi DB; beberapa yang paling umum adalah:

• Menggunakan tatanan kunci untuk memperoleh kunci dalam tatanan global yang konsisten, menghindari kondisi tunggu melingkar.
• Menggunakan batas waktu untuk transaksi DB untuk secara otomatis menghentikan operasi yang berjalan lama yang dapat menyebabkan kebuntuan.
• Gunakan kontrol konkurensi optimis jika memungkinkan, untuk menghindari penahanan kunci terlalu lama.

Dimulai dari dasar pemahaman bahwa komunikasi antar-layanan Anda dimaksudkan hanya terjadi di dalam jaringan pribadi (idealnya, tidak ada lalu lintas publik yang boleh mencapai layanan ini), berikut adalah beberapa rekomendasi:

• Gunakan saluran terenkripsi, seperti TLS untuk mencegah serangan umum seperti man-in-the-middle .
• Gunakan gateway API untuk mengelola dan mengautentikasi lalu lintas yang mencapai jaringan pribadi ini.
• Terapkan autentikasi dan otorisasi untuk pesan antar-layanan, pastikan hanya layanan mikro yang valid yang dapat saling menjangkau, dan saat mereka melakukannya, mereka hanya memiliki akses ke apa yang menjadi hak mereka.

Beberapa teknik umum meliputi:

• Menambahkan dan menerapkan aturan validasi untuk mencegah entri data yang tidak valid. Melalui definisi skema dan batasan skema untuk menegakkan standar minimum tertentu, Anda dapat mencegah terjadinya anomali data.
• Terapkan pembuatan versi data untuk memudahkan pengembalian jika ada anomali yang terdeteksi.
• Terapkan praktik kualitas data yang kuat untuk memastikan bahwa informasi apa pun yang masuk ke sistem Anda divalidasi dengan benar dan ditandai jika diperlukan.

Membangun penyimpanan data dengan ketersediaan tinggi melibatkan beberapa area, termasuk:

• Lingkungan multizona. Jika Anda menggunakan solusi berbasis cloud (seperti Azure, AWS, GCP, atau lainnya), kemungkinan besar persyaratan ini akan langsung terpenuhi (kecuali untuk beberapa wilayah tertentu di dunia). Hal ini untuk memastikan ketersediaan bahkan selama pemadaman jaringan parsial.
• Replikasi data. Pastikan data Anda direplikasi antara server di semua zona. Hal ini untuk memastikan bahwa jika terjadi kegagalan yang mengakibatkan beberapa server mati (atau bahkan seluruh zona), tidak ada kehilangan data.
• Penyeimbangan beban. Pastikan lalu lintas diseimbangkan bebannya dengan benar di antara semua zona ketersediaan Anda untuk memastikan latensi terendah bagi semua klien Anda.
• Lalu ada persyaratan lain seperti menyiapkan kebijakan tata kelola data yang tepat untuk memastikan akses data diatur, serta sepenuhnya mematuhi peraturan data setempat (seperti GDPR).

Kesimpulan

Mempersiapkan diri untuk wawancara sebagai backend developer adalah langkah penting dalam perjalanan karier Anda di dunia teknologi. Dengan memahami pertanyaan-pertanyaan yang sering diajukan, seperti konsep database, API, arsitektur aplikasi, dan pengoptimalan performa, Anda dapat menunjukkan keahlian teknis dan problem-solving yang diharapkan oleh perusahaan. Selain pertanyaan teknis, jangan lupa untuk siap menghadapi pertanyaan tentang pengalaman kerja, proyek yang pernah dikerjakan, dan kemampuan beradaptasi terhadap teknologi baru.

Latihan menjawab pertanyaan, belajar dari pengalaman, dan memperkuat pemahaman dasar teknologi backend akan membantu Anda tampil percaya diri dan profesional dalam sesi wawancara. Dengan persiapan yang matang, Anda akan lebih siap untuk mengesankan pewawancara dan meningkatkan peluang Anda untuk mendapatkan posisi sebagai backend developer yang Anda inginkan. Selamat mempersiapkan diri, dan semoga sukses dalam wawancara Anda!