Tag Archives: JavaScript

AWS Serveless Computing Example: Wild Rydes Part I

I’ve been working through a tutorial I started in a session I took at AWS re:Invent 2016.  I did not finish the tutorial in class so I started working on it again after getting home from the conference.  The tutorial is on GitHub if you care to follow along.

Admittedly, I’m not the sharpest knife in the drawer(but I am made of the hardest, most persistent steel…they call me, ‘Blue Steel’ – said in my best Ben Stiller voice).  It took me a while to figure out why I could not get the AWS Javascript SDK to allow unauthorized users, vis-a-vis AWS Cognito, to access my DynamoDB Email Table.  Here are some errors and things I learned troubleshooting this:

The latest Firefox browser seems to give better clues about why things are not working in the Developer Console than Google Chrome.  Using Google Chrome, I kept seeing an error like, “Missing Credentials In Config”, and was really confused what exactly that meant.  I was following the tutorial exactly, as far as I could tell, so I could not discern whether this error was from a code change I made or an AWS configuration problem?  Then I looked at my website in Firefox, using the Firefox Developer Console, and could see a little bit better what was going on.

Here’s my main error as seen in the Google Chrome Developer Console:

And here’s the same error as reported by Firefox Developer Console:

Ahh!  So a ‘ResourceNotFoundException’ is being thrown.  Now I could see that my Javascript code probably wasn’t the problem and that my Cognito/IAM Role Configuration might be the culprit.

After further investigation..a day (or so) later…I discovered a simple typo in my DynamoDB Table Name:

The table name should have been ‘Wildrydes_Emails’.  Seriously?!?!  Yes, I’m an idiot (but one made of ‘Blue Steel’…).  Once that was corrected, I was finally able to get my unauthenticated Cognito Role to access my DynamoDB Table.

There is still work to be done in this tutorial, and I’ll blog about any issues I overcome as I encounter them.  My work is being hosted in my AWS account on Cloudfront, so feel free to check it out and submit your email to my DynamoDB database.  Let’s get this startup rolling!

http://d39nkefhhvszkn.cloudfront.net/

Getting MEAN: A Java Developer’s Perspective

I intimidate many people because I’m so pretty. Others might say I’m pretty ugly. But when I had the chance to get MEAN too, I jumped at it. In this context, MEAN is an acronym for the technology stack consisting of: MongoDB, Express, AngularJS and NodeJS. I wanted to briefly document some of my recent experiences and take-aways in working with this technology stack, so here are my thoughts.

For most of my programming career now, I’ve been working with mostly Enterprise Java. I started teaching myself Java in the mid-nineties from an O’Reilly book and from the start found the language very intuitive to understand (then). For a number of years now, however, I’ve been thinking that full-stack JavaScript is the way to go for Enterprise Software Development (and other applications as well). So when I had the opportunity to work on a short project using MEAN I was quite glad to get some hands-on experience with it.

First of all, when working with MEAN, you are essentially using the JavaScript language at all layers of application development, from the front-end to the middle-tier to the back-end data store. Theoretically, this should make the learning curve considerably smaller when working across layers, and should also make JavaScript Developers equally interchangeable across layers. The reality, however, is not quite that, but it’s close.

‘M’ Is For MongoDB

MongoDB is a NoSQL database used for storing JSON Documents. MongoDB is very easy to install and run, especially on Linux-based systems. You can run JavaScript in the database; you can even write MapReduce programs in JavaScript and run them on the database. But the main advantage of using MongoDB in this technology stack is the ability to easily store and retrieve JSON documents without have to apply JSON structure to your data after pulling it out of the database. This makes it easier to ship JSON formatted data directly to your front-end without having to mess with RDBMS tables and SQL… and even DBA’s for that matter (‘…can you PLEASE create a table for me!’). Wait, I don’t say ‘please’ anymore because I’m MEAN.

‘E’ Is For Express

Express is a dream to work with. It’s very simple and intuitive to use and takes no time at all to go from knowing nothing to creating fairly complex JSON REST Web Services. We connected Express to our MongoDB instance using Mongoose, which is so simple even I could configure it. Simple is good, right?

‘A’ Is For AngularJS

I found working in Angular 1.x fairly difficult to understand. The associated documentation is not all that well written and generally not very helpful. I feel like the framework is a bit over-engineered. I have not worked with Angular 2.x yet, so perhaps things have improved. Nevertheless, many, many organizations have invested heavily in Angular, so I’m sure I must be missing something, and without a doubt AngularJS is better than working with Java Server Faces (JSF) or Struts. Nevertheless, I might actually try ReactJS as the front-end framework next time as several co-workers have strongly recommended it.

‘N’ Is For NodeJS

NodeJS is the server-side JavaScript middleware that ran our Express JSON REST Services. Working with NodeJS requires that you get used to writing asynchronous code, but once you get the hang of that it’s quite fun and easy to use. From a Java Developer’s perspective, working with NodeJS is so much more efficient than having to compile and package Java Code into a WAR or EAR before deploying it to a JEE Container, like Tomcat or JBoss or Websphere or Weblogic. In Java land, that process seems to take years sometimes. When using NodeJS and a code monitor like nodemon, you simply forget about about the code deploy process and start to take for granted that your code changes are instantly available for testing on your local server. What?!?!

The Node Package Manager (npm) makes installing and managing modules very easy as well.

Fast Development, Fast Deployment

As mentioned, using code watch tools like nodemon, or even grunt or gulp serve-up local code changes in real-time. That speeds up development time significantly. Moreover, your mocha, chai, karma, etc. test scripts are invoked automatically each time you make a code change, so feedback on whether your build is broken or not is instant and continuous. Once integrated with an efficient Continuous Integration/Continuous Delivery (CI/CD) Pipeline, code commits to Git can be automatically built, tested and pushed-out to a running server in your environment of choice. Of course you can do the same in Java, but I bet that MEAN Developers can develop twice the functionality, if not more, than Java Developers in the same amount of time.

In business, speed kills when your MEAN (and pretty).