<commit_before>##Lesson One: Intro

###Lesson Plan

####Introduction
First, thanks for purchasing this course. I think you will get a lot out of it, and I hope you have fun working through the lessons. I think the best place to start is to show you what we're going to be building and some of the mechanics of the class.

As you know, this course is designed to help you dive into React + GraphQL. Although we wont be building a particularly complicated application, it will tie in all the concepts you will need to get started building a GraphQL server, connecting to a GraphQL client, and building a interface for your API using React. Concepts you will understand at the end of this course are:

* How GraphQL servers handle requests, gather data from your database as well as 3rd party APIs, and how your payload gets delivered to your client
* How a GraphQL enabled client makes requests and handles the payload returned from your server
* How to get GraphQL data into your React components
* How to modify data on your GraphQL server from your User interface

We will be relying on a few other tools to help us get up and running; most notably, the Apollo Stack from the Meteor Development Group.

The application we're going to be building is a beer review web application. I chose this particular app because I think it's fun, and it also ties in all the concepts that we are going to be exploring with React, GraphQL, and the Apollo Stack. We also have a nice rich data source we can use for descriptions, images, and other beer details.

But before we get into the application, let's take a high-level overview of the whats and whys of GraphQL.

####GraphQL

#####What is GraphQL?

GraphQL is an *application* layer query language for fetching data from any backend - SQL, MongoDB, Redis. What does that mean? It means that GraphQL is a thin layer of abstraction between your client and your backend that acts as a go-between, fetching and mutating data.

It's important to understand that GraphQL is a a *specification* rather than an *implementation*. This means that Facebook is relying on the community to develop full implementations of the spec for use in your applications. The *reference* implementation for JavaScript is [express-graphql](https://github.com/graphql/express-graphql) which will help you get a GraphQL server running with Express. This is a *reference* implementation so may not be as full-featured as you'd want to get going building your own GraphQL server. More on that later.

######Some GraphQL specific features:

#######Single Endpoint

One of the first things you will see when you start using GraphQL is that you have a single endpoint `/graphql` from which all your data will flow and to which you post all of your data actions. This is quite different from the usual REST style APIs that have pre-scripted end-points. This may strike you as strange, coming from REST land.

#######Client-Specified Queries

The actual queries you will write look a lot like the JSON you expect to receive back from your server. An example query:

`{
  user(id: 3500401) {
    id,
    name,
    isViewerFriend,
    profilePicture(size: 50)  {
      uri,
      width,
      height
    }
  }
}`

Will return the data:

`{
  "user" : {
    "id": 3500401,
    "name": "<NAME>",
    "isViewerFriend": true,
    "profilePicture": {
      "uri": "http://someurl.cdn/pic.jpg",
      "width": 50,
      "height": 50
    }
  }
}`

All the magic happens in your resolvers and mutations (more on that later). With this structure it is the client, rather than the server, that determines what data is returned.

An immediate implications of this method is that working on your API becomes far simpler; you don't have to worry about breaking end-points or versioning your API because the endpoint is always the same. The only thing that needs to change on the client side is the data requested in the query.

#######One Round-Trip

Typically in a REST architecture, your client might have to make several round-trips in order to gather the data it needs to render, calling various end-points. With GraphQL, all that data-wrangling is done on the server, and the client gets one payload with all the data it requested in the query, significantly reducing network requests.

######Some Terminology:

We're not going to go into any detail here, but just so you have a general idea of what we're talking about when referencing some terminology.

#######Resolvers

A resolver is exactly what is sounds like: it's a server-side function that retrieves some data, optionally manipulates it, and returns it to the querying client. It's the part of your GraphQL server that decides what data to return to the client.

#######Mutations

A mutation is a string that looks much like a query string, but changes the underlying database in some way. Simple as that. Use them to create, update, delete, or whatever else you do to change your data.

#######Fragments

Fragments are a way to define a grouping of commonly used fields and reuse them in your queries. For example if you are rendering a list of blog posts and want info on the Author, you can include a fragment (predefined set of fields) in your blog post requests and you will get that info returned from a single query. All this saves you round trips to the server.
<commit_msg>formatting for lesson one md<commit_after>#Lesson One: Intro

##Lesson Plan

