GraphQL and Angular 2.0 celebrated initial stable releases this week, yielding healthy amounts excitement for plenty of developers. This week also hosts the Github Universe conference, which came alongside a very large and important piece of news for GraphQL advocates: The Github API in GraphQL.
This is big news for the Meteor Development Group and Apollo. A missing piece separating features Meteor provides from features Apollo can provide has always been the option of reactivity. Meteor has always been "Real time and reactive by default" while Apollo has been, "Real time, if you can build it." That is, until today. I'm looking forward to pouring over the documentation and trying it out.
Angular has always been an important part of the bleeding edge front end JS ecosystem. While the choice to vastly change the API for Angular 2.0 was highly controversial, arguably for good reason, lots of developers are claiming it payed off. This week Angular 2.0 reached it's initial '1.0' release, meaning that developers can be confident the API shouldn't change much until the next major release.
GraphQL reached it's first 'release' today, meaning that it's no longer in a technical preview. This release was not marked with new spec features, but rather a landing page revamp and documentation page revamp. This news should help provide ammunition to developers convincing organizations hesitant to use fast moving technology that GraphQL is ready for production.
GitHub providing a GraphQL is a major win for GraphQL advocates. Not only is the GraphQL API accessible today, but the API is well documented and provides a great model for other organizations looking to build similar APIs at scale. I would recommend reading this post by Jonas Helfer of MDG pointing out the important parts.
Netflix is moving a lot of their front end servers to Node.js apps running in Docker. Always great to see such a large organization with massive server infrastructures finding ways to save time and sanity by using Node (and Docker!)
Refactoring is a bear, especially when you are working on a fast moving project and need to find a way to attach it to your sprint schedule. Ronald Jeffries provides a remarkably sane approach scheduling refactors and deciding what refactors to complete. Article also includes some clever illustrations.