The origins of GraphQL: An Interview with Lee Byron

I recently interviewed the GraphQL co-creator Lee Byron for Nordic APIs, an international community of API enthusiasts. It was a great opportunity to find out how GraphQL came about, why it was open-sourced and where he sees it developing in the future. We also touched upon documentation and the importance of descriptions in GraphQL, something I’ll share in a future post.

The Adventures of SuperGraph

Ten years ago Lee Byron was a graphics engineer designing interactive news graphics at the New York Times when a friend approached him to join a small social media startup based in San Francisco, California. The company was Facebook, which had only just surpassed MySpace as the world’s most visited social media website at the time, and four years later Byron would find himself managing the team working on the Facebook native iOS app when the first seeds were planted for what would later evolve into GraphQL.

Facebook_Headquarters_Entrance_Sign_Menlo_Park-e1493846796266.jpg
GraphQL was created at Facebook.

 

“Right around then our mobile apps were built with HTML, they had native wrappers around them and they had suffered from real performance problems,” he said. “We made a bet on that technology thinking that Apple and Google would maintain really high quality web browsers and they didn’t so that didn’t really work out very well and we decided we needed to build a native app.”

“We started this little skunkworks project where two engineers from my team and two engineers who were relatively new to the company started building out what would become the native iOS app for News Feed.”

Facebook-Original-App
Issues with the original Facebook mobile app led to the creation of GraphQL.

The team produced a high quality, working prototype but Byron spotted that News Feed stories were missing because they had used a three-year-old, unsupported platform partner API and he realised they would need to build a new one.

“That kind of sent things to crisis,” he said. “They thought they were almost done and it turned out they had a ton of stuff left to do so I started focussing in on those problems and I was like “Okay, I need to build a News Feed API somehow. Who are the people I need to talk to? How does that need to get done?” A big problem is that the News Feed is incredibly complicated and typical API technology probably wouldn’t do quite the right job so I started sketching out what a good API might look like. It definitely wasn’t what GraphQL is now but it was sort of like really beginning inklings in that direction.”

“Meanwhile another one of the GraphQL co-creators Nick Schrock had just spent the last couple of years working on a bunch of data infrastructure on our server side and had spent a little bit of time exposing some of that over APIs, not GraphQL but a different kind of API, and had an idea about how this could be made much, much more simple so I credit Nick Schrock with the first prototype that really resembled GraphQL. He called it SuperGraph.”

A screenshot of an early GraphQL prototype that Nick Schrock called SuperGraph.

A member of Byron’s team introduced him to Schrock and Dan Schafer, hailed as the best News Feed engineer at Facebook at the time, and the trio started work an initial version of GraphQL. “The three of us got to work trying to figure out how to build a better News Feed API and we just got super far down the rabbit hole,” Byron said. “I think just a month or two of iterative improvements on what started as a prototype enfolding all of our ideas ended up being the first version of GraphQL.”

The launch of the native iOS app, helped by the introduction of GraphQL, was a success and the excitement around GraphQL and its capabilities made other Facebook teams interested in using it. As a result, Byron and the early GraphQL team would go on to develop a whole ecosystem around GraphQL; how it integrated with the iOS and Android apps, how it integrated into the server and GraphiQL, the in-browser IDE.

1_CtjF44Lt5bDk6QSzB_2IhA
The decision to open-source GraphQL was inspired by React and Relay.

The final phase of the project was the decision to open-source GraphQL in 2015, something that was driven in part by the successful release of React, Facebook’s open-source JavaScript library, and also by the desire to open-source Relay, Facebook’s open-source JavaScript framework, which was inherently linked to GraphQL.

“We were excited about it,” Byron said. “I mean sharing things with the community is always good but it would be a lot of work and we weren’t totally sure people outside of Facebook would even care or find value in it. We thought maybe this was something that only solves a Facebook problem and wasn’t a generic solution but the Relay team had us excited so we followed that path and I’m super happy that we did. GraphQL now has a really big community outside of Facebook.”

The release and adoption of GraphQL