###Introduction
First, thanks for purchasing this course. I think you will get a lot out of it, and I hope you have fun working through the lessons. I think the best place to start is to show you what we're going to be building and some of the mechanics of the class.

As you know, this course is designed to help you dive into React + GraphQL. Although we wont be building a particularly complicated application, it will tie in all the concepts you will need to get started building a GraphQL server, connecting to a GraphQL client, and building a interface for your API using React. Concepts you will understand at the end of this course are:

* How GraphQL servers handle requests, gather data from your database as well as 3rd party APIs, and how your payload gets delivered to your client
* How a GraphQL enabled client makes requests and handles the payload returned from your server
* How to get GraphQL data into your React components
* How to modify data on your GraphQL server from your User interface

We will be relying on a few other tools to help us get up and running; most notably, the Apollo Stack from the Meteor Development Group.

The application we're going to be building is a beer review web application. I chose this particular app because I think it's fun, and it also ties in all the concepts that we are going to be exploring with React, GraphQL, and the Apollo Stack. We also have a nice rich data source we can use for descriptions, images, and other beer details.

But before we get into the application, let's take a high-level overview of the whats and whys of GraphQL.

###GraphQL

####What is GraphQL?

GraphQL is an *application* layer query language for fetching data from any backend - SQL, MongoDB, Redis. What does that mean? It means that GraphQL is a thin layer of abstraction between your client and your backend that acts as a go-between, fetching and mutating data.

It's important to understand that GraphQL is a a *specification* rather than an *implementation*. This means that Facebook is relying on the community to develop full implementations of the spec for use in your applications. The *reference* implementation for JavaScript is [express-graphql](https://github.com/graphql/express-graphql) which will help you get a GraphQL server running with Express. This is a *reference* implementation so may not be as full-featured as you'd want to get going building your own GraphQL server. More on that later.

#####Some GraphQL specific features:

######Single Endpoint

One of the first things you will see when you start using GraphQL is that you have a single endpoint `/graphql` from which all your data will flow and to which you post all of your data actions. This is quite different from the usual REST style APIs that have pre-scripted end-points. This may strike you as strange, coming from REST land.

######Client-Specified Queries

The actual queries you will write look a lot like the JSON you expect to receive back from your server. An example query:

`{
  user(id: 3500401) {
    id,
    name,
    isViewerFriend,
    profilePicture(size: 50)  {
      uri,
      width,
      height
    }
  }
}`

Will return the data:

`{
  "user" : {
    "id": 3500401,
    "name": "<NAME>",
    "isViewerFriend": true,
    "profilePicture": {
      "uri": "http://someurl.cdn/pic.jpg",
      "width": 50,
      "height": 50
    }
  }
}`

All the magic happens in your resolvers and mutations (more on that later). With this structure it is the client, rather than the server, that determines what data is returned.

An immediate implications of this method is that working on your API becomes far simpler; you don't have to worry about breaking end-points or versioning your API because the endpoint is always the same. The only thing that needs to change on the client side is the data requested in the query.

######One Round-Trip

Typically in a REST architecture, your client might have to make several round-trips in order to gather the data it needs to render, calling various end-points. With GraphQL, all that data-wrangling is done on the server, and the client gets one payload with all the data it requested in the query, significantly reducing network requests.

#####Some Terminology:

We're not going to go into any detail here, but just so you have a general idea of what we're talking about when referencing some terminology.

######Resolvers

A resolver is exactly what is sounds like: it's a server-side function that retrieves some data, optionally manipulates it, and returns it to the querying client. It's the part of your GraphQL server that decides what data to return to the client.

######Mutations

A mutation is a string that looks much like a query string, but changes the underlying database in some way. Simple as that. Use them to create, update, delete, or whatever else you do to change your data.

######Fragments

Fragments are a way to define a grouping of commonly used fields and reuse them in your queries. For example if you are rendering a list of blog posts and want info on the Author, you can include a fragment (predefined set of fields) in your blog post requests and you will get that info returned from a single query. All this saves you round trips to the server.

{'fraction_non_alphanumeric': 0.05157244477723699, 'fraction_numerical': 0.003931111943092475, 'mean_word_length': 4.04723665564478, 'pattern_counts': {'":': 14, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '291106', 'n_tokens_mistral': 2697, 'n_tokens_neox': 2569, 'n_words': 1722}