The instructions for the Twitch project maybe need to be updated

The instructions for the Twitch project maybe need to be updated
0

#1

Item # 7: "Hint: The relevant documentation about this API call is here: https://dev.twitch.tv/docs/v5/reference/streams/#get-stream-by-user."

I’m going through the process right now and the v5 API is deprecated. From their documentation: “V5 is deprecated as of 8/31/17 and will be removed entirely on 12/31/18 (in favor of the new Twitch API, mentioned above).”

I know Dec 2018 is quite a ways still, but we are past Aug 2017 and they do recommend to start using their new API which is provided.

Also, you do now have to register an app in order to get a client ID, that may already be something people have figured out. I’m just getting started, so forgive me if I’m telling you things you already know. I thought you might want to know about the new API. There is no longer access to an ID through the “connections” tab in the normal user settings - you have to go ahead and sign up for a dev profile, but it’s easy and your regular user login gives you access.


#2

I believe that fcc has a new api for students to use that does not require all this key and technicalities (basically a simplified api for the twitch api). Check out these new instructions from the beta version (if you can’t find this challenge in the beta version, look under coding interview take-home projects at the bottom).

freeCodeCamp wiki info and example call
relevant twitch documentation


#3

Thank you!! Those links at the bottom were exactly what I needed - I think - I am pretty sure I’ve already read the entire Twitch dev documentation beginning to end, and I even got a successful api started with valid request / response returning json data but using a Twitch-issued client ID, which (now) I understand can’t be used for the assignment.

I also realize now that the “deprecated” announcement is kinda premature. Their “new” api is not even really available yet or at least, the only thing I could find was a performance dashboard, and that was all! But they remind you all over the place that you are using v5, a DEPRECATED (to me that means unsupported??) api. Whatever.

Thanks again, really appreciate the help. :slight_smile:


#4

Wait, one question: That guide was posted in July 2016, and I’m reading all the follow up questions and answers, and at one point username “zelite” made an authoritative-sounding statement that using a client ID in front-end javascript is not a security issue; if that is true, then my work is almost done. The hard part, anyway. So, is this statement endorsed?

Otherwise, they provide a hard-coded JSON file, to use instead of sending any request at all? Am I reading that correctly? We can make a static page that only looks like a status dashboard, no functionality? Hmm… that seems utterly pointless, but okay. I can play with HTML and CSS all day long!


#5

Its been over a year since I messed with the twitch project, and I cannot explain to you the difference between a client ID and an api key. To be honest, you don’t really need to worry to much about people stealing free api keys - well, since they’re free :stuck_out_tongue_winking_eye:

I don’t think that’s pointless. The point of this exercise is figuring out how to get data from an api and use it in your front-end code. Building an app to see if twitch streamers are online isn’t really that useful, but learning how to handle JSON data from an api is very useful and something you will need to learn. When you start building “real” projects, you will build your own api’s and won’t have to worry about all the crazy jsonp, CORS, api keys, and all related pain in the butts. But since you didn’t build the api yourself, you have to deal with all these annoying things. Using hardcoded JSON simplifies you from pulling your hair out (assuming you have some) messing with third-party api’s on the front-end while still giving you the opportunity to learn how to use data just as if you got it from your own api service. After all, just requesting data from a server is extremely simple, if you are using the new fetch api and promise/async functions. Hope that clarifies the point somewhat better.


#6

No, deprecation just means it’s not guaranteed to be supported for much longer and its use is discouraged. Once it’s completely unsupported, it’s no longer referred to as “deprecated”.


#7

OH I see… Good point!! I guess it confused me more since I had already got the Twitch api working for me… I was already getting json data with my client ID, and all I had left to do was format it. The only hesitation I had was the idea it was frowned upon to publish what I had on codepen because I would be exposing the client ID in my code. (I just read that in a reddit comment somewhere, and for some reason it made me paranoid! Security flags always make me want to be extra cautious! I need to stop taking reddit comments seriously!!) But like you said, the client ID is freely provided, all you have to do is have a user account and ask for it.

*Just FYI, for anyone who asks, I learned that the Twitch client ID alone only gives you access to “unauthenticated” data requests; which is perfectly fine for this exercise. There is also a “secret key” or something you have to use for making authenticated data requests. That’s a whole other can of worms I have no intention of getting into. Not yet, anyway.

So the intent of the hardcoded JSON was to use after you get the data from Twitch, and get your app working? Just a workaround for publishing on codepen? That might make more sense, I guess. I’m still not 100% clear on the final requirements. (I’m not using jQuery or fetch, I keep using XMLHttpRequest() in vanilla JS, because it just keeps working for me.)

Also, side question: how are we to know if our codepens are acceptable or not? I never get any feedback after submitting them and moving onto the next project. Is it just, no news is good news? Am I supposed to just assume it passed?


#8

Wow thanks for the explanation, now I know.

But, isn’t it kinda weird that the word “deprecated” sounds like it’s in the past, with the -ed on the end? They don’t say, “This version is being deprecated”, they say it is deprecated, but then they put the date waaaaay in the future. That’s why at first, I was like, oh crap, this is the wrong version!

Sorry just being pedantic again. :neutral_face:


#9

We are a non-profit volunteer organization. Because of the literally millions of people our platform reaches and hundreds of thousands of code submissions, it is not practical to have a staff member review each person’s code. This is part of the purpose of our forum and gitter. You can post your completed projects here and have developers from the community give you feedback on it. You are pretty much responsible for keeping yourself honest. In reality, the program is free and the only person you cheat by not completing the assignments all the way is yourself. (I didn’t tell you that by the way…)


#10

OK wow I had no idea what kind of numbers there were, no wonder! You guys got your hands full I guess!

Thanks for the quick reply! :slight_smile:


#11

To be honest, the forum staff has pretty much nothing to do but block obnoxious spammers and trolls. The contributors on youtube, medium, and github are the real heros!

You can see some statistics here:


#12

OH yeah I love the Medium articles! I have read some really good ones, really helpful.


#13

No worries! For the better part of my adult life, I’d always misread it as “depreciated”.

It’s not past tense, it’s a participle adjective (had to Google to find that term, haha). The “-ed” suffix has three distinct functions in English (the other one being passive voice).

Regarding the word itself:
Wikipedia article — Deprecation

In general English usage, the infinitive “to deprecate” means “to express disapproval of (something)”. It derives from the Latin verb deprecare, meaning “to ward off (a disaster) by prayer”. In current technical usage, for one to state that a feature is deprecated is merely a recommendation against using it. It is still possible to produce a program or product without heeding the deprecation.


#14

Ha! Wow I’m never going to see “deprecated” again, in any api documentation, without thinking, “ward off disaster by prayer” and “disapproval”. Especially when they don’t have a functional replacement. LOL!