The adoption of GraphQL took far less time than the team initially predicted. Speaking at the first ever GraphQL Summit in October 2016, Byron said he hoped GraphQL would be picked up by big companies within four years and reach ubiquity within five years. Byron laughed when he reflected on the accuracy of those predictions.

Lee-Byron
GraphQL co-creator Lee Byron speaking at the GraphQL Summit in 2016.

“I think I overestimated how long it would take for large companies to adopt it and underestimated ubiquity,” he said. “It’s probably because ubiquity is kind of vague but certainly I still talk to tons of people who work in the API space and at best they say “Oh GraphQL, I think I’ve heard of that before but I don’t really know what it is”. It’s certainly better this year than it was last year and better than the year before that.”

He added: “I remember going to an APIDays conference shortly after the first GraphQL Summit and literally there were zero talks on GraphQL. After the next one, there was a whole track talking about GraphQL. The one after that GraphQL was featured in one of the key notes and there wasn’t a specific track but GraphQL was scattered around. So it’s definitely picking up steam. I think there’s visible progress towards a ubiquity, if we want to talk about ubiquity as knowledge. People are aware of the technology and what it does and why they should use it or not.”

One of the biggest surprises for Byron was seeing Github become one of the early adopters of the technology, particularly as he considers them an API leader.

“I was really surprised to see that within a year of GraphQL being open-sourced, Github decided that their public API would be GraphQL,” he said. “That was particularly significant because they kind of helped to popularise REST. You know REST has been around for a while but it wasn’t really the dominant, popular way to build APIs until Github decided to build their API and they used REST and they made a big deal about it and wrote a bunch of blog posts and everybody paid attention.”

Screen Shot 2018-10-10 at 23.14.48

He added: “I thought “Wow, this API is really well built, it must be because of REST” and it was to a large degree but it’s also because the people at Github are really smart and they built a really great API. It’s really exciting to me that I consider Github to be sort of an API leader and they jumped on that first and they’re not the only ones any more.”

GraphQL and REST APIs can co-exist

Although GraphQL has been lauded as the natural successor to REST technology, Byron is modest about its capabilities and believes the two can co-exist.

GraphQLvsREST.png

“There are plenty of things that REST does well or that does better than GraphQL and vice versa,” he said. “I’m a big believer in the more tools that we have, the more choices that we have to solve problems. I’m certainly not one of those people who that think I’ve invented the silver bullet here and everything should be GraphQL and there’s no room for anything else. I think that would be a little unwise. I think REST is an amazing technology so I would be really sad to see it disappear.”

“I’m certainly not one of those people who that think I’ve invented the silver bullet here and everything should be GraphQL and there’s no room for anything else. I think that would be a little unwise. I think REST is an amazing technology so I would be really sad to see it disappear.”

“I do think that as GraphQL continues to expand in scope we’ll see a much healthier balance between the two. My expectation was that public APIs would remain REST because that was simpler and more familiar where internal APIs, so to build your company’s own product, would use GraphQL because while it brought more complexity, it also brought some more expressiveness and capability.”

As GraphQL continues to grow, one of the things Byron is excited to see is more public APIs adopting the technology, like companies have done with REST.

“I think the space of public APIs or partner APIs is particularly interesting because I think the vast majority of GraphQL adoption so far has been for a company’s own internal projects. For example, Walmart use GraphQL but they use it for the Walmart app and I think it would be really interesting if GraphQL starts to be used for these public and partner APIs so that we have companies that are working with each other and then it’s not just about the API design and the mental model for within that company but between companies.”

“I think that could be really interesting because it could help start to build one conceptual graph of all information. I don’t think GraphQL is going to be the technology that gets us there but that’s one of the big dreams of the internet is that we could have the one data internet but we need to start having some serious conversations along that path if we ever want to get there. I think GraphQL could be a really useful stepping stone on that path.”

Hopes for the future of GraphQL

Despite being happy with its growing popularity and some the open-source development going on around it, Byron hopes to see more growth in GraphQL tools and integrations.

graphcool-ionic
Lee Byron hopes to see more growth in GraphQL tools.

