Type Casting

RapidQL query strings are viewed as "contracts" between the developer and the RapidQL Engine. Basically, every property that appears in the query, will appear (under the same name) in the returned object (barring the use of optional node, which - as the name suggest - are optional). Thus, if you have a query that looks like that:

{
  user:RapidAPI.FacebookGraphAPI.getUser(userid: id, accessToken: token) {
		name,
  	age,
  	birthDate,
  	profilePicture {
  		full_url,
  		thumbnail_url
		}
	} 
}

Than if the query succeeded, you are guaranteed that:

• There will be an object called user (notice renaming).
• That object will have the properties name, age, birthDate and profilePicture.
• profilePicture will either be an object, or array of objects, with the properties full_url and thumbnail_url.

These guarantees are a very powerful feature of RapidQL. They prevent you from having to check data being returned from APIs, in the form of code like this:

if (result.hasOwnProperty('user'))
  ...

While normally data fetched from an API should be checked, RapidQL performs the verifications for you!

Type Casting

With type casting, you can extend the guarantee RapidQL gives you about returned data. On top of guaranteeing that the data is there, you can guarantee what data type will be there. For example, in the query above, age could be an int, or string number. Similarly, birthDate could be a Date object, or a string in any date format.

By type casting them, you can make sure age is an int and birthDate is a Date object:

{
  user:RapidAPI.FacebookGraphAPI.getUser(userid: id, accessToken: token) {
		name,
  	int(age),
  	date(birthDate),
  	profilePicture {
  		full_url,
  		thumbnail_url
		}
	} 
}

If those aren't the right type, RapidQL will do it's best to convert the data to the right type. For instance, if age is a float, it'll cast it to an int. If it's a string, it'll see if it could be parsed as an int ("12" would become 12), and so on...

Supported Casts

• int
• float
• date