GraphQL is new. GraphQL is cool. Look! Github dumped REST for it! We MUST do it too!
Well, why not. GraphQL could be a great tool, but like any tool, you don’t choose it just because. You choose it because it solves a problem in a given context. You choose it knowing its strengths and weaknesses.
While discovering what is GraphQL we will see what REST API providers should think about before blindly dumping REST for it. From design and implementation to pricing model and analytics down to developers experience and implementations, choosing an API design style will have impact on the whole API lifecycle. Therefore, this choice must be an enligthned one and not based on simple beliefs.
ICYMI, I’ve just switched from a self hosted Wordpress to a Jekyll static website hosted on Github. The code is available in the apihandyman.io repository. If you’re looking for information and tips about how to enable pagination on categories pages and have infinite scroll with Jekyll or how to to deploy a Jekyll website using custom plugins on Github Pages, you should take a look at it.
If you wonder how to evolve a company’s IS in the lego computing age, read my post on Nordic APIs blog.
After API Days London, and Nordic APIs Summit in Stockholm, Scottie beamed me to API Strat Boston 2016 for the final part of my OpenAPI specification (fka. Swagger specification) talk series: OpenAPI Trek Beyond API Documentation.
Just before the Developing an API Strategy for 2017 panel, I have been interviewed about Swagger/OpenAPI specification and the API Stylebook by Keshav Vasudevan from Smartbear.