“It’s kind of sad that there’s the Apollo Client for iOS and Android and then that’s kind of it,” he said. “There needs to be many competing pieces there and that’s true for any sort of technology that’s reached ubiquity has at least two if not closer to a dozen different options for how you would go about implementing that. If you wanted to build a web server, there’s like hundreds of ways to build a web server in dozens if not hundreds of languages and that’s kind of where I want to get to with GraphQL as well.”

Byron left Facebook after a decade of service to become head of web engineering at fintech startup Robinhood earlier this year, citing the desire to work at a smaller company and its refreshing vision as some of his reasons for leaving.

“Robinhood’s roughly the same size today that Facebook was when I joined it and I really missed that and I realised that some of the best work that I did at Facebook was when there were a little smaller. Not that Facebook’s not a great place to work now, it’s just I really appreciated having the smaller work environment and was happy to have that back.”

“I’m also just kind of interested in finance in general so it’s a new space for me to learn which has been pretty fun and then they’ve got a bunch of really interesting technical challenges and people challenges. That’s my bread and butter. I really love technical problems and people problems, then the product problems I’m interested in but it’s new to me so there’s room to learn.”

On top that, he is still the editor of the GraphQL spec and runs the working group meetings to ensure that GraphQL continues to improve while also maintaining stability.

“One my of goals for GraphQL is that it is stable because Amazon and Twitter and Pinterest and Airbnb and Facebook and Walmart and so many other companies have bet their future on GraphQL,” he said. “If GraphQL changes so rapidly that every year there’s like maintenance work to have to go in and improve all of those pieces of infrastructure, if I was an engineering director at those companies I’d feel shaken and I’d question the choice to use that technology. At the same time I want to make sure that there’s room for it to grow and improve and those improvements don’t have to come from me. I don’t think that I’m the smartest person in the room. I want to make sure that experiences of people from lots of different companies and environments can help influence that direction.”

 

He added: “GraphQL is still new. I’m really impressed with how much has been built by the open-source community and how much adoption has happened within the open-source community, especially the large companies. I mean, there’s a ton of large companies that are using GraphQL and that’s only three years out from open-sourcing, I think that’s pretty incredible but there’s always room to grow.”

Advertisements

Write the Docs Portland 2018

Earlier this year I stumbled upon Write the Docs, a global community of people who care about documentation, and through its Slack channel, I have learned so much from the advice and knowledge shared by its thousands of members. The discovery has been a real godsend for someone like me who has worked independently or in small teams for most of my technical writing career.

This month I was lucky enough to go halfway across the world to the annual Write the Docs conference in Portland, Oregon to meet some of the community in person and listen to some brilliantly insightful and entertaining talks from fellow technical writers. In this post, I’ll share my highlights of the conference, my favourite bits of Portland and offer some advice on how to get there.

Conference Highlights

DISCLAIMER: I didn’t attend every single presentation but all of the talks I listened to were great. I’ve highlighted a few memorable ones below:

Kat King from Twilio, who had the unenviable task of giving the first talk of the conference, delivered an entertaining and engaging talk about how she and her team were able to quantify and improve their documentation with user feedback.

Beth Aitman from Improbable spoke about how to encourage other members of your development team to contribute to the documentation. This is something I think we all struggle with and can relate to. It’s well worth a watch:

Bob Watson gave a great talk about strategic API documentation planning, with some interesting tips about your target audience and the different types of API doc consumer  you might come across. These included the ‘Copy and Pasters’ and the ‘Bigfoot’, the rare developer who actually studies the documentation and applies the code!

As well as the main talks, there were some excellent Lightning Talks, five minute presentations given during the lunch breaks, that contained some real gems such as Mo Nishiyama’s resilience tips when dealing with Imposter Syndrome and Kayce Basque’s talk on improving response rates from feedback widgets:

If the talks aren’t your thing, there was also an Unconference where you could discuss topics such as API documentation, documentation testing, individual tools; whatever you want really. I just sat and talked with two technical writers about a documentation tool for half an hour!

