Unlock a flexible GraphQL structure that scales with your app

Back in 2016, I started using GraphQL on a personal project. Since then, I’ve advocated for its use in all my consulting activities. I do not need to convince you, a savvy developer, GraphQL offers many advantages over its predecessors REST and SOAP. In the many projects I’ve led, there were some hard lessons learned about architecting the graph correctly.

Back in 2018, I wrote about a password reset method illustrating how to do a password reset without storing a reset code in the database. This has worked well for a few of my apps, but recently some good friends, we’ll call them Pedro and Rosco, came up with a much better solution.

I’m asked all the time “How can I learn all this stuff?”. The simple answer is ‘build an app’

Paige Niedringhaus writes a nice blog post called Password Reset Emails In Your React App Made Easy with Nodemailer, where she outlines how to use Nodemailer + ReactJS + Node.js + MySQL + Sequelize to build a simple password reset flow. Everyone reading these words has doubtless gone through the familiar password reset song and dance. Enter your email into a form field, receive an email with a link, click the link, reset your password, voilà!

It’s 2018 and file upload is still an involved process

I’ll admit, this process is not straight forward, but once set up, it works like a charm. What’s the goal? We want the client (browser) to upload a file directly to S3 and then store the uploaded information in our server/database.

I find it hard to believe that I could not find a good article online of how to get env vars working in OpsWorks. I think even more astounding is that it takes a custom recipe to accomplish this end. When you host your app on Heroku, you can easily just do an heroku config:set FOO=bar with the Heroku Toolbelt. In AWS OpsWorks, it’s a little more involved. Let’s see just how.

Maybe you’re familiar with the LAMP stack? Linux, Apache, MySql, PHP. That’s been a pretty common way to serve websites for many years (circa 1998?). But things have changed, technologies have changed, and it’s not 1998 anymore. IE6 is dead, nested tables are dead, and the LAMP stack is the Old and Busted. The New Hotness is the MEAN stack, MongoDB, ExpressJS, AngularJS, and NodeJS. This new stack of technologies is what many new web apps are using these days.

Setting up Jenkins for Node.js + Mocha testing and such Install this stuff Node.js via Nave git clone https://github.com/isaacs/nave.git* ./bin/nave.sh usemain v.0.8.9 Mocha npm install -g mocha ChaiJS npm install -g chai xunit-file (Mocha custom report for Jenkins) npm install -g xunit-file Jshint npm install -g jshint Nock npm install -g nock Supertest npm install -g supertest Testacular npm install -g testacular PhantomJS npm install -g phantomjs Here is a handy script that will install v0.

So I needed to install Node.js on CentOS, but I was hard pressed to find a yum repo that was up to date. Then I stumbled upon Nave. This is really easy. It’s just a bash script that you run to install node and npm. # Get the nave.sh shell script wget https://raw.github.com/isaacs/nave/master/nave.sh chmod +x nave.sh ./nave.sh usemain 0.8.8 node -v # Will print # v0.8.8 Life could not be easier

The following is account of why I prefer writing programs in JavaScript over PHP. I have well over 10 years of programming experience in PHP. I’ve written everything from a simple one page PHP program, to a complex Zend Framework apps, to you name it, I’ve coded it in PHP (even stuff I know I should have not done in PHP). You Always Play To Your Strengths, if PHP is your strength, that’s going to be your game