knitr::opts_chunk$set( eval = FALSE, collapse = TRUE, comment = "#>" )
library(bolsteR)
The aim of this simple Vignette is to get the user familiar with the bolsteR. This package uses R6 classes to allow for a clean and seamless experience.
The first step is to create an object of class Country_R6
. To create such an object we need two things; the name of the country we want to query the APIs about and an API key or token. The key we need is for the Healthsities.io API. The Healthsities.io API key is optional, especially if health-sites data is not of interest to you. Please follow the following steps to get your own Healthsities.io API key.
Once you have your API key, you will need to keep it somewhere safe and readily accessible to the relevant functions. The package provides two helper-functions, set_hs_API_key
and get_hs_API_key
, to assist with this task. The former saves the Healthsities.io API key as an environment variable (a locally accessible variable), while the second one retrieves it. Below is a demonstration of this functionality. Please note that by default the get_hs_API_key
function expects the name of the environment variable housing the Healthsities.io API key to be "Healthsites_API_key"
; to this effect, make sure you retrieve the correct variable should you decide to save your API key via other methods but the set_hs_API_key
.
# Set Healthsities.io API key as an environment variable: # Using 123abcdefg as an API key: set_hs_API_key(API_key = "123abcdefg") # Get the locally stored Healthsities.io API key: key <- get_hs_API_key(env_var_name = "Healthsites_API_key")
Now that we have set the API key, we can create our first Country_R6 object. Lets consider Kenya as a country of interest for this example. The first step is to instantiate a copy of class Country_R6, think of this as creating or getting your own copy of the API querying machine. To do this, we invoke the new
function (better known as the new
method but we will keep it simple for now). The new
function requires two arguments, the name of the country (Kenya
) and the Healthsities.io API key. To keep your API key safe, you can use the get_hs_API_key
function to feed it directly to the new
function. Please note that you (the user) may not want to query the Healthsites.io API, and therefore do not have or do not want to use the API key. In such occasions, you simply have the choice not to invoke the hs_API_key
argument when instantiating your copy of the Country_R6
class.
# Instantiate a copy of class Country_R6: Kenya <- Country_R6$ new(country_name = "Kenya", hs_API_key = get_hs_API_key())
The first feedback we get is a vector
of information indicating if the country of interest's (Kenya's
) data was available in the respective API. In the current example, all four APIs seem to have Kenya
-specific data.
The package provides a few ways to initiate the process of fetching data from the relevant APIs, when such data is available. Actually, the first time this happens is when the APIs are queried about the availability of data (as we discussed in the previous section). For the next set of actions we will look at a group of functions (the initiate_
family) that either grab the country data, or some auxiliary data, off the APIs. As the name suggests, we mainly need to trigger any of these functions the first time we interact with the respective API(s); in fact, calling any of these functions more than once results in nothing (as if they were not executed).
The initiate_APIs
is a wrapper function that happens to call the initiation function(s) of the API(s) that contain data for the country of interest. Below we demonstrate the use of the other initiate_xxx
functions. Kindly remember that the time required by any of the initiate_xxx
functions depends on the speed of your internet connection, the status of the API server, your local machine and the amount of data available for the country of interest.
On a different note, the package provides several functions that allows the user to interact with the information returned from the APIs, we call these functions getters
, and they all start with get_
. On the other hand, functions that start with set_
are called setters
and they mostly interact with or request data from the API(s).
The getter
functions are unlike the new
and initiate_xxx
in that they return something (a data table or a map); while the latter ones return nothing (at least to the user). This distinction is important if you (the user) were chaining the functions. Chaining is better illustrated by the following example.
To initiate the GHO API we use the initiate_GHO_API
function which fetches all available GHO indicators. The user can then access the GHO indicators by using the get_gho_ind_list
function to identify the GHO indicator of interest. For example, if the user wants the value of the Ambient air pollution attributable DALYs per 100'000 children under 5 years
, then they should pass the indicator's code/label AIR_10
to the get_gho_ind_data
function. The code for this example is shown below.
# Initiate the API: Kenya$ initiate_GHO_API() # Check the indicators: Kenya$ get_gho_ind_list() %>% head(10) # Query the GHO for the indicator with the label "AIR_10": Kenya$ get_gho_ind_data(indicator_code_ = "AIR_10")
The following lines of code shows how the initiating the API and checking the indicators could be done in one step by chaining the get_gho_ind_list
function to the initiate_GHO_API
.
# Chaining: initiate the API and check the indicators: Kenya$ initiate_GHO_API()$ get_gho_ind_list() %>% head(10)
Chaining is a feature of R6 class
objects' methods (again just think of methods as functions in this context), but requires the chained-to function (the initiate_GHO_API
in this example) to return invisible
(i.e. to return nothing to the user). This constraint means that chaining two getter
functions (or any functions that return something, but invisible
, when called) together throws an error.
In line with the previous API, the DHS API is initiated via the initiate_DHS_API
function. Unlike the GHO API initiation function, this function retrieves the entire data for the country of interest. Once it finished fetching the data, this function populates two objects, the dhs_survey_years
and dhs_indicators
. These two objects informs the user of the available surveys and the indicators observed in all of them. This user can go through the data available in these objects and use a survey year
or indicator label
to filter the data using the get_dhs_survey_data
and get_dhs_ind_data
functions, respectively. A simple example is shown below.
# Initiate the API and check the survey years: Kenya$ initiate_DHS_API()$ dhs_survey_years # Get data from the 2020 survey: Kenya$ get_dhs_survey_data(survey = 2020) %>% head(10) # Check surveys' indicators: Kenya$ dhs_indicators %>% head(10) # Get data for the "Age specific fertility rate: 25-29" indicator: Kenya$ get_dhs_ind_data( indicator_name = 'FE_FRTR_W_A25', filter_var = 'IndicatorId')
Please note that the FE_FRTR_W_A25
, in the get_dhs_ind_data
function, is the indicator's label or identifier, not name. The same function can be used with indicator names for example (Age specific fertility rate: 25-29
), however, the filter_var
must be changed to Indicator
instead of IndicatorId
.
Similar to the previous APIs, the WB API is initiated using initiate_WB_API
function which fetches available WB indicators and stores them in the internal object wb_indicators
.
# Initiate the API and search for the "GDP" indicator label/code: Kenya$ initiate_WB_API()$ wb_indicators %>% dplyr::filter(grepl(pattern = "domestic product", x = name)) # Request data for the "Gross domestic product (in USD)" and investigate the results: Kenya$ set_wb_data(indicator_label = "C1.12")$ get_wb_ind_data()
The initiate_HS_API
is the only function in this package that interacts with the Healthsites.io API. Once triggered/called, this function retrieves all health sites data available via the API and stores it in the Country_R6
object. The user can get the data returned from the HS API via the get_facilities_data
, get_facilities_stats
, and get_facilities_map
functions. The first and second functions return the raw and processed health sites data, respectively; whereas, the last one returns a map showing the locations and characteristics of the fetched health sites.
# Initiate the API: Kenya$ initiate_HS_API() # Retrieve raw data: Kenya$ get_facilities_data() %>% head(10) # Get facilities' counts: Kenya$ get_facilities_stats() # Plot facilities data on a map: Kenya$ get_facilities_map()
The package is shipped with a demo shiny app the allows the user to interact swiftly with the APIs. Execute run_API_demo_App()
in the console to run the app.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.