Apart from the people, one of the best things about Write the Docs Portland was the venue, a striking 100-year-old ballroom with a “floating” dance floor that has played host to the likes of Jimi Hendrix, the Grateful Dead, Buffalo Springfield and James Brown. Also, if stickers are your thing then you could collect a load of stickers provided by the conference sponsors, hiring companies and Write the Docs themselves (see below):

Portland Highlights

Apart from its scenic surroundings and the views of the Tualatin Mountains, Portland has a lot to offer in the city itself. Some of my personal highlights included:

Doughnuts – Portland has a reputation for great doughnuts. We skipped the enormous queues outside Voodoo Doughnuts and went to Blue Star Donuts instead. The PB  & J with habanero pepper was pretty unusual!

Coffee – Portland has developed a thriving yet relaxed coffee culture with more than 30 coffee roasters across the city. It goes without saying that the coffee here is good! Check out Heart or Barista.

Restaurants – The food in Portland was amazing. One of my favourite meals was at Life Aquatic-themed oyster bar Jacqueline in SE Portland. For sushi check out Masu on SW 13th Ave and for a relatively cheap but delicious lunch go to Nong’s Khao Man Gai thai food cart.

Washington Park – If you want to escape the sights and sounds, head to the 412-acre Washington Park which boasts a Japanese garden, a zoo, a rose garden, an amphitheatre and lots of trees!

Powell’s Books – No trip to Portland is complete without visiting the world’s largest independent bookstore. My only advice would be to pick up a map and have some idea of what you’re looking for, otherwise you’ll find yourself wandering the many colour-coded sections and aisles for hours.

How to get there

If you live in the US or Canada, it might be slightly easier to convince your boss to fund your trip to Write the Docs. If like me, you’re based in the UK, its slightly more difficult but there are a number of options:

1. Use your training budget – Ask if you can use your training budget for the trip. It cost me my annual budget but it was well worth it and I was able to combine it with a trip to my company’s head office in San Francisco.

2. Become a speaker – I met a few writers whose company paid for them to be there because they were speakers. It’s great exposure for you, your documentation team and your company.

3. Recruitment  – If you’re company needs to grow its documentation team, you might be able to justify the cost by attending because there is a job fair and you have the opportunity to network and meet writers with a wide range of experience.

4. Exposure – Even if you don’t become a speaker, it’s a great way to raise your personal profile and that of your company. You never know when that visibility might come in handy in future.

5. Specific talks – Highlight a few specific talks from the schedule of the upcoming conference or a previous conference that may benefit you or your team. Write the Docs is a fantastic opportunity to learn from some of the best technical writers in the business!

If all else fails, see the sample email and other tips under the ‘Convince Your Manager‘ section of the Write the Docs website.

 

Bernard-Paul Heroux: Fact or Fiction?

If you Google for quotes about tea, one of the top hits is from the philosopher Bernard-Paul Heroux who is attributed with this quote:

There is no trouble so great or grave that cannot be much diminished by a nice cup of tea.

The philosopher’s words of wisdom about tea are quoted in articles by the Telegraph, Reuters, the Guardian and numerous blogs and websites online. An image search also shows that the Tregothnan estate in Cornwall and American retailer Trader Joe’s use the quote on their packets of tea.

This slideshow requires JavaScript.

The former journalist in me wanted to find out more about the mystery man behind the famous phrase. Searches of the name Bernard-Paul Heroux return no wikipedia listings and his name isn’t listed alongside other famous Basques or famous Basques philosophers. In fact, the only hit I got at all, aside from the quote, was that the Heroux name was a surname from the Languedoc-Rousillion region of France, a good six hour drive from Basques country. However, the Heroux surname is not listed in any online database of Basques surnames and trawling several sites of Basques births, deaths and marriages returned nothing. It’s as if Mr Heroux appeared at some point in the 1900s, made his famous quote about tea and then vanished into thin air.

Apart from the lack of evidence he ever existed, my other major doubt around the authenticity of this phrase is the fact that Basques country, as with other parts of northern Spain, has had has much more of a coffee-drinking culture for centuries. It’s just a fact, the Basques and the Spanish are traditionally coffee drinkers – not tea drinkers.

