A little Friday humor: Learning JS in 2016

[Ken g6]

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f

It's funny. In a black humor sort of way. Unless someone's actually forcing you to learn modern JS libraries. Which is why it's more likely to be funny on a Friday before a holiday weekend.

 

[dave_the_nerd]

That %^*&% is why the internet sucks now.

 

[Chaotic42]

Yeah, I've been sent to buzzwordy development events and that's basically how I feel.

 

[Red Squirrel]

What I hate is trying to find information on how to do something in JS. You just run into "just use xyz library!" responses and never get a real answer. Uhh no, I just want to do that one specific thing, I'm not linking or loading a huge file just to do one purpose.

All these libraries is why websites are ridiculously bloated now. People are lazy and just take the easy route for everything instead of optimizing.

 

[LFaWolf]

Oh my goodness, I just had a very similar situation - simple web project, need data access, intern said "we should use React! It is great!" I said nope, AJAX and JQuery it is.

So much buzzword of the React and AngularJS. I am not saying they are bad, but people say them without really understand what they consists of and are used for.

 

[sao123]

fortunately, we can just use ASP.net to do ALL of what the author is describing...

 

[Maximilian]

I can relate to this. I thought I could just learn JS, HTML, CSS and be done with it. How wrong was I

fortunately, we can just use ASP.net to do ALL of what the author is describing...

Really? Isn't that all server side rendering though? Ive only fiddled with .NET Core, I know nothing of ASP.net unfortunately.

 

[purbeast0]

I'm using node.js as my backend server and it's pretty awesome that you can just find so many libraries that do things for you so you don't have to reinvent the wheel.

We just completely redid our backend from using Parse (https://github.com/ParsePlatform/parse-server) to just using no framework at all, and we had to implement push notifications in another way since we were using Parse to do it. There were plenty of libraries out there that already do it but we ended up with one that still gets support. Plus if we ever need to make any changes we can just fork it.

Oh, and we are using React Native for portions of the front end lol. It's only on iOS now but when we move to Android, that is going to be a huge time saver.

 

[sao123]

I can relate to this. I thought I could just learn JS, HTML, CSS and be done with it. How wrong was I



Really? Isn't that all server side rendering though? Ive only fiddled with .NET Core, I know nothing of ASP.net unfortunately.

some of it is server side, but there is the whole AjaxControlToolkit which creates client side Javascript. Also all of the asp.net validator controls also function client side and server side for redundent checking.

 

[clamum]

I thought that original article was great and this JavaScript one is too. Jesus people are obsessed with the current popular InsertNameHere (that'll be forgotten in 5 years anyway). Say what you want about ASP.NET (MVC) but the shit works and it's fairly easy to put a web app together without pulling out your fucking hair learning ten million different frameworks and all that nonsense. Plus it integrates with jQuery and Bootstrap pretty well these days. Tons of resources for it, has been around and will be around, etc. Love it.

This whole thing kinda reminds me of me when I was wondering how I'd secure a Web API site (.NET Web API) that will be accessed by a mobile app and a website, and only by them (so ignore/deny requests from any other source). I was told "use IdentityServer3" multiple times and yikes... after many hours I've finally gotten it to work, kind of, but only as a test using Postman. I still need to integrate it with the actual Web API site (and MVC website) but ugh, it ain't simple (although the frickin Pluralsight video I watched make it look that way). Of course you can't just learn IS3, you also gotta learn (at least somewhat) Katana, OWIN, OpenID Connect, OAuth 2.0, etc. It's definitely got me annoyed already and I haven't even started the mobile app. FML

 

[purbeast0]

I thought that original article was great and this JavaScript one is too. Jesus people are obsessed with the current popular InsertNameHere (that'll be forgotten in 5 years anyway). Say what you want about ASP.NET (MVC) but the shit works and it's fairly easy to put a web app together without pulling out your fucking hair learning ten million different frameworks and all that nonsense. Plus it integrates with jQuery and Bootstrap pretty well these days. Tons of resources for it, has been around and will be around, etc. Love it.

This whole thing kinda reminds me of me when I was wondering how I'd secure a Web API site (.NET Web API) that will be accessed by a mobile app and a website, and only by them (so ignore/deny requests from any other source). I was told "use IdentityServer3" multiple times and yikes... after many hours I've finally gotten it to work, kind of, but only as a test using Postman. I still need to integrate it with the actual Web API site (and MVC website) but ugh, it ain't simple (although the frickin Pluralsight video I watched make it look that way). Of course you can't just learn IS3, you also gotta learn (at least somewhat) Katana, OWIN, OpenID Connect, OAuth 2.0, etc. It's definitely got me annoyed already and I haven't even started the mobile app. FML

I am far from a security expert so I couldn't elaborate on this in too much detail, but we changed our backend to use a single graphQL endpoint and wow, it is REALLY nice. The thing about it too is that you're literally only securing one endpoint. And the way we have it set up is you pass in a token with the header. If your token doesn't match the session token, then you can't access the endpoint. It doesn't matter where you are hitting it from (web on pc, web on mobile, mobile app, etc), if your token doesn't match, you're not accessing the endpoint.

So when I test it through postman, the mobile app, or graphiql (the graphQL test app), if that header isn't set, I get a forbidden response. if it's set to my valid token, it works.

I'd strongly recommend looking into graphQL for hitting a backend.

 

[clamum]

I am far from a security expert so I couldn't elaborate on this in too much detail, but we changed our backend to use a single graphQL endpoint and wow, it is REALLY nice. The thing about it too is that you're literally only securing one endpoint. And the way we have it set up is you pass in a token with the header. If your token doesn't match the session token, then you can't access the endpoint. It doesn't matter where you are hitting it from (web on pc, web on mobile, mobile app, etc), if your token doesn't match, you're not accessing the endpoint.

So when I test it through postman, the mobile app, or graphiql (the graphQL test app), if that header isn't set, I get a forbidden response. if it's set to my valid token, it works.

I'd strongly recommend looking into graphQL for hitting a backend.

Hmmm. While neat, GraphQL just looks like a layer that fits over an API and allows "easier" querying of it (as well as maintenance for the API developers). I don't see any mention of security or anything, looking at the GraphQL site.

 

[purbeast0]

Hmmm. While neat, GraphQL just looks like a layer that fits over an API and allows "easier" querying of it (as well as maintenance for the API developers). I don't see any mention of security or anything, looking at the GraphQL site.

Yeah it is an extra layer, but since our backend is all node.js and we were just hitting the server before, we didn't really have it as another layer. It was just built into it. We were initially using Parse (running on node.js as well) but ended up getting rid of it, a major reason being security. In all honesty though I am not sure if it can be setup outside of javascript, or if it would have to be another layer running on a node.js server.

If that is the case, then in your case you would basically setup the graphQL schema on a node.js server to then hit your API endpoints. But at that point, the ONLY thing that you would have to secure hitting your API would be the node server. Nothing else would should ever need to hit the API.

And then at that point, you only have 1 endpoint that you'd have to secure on the node.js side of things. As mentioned, I'm no security expert, and the other dev actually set up graphQL for us. I believe the token thing may be something he just added onto it himself. But we have a token that is created for your installation sessin when you sign up, and then our client gets that from the db when the user is logged into the app, and whenever it makes requests to the backend, it passes that token with the request. But the beauty and simplicity of it is that you literally hit 1 endpoint and just send different data in with the body.

I believe Facebook created it and that it was all internal to Facebook but they made it public and open sourced it. I know that Facebook uses it though for all of their stuff and we access the facebook API via their graph api.