ālearningā says the one that will have a tutorial before EOY on using APIāsā¦looking forward to it
Thats almost like my employee app, Weāve had weather in that for a little over 6 months
Mine just useās devices current location though. I bet your wondering how I got Glide to use location settings in a Glide app arenāt you
Location component?
No, Itās in the scripts
I like this new API idea but I have so many already integrated into scripts I do not know if I will switch. You know that HTML5 has built into it a Geolocation feature. As long as they have allowed this feature in their normal browser you can use it through a script to identify a location.
So much fun!
For a moment it felt like one of those guys that swore they saw a UFO and they are just like,āwell, its coming soonā¦wheres my UFO?ā I was feeling that in the mac n cheese waitā¦I was thinking,ādamn UFOs took his mac n cheeseā
You need to get it to sing these songs in a computer/android voiceā¦ thats the next step to greatness sir, the next stepā¦
Yaā¦still a bit sticky when it comes to the refresh, Iām sure itās my code.
Ha! I was thinking of also merging with YouTube API to pull the music video at least.
Here I am wondering why Robert hasnt āmerged with youtube apiāā¦lol, what are you waiting for?
Iām probably waiting til I use the correct terminology and sound like I know what the heck Iām doing
You say this as the only person posting videos trying to learn the API columnā¦I donāt think you have to worry about someone calling you out on your jargon, you could literally use the term, āthingamabobā and Iām sure someone will right it down as a way to reference the API call or whatever you were referencing at the time.
Besides I think we have months to go before they release this. Give it another week and youāll be telling us how our API calls in scripts need to be cleaner.
Great Job @Robert_Petitto!
He doesnāt get a great job until we have youtube dance parties from his API calls dammit.
Give him 5 more minutes and youāll be surprised.
Surprised? or wondering why he didnāt interrupt my typing with a video of youtube pumps and a bump from hammer? For some reason, I have no clue why that songed popped in my headā¦
I canāt wait to try this out.
A suggestion for those of you who do a little code - I would recommend building a simple API cache proxy and hit whatever endpoint you need from that, so you can cache common results and not get throttled by the remote API. I have a very basic example of something like this using express and nodejs that you can check out on my GitHub. This example is set up to query a giant Airtable database I manage, but it can easily be adapted to any API.
So what happens is, you make a request to your API cache proxy server, passing any params you need to hit the API endpoint with. Before you pass the request on to the remote API endpoint, check to see if the data being requested is in your cache (first time obviously it wonāt be). An easy way to do this is to store the data as json in folders that match the request url and a file name equal to the exact configuration of any url params sent (you could parse these and organize them in folders too). The alternative to actually writing files on the server disk is to store cached values in some type of hash table or document store like redis, or memcached for smaller results. You also want to check to make sure the age of the file is not older (stale-r) than you desire. Depending on how frequently the data changes on your endpoint, this cache expiration time might need to be something like a few minutes, or it could be much longer. Generally unless you are fielding many thousands of requests in a short amount of time, you can get away with a pretty short lifetime/expiration date for cache data. If you are using a hash table or document store you need to store the āfreshnessā of the data along with the document. The first time a given request is made, or if a request matches but the data is expired, it will be a ācache missā, and in this case you pass on the request to the actual remote API, handle the response, store it to the cache, and then pass it back to your glide app. If someone else does the same request while the cache item is still fresh, it will be a ācache hitā, and they will just get a copy of whatever is in the cache, instead of hitting the remote API. Another benefit of this model is you can intercept the results from the API endpoint and format them or parse them before you send it back to glide, so that the data is in a more usable form for Glide, however great it is, of course lacks a lot of the tools needed to receive many API responses properly.
So, if you have lots of the same kind of request users are making over and over fairly frequently, you might want to consider using this kind of setup, since you can manage your own scale, throttle as needed, but you can get locked out of a remote API you donāt control without recourse if you overload it.
Mark was mentioning the exact same thing yesterday. Iāll need to check this out. Thanks for posting!