Implementasi penelusuran FHIR Cloud Healthcare API sangat skalabel dan berperforma tinggi, sekaligus tetap mengikuti panduan dan batasan REST serta spesifikasi FHIR. Untuk membantu mencapai hal ini, penelusuran FHIR memiliki properti berikut:
Total penelusuran adalah estimasi hingga halaman terakhir ditampilkan. Hasil penelusuran yang ditampilkan oleh metode
fhir.searchmencakup total penelusuran (propertiBundle.total), yang merupakan jumlah total kecocokan dalam penelusuran. Total penelusuran adalah estimasi hingga halaman terakhir hasil penelusuran ditampilkan. Total penelusuran yang ditampilkan dengan halaman hasil terakhir adalah jumlah akurat dari semua kecocokan dalam penelusuran.Hasil penelusuran memberikan penomoran halaman maju berurutan. Jika ada hasil penelusuran lainnya yang akan ditampilkan, respons akan menyertakan URL penomoran halaman (
Bundle.link.url) untuk mendapatkan halaman hasil berikutnya.
Kasus penggunaan dasar
Penelusuran FHIR memberikan solusi untuk kasus penggunaan berikut:
- Jelajahi secara berurutan. Pengguna membuka halaman berikutnya secara berurutan melalui sejumlah halaman hasil penelusuran yang terbatas. Estimasi total penelusuran ditampilkan dengan setiap halaman.
- Memproses kumpulan hasil penelusuran. Aplikasi mendapatkan kumpulan hasil penelusuran, membaca hasil, dan memproses data.
Lihat bagian berikut untuk mengetahui kemungkinan solusi untuk kasus penggunaan ini.
Menjelajahi secara berurutan
Anda dapat membuat aplikasi latensi rendah yang memungkinkan pengguna menjelajahi halaman hasil secara berurutan hingga pengguna menemukan kecocokan yang mereka inginkan. Solusi ini dapat dilakukan jika jumlah kecocokan cukup kecil sehingga pengguna dapat menemukan kecocokan yang diinginkan dengan menjelajahi halaman demi halaman tanpa melewati hasil. Jika kasus penggunaan Anda mengharuskan pengguna untuk membuka beberapa halaman sekaligus, atau membuka halaman sebelumnya, lihat Membuka halaman terdekat.
Solusi ini tidak dapat memberikan total penelusuran yang akurat hingga halaman hasil terakhir ditampilkan. Namun, fitur ini dapat memberikan perkiraan total penelusuran dengan setiap halaman hasil. Meskipun total penelusuran yang akurat dapat menjadi persyaratan untuk proses latar belakang, perkiraan total penelusuran biasanya memadai untuk pengguna manusia.
Alur kerja
Berikut adalah contoh alur kerja untuk solusi ini:
Aplikasi memanggil metode
fhir.search, yang menampilkan halaman pertama hasil penelusuran. Respons menyertakan URL penomoran halaman (Bundle.link.url) jika ada hasil lainnya yang akan ditampilkan. Respons juga menyertakan total penelusuran (Bundle.total). Jika ada lebih banyak hasil yang ditampilkan daripada dalam respons awal, total penelusuran hanyalah estimasi. Untuk informasi selengkapnya, lihat Penomoran halaman dan pengurutan.Aplikasi menampilkan halaman hasil penelusuran, link ke halaman hasil berikutnya (jika ada), dan total penelusuran.
Jika pengguna ingin melihat halaman hasil berikutnya, mereka mengklik link, yang menghasilkan panggilan ke URL penomoran halaman. Respons menyertakan URL penomoran halaman baru jika ada lebih banyak hasil yang akan ditampilkan. Respons ini juga menyertakan total penelusuran. Ini adalah estimasi yang diperbarui jika ada lebih banyak hasil yang akan ditampilkan.
Aplikasi akan menampilkan halaman baru hasil penelusuran, link ke halaman hasil berikutnya (jika ada), dan total penelusuran.
Dua langkah sebelumnya diulang hingga pengguna berhenti menelusuri atau halaman hasil terakhir ditampilkan.
Praktik terbaik
Pilih ukuran halaman yang sesuai untuk dibaca manusia tanpa kesulitan. Bergantung pada kasus penggunaan Anda, jumlah ini mungkin 10 hingga 20 kecocokan per halaman. Halaman yang lebih kecil dimuat
lebih cepat, dan terlalu banyak link di halaman dapat menyulitkan pengguna untuk mengelolanya. Anda
mengontrol ukuran halaman dengan parameter _count.
Memproses kumpulan hasil penelusuran
Anda bisa mendapatkan kumpulan hasil penelusuran dengan melakukan panggilan berturut-turut ke metode fhir.search menggunakan URL penomoran halaman. Jika jumlah hasil penelusuran
cukup kecil, Anda bisa mendapatkan kumpulan hasil lengkap dengan melanjutkan hingga
tidak ada lagi halaman yang ditampilkan. Total penelusuran yang akurat disertakan di halaman
hasil terakhir. Setelah mendapatkan hasil penelusuran, aplikasi Anda dapat membacanya
dan melakukan pemrosesan, analisis, atau agregasi apa pun yang Anda perlukan.
Perlu diingat bahwa jika Anda memiliki hasil penelusuran dalam jumlah yang sangat besar, Anda mungkin tidak dapat mendapatkan halaman terakhir hasil penelusuran (dan total penelusuran yang akurat) dalam waktu yang praktis.
Alur kerja
Berikut adalah contoh alur kerja untuk solusi ini:
Aplikasi memanggil metode
fhir.search, yang menampilkan halaman pertama hasil penelusuran. Respons menyertakan URL penomoran halaman (Bundle.link.url) jika ada hasil lainnya yang akan ditampilkan.Jika ada lebih banyak hasil yang akan ditampilkan, aplikasi akan memanggil URL penomoran halaman dari langkah sebelumnya untuk mendapatkan halaman hasil penelusuran berikutnya.
Aplikasi mengulangi langkah sebelumnya hingga tidak ada lagi hasil yang akan ditampilkan atau beberapa batas yang telah ditentukan sebelumnya tercapai. Jika Anda mencapai halaman terakhir hasil penelusuran, total penelusuran akan akurat.
Aplikasi memproses hasil penelusuran.
Bergantung pada kasus penggunaan, aplikasi Anda dapat melakukan salah satu hal berikut:
- Tunggu hingga semua hasil penelusuran diterima sebelum memproses data.
- Memproses data saat diterima dengan setiap panggilan berturut-turut ke
fhir.search. - Tetapkan beberapa jenis batas, seperti jumlah kecocokan yang ditampilkan atau jumlah waktu yang berlalu. Jika batas tercapai, Anda dapat memproses data, tidak memproses data, atau melakukan tindakan lain.
Opsi desain
Berikut adalah beberapa opsi desain yang dapat mengurangi latensi penelusuran:
Tetapkan ukuran halaman yang besar. Gunakan parameter
_countuntuk menetapkan ukuran halaman yang besar, mungkin 500 hingga 1.000, bergantung pada kasus penggunaan Anda. Menggunakan ukuran halaman yang lebih besar akan meningkatkan latensi untuk setiap pengambilan halaman, tetapi dapat mempercepat proses secara keseluruhan, karena lebih sedikit pengambilan halaman yang diperlukan untuk mendapatkan seluruh kumpulan hasil penelusuran.Batasi hasil penelusuran. Jika yang Anda butuhkan hanyalah total penelusuran yang akurat (Anda tidak perlu menampilkan konten resource), tetapkan parameter
_elementsmetodefhir.searchkeidentifier. Hal ini dapat mengurangi latensi kueri penelusuran Anda, dibandingkan dengan meminta pengembalian resource FHIR lengkap. Untuk informasi selengkapnya, lihat Membatasi kolom yang ditampilkan dalam hasil penelusuran.
Kasus penggunaan yang memerlukan pengambilan data sebelumnya dan penyimpanan dalam cache
Anda mungkin memerlukan fungsi yang lebih dari yang memungkinkan menggunakan mekanisme sederhana
untuk memanggil metode fhir.search secara berurutan menggunakan URL penomoran halaman. Salah satu
kemungkinannya adalah membuat lapisan penyimpanan dalam cache antara aplikasi Anda dan penyimpanan
FHIR yang mempertahankan status sesi saat melakukan pengambilan data sebelumnya dan menyimpan dalam cache hasil penelusuran.
Aplikasi dapat mengelompokkan hasil penelusuran ke dalam "halaman aplikasi" kecil yang berisi 10 atau 20
hasil yang cocok. Aplikasi kemudian dapat dengan cepat menayangkan halaman aplikasi kecil ini kepada
pengguna dengan cara langsung dan non-sekuensial, berdasarkan pilihan pengguna. Lihat
Membuka halaman di sekitar untuk mengetahui contoh
jenis alur kerja ini.
Membuka halaman di sekitar
Anda dapat membuat solusi latensi rendah yang memungkinkan pengguna menjelajahi sejumlah besar hasil penelusuran hingga mereka menemukan kecocokan yang mereka cari. Algoritma ini dapat diskalakan ke jumlah pencocokan yang hampir tidak terbatas sekaligus menjaga latensi tetap rendah dan menyebabkan peningkatan konsumsi resource yang relatif kecil. Pengguna dapat langsung membuka halaman hasil penelusuran, hingga jumlah halaman yang telah ditentukan untuk maju atau mundur dari halaman saat ini. Anda dapat memberikan estimasi total penelusuran dengan setiap halaman hasil. Sebagai referensi, desain ini mirip dengan desain untuk Google Penelusuran.
Alur kerja
Gambar 1 menunjukkan contoh alur kerja untuk solusi ini. Dengan alur kerja ini, setiap kali pengguna memilih halaman hasil untuk dilihat, aplikasi akan memberikan link ke halaman di sekitar. Dalam hal ini, aplikasi menyediakan link ke halaman hingga lima halaman mundur dari halaman yang dipilih dan hingga empat halaman maju dari halaman yang dipilih. Agar empat halaman berikutnya tersedia untuk dilihat, aplikasi akan melakukan pramuat 40 kecocokan tambahan saat pengguna memilih halaman hasil.
Gambar 1. Aplikasi mengelompokkan hasil penelusuran ke dalam "halaman aplikasi" yang di-cache dan tersedia untuk pengguna.
Gambar 1 menggambarkan langkah-langkah ini:
Pengguna memasukkan kueri penelusuran ke frontend aplikasi, yang memulai tindakan berikut:
Aplikasi memanggil metode
fhir.searchuntuk melakukan pengambilan data sebelumnya pada halaman pertama hasil penelusuran.Parameter
_countditetapkan ke 100 agar ukuran halaman respons relatif kecil, sehingga menghasilkan waktu respons yang relatif cepat. Respons menyertakan URL penomoran halaman (Bundle.link.url) jika ada hasil lainnya yang akan ditampilkan. Respons juga menyertakan total penelusuran (Bundle.total). Total penelusuran adalah estimasi jika ada lebih banyak hasil yang akan ditampilkan. Untuk informasi selengkapnya, lihat Penomoran halaman dan pengurutan.Aplikasi mengirimkan respons ke lapisan penyimpanan dalam cache.
Di lapisan penyimpanan dalam cache, aplikasi mengelompokkan 100 kecocokan dari respons ke dalam 10 halaman aplikasi yang masing-masing berisi 10 kecocokan. Halaman aplikasi adalah pengelompokan kecil kecocokan yang dapat ditampilkan aplikasi kepada pengguna.
Aplikasi menampilkan halaman 1 aplikasi kepada pengguna. Halaman 1 aplikasi menyertakan link ke halaman aplikasi 2-10 dan estimasi total penelusuran.
Pengguna mengklik link ke halaman aplikasi lain (halaman aplikasi 10 dalam contoh ini), yang memulai tindakan berikut:
Aplikasi memanggil metode
fhir.search, menggunakan URL penomoran halaman yang ditampilkan dengan pengambilan data sebelumnya, untuk mengambil data halaman berikutnya hasil penelusuran.Parameter
_countditetapkan ke 40 untuk melakukan pramuat 40 kecocokan berikutnya dari kueri penelusuran pengguna. 40 kecocokan tersebut adalah untuk empat halaman aplikasi berikutnya yang disediakan aplikasi untuk pengguna.Aplikasi mengirimkan respons ke lapisan penyimpanan dalam cache.
Di lapisan penyimpanan dalam cache, aplikasi mengelompokkan 40 kecocokan dari respons ke dalam empat halaman aplikasi yang masing-masing berisi 10 kecocokan.
Aplikasi menampilkan halaman aplikasi 10 kepada pengguna. Halaman aplikasi 10 menyertakan link ke halaman aplikasi 5-9 (lima halaman aplikasi ke belakang dari halaman aplikasi 10) dan link ke halaman aplikasi 11-14 (empat halaman aplikasi ke depan dari halaman aplikasi 10). Halaman 10 aplikasi juga menyertakan estimasi total penelusuran.
Hal ini dapat berlanjut selama pengguna ingin terus mengklik link ke halaman aplikasi. Perhatikan bahwa jika pengguna menavigasi kembali dari halaman aplikasi saat ini dan Anda sudah meng-cache semua halaman aplikasi di sekitar, Anda dapat memilih untuk tidak melakukan pengambilan data baru, bergantung pada kasus penggunaan Anda.
Solusi ini cepat dan efisien karena alasan berikut:
- Pengambilan data kecil, dan bahkan halaman aplikasi yang lebih kecil, diproses dengan cepat.
- Hasil penelusuran yang di-cache mengurangi kebutuhan untuk melakukan beberapa panggilan untuk hasil yang sama.
- Mekanisme ini tetap cepat, terlepas dari seberapa tinggi skala jumlah hasil penelusuran.
Opsi desain
Berikut beberapa opsi desain yang dapat dipertimbangkan, bergantung pada kasus penggunaan Anda:
Ukuran halaman aplikasi. Halaman aplikasi Anda dapat berisi lebih dari 10 kecocokan jika sesuai dengan kasus penggunaan Anda. Perlu diingat bahwa halaman yang lebih kecil dimuat lebih cepat, dan terlalu banyak link di halaman dapat menyulitkan pengguna untuk mengelolanya.
Jumlah link halaman aplikasi. Dalam alur kerja yang disarankan di sini, setiap halaman aplikasi menampilkan sembilan link ke halaman aplikasi lain: lima link ke halaman aplikasi langsung mundur dari halaman aplikasi saat ini, dan empat link ke halaman langsung maju dari halaman aplikasi saat ini. Anda dapat menyesuaikan angka ini agar sesuai dengan kasus penggunaan Anda.
Praktik terbaik
Gunakan lapisan penyimpanan dalam cache hanya jika diperlukan. Jika Anda menyiapkan lapisan cache, gunakan hanya jika kasus penggunaan Anda memerlukannya. Penelusuran yang tidak memerlukan lapisan penyimpanan dalam cache harus mengabaikannya.
Kurangi ukuran cache. Untuk menghemat resource, Anda dapat mengurangi ukuran cache dengan menghapus hasil penelusuran lama sekaligus mempertahankan URL halaman yang Anda gunakan untuk mendapatkan hasil. Kemudian, Anda dapat merekonstruksi cache sesuai kebutuhan dengan memanggil URL halaman. Perlu diingat bahwa hasil dari beberapa panggilan ke URL penomoran halaman yang sama dapat berubah dari waktu ke waktu, karena resource di penyimpanan FHIR dibuat, diperbarui, dan dihapus di latar belakang. Apakah akan menghapus, cara menghapus, dan seberapa sering menghapus cache adalah keputusan desain yang bergantung pada kasus penggunaan Anda.
Menghapus cache untuk penelusuran tertentu. Untuk menghemat resource, Anda dapat menghapus sepenuhnya hasil dari penelusuran yang tidak aktif dari cache. Pertimbangkan untuk menghapus penelusuran yang tidak aktif paling lama terlebih dahulu. Perlu diingat bahwa jika penelusuran yang dihapus menjadi aktif lagi, hal ini dapat menyebabkan status error yang memaksa lapisan penyimpanan dalam cache untuk memulai ulang penelusuran.
Membuka halaman mana pun
Jika Anda ingin pengguna dapat membuka halaman mana pun di hasil penelusuran, bukan hanya halaman di sekitar halaman saat ini, Anda dapat menggunakan lapisan penyimpanan dalam cache yang mirip dengan yang dijelaskan di Membuka halaman di sekitar. Namun, agar pengguna dapat membuka halaman aplikasi hasil penelusuran mana pun, Anda harus melakukan pengambilan data sebelumnya dan menyimpan dalam cache semua hasil penelusuran. Dengan jumlah hasil penelusuran yang relatif sedikit, hal ini dapat dilakukan. Dengan jumlah hasil penelusuran yang sangat besar, mungkin tidak praktis atau tidak mungkin untuk melakukan pengambilan data sebelumnya. Meskipun dengan jumlah hasil penelusuran yang sedikit, waktu yang diperlukan untuk melakukan pengambilan data sebelumnya dapat lebih lama dari yang wajar untuk ditunggu pengguna.
Alur kerja
Siapkan alur kerja yang mirip dengan Membuka halaman di sekitar, dengan perbedaan utama ini: aplikasi terus melakukan pengambilan data hasil penelusuran di latar belakang hingga semua kecocokan ditampilkan atau beberapa batas yang telah ditentukan sebelumnya tercapai.
Berikut adalah contoh alur kerja untuk solusi ini:
Aplikasi memanggil metode
fhir.searchuntuk melakukan pengambilan data sebelumnya pada halaman pertama hasil penelusuran dari kueri penelusuran pengguna. Respons menyertakan URL penomoran halaman (Bundle.link.url) jika ada hasil lainnya yang akan ditampilkan. Respons juga menyertakan total penelusuran (Bundle.total). Ini adalah perkiraan jika ada lebih banyak hasil yang akan ditampilkan.Aplikasi mengelompokkan kecocokan dari respons ke dalam halaman aplikasi yang berisi 20 kecocokan dan menyimpannya dalam cache. Halaman aplikasi adalah pengelompokan kecil kecocokan yang dapat ditampilkan aplikasi kepada pengguna.
Aplikasi menampilkan halaman aplikasi pertama kepada pengguna. Halaman aplikasi menyertakan link ke halaman aplikasi yang di-cache dan estimasi total penelusuran.
Jika ada lebih banyak hasil yang akan ditampilkan, aplikasi akan melakukan hal berikut:
- Memanggil URL penomoran halaman yang ditampilkan dari pengambilan data sebelumnya untuk mendapatkan halaman hasil penelusuran berikutnya.
- Mengelompokkan kecocokan dari respons ke dalam halaman aplikasi yang berisi 20 kecocokan dan menyimpannya dalam cache.
- Memuat ulang halaman aplikasi yang saat ini dilihat pengguna dengan link baru ke halaman aplikasi yang baru dimuat sebelumnya dan di-cache.
Aplikasi mengulangi langkah sebelumnya hingga tidak ada lagi hasil yang akan ditampilkan atau beberapa batas yang telah ditentukan sebelumnya tercapai. Total penelusuran yang akurat ditampilkan dengan halaman terakhir hasil penelusuran.
Saat aplikasi melakukan pengambilan data sebelumnya dan menyimpan ke cache kecocokan di latar belakang, pengguna dapat terus mengklik link ke halaman yang di-cache.
Opsi desain
Berikut beberapa opsi desain yang dapat dipertimbangkan, bergantung pada kasus penggunaan Anda:
Ukuran halaman aplikasi. Halaman aplikasi Anda dapat berisi lebih dari atau kurang dari 20 kecocokan jika sesuai dengan kasus penggunaan Anda. Perlu diingat bahwa halaman yang lebih kecil akan dimuat lebih cepat, dan terlalu banyak link di halaman dapat sulit dikelola oleh pengguna.
Muat ulang total penelusuran. Saat aplikasi melakukan pengambilan data sebelumnya dan menyimpan hasil penelusuran dalam cache di latar belakang, Anda dapat menampilkan jumlah penelusuran yang semakin akurat kepada pengguna. Untuk melakukannya, konfigurasikan aplikasi Anda untuk melakukan hal berikut:
Pada interval yang ditetapkan, dapatkan total penelusuran (properti
Bundle.total) dari pengambilan data sebelumnya terbaru di lapisan penyimpanan dalam cache. Ini adalah perkiraan terbaik saat ini dari total penelusuran. Menampilkan total penelusuran kepada pengguna, yang menunjukkan bahwa total tersebut adalah estimasi. Tentukan frekuensi pembaruan ini berdasarkan kasus penggunaan Anda.Mengidentifikasi kapan total penelusuran dari lapisan penyimpanan dalam cache akurat. Artinya, jumlah penelusuran berasal dari halaman terakhir hasil penelusuran. Saat halaman terakhir hasil penelusuran tercapai, aplikasi akan menampilkan total penelusuran dan menunjukkan kepada pengguna bahwa total penelusuran akurat. Aplikasi kemudian berhenti mendapatkan total penelusuran dari lapisan penyimpanan dalam cache.
Perhatikan bahwa dengan pencocokan dalam jumlah besar, pengambilan data di latar belakang dan penyimpanan dalam cache mungkin tidak mencapai halaman terakhir hasil penelusuran (dan total penelusuran yang akurat) sebelum pengguna menyelesaikan sesi penelusuran.
Praktik terbaik
Menghapus duplikat resource yang disertakan. Jika Anda menggunakan parameter
_includedan_revincludesaat melakukan pengambilan data sebelumnya dan menyimpan hasil penelusuran dalam cache, sebaiknya hapus duplikat resource yang disertakan dalam cache setelah setiap pengambilan data sebelumnya. Tindakan ini akan membantu menghemat memori dengan mengurangi ukuran cache Anda. Saat Anda mengelompokkan kecocokan ke dalam halaman aplikasi, tambahkan resource yang disertakan yang sesuai ke setiap halaman aplikasi. Untuk informasi selengkapnya, lihat Menyertakan resource tambahan dalam hasil penelusuran.Tetapkan batas pada pengambilan data sebelumnya dan penyimpanan dalam cache. Dengan jumlah hasil penelusuran yang sangat besar, mungkin tidak praktis atau tidak mungkin untuk melakukan pengambilan data sebelumnya. Sebaiknya tetapkan batas jumlah hasil penelusuran yang akan dipramuat. Hal ini membuat cache Anda tetap berukuran yang dapat dikelola dan membantu menghemat memori. Misalnya, Anda dapat membatasi ukuran cache hingga 10.000 atau 20.000 pencocokan. Atau, Anda dapat membatasi jumlah halaman yang akan dipramuat, atau menetapkan batas waktu setelah pramuat berhenti. Jenis batasan yang Anda terapkan dan cara Anda menerapkannya adalah keputusan desain yang bergantung pada kasus penggunaan Anda. Jika batas tercapai sebelum semua hasil penelusuran ditampilkan, sebaiknya tunjukkan hal ini kepada pengguna, termasuk bahwa total penelusuran masih merupakan estimasi.
Penyimpanan cache frontend
Frontend aplikasi, seperti browser web atau aplikasi seluler, dapat menyediakan beberapa cache hasil penelusuran sebagai alternatif untuk memperkenalkan lapisan cache ke dalam arsitektur. Pendekatan ini dapat memberikan navigasi ke halaman sebelumnya, atau halaman apa pun dalam histori navigasi, dengan memanfaatkan panggilan AJAX dan menyimpan hasil penelusuran dan/atau URL penomoran halaman. Berikut beberapa keuntungan dari pendekatan ini:
- Lapisan ini dapat lebih hemat resource daripada lapisan penyimpanan dalam cache.
- Cara ini lebih skalabel karena mendistribusikan tugas penyimpanan dalam cache ke banyak klien.
- Lebih mudah untuk menentukan kapan resource yang di-cache tidak lagi diperlukan — misalnya, saat pengguna menutup tab atau keluar dari antarmuka penelusuran.
Praktik terbaik umum
Berikut adalah beberapa praktik terbaik yang berlaku untuk semua solusi dalam dokumen ini.
Rencanakan halaman yang lebih kecil dari nilai _count. Dalam beberapa keadaan, penelusuran mungkin menampilkan halaman yang berisi lebih sedikit kecocokan daripada nilai
_countyang Anda tentukan. Misalnya, hal ini dapat terjadi jika Anda menentukan ukuran halaman yang sangat besar. Jika penelusuran menampilkan halaman yang lebih kecil dari nilai_count, dan aplikasi Anda menggunakan lapisan cache, Anda mungkin perlu memutuskan apakah akan (1) Menampilkan lebih sedikit hasil daripada yang diharapkan di halaman aplikasi, atau (2) Mengambil beberapa hasil lagi untuk mendapatkan cukup hasil untuk halaman aplikasi yang lengkap. Untuk informasi selengkapnya, lihat Penomoran halaman dan pengurutan.Mencoba lagi error permintaan HTTP yang dapat dicoba ulang. Aplikasi Anda harus mengantisipasi error permintaan HTTP yang dapat dicoba lagi, seperti
429atau500, dan mencoba lagi setelah menerimanya.
Mengevaluasi kasus penggunaan Anda
Mengimplementasikan fitur seperti membuka halaman apa pun, mendapatkan total penelusuran yang akurat, dan memperbarui estimasi total akan meningkatkan kompleksitas dan biaya pengembangan untuk aplikasi Anda. Fitur ini juga dapat meningkatkan latensi dan meningkatkan biaya uang untuk penggunaan resource Google Cloud. Sebaiknya evaluasi kasus penggunaan Anda dengan cermat untuk memastikan bahwa nilai fitur ini sebanding dengan biayanya. Berikut beberapa hal yang perlu dipertimbangkan:
Membuka halaman apa pun. Pengguna biasanya tidak perlu membuka halaman tertentu, banyak halaman dari halaman saat ini. Dalam sebagian besar kasus, Membuka halaman di sekitar sudah memadai.
Total penelusuran yang akurat. Total penelusuran dapat berubah saat resource di penyimpanan FHIR dibuat, diperbarui, dan dihapus. Oleh karena itu, total penelusuran yang akurat akan akurat pada saat ditampilkan (dengan halaman terakhir hasil penelusuran), tetapi mungkin tidak tetap akurat seiring waktu. Oleh karena itu, total penelusuran yang akurat mungkin memiliki nilai terbatas untuk aplikasi Anda, bergantung pada kasus penggunaan Anda.