So is Bernard-Paul Heroux’s quote fact or fiction? Was he a real man or it just a figment of the imagination, dreamed up as part of an elaborate piece of marketing? I don’t want to make a storm in a teacup but until someone can prove to me otherwise, I think it’s probably the latter.

 

Debugging the word ‘Bug’

Etymology and the origin of English language have always fascinated me, partly because so many of the words we use every day represent remnants of history; artefacts left behind by the Roman Empire, the Vikings and the Norman conquest. Although words relating to computing and technology are much younger, some are just as quirky and steeped in history as those from the past.

Like a Moth to a Flame

The origin of the word ‘bug’ in the computing world is often mistakenly credited to computer scientist Grace Hopper. The story goes that while working on the Harvard Mark II computer in 1947 she discovered a dead moth stuck in a relay. It was removed and taped into a logbook where she wrote “First actual case of a bug being found” (see picture below), which suggests that the term was already in use at that time.

H96566k

While this might have been the first literal case of ‘debugging’, there is evidence that ‘bug’ had been used in engineering for many years before that.

Scarecrows, Bugs and Bogeys

The most accepted origin of ‘bug’ is the Middle English word ‘bugge’ or ‘bogge’ (n.), which meant a scarecrow or a scary thing. One of the first iterations of the word came in John Wycliffe’s English translation of the bible (circa 1320-1382): “As a bugge either a man of raggis in a place where gourdis wexen kepith no thing, so ben her goddis of tree.” (As a scarecrow or a man of rags in a place where gourds grow guards nothing, so are their gods of wood.)

Bugs-2.png
‘Bugge’ (n) originally meant scarecrow then became an early name for bedbug.

As language evolved, another off-shoot of ‘bugge’, the scarecrow, was ‘bogey’, an evil or mischievous spirit. This gave rise to a family of other ghost and hobgoblin names including ‘bogeyman’, ‘boggart’, ‘bogle’ and ‘bugaboo’. While the archaic form of ‘bugbear’ is also another hobgoblin figure. In general these all have the same negative connotation of things to avoid and that cause fear or irritation. The direct descendant of these words is ‘bogey’ which still survives today in modern English, in aviation where a ‘bogey’ is an enemy aircraft, in golf where a ‘bogey’ is one over par (a bad score) and a ‘bogey’ (UK) or ‘booger’ (US) is a piece of nasal mucus.

giphy (1).gif

By the middle of the seventeenth century, the word ‘bug’ no longer meant scarecrow and had come to mean ‘insect’, which makes sense as many people consider them to be alien and scary. The earliest references to ‘bugs’ meaning insects often related to ‘bedbugs’, supposedly because when someone woke up covered in bedbug bites, it was as if they had been visited by something scary during the night.

Thomas Edison’s Bugs

By the 1870s, the meaning of bug had changed once more and perhaps made its first appearance in technology when American inventor Thomas Edison referred to what he called a ‘bug’ while developing a quadruplex telegraph system in 1873. He also mentioned ‘bugs’ in a letter to an associate:

“It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise — this thing gives out and [it is] then that “bugs” — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.”

They were mentioned once again in an article in the Pall Mall Gazette in 1889:

“Mr. Edison, I was informed, had been up the two previous nights discovering ‘a bug’ in his phonograph – an expression for solving a difficulty, and implying that some imaginary insect has secreted itself inside and is causing all the trouble.”

Another early example of ‘bugs’ being used to refer to technology was with the release of the first mechanical pinball machine, Baffle Ball, which was created by David Gottlieb in 1931. It was advertised with the strap-line “No bugs in this game!” (see poster below):

No-Bugs1
So it seems fair to assume that the word ‘bug’ came from ‘bugge’, the Middle English for scarecrow, which led to ‘bogey’ and all the similar words meaning an obstacle, a source of dread or something to be feared. In modern times the word ‘bug’ has become a verb meaning to vex or irritate, while the noun form has become a synonym for disease-causing germs, crazily enthusiastic or obsessive people (e.g. a firebug is a pyromaniac), concealed recording devices used by spies and perhaps, thanks to Edison, an error in technology.