When most folks talk about GraphQL features, a few things tend to surface commonly. Things like GraphiQL, declarative data, and consolidated network calls are distinguishing factors that I’m sure you’ve heard of.
The first-ever GraphQL summit is already over, and I was lucky enough to attend and hear all the great things people have to say (including from one of the authors of the specification, Lee Byron). It’s hard to boil down all the knowledge into a single post, but I’ll do my best to distribute what I saw as incredibly valuable in both maintaining and starting a GraphQL service.
I’ve recently went down the rabbit-hole wrapping a massive API with FaceBook’s GraphQL specification. Aside from learning a ton about my company’s API’s, I walked away with a lot of lessons on good conventions doing this work.
On an application of medium to large size, requiring JavaScript files with relative paths can become a chore. I think you can agree that seeing: require('../../../some/dir/file_i_want.js')
makes you feel somewhat uncomfortable. Though this may work in early-stage projects, and is pretty easy to do, there is pain that comes when refactoring or moving this module. That, plus it’s now harder to search and replace all the instances where file_i_want.js
is used since all the require
‘s vary just a bit. Ideally, what if we could just do require('my-app/some/dir/file_i_want.js')
?
One of the coolest, almost unheard of libraries, I’ve ever had the joy of working with is rewire. If you haven’t already heard of it, rewire allows you to rewire variables in a JavaScript file to another reference.
React is an open source library for “building User-Interfaces”, open sourced by Facebook. If you’re familiar with the traditional MVC pattern, React would be the “V” layer of that paradigm. I would even go so far to say that if you’re not careful, React can also become the “C” layer as well. I’ve built a pretty slick deal site with it, and I can say with fair certainty that I think that React is the way forward and all other frameworks will follow a similar pattern soon.
Sicksync is a project born out of the need to “mirror” a file-system quickly. I had issues with rsync
and scp
as my workflow requires me to VPN to the east-coast, and back to my developer machine in LA. This wasn’t super ideal, and for small file changes (where you need a quick feedback loop), I was waiting up to 5 seconds to see changes happen in the browser. Booh!
Sinon actually already has a nice API for doing this out of the box without any prototype mucking:
You’re probably familiar with the standard schlew of Array methods in JavaScript. We’re all fond of timeless classics such as forEach
, map
, and even filter
. However, there is one method that has been hiding under the radar (at least for me) for quite a while now. It’s one that functional-reactive-programming tends to use somewhat often, and that method is reduce
.
Hey friends.
Last night I gave a talk on how to build a front-end asset pipeline with gulp. It was pretty sweet. If you missed it, here is the code XOR slides at no additional cost to you: