Minna Lunney

To begin, it's essential to make sure we understand what GraphQL is. It's a technology developed by Facebook in 2012 to address their issues with mobile platforms. One of the technologies they were trying to use, REST, was not performing well in their particular setup, so they decided to replace it with a homegrown solution. GraphQL was the result. A few years later, the GraphQL specification was made open-source so that anyone could potentially benefit from it and contribute to it.

GraphQL is a query language for APIs (application programming interfaces) and a server for executing those queries. APIs are the means by which computer programs communicate with each other to exchange and manipulate data. 

REST is the most-used API architecture by far (as Postman's recent API report shows | graph is below); however, GraphQL adoption is on the rise, and many already are using it in place of REST to facilitate communication with all the different APIs that an application may have to talk to.

But first, a background story to give you context. I didn't take the path most Computer Science students take once they graduate. At some point during my college career, while coding my brains out in Java, C++, and assembly, I decided that being a full-time developer was not for me.

To be fair, I hadn't known what to do with myself even before college. I’d always liked writing, but you couldn’t get paid for that. (Right?)

As the Internet became more popular, I’ve enjoyed building homemade websites in HTML+CSS, learned a great deal about how to use search engines, connected with people worldwide, and even bought books and Star Trek memorabilia off eBay.

Therefore, the elders in my life had nudged me toward Computer Science, saying I’d be sure to make a lot of money once I graduated. I’d started with programming classes in high school, then continued with that path into college. And while I kept up with my coursework, I was never all that into coding for coding’s sake. It wasn’t something I itched to do in or out of the classroom.

As a result, my career path has been colorful: tech support, technical training, business analysis, and project management. I once had a job helping developers who used my company’s SaaS and APIs to get up and running and troubleshoot their programming issues. But by far, my favorite thing to do has always been technical writing and documentation. I enjoyed writing articles for the company website, for the knowledge base, you name it.

It turned out I could get paid for writing. Who would’ve thunk it?

I like writing so much that I’ve done a fair bit of it outside work as well. It’s been mostly for myself and my own fun, but I was able to get some work self-published under a pen name.

Now I’m doing technical writing full-time. Although I enjoy every second of it and wouldn’t want things any other way, there’s no denying that my technical side has atrophied a bit. It's super-hard for a full-time developer to keep up with all the latest technological trends, never mind someone who isn’t constantly immersed in it.

So, every once in a while, I like to dip my toes back into that water to learn what’s going on. It helps me to write better documentation when I know firsthand what’s important from the developer’s perspective.

On one occasion, I wanted to see if I could deploy one of the Crystallize boilerplates myself. And if I wanted to later on, I could eventually customize the boilerplate to sell my short stories and novels without having to rely on the big A or the big G.

What follows is a nice bit of hands-on experience. How easy or hard was it for a beginner like me to pull off?

More and more businesses are relying on cloud-native microservice apps to increase development speed and take advantage of the cloud's scalability and availability.