Tag Archives: Facebook

Is GraphQL really “self-documenting”?

If you Google for ‘API trends’ or ‘the future of APIs’ , one technology that crops up a lot is GraphQL. Developers rave about it being a more powerful and flexible alternative to REST. Not only that but if you’re a technical writer like me, claims that it is self-documenting are particularly interesting. So what is GraphQL and is it really as self-documenting as people say?

What is GraphQL?

GraphQL is an open source data query and manipulation language that was developed internally by Facebook for their mobile applications before being released publicly in 2015. Since then it has grown in popularity with some people claiming it might replace REST APIs in the future.

Like REST APIs, both operate over HTTP with requests being sent to retrieve or manipulate data. The key difference is with REST you might need to send requests to multiple endpoints to retrieve a particular set of data, with GraphQL there is only one endpoint so with a single request you can retrieve an object and all of its related objects.

For example, with this GraphQL schema and server wrapping the SWAPI (Star Wars API), you can retrieve multiple pieces of data using just one endpoint. In this case, finding out the species and home planet of Luke Skywalker by adding more fields to the endpoint:

Star-Wars-GraphQL

“The self-descriptive nature of GraphQL”

There seems to be plenty of love for GraphQL on Twitter with developers praising its speed, flexibility and introspective nature. The other key attribute that crops up a lot is “self-documenting” or “self-descriptive”:

One developer even went as far to say that GraphQL doesn’t require documentation at all. However, after playing around with GraphQL and experimenting with some public GraphQL examples out there, I’m not so sure I agree.

Naming matters

The key thing about GraphQL from a documentation perspective is the importance of naming. Lee Byron, one of developers behind GraphQL, spoke about this in his talk “Lessons from Four Years of GraphQL” at the GraphQL Summit in November 2016: “Naming things is super important in GraphQL APIs,” he said. “An important question to ask when designing APIs is ‘Would a new engineer understand this?'[… ] And that means no code names or server-side lingo.”

Lee-Byron
Lee Byron, one of the developers behind GraphQL, spoke about the importance of naming.

He continued: “Imagine that most of the engineers who are going to be using your API might not find it so easy to go and find out how that field maps to some underlying system. It’s really important not just to have names that are good but to have names that are self-documenting. Naming things that adhere closely to what those things actually do is really important to make this experience actually work.”

“An important question to ask when designing APIs is ‘Would a new engineer understand this?’ […] Naming things that adhere closely to what those things actually do is really important to make this experience actually work.” – Lee Byron

Despite Byron’s warnings, fields with poor or no descriptions were a common issue in the different GraphQL APIs I looked at. In the example below, taken from the GraphiQL documentation explorer, I had no idea what the ‘section’ query field did or what data it sent back because it had no description:

Screen Shot 2018-07-25 at 18.44.37

Apart from the documentation explorer, another way to see what query and mutation fields are available is the auto-populating feature in GraphiQL. Hovering over the field or type reveals a description but this can be as useless as the description in the documentation explorer if all it says is ‘Self descriptive’, as this Twitter user found out:

Does GraphQL need documentation?

I agree that GraphQL is self-descriptive and if you’re familiar with the query language and the schema, its introspective nature means it is easy to refer to the description of a field or type to find out what it does. One of the other advantages of GraphQL is the API documentation is easy to keep accurate and up-to-date as the descriptions are pulled directly from the code. In version 0.7 or above of GraphQL, this is as simple as adding a comments directly above the type or field in the code:

Star-Wars

However, GraphQL is only “self-documenting” if the developer or a technical writer has given the fields adequately intuitive or self-descriptive names or has added decent descriptions for them in the schema code. If the names are obscure or the descriptions aren’t great then your GraphQL API is as useful as a chocolate teapot and there are already a few chocolate teapots out there from what I’ve seen. So I guess the good news for technical writers is that we still have a role to play in helping to document GraphQL, it isn’t a magical solution that renders us unnecessary just yet!

Advertisements

10 Tips for making Content more Engaging

I’ve always liked to learn new bits of software by trial and error, trying things out for myself first and learning from my mistakes but there’s only so far you can get before you get stuck. This is why documentation and help are so invaluable because a piece of software is worthless unless you know how it works.

1c00898.jpg

In today’s fast-paced world, people don’t have time to read chunky 900 to 1000 page manuals, they want information to be quick and accessible. As a result, technology companies and their technical writers are having to adapt their techniques and content strategies to make documentation more exciting and engaging for readers.

Here are some of the best ways to keep people interested in your content:

1. Pictures

As you have probably seen from my blogs, I am a real advocate for using good images to break up text and make documentation more approachable and more visually interesting.

2016-05-20 11_32_36-Mozilla Support.jpg

This is just the Firefox help homepage but as I mention in my blog last week, I thought the design and use of imagery was really visually appealing.

2. Videos

Taking this approach one step further, videos are another brilliant and effective way to engage help users as long as they are well put together, short and succinct.

The example above is one of Skype’s excellent video tutorials which are really well produced.

Videos can be made with software such as Camtasia or free tools such as Open Broadcaster Software.

3. Gifs

Like videos, it is possible to add gifs to make your content more dynamic and visually interesting. They are a quick simple way to show an example of how something is done:

Animation

This gif was produced using free open-source software called ScreenToGif.

4. Infographics

I think graphics are a great way to get a lot of information across to your readers in one image if they are designed well.

all-about-spotify-and-ecosport_527a5b85c6af0_w1500

The Spotify infographic above has 10 separate facts spread across one image.

5. Examples

Using examples is the best way to show your readers what you are trying to explain.

2016-06-02 14_05_27-Embedding a Tweet on your website or blog _ Twitter Help Center

On the page above, taken from the Twitter, the help describes how to embed a Tweet and then gives examples.

6. Be Human

Use an informal or conversational writing style. Write as if you were describing how the software works to a friend. Readers won’t engage with a robotic tone of voice.

2016-06-02 14_07_29-People You May Know _ LinkedIn Help

Linkedin’s Help addresses users by their first name to make the experience more personal.

7. Keep it Short

Don’t overwrite. If you can explain it in one sentence then write one sentence. It’s better to use 25 words rather than 250. The shorter the better.

2016-06-02 14_10_12-Login Basics _ Facebook Help Centre

Facebook’s Help Centre covers the login basics in just 73 words (and three links).

8. Keep it Simple

Don’t use lengthy words the average person won’t understand or that will get lost in translation. Go with “move in a circle” rather than “circumbilivagination” or “use” instead of “utilise”.

2016-06-02 14_14_05-Start

Sorry Royal Mail but I really dislike the use of “utilise”, it’s just a waste of four letters!

9. Easy Navigation

If your help system is easy to work your way around then people will want to use it.

2016-06-02 14_20_59-Start

Skype’s Help is really easy to navigate from my experience. You can check it out here.

10. Make it fun!

Use humour and unusual text to catch people’s attention. This is discussed by Mozilla’s Michael Verdi in his presentation How To Write Awesome Documentation.

Atlassian Confluence’s help system, shown below, encourages new users to join a fictional space program and complete a mission:

2016-06-01 14_40_40-Get started - Atlassian Documentation

2016-06-01 14_40_57-Tutorial_ Navigate Confluence - Atlassian Documentation

Sure, it’s a bit wacky and off-the-wall but its fun, it catches attention and keeps readers interested and engaged.