Top new features in Python 3.8


I recently came across an interesting library for GraphQL. Strawberry is a new GraphQL library for Python 3, inspired by dataclasses. An initial version of Strawberry has been released on GitHub. To follow the project, you can sign up to get updates on the Strawberry site or github. Links below:

![](strawberry.png)

https://strawberry.rocks/

Strawberry is created by [patrick91](https://twitter.com/patrick91) who is also an organizer of @pyconit. It was originally announced during Python Pizza Berlin.

![](strawberry2.png)

#PyPi release and demo

Alpha version on PyPI: https://pypi.org/project/strawberry-graphql
Demo on Heroku using Starlette: https://demo.strawberry.rocks/graphql

#Installation

```
pip install strawberry-graphql
```

Getting Started

Create a file called app.py with the following code:

```
import strawberry


@strawberry.type
class User:
    name: str
    age: int


@strawberry.type
class Query:
    @strawberry.field
    def user(self, info) -> User:
        return User(name="Patrick", age=100)


schema = strawberry.Schema(query=Query)
```

This will create a GraphQL schema defining a User type and a single query field user that will return a hard-coded user.

To run the debug server run the following command:

```
strawberry run server app
```

Open the debug server by clicking on the following link: http://0.0.0.0:8000/graphql

This will open a GraphQL playground where you can test the API.

{% github strawberry-graphql/strawberry %}


GraphQL library for Python - Strawberry


This article will give you a detailed introduction on how to set up your computer as a web developer.  It was created for MacOS cause I mostly work on MacOS, however, you can easily interchange those instructions for Windows. Setting up a web development environment is the first challenge on a road to become a web developer today.  Don't give up, try right away!

There are a few ways you can set up your development environment. You can have everything in one IDE alternatively you can use many lightweight tools to combine them with their purposes. The following short checklist reflects my favourite tools in lightweight combination. In some cases, I prefer to use lightweight tools and for example, for react I use one IDE. Follow me to get more, in the next article I'll cover the basics of React Development Environment. 

#Agenda:
- Homebrew
- Git & GitHub
- Sublime as Editor
- Node and NPM
- iTerm2

#Homebrew

You will need to use the Mac Terminal app to install Homebrew. The Terminal app is located in the Utility folder in the Applications folder.

Homebrew is a package manager for MacOS. Rather than having to download every app from a web, Homebrew enables you to install and control applications from the command line. It’s an excellent tool to get used to the command line at the beginner's journey. You should feel relaxed on the command line as developer thus it makes sense to perform as many tasks as possible there. In addition, Homebrew gives you the ability to manage all of your applications with only one tool. You can get all the necessary instructions for Homebrew on their website. Otherwise, simply type the following command in your command line (terminal) to install Homebrew.

```
ruby -e "$(curl -fsSL
https://raw.githubusercontent.com/Homebrew/install/master/install)" 
```

To verify if the installation was successful type: 

    brew --version

Afterwards, Homebrew should be ready for you. It should be accessible on the command line when you type brew. Whenever you install another tool with Homebrew, type brew update in your command line to update the Homebrew repository with all the recent versions of the packages. Afterwards, you can install the desired tool with brew install <tool> or upgrade it with brew upgrade <tool>.

#Git and GitHub

Git will be your distributed version control system. It manages your local projects on your machine and your remote projects on platforms such as GitHub and GitLab. Sooner or later, you will need it to cooperate on projects with other developers. Git should have been installed along the way with the Homebrew installation. Type git --version to verify that it is there. Otherwise, you can use Homebrew for the first time to install it with the following command on the command line:

    brew install git

To verify if the installation was successful type: 

    git --version

Next, you have to create a GitHub account and connect it from a terminal. GitHub is a web-based hosting service for version control using Git. It offers all of the distributed version control and source code management (SCM) functionality of Git as well as adding its other features. It provides access control and several collaboration features such as bug tracking, feature requests, task management, and wikis for every project. To learn more how to setup GitHub over terminal check this [link](https://help.github.com/en/articles/set-up-git).

#Sublime as Editor

Sublime is one of the top editors for developers. That’s the part where everybody has their own opinion. You can use any editor or IDE of your choices like Visual Studio Code, Atom and VIM.

Unfortunately, Sublime isn’t directly accessible via Homebrew. But you can use Cask to install it. Cask is another package manager within Homebrew for GUI tools. For instance, Chrome could be installed on your machine with Cask as well.  Just type selected commands in a terminal:

    brew install caskroom/cask/brew-cask
    brew tap caskroom/versions
    brew cask install sublime-text

To verify if the installation was successful type: 
    subl -v

#Node and NPM 

If you are working with JavaScript, node and npm is a must. The node package manager is used to install libraries/frameworks (node packages) on the command line to your project.

    brew install node

To verify if the installation was successful type: 
    node -v
    npm -v

#iTerm2

MacOS and other OS’s already come with their own command line terminal tool. Thus, another command line tool is optional, but you might want to install iTerm2 because of various advantages. It comes with powerful integrations, beautiful themes and other useful utility tools that will enrich your daily toolset. Homebrew with Cask helps you to install it, just type: 

    brew cask install iterm2

#Summary

That are all the basic tools you need to set up a development environment. Homebrew is used to install all the tools for you on the command line. Cask is used on top of Homebrew to install graphical user interfaces apps applications such as Chrome, iTerm2 and Sublime. The later stage you can choose any code editor as you want since you'll spend most of the time in it. As a JavaScript developer, there is no way around node and npm and thus you should install them with nvm to manage multiple node versions.  Git and GitHub should be used to handle your projects.


##Would you add anything to my list?

Junior Web Developer environment setup

There’s a lot of hype on GraphQL and debate to compare it to REST. GraphQL is in the early stage of adoption globally and no one exactly knows where it will end. Researching on the internet, I was able to find many positive articles presenting this new piece of tech. Is it just a hype of the first impression?

I’ve researched Reddit and selected the most upvoted comments on GraphQL.  My goal was to write down as much transparent and objective article on the topic. I’ve used discussions and arguments between users to present a different point of view on each aspect. Each comment quoter below has a link to its author and number of upvotes in (). Keep in mind that upvote numbers might change since I've written this article.

##Agenda 

- General review
- React & Apollo review
- Big Boys & GraphQL 
- Caching
- Data Fetching
- Summary.


#General review

Starting from a general view I’ve chosen two cases. First, one - [SwiftOneSpeaks](https://www.reddit.com/user/SwiftOneSpeaks/) shows front end developer perspective and potential improvements in time to market. Secondly, [Scruffles360](https://www.reddit.com/user/scruffles360/) presents strategy trends on how teams adapt graphql and which one they used. Later on you’ll find more about his case. The second comment was the least upvoted one that I’ve chosen in the article.

[SwiftOneSpeaks](https://www.reddit.com/r/reactjs/comments/bozrg1/graphql_vs_rest_putting_rest_to_rest/eno3ovb/) (23) says: 

> *When I was working with a backend dev team, they were far more willing to provide new queries to match my needs because it didn't impact existing queries they had to support. (That said, I have no idea how well this scales over time). It also reduced the number of crappy responses I had to reparse into usable (for my needs) data structures. (example, I'd get 3 arrays back that I had to relate and zip together into a single set of objects. With GraphQL, I had more ability to demand data in a useful shape, though the backend still has to do their part).*

[Scruffles360](https://www.reddit.com/r/reactjs/comments/bozrg1/graphql_vs_rest_putting_rest_to_rest/enpb6fg/) (8) explains his three trends in GraphQL scope:

>- The monolith - which is what Apollo is pushing now. Every company has one and only one api endpoint and schema that proxies to everything else (https://principledgraphql.com/). I disagree with this wholeheartedly, but won't repeat my arguments here (you can dig through my comment history if you want)
- The database api - for some strange reason people have started adding plugins to databases that give you direct database access via graphql. Graphql is wonderful for so many reasons, but it doesn't come close to competing with a native database query language. More importantly, this takes away your business layer giving callers direct access to your store. No one should have access to your store except one single microservice. Everyone else should be calling through your api.
- The medium approach - The classic API approach where each app has their own API (graphql in this case). It might isolate business logic or proxy to microservices (via rest or by schema stitching another Graphql schema). That's the route we went, and I don't regret a thing.

#React & Apollo review

React & Apollo combination review request  gained a lot of attention. Additionally [Wronglyzorro](https://www.reddit.com/user/wronglyzorro/) and [Livelierepeat](https://www.reddit.com/user/livelierepeat/) argued about why backend developers might not like GraphQL. The response from more experienced developer gained triple more upvotes! Additionally I've choosen one longer but very detailed review.

[Wronglyzorro](https://www.reddit.com/r/reactjs/comments/9nmj0w/what_is_your_experience_with_react_apollo_graphql/e7nkk73/) (12) says: 

>*We strictly use react + apollo on our web app. We're also forcing the mobile clients to use it as well. It's incredible and the future. Backend devs of course hate it because they are set in their ways and don't like change. However over the last year when there have been any sort of outages it was never graphql that was a point of weakness. It was always the legacy backend services that crapped out.*
 
[Livelierepeat](https://www.reddit.com/r/reactjs/comments/9nmj0w/what_is_your_experience_with_react_apollo_graphql/e7o92o5/) (40) responded: 
>*You might want to gain a little more insight that that. I used to be a young dev who used all of the latest tools and scoffed at those who "couldn't adapt". I've learned that there are often much more interesting reasons than, "people hate change". Like does GraphQl create burdensome abstractions? What is getting added to their workload that they are resisting?
At some point using all of the latest tools loses its luster. More power comes from understanding the code and the people processes as well.*
 
 [Capaj](https://www.reddit.com/r/reactjs/comments/9nmj0w/what_is_your_experience_with_react_apollo_graphql/e7nlgrn/ 
) (11) detailed review: 
>*We use it in production since May. We're a fullstack team so we're not on the mercy of some other team doing the backend. It wasn't easy persuading everyone, but with a single sample feature built in GQL everyone agreed it looked way better than REST. Graphiql helped a lot with that. It's been quite good. We have apollo engine enabled on the backend and I really enjoy using metrics to hunt API bugs in prod. We use decapi to decorate our objection.js DB models. We have a single place where we define our models and GQL gets generated almost for free.
On the frontend we use apollo-client, but we don't use caching so far. Our FE focus is on getting rid of our legacy angular.js code, so we don't have time yet to experiment with FE caching.
I don't event consider using apollo for client side state management, because all the feedback I've heard so far was that it's not production ready yet. Also I have to say it looks quite verbose for what it really does. Instead I am hoping I can extend https://github.com/mhaagens/gql-to-mobx and use that for our state management needs. MST works wonders with typescript. If we can generate MST models from our queries on the fly while editing our GQL queries we can boost our productivity considerably.*


#Caching
 
I’ve found a lot of great and upvoted comments from [SwiftOneSpeaks](https://www.reddit.com/user/SwiftOneSpeaks/) and [Scruffles360](https://www.reddit.com/user/scruffles360/) which had been already mentioned here. Here’s what they discussed on lack of caching and potential solution.

[SwiftOneSpeaks](https://www.reddit.com/r/reactjs/comments/bozrg1/graphql_vs_rest_putting_rest_to_rest/eno3ovb/) (23) writes: 

>*While you can configure GraphQL to work differently, as a practical matter they will always be POST requests. Which means all your browser/CDN/proxy caches that rely on GET being idempotent and POST not being now don't work by default. Everything is treated as a new request. You can set the client to do more smart caching, but that's literally solving a problem you created.*

[Scruffles360](https://www.reddit.com/r/reactjs/comments/bozrg1/graphql_vs_rest_putting_rest_to_rest/enokkzb/) (11) respoded: 

>*Apollo has a solution for this. I haven't tried it, but its called Dynamic Persisted Queries if you want to read up. Basically the client makes a GET call with a hash of the query and if it fails, falls back to POST. The next GET call will succeed and populate any proxy caches.*

#Data Fetching

Those guys also presented a different points of view on data fetching. In the [original article](https://www.imaginarycloud.com/blog/graphql-vs-rest/) writer describes an example of blog app with multiple authors and possibility of using GraphQL vs REST. 

[SwiftOneSpeaks](https://www.reddit.com/r/reactjs/comments/bozrg1/graphql_vs_rest_putting_rest_to_rest/eno3ovb/) (23) says: 

>*Everyone emphasizes the "over fetching" problem. I feel like that's a red herring outside of poorly designed services (and that sort of points out the flaw - don't expect GraphQL services from poor service developers to suddenly not be poor) It's easy to resolve if you put a service in front - GraphQL can be that service, but so can something else. The issue isn't over fetching vs not, it's having a central service AND solving the caching issues.*

[Scruffles360](https://www.reddit.com/r/reactjs/comments/bozrg1/graphql_vs_rest_putting_rest_to_rest/enokkzb/) (12) responded:

>*Over fetching is a real problem. When you have hundreds of clients, each calling your system in different ways, adding a property to a rest api causes massive inefficiencies. Many people point out using client-centric facades for their mobile client vs web for example, but that doesn't scale. My project is called by hundreds of clients, each asking for slightly different data in different ways.*

#Big Boys & GraphQL 

Everyone is interested in big companies like Facebook, Netflix and Coursera and their adaptation of GraphQL. In the [article](https://www.imaginarycloud.com/blog/graphql-vs-rest/) commented on Reddit we can find two main reasons as an author - states. The first comment presented was the most upvoted comment that I’ve found. 

- In the early 2010s there was a boom in mobile usage, which led to some issues with low-powered devices and sloppy networks. REST isn't optimal to deal with those problems;
- As mobile usage increased, so did the number of different front-end frameworks and platforms that run client applications. Given REST's inflexibility, it was harder to develop a single API that could fit the requirements of every client.

[Greulich](https://www.reddit.com/r/reactjs/comments/bozrg1/graphql_vs_rest_putting_rest_to_rest/ennt7ak/) (62) responded to article:   
 
>- This is so tangential as to be pointless. A different method of structuring your requests, does not render the network on which those requests better or worse.
- I think the author means endpoint rather than API, because any endpoint, no matter how many there are, is part of the API.
Assuming that is the case, why do we NEED only one endpoint?

[Scruffles360](https://www.reddit.com/r/reactjs/comments/bozrg1/graphql_vs_rest_putting_rest_to_rest/enohrog/) (16) responded to Greulich:

>*The first two points weren't worded well in the article, but are still valid. A REST API can either be generic and reusable or crafted specifically for a known client. In the first case, you aren't going to get good performance when you keep making calls back to the system for more data (especially on high-latency networks like we had on mobile 10 years ago). If you craft your API for a specific client, you obviously run into scalability problems.*
 
#Summary

There’s a lot to say or choose when picking the right comment to summarize the state of GraphQL. **Till today the most popular submissions on reddit are case studies of facebook or netflix yet they aren’t much commented**. 
This gives us already a good summary on reddit’s view on GraphQL. 
From a daily developer life I couldn’t skip what [Kdesign](https://www.reddit.com/r/reactjs/comments/bozrg1/graphql_vs_rest_putting_rest_to_rest/enn9sdf/) (36) wrote:  
> ###*GraphQL provides job security, that’s for sure*.

[Kollektiv](https://www.reddit.com/r/node/comments/bozsb1/graphql_vs_rest_putting_rest_to_rest/enng3ba/) (44) stated a great list of GraphQL issues:
>- Things like query rate limiting and credit estimation are difficult.
- The way type and dataloaders work, it's difficult to bind queries to the database layer in an efficient way by grouping queries without writing a full module for it.
- Validation only checks types so you still need some kind of JSON schema to do additional format validation.
- GraphQL queries only allow for left joins so recreating SQL like INNER JOINs together with filters quickly becomes awkward.
- The imposed pagination (connections) from frameworks like Relay are a mess.

Regarding my initial research on GraphQL [SwiftOneSpeaks](https://www.reddit.com/r/reactjs/comments/bozrg1/graphql_vs_rest_putting_rest_to_rest/eno3ovb/) (24) wrote: 
>I expect many of the "GraphQL is great" reports we are seeing is mainly because ANY new service is great - they only get klunky over time, as assumptions are violated and needs change and code changes accrue. This doesn't mean GraphQL won't be great - it just means I can't trust early reports too much.
 
And finally, I’ve chosen [Mando0975](https://www.reddit.com/r/node/comments/bozsb1/graphql_vs_rest_putting_rest_to_rest/enopzpk/ 
) (28) opinion to summarize this article:

>*Development should always be about picking the right tool for the job. GraphQL isn't always the right tool. REST isn't dead and GraphQL isn't going to kill it.*

###What's your experience with GraphQL?
 
 
 
 

 



The state of GraphQL by Reddit

#Intro

After periods of hard work from numbers of contributors, the React Native Core team is proud to publish of new version 0.60. This release touches important migrations for both Android and iOS and many more fixed issues. This article covers the top highlights. If you would like to check more detailed information, refer to the changelog. Finally, we should cheer for all contributors who helped improve this version.

#Accessibility

The new version added many enhancements to the accessibility APIs, like 
- Several missing roles have been added for various components.
- New Accessibility States API for web support in the future.
- AccessibilityInfo.announceForAccessibility is confirmed on Android.
-  Accessibility actions will include callbacks that deal with user-defined actions.
- iOS accessibility flags and reduce motion are supported on iOS.
- A clickable prop and an onClick callback are added for invoking actions via keyboard navigation.
Accessibility is a complicated science, but we hope these changes make it a bit easier to be available to disabled users (according to A11Y). Check latest React Native Open Source Update for more details.


#Start Screen
React Native's home screen has been refreshed!  This new "Hello World" will greet users to the ecosystem in a more welcoming, engaging way.

![](react060.png)

#AndroidX Support

With this release, React Native has been moved to AndroidX (Android Extension library). As this is a major change, developers need to transfer their native code and dependencies. The React Native community created a temporary solution for this called “jetifier”, an AndroidX transition tool in npm format, with a react-native compatible style.

Users are excited about the release and reflected it to be the most important RN release.

#CocoaPods by Default

React Native for iOS comes with CocoaPods by default. It is an application level dependency manager for Objective-C Cocoa projects and Swift. Developers are suggested to check the iOS platform code using the ‘xcworkspace’ file. Additionally, the Pod specifications of internal packages have been updated to make them compatible with the Xcode projects, which will assist with troubleshooting and debugging. Assume to make some straightforward changes to your Podfile as part of the upgrade to 0.60 to bring this support. 

#Lean Core project

The team started Lean Core project to bring the React Native repository to a manageable state. They have extracted WebView and NetInfo toward separate repo. In this version 0.60, the team has completed migrating them out of the React Native repo. Also, geolocation has been extracted based on the community feedback about the new App Store policy.

#Native Modules are now Autolinked
The CLI React Native team has offered significant advances to native module linking called auto-linking! Majority situations will not require the use of the react-native link. The team, at the same time,  overhauled the linking process in general. Unlink react-native any preexisting dependencies as mentioned in the docs.

#Upgrade Helper
The team of @lucasbento, @pvinis, @kelset, and @watadarkstar have built Upgrade Helper to simplify the upgrade process. Their goal was to help React Native users with brownfield apps or complicated customizations to see what's changed among versions. Try yourself and check updated upgrading docs.

![](upgradehelper.png)

#A word to Library Maintainers
 AndroidX changes will almost absolutely require updates to your library, so be sure to cover support. If you're ready to upgrade yet, consider checking your library with jetifier to confirm that users at build time can patch your library.

Check the autolinking docs to update your configs & readme. Depending on the previous integration of your library, you may also need to make some extra adjustments. 

#Thanks!
For more details check [changelog](https://github.com/react-native-community/releases/blob/master/CHANGELOG.md) 

 
 
 

 



Top features in React Native 0.60


NPM posted [javascript predictions](https://blog.graphqleditor.com/javascript-predictions-for-2019-by-npm) at the begging of this year with GraphQL as an essential point. They mentioned it twice and stated that you'd have to learn GraphQL this year. We are in the middle of 2019, and I’ve decided to write my predictions focused only on future of GraphQL! There’re five bullet points:

# Lee Byron & foundation will make GraphQL technology an industry standard.

In November 2018, GraphQL co-creator Lee Byron announced the creation of a GraphQL foundation. The GraphQL foundation from the start is supported by the Linux Foundation and aims to grow a neutral GraphQL ecosystem.

In March 2019 - The GraphQL Foundation declared a collaboration with the Joint Development Foundation to promote Open Source and Open Standards. With JDF, the GraphQL community can create and popularize open standards more quickly than ever.

In March 2019 - GraphQL Foundation was joined by IBM to grow open source adoption. At IBM they’ve created OASGraph (a GraphQL wrapper for REST APIs), and they see several opportunities to make GraphQL enterprise-level, for example in API Management.

![](ibm.png)

# Majority of the community will experience GraphQL.

Analyzing the latest editions of The State of Javascript survey, we can spot massive growth in desire to experience GraphQL. In the most recent 2018 edition, just 7.1% of the respondent has never heard of GraphQL (matching to 36.% in 2016, and 17.9% in 2017). The 62.5% people say that they would like to learn GraphQL when 20.4% applied it and would use again (it's a 200% growth matching to 2017), and only 1.3% have already given it a try, but would not use it again.

![](state.png)

The number of quality learning materials is growing thanks to the community-driven effort. Resources like How to GraphQL, Learn Hasura and Open GraphQL are free, easy to use, and top quality. Youtube is full of great videos - i.e., enterprise case studies from Shopify, GitHub, Medium, Docker, or Twitter at GraphQL Europe Conference. Facebook also recently posted a video on how they used GraphQL with a new version of their UI on their developer page.

https://www.youtube.com/watch?v=02mIJOxpoh0

#GraphQL events will boom all over the globe!

Right now on meetup.com, there are 124 GraphQL meetups with over 61229 members all over the world. Last year we had two major conferences and a lot of smaller full-day events. GraphQL Day has been organized three times in Toronto, Amsterdam, and southern Germany (Lake Constance). Apollo Day happened twice last year (once in New York as well in San Francisco). The most significant events for 2019 are already published:

- GraphQL Conf Berlin - June 20-21, 2019
- GraphQL Summit SF - 29-31 October, 2019

We already past two amazing events:

- GraphQL Day in Toronto (Feb)
- GraphQL Asia in India (April)

# GraphQL will be a dominant API Management tool.

From home automation to apps like Zapier, the tech industry is taking more investment in APIs than ever. Combine this with a desire to learn GraphQL, and we may well have something of a hurricane of adoption.

The number of big companies adopting GraphQL is growing. According to stackshare.io, there are more than 500 companies already adopted. At GraphQL Europe last year, several big players presented case studies of how they’re using GraphQL:

https://www.youtube.com/watch?v=lj41qhtkggU

https://www.youtube.com/watch?v=2It9NofBWYg

https://www.youtube.com/watch?v=GKxog_SETzs

https://www.youtube.com/watch?v=7m3h3PZ-x2w

Smaller tech companies are usually influenced by what the “big boys” in tech are doing…not because they may need to understand it to plug into those APIs. As a result, the ongoing adoption of GraphQL by big companies is a step towards ubiquity.

#Schema First will be the dominant approach

Schema first is the most popular approach with GraphQL. I believe it will remain this way as a dominant, cause of the few reasons.

- Faster Development: having a common, accepted specification means that development is much faster than traditional methods would allow. Frontend teams can instantly start building components regardless of backend components.

- Choosing a constrained schema forces teams to talk to one another and to work more efficiently and closely by updating specification.

- Cleaner Development means cleaner codebase, in which expected functionality is presented cleanly without duplication of code and effort.

- All of these interests come together to one bigger picture of why schema-first is a great idea – a single source of truth.

Schema-first design is easy, and the benefits gathered from its adoption are huge can’t be ignored. A single source of truth is remarkably powerful, and should be done at the start in a development process – and adopting schema-first design is the easiest way to establish such a source.


GraphQL Predictions 2019+

Web APIs are the motors that power most of our nowadays apps. For many years REST has been the principal architect for APIs, but in this article, we will investigate Django to GraphQL library! 

With REST APIs, you were regularly creating URLs for every object of data that's available. Thinking about REST API example for books - we'll have URLs for the books themselves, authors, prizes, characters and heroes ... it's already a lot! This could involve a lot of requests. 

With GraphQL you have one endpoint, ask what you want and get exactly that. It's is the top wanted technology according to The state of JS 2018 and every week community creates something interesting to help users adopt into new technology. [Yezyilomo](https://twitter.com/yezyilomo) came with the idea of python library that allows to turn Django Rest Framework into GraphQL like API.  Let's explore it more.

Django-restql is a library which turn your API made with Django REST Framework(DRF) into a GraphQL like API. With django-restql you will be able to: 

- Send a query to your API and get precisely what you need, nothing extra and nothing less.
- Get expected results, since you control what you get from the server.
- Control the data you get, not the server.
- Save the load of fetching unused data from the server.

The library works by choosing dynamically a subset of fields per DRF resource as specified by the request's `query` parameter.

[![](github.png)](https://github.com/yezyilomo/django-restql)  

Follow [Yezyilomo](https://twitter.com/yezyilomo) to get in touch with him! 

[![](twitter.png)](https://twitter.com/yezyilomo)

# Installing

```python
pip install django-restql
```

# Getting Started
Using **django-restql** is very simple, you just have to use the DynamicFieldsMixin when defining a View.

```python
from rest_framework import viewsets
from django.contrib.auth.models import User
from .serializers import UserSerializer
from django_restql import DynamicFieldsMixin

class UserViewSet(DynamicFieldsMixin, viewsets.ModelViewSet):
    queryset = User.objects.all().order_by('-date_joined')
    serializer_class = UserSerializer
```

A regular request returns all fields specified on DRF serializer, in fact **django-restql** doesn't handle this request at all:

```GET /users```

``` json
    [
      {
        "id": 1,
        "username": "yezyilomo",
        "email": "yezileliilomo@hotmail.com",
        "groups": [1,2]
      },
      ...
    ]
```

**django-restql** handle all GET requests with `query` parameter, this parameter is the one used to pass all fields to be included on a response. For example to select `id` and `username` fields from `user` model, send a request with a ` query` parameter as shown below.

`GET /users/?query=[["id", "username"]]`

```json
    [
      {
        "id": 1,
        "username": "yezyilomo"
      },
      ...
    ]
```

If a query contains nested field, **django-restql** will return its id or array of ids for the case of nested iterable field(one2many or many2many). For example on a request below `location` is a flat nested field(many2one) and `groups` is an iterable nested field(one2many or many2many).

`GET /users/?query=[["id", "username", "location", "groups"]]`

```json
    [
      {
        "id": 1,
        "username": "yezyilomo",
        "location": 6,
        "groups": [1,2]
      },
      ...
    ]
```

**django-restql** support querying both flat and nested resources, so you can expand or query nested fields at any level as long as your field is defined as nested field on a serializer. For example you can query a country and region field from location.

`GET /users/?query=[["id", "username", {"location": ["country", "region"]}]]`

```json
    [
      {
        "id": 1,
        "username": "yezyilomo",
        "location": {
            "contry": "Tanzania",
            "region": "Dar es salaam"
        }
      },
      ...
    ]
```

**django-restql** got your back on expanding or querying iterable nested fields too. For example if you want to expand `groups` field into `id` and `name`, here is how you would do it.

`GET /users/?query=[["id", "username" {"groups": [[ "id", "name" ]]}]]`

```json
    [
      {
        "id": 1,
        "username": "yezyilomo",
        "groups": [
            {
                "id": 2,
                "name": "Auth_User"
            }
            {
                "id": 3,
                "name": "Admin_User"
            }
        ]
      },
      ...
    ]
```

Turn your Django REST API into a GraphQL like API


[The stage of Javascript 2018 Survey](https://2018.stateofjs.com) was completed by 20k users and contains an analysis of what aspects people like & dislike about web technologies. I found React & GraphQL interesting since they're completing each other and stand out from surveys conclusions: 

> React is the most popular among front end frameworks.

![](react.png)

> GraphQL is the top most wanted technology to learn.

![](graphql.png)

Following that, I've combined popular boilerplates and starter apps to start using React with GraphQL. There's so much stuff on the internet that I've decided to split article two articles. 

#Agenda:

1. ReactQL
2. SaaS Boilerplate
3. React apollo todo app
4. Universal React Apollo app
5. Relay Skeleton

# [1. ReactQL](https://reactql.js.org/)

###Universal React+GraphQL starter kit: React 16, Apollo 2, MobX, Emotion, Webpack 4, GraphQL Code Generator, React Router 4, PostCSS, SSR.

![](reactql.png)

### Front-end stack

- [React v16.8](https://facebook.github.io/react/) (the one with [hooks](https://reactjs.org/docs/hooks-intro.html)!) for UI.
- [Apollo Client 2.5 (React)](http://dev.apollodata.com/react/) for connecting to GraphQL.
- [MobX-React-Lite](https://github.com/mobxjs/mobx-react-lite) for declarative, type-safe flux/store state management.
- [Emotion](https://emotion.sh/) CSS-in-JS, with inline `<style>` tag generation that contains only the CSS that needs to be rendered.
- [Sass](https://sass-lang.com/), [Less](http://lesscss.org/) and [PostCSS](https://postcss.org/) when importing `.css/.scss/.less` files.
- [React Router 4](https://reacttraining.com/react-router/) for declarative browser + server routes.
- [GraphQL Code Generator v1.1](https://graphql-code-generator.com/) for parsing remote GraphQL server schemas, for automatically building fully-typed Apollo React HOCs instead of writing `<Query>` / `<Mutation>` queries manually
- Declarative/dynamic `<head>` section, using [react-helmet](https://github.com/nfl/react-helmet).

### Server stack

- Built-in [Koa 2](http://koajs.com/) web server, with async/await routing.
- Full route-aware server-side rendering (SSR) of initial HTML.
- Universal building - both browser + Node.js web server compile down to static files, for fast server re-spawning.
- Per-request GraphQL store. Store state is dehydrated via SSR, and rehydrated automatically on the client.
- MobX for app-wide flux/store state, for automatically re-rendering any React component that 'listens' to state. Fully typed state!
- Full page React via built-in SSR component - every byte of your HTML is React.
- SSR in both development and production, even with hot-code reload.

### Real-time

- Hot code reloading; zero refresh, real-time updates in development.
- Development web server that automatically sends patches on code changes, and restarts the built-in Web server for SSR renders that reflect what you'd see in production.
- WebSocket `subscription` query support for real-time data (just set `WS_SUBSCRIPTIONS=1` in .env)

### Code optimisation

- [Webpack v4](https://webpack.js.org/), with [tree shaking](https://webpack.js.org/guides/tree-shaking/) -- dead code paths are automatically eliminated.
- Asynchronous code loading when `import()`'ing inside a function.
- Automatic per-vendor chunk splitting/hashing, for aggressive caching (especially good behind a HTTP/2 proxy!)
- Gzip/Brotli minification of static assets.
- CSS code is combined, minified and optimised automatically - even if you use SASS, LESS and CSS together!

### Styles

- [Emotion](https://emotion.sh/), for writing CSS styles inline and generating the minimal CSS required to properly render your components.
- [PostCSS v7](http://postcss.org/) with [next-gen CSS](https://preset-env.cssdb.org/) and automatic vendor prefixing when importing `.css`, `.scss` or `.less` files.
- [SASS](http://sass-lang.com) and [LESS](http://lesscss.org/) support (also parsed through PostCSS.)
- Automatic vendor prefixing - write modern CSS, and let the compiler take care of browser compatibility.
- Mix and match SASS, LESS and regular CSS - without conflicts!
- CSS modules - your classes are hashed automatically, to avoid namespace conflicts.
- Compatible with Foundation, Bootstrap, Material UI and more. Simply configure via a `.global.(css|scss|less)` import to preserve class names.

### Production-ready

- Production bundling via `npm run production`, that generates optimised server and client code.
- [Static compression](https://webpack.js.org/plugins/compression-webpack-plugin/) using the Gzip and [Brotli](https://opensource.googleblog.com/2015/09/introducing-brotli-new-compression.html) algorithms for the serving of static assets as pre-compressed `.gz` and `.br` files (your entire app's `main.js.bz` - including all dependencies - goes from 346kb -> 89kb!)
- Static bundling via `npm run build:static`. Don't need server-side rendering? No problem. Easily deploy a client-only SPA to any static web host (Netlify, etc.)

# [2. SaaS Boilerplate](http://codefoundries.com/products/UniversalRelayBoilerplate.html)

###SaaS Boilerplate + examples using React, Relay, GraphQL, Node.js, and Cassandra/Elassandra.

### Front-end stack

| **Technology** | **Description**|
|----------------|----------------|
| [found](https://github.com/4Catalyzer/found)                    | Extensible route-based routing for React applications. |
| [GraphQL](http://graphql.org/docs/getting-started/)             | A query language for describing the capabilities and requirements of data models for client‐server applications. |
| [JSS](http://cssinjs.org/)                                      | JSS is a more powerful abstraction over CSS. It uses JavaScript as a language to describe styles in a declarative and maintainable way. |
| [Material UI](http://www.material-ui.com/)                      | Library for implementing [Material Design](https://www.google.com/design/spec/material-design/introduction.html) in React. All user interface in this kit is built predominantly using Material UI components. |
| [React](https://facebook.github.io/react/)                      | The best library for building modern browser-based and mobile UIs. |
| [React Helmet](https://github.com/nfl/react-helmet)             | Reusable React component will manage all of your changes to the document head with support for document title, meta, link, script, and base tags. |
| [Relay](https://facebook.github.io/relay/)                      | A Javascript framework for building data-driven react applications. |

### Server stack

| **Technology** | **Description**|
|----------------|----------------|
| [Apache Cassandra](http://cassandra.apache.org/)                | The right choice when you need scalability and high availability without compromising performance. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data. Cassandra's support for replicating across multiple datacenters is best-in-class, providing lower latency for your users and the peace of mind of knowing that you can survive regional outages. |
| [Data Loader](https://github.com/facebook/dataloader)           | Generic utility to be used as part of your application's data fetching layer to provide a consistent API over various backends and reduce requests to those backends via batching and caching. |
| [Elassandra](http://www.strapdata.com/)                         | Elassandra Combines Cassandra And Elasticsearch In A Single Powerful Integrated Solution. URB works well with Elassandra. |
| [Express](https://expressjs.com)                                | Fast, unopinionated, minimalist web framework for Node.js |
| [express-cassandra](https://express-cassandra.readthedocs.io)   | Cassandra ORM/ODM/OGM for Node.js with optional support for Elassandra & JanusGraph |
| [Express GraphQL](https://github.com/graphql/express-graphql)   | A Node.js express library that allows the creation of GraphQL servers. |
| [JWT](https://jwt.io/)                                          | JSON Web Tokens is an industry standard [RFC 7519](https://tools.ietf.org/html/rfc7519) method for representing claims securely between two parties. |
| [Node.js](https://nodejs.org/en/)                               | Event-driven, non-blocking I/O runtime based on JavaScript that is lightweight and efficient. |
| [Winston](https://github.com/winstonjs/winston)                 | A logger for just about everything. |

### Development tools

| **Technology** | **Description**|
|----------------|----------------|
| [Babel](http://babeljs.io)                                      | Transpiles ESX to ESX and performs relay transformations. |
| [concurrently](https://www.npmjs.com/package/concurrently)      | Run multiple commands concurrently. |
| [ESLint](https://eslint.org)                                    | A fully pluggable tool for identifying and reporting on patterns in JavaScript. |
| [Flow](http://flowtype.org/)                                    | Static type checker, designed to find type errors in JavaScript programs. |
| [Husky](https://github.com/typicode/husky)                      | Git hooks for eslint and prettier. |
| [LocalTunnel](https://localtunnel.github.io/www/)               | Expose yourself to the world. |
| [Prettier](https://github.com/prettier/prettier/)               | Code formatter for javaScript. |
| [React Hot Loader](https://gaearon.github.io/react-hot-loader/)         | Allows tweaking of React components in real time. |
| [Webpack](http://webpack.github.io)                             | Bundles npm packages, application Java Script, CSS, images, etc. into bundles. |

# [3. React apollo todo app](https://github.com/k8s-platform-hub/react-apollo-todo-app)

###A simple todo app build on react using the graphql queries of hasura

This is a basic todo app built on react. The app uses Hasura for its backend, leveraging the following features of Hasura:

- Deploy the react app
- Hasura Authentication the Auth UI Kit
- Hasura Database
- GraphQL queries provided by Hasura

This project comes with the following custom microservice - a React TODO app made using GraphQL with Apollo Client

# [4. Universal React Apollo app](https://github.com/WeLikeGraphQL/universal-react-apollo-example)

###Universal React Apollo App (GraphQL) consuming

### Features

 - [GraphQL](http://graphql.org/) for fetching data! The most awesome part of the project!
 - Universal Rendering (Server Side Rendering)
 - ES6/ES2015 with [Babel](https://babeljs.io/)
 - React data container for the [Apollo Client](http://dev.apollodata.com/react/) 
 - Integrating predictable state container [Redux](http://redux.js.org) with Apollo
 - Hot reloading using [React-Hot-Loader](https://github.com/gaearon/react-hot-loader)
 - [Recompose](https://github.com/acdlite/recompose) as a React utility belt for higher order components
 - Development and production bundling by [Webpack](https://webpack.github.io)
 - [CSSNext](http://cssnext.io/): use of official W3C syntax of the future CSS
 - Transforming styles with JS plugins by [PostCSS](http://postcss.org/)
 - [Wow.js](http://mynameismatthieu.com/WOW/) for CSS animations
 - [Flexbox](https://css-tricks.com/snippets/css/a-guide-to-flexbox/) for resolving [layout fatigue](http://blog.karenmenezes.com/2014/apr/13/floats-inline-block-or-display-table-or-flexbox/) and making the app responsive (open the app in desktop, mobile, whatever...). Doesn't work on IE 9, but it should not be a problem nowadays. See [browsers usage](http://caniuse.com/usage-table).
 - [CSS Modules](https://github.com/css-modules/css-modules): say goodbye to global scope in CSS and most of conflicts
 - [Jest Snapshot Testng](https://facebook.github.io/jest/blog/2016/07/27/jest-14.html), some parts in [Enzyme](http://airbnb.io/enzyme/) and [Sinon](http://sinonjs.org/)
 - Linting both JS and CSS, respectively by: [ESLint](http://eslint.org/) and [Stylelint](http://stylelint.io/)

# [5. Relay Skeleton](https://github.com/fortruce/relay-skeleton)

###React, Relay, GraphQL project skeleton

This skeleton project is meant to scaffold a fullstack React, Relay, and GraphQL project. The skeleton uses webpack and gulp to manage the build and provide a great development experience. The frontend stack is React, and Relay. All React changes are automatically hot reloaded using react-hot-loader. Also, the backend server is automatically
restarted upon any changes using nodemon.

Both the server and frontend code are built and transpiled using webpack, while gulp is used primarily to start the webpack-dev-server and nodemon.

### Typical Usage

This skeleton was designed with a typical use case of having a backend api serve a React SPA. The skeleton automatically proxies all requests to `/graphql` thru the webpack-dev-server to the backend GraphQL server.

The frontend is automatically hot reloaded whenever you save a file. See
[react-hot-loader] for more details on how this works. It enables you to immediately see changes in React components without losing application state or having to reload your page!

The backend server is automatically restarted whenever you save a file.
If, for example, you modify the GraphQL schema, then the GraphQL server will be restarted to reflect the changes, the `schema.json` will be regenerated using an introspection query, and the frontend code will be recompiled to re-run `Relay.QL` queries through the `babel-relay-plugin`.







Getting started with React & GraphQL part I


I've decided to create a list of top resources to learn for two modern and trending technologies after checking results of [The stage of Javascript 2018 Survey](https://2018.stateofjs.com). The survey was completed by 20k users. React is, of course, the most popular among front end frameworks.

![](react.png)

GraphQL is the top wanted to learn technology.

![](graphql.png)

# Clients

- [Apollo GraphQL ](https://www.github.com/apollographql/apollo-client): A fully-featured, production ready caching GraphQL client for every UI framework and GraphQL server

![](apollo.png)

- [Relay Modern](https://facebook.github.io/relay/): A JavaScript framework for building data-driven React applications

![](relay.jpeg)

- [AppSync](https://github.com/awslabs/aws-mobile-appsync-sdk-js): JavaScript GraphQL library for Offline, Sync, Sigv4. includes support for React Native

![](appsync.jpeg)

- [FormidableLabs - urql](https://github.com/FormidableLabs/urql): A highly customizable and versatile GraphQL client for React

![](urql.jpeg)

- [Graphql.js](https://github.com/f/graphql.js):A Simple and Isomorphic GraphQL Client for JavaScripy

![](graphqljs.png)

# Tutorials

- React
  - [A complete React with GraphQL Tutorial](https://www.robinwieruch.de/react-with-graphql-tutorial/)
  - [A complete React with Apollo and GraphQL Tutorial](https://www.robinwieruch.de/react-graphql-apollo-tutorial/)
  - [React + Apollo Tutorial](https://www.howtographql.com/react-apollo/0-introduction/)
  - [React + Relay Tutorial](https://www.howtographql.com/react-relay/0-introduction/)

https://www.youtube.com/watch?v=XeALXh37WeU

https://www.youtube.com/watch?v=gF-peiFjG0o

https://www.youtube.com/watch?v=7giZGFDGnkc

https://www.youtube.com/watch?v=kXH2dbnHYA0

- React Native
  - [Code an App With GraphQL, React Native, and AWS AppSync: The API](https://code.tutsplus.com/tutorials/code-an-app-with-graphql-and-react-native--cms-30511)
  - [Code an App With GraphQL, React Native and AWS AppSync: The App](https://code.tutsplus.com/tutorials/code-an-app-with-graphql-react-native-and-aws-appsync-the-app--cms-30569)
  - [How to setup React Native + GraphQL + Relay Modern](https://codeburst.io/how-to-setup-a-react-native-graphql-relay-modern-a6a5f6c18353)
  - [Building Chatty](https://medium.com/react-native-training/building-chatty-a-whatsapp-clone-with-react-native-and-apollo-part-1-setup-68a02f7e11): A WhatsApp clone with React Native and Apollo

https://www.youtube.com/watch?v=33qP1QMmjv8

https://www.youtube.com/watch?v=nyE6shIRzxM

# Developer Tools

- [GraphQL Playground](https://github.com/graphcool/graphql-playground): Powerful GraphQL IDE built on top of GraphiQL

![](graphql-playground.png)

- [GraphiQL Online](https://graphiql-online.com): An online version of GraphiQL with a configurable endpoint and headers.

- [GraphQL Editor](https://graphqleditor.com): a visual graphql editor that allows you to visualize graphql schema and create fake backend out of schema.

- [apollo-tooling](https://github.com/apollographql/apollo-tooling): Tooling for development and production Apollo workflows

- [graphql-code-generator](https://github.com/dotansimha/graphql-code-generator): GraphQL code generator with flexible support for custom templates

![](gcg.png)

- [eslint-plugin-graphql](https://github.com/apollographql/eslint-plugin-graphql): Check your GraphQL query strings against a schema.

![](eslint.png)

- [Apollo Client Developer Tools](https://chrome.google.com/webstore/detail/apollo-client-developer-t): Chrome extension for Apollo Client developer tools

![](apollo-chrome.jpg)

- [Relay DevTools](https://chrome.google.com/webstore/detail/relay-devtools/oppikflppfjfdpjimpdadhelffjpciba): A Chrome Extension that creates a Relay tab in the developer tools interface for debugging apps in Chrome

![](relay-chrome.jpg)

- [Relay Devtools Electron](https://www.npmjs.com/package/relay-devtools): Standalone Relay DevTools App for debugging Relay outside Chrome


Best resources to learn React & GraphQL


This post is a summary of the best python libraries for GraphQL. Python in recent years is starting to be on the list of top programming language. GraphQL is emerging but very promising query language and execution engine tied to any backend service. 

Python is one of the most popular languages used in data science, machine learning and AI systems. GraphQL was introduced by Facebook as an alternative to REST and it's popular of flexibility on handling complex systems.

#Ariadne
Ariadne is a Python library for implementing GraphQL servers using schema-first approach. 

Ariadne is a Python library for implementing GraphQL servers.

- Schema-first: Ariadne enables Python developers to use schema-first approach to the API implementation. This is the leading approach used by the GraphQL community and supported by dozens of frontend and backend developer tools, examples, and learning resources. Ariadne makes all of this immediately available to your and other members of your team.
- Simple: Ariadne offers small, consistent and easy to memorize API that lets developers focus on business problems, not the boilerplate.
- Open: Ariadne was designed to be modular and open for customization. If you are missing or unhappy with something, extend or easily swap with your own.
Documentation is available here.

Features:

- Simple, quick to learn and easy to memorize API.
- Compatibility with GraphQL.js version 14.0.2.
- Queries, mutations and input types.
- Asynchronous resolvers and query execution.
- Subscriptions.
- Custom scalars and enums.
- Unions and interfaces.
- Defining schema using SDL strings.
- Loading schema from .graphql files.
- WSGI middleware for implementing GraphQL in existing sites.
- Opt-in automatic resolvers mapping between camelCase and snake_case.
- Build-in simple synchronous dev server for quick GraphQL experimentation and GraphQL Playground.
- Support for Apollo GraphQL extension for Visual Studio Code.
- GraphQL syntax validation via gql() helper function. Also provides colorization if Apollo GraphQL extension is installed.

####Installation

```
pip install ariadne
```

####Quickstart

The following example creates an API defining Person type and single query field people returning a list of two persons. It also starts a local dev server with GraphQL Playground available on the http://127.0.0.1:8000 address. Start by installing uvicorn, an ASGI server we will use to serve the API:

Start by installing uvicorn, an ASGI server we will use to serve the API:

```
pip install uvicorn
```

Then create an example.py file for your example application:

```python
from ariadne import ObjectType, QueryType, gql, make_executable_schema
from ariadne.asgi import GraphQL

# Define types using Schema Definition Language (https://graphql.org/learn/schema/)
# Wrapping string in gql function provides validation and better error traceback
type_defs = gql("""
    type Query {
        people: [Person!]!
    }

    type Person {
        firstName: String
        lastName: String
        age: Int
        fullName: String
    }
""")

# Map resolver functions to Query fields using QueryType
query = QueryType()

# Resolvers are simple python functions
@query.field("people")
def resolve_people(*_):
    return [
        {"firstName": "John", "lastName": "Doe", "age": 21},
        {"firstName": "Bob", "lastName": "Boberson", "age": 24},
    ]


# Map resolver functions to custom type fields using ObjectType
person = ObjectType("Person")

@person.field("fullName")
def resolve_person_fullname(person, *_):
    return "%s %s" % (person["firstName"], person["lastName"])

# Create executable GraphQL schema
schema = make_executable_schema(type_defs, [query, person])

# Create an ASGI app using the schema, running in debug mode
app = GraphQL(schema, debug=True)
```



#Strawberry


Strawberry is a new GraphQL library for Python 3, inspired by dataclasses. An initial version of Strawberry has been released on GitHub. Strawberry was created by @patrick91 who is also an organizer of @pyconit. It was originally announced during Python Pizza Berlin.


![](https://thepracticaldev.s3.amazonaws.com/i/jrow1cc45mi8n650eiba.png)

https://strawberry.rocks/

####Installation

```
pip install strawberry-graphql
```

####Getting Started

Create a file called app.py with the following code:

```python
import strawberry


@strawberry.type
class User:
    name: str
    age: int


@strawberry.type
class Query:
    @strawberry.field
    def user(self, info) -> User:
        return User(name="Patrick", age=100)


schema = strawberry.Schema(query=Query)
```

This will create a GraphQL schema defining a User type and a single query field user that will return a hard-coded user.

To run the debug server run the following command:

```
strawberry run server app
```

Open the debug server by clicking on the following link: http://0.0.0.0:8000/graphql

This will open a GraphQL playground where you can test the API.

#Graphene

Graphene is a Python library for building GraphQL schemas/types fast and easily.

- Easy to use: Graphene helps you use GraphQL in Python without effort.
- Relay: Graphene has builtin support for Relay.
- Data agnostic: Graphene supports any kind of data source: SQL (Django, SQLAlchemy), NoSQL, custom Python objects, etc. We believe that by providing a complete API you could plug Graphene anywhere your data lives and make your data available through GraphQL.

####Integrations

Graphene has multiple integrations with different frameworks:

- Django - graphene-django
- SQLAlchemy - graphene-sqlalchemy
- Google App Engine - graphene-gae
- Peewee - In progress (Tracking Issue)

Also, Graphene is fully compatible with the GraphQL spec, working seamlessly with all GraphQL clients, such as Relay, Apollo and gql.


####Installation

For instaling graphene, just run this command in your shell

```
pip install "graphene>=2.0"
```

####Examples

```python
Here is one example for you to get started:

class Query(graphene.ObjectType):
    hello = graphene.String(description='A typical hello world')

    def resolve_hello(self, info):
        return 'World'

schema = graphene.Schema(query=Query)
```

Then Querying graphene.Schema is as simple as:

```python
query = '''
    query SayHello {
      hello
    }
'''
result = schema.execute(query)
```

Top 3 python libraries for graphql


##Introduction

It's hard to choose what to learn when you're starting your journey as a frontend developer. There're plenty of sources, courses, tutorials or frameworks to choose from. You might get confused starting researching all above. One practical approach is a craftsman road where you learn the process by tools. I've created a list of top tools for junior frontend developer and explained why you should use them. Follow me to get more tutorials!

#GitHub

GitHub is a web-based hosting service for version control using Git. It offers all of the distributed version control and source code management (SCM) functionality of Git as well as adding its other features. It provides access control and several collaboration features such as bug tracking, feature requests, task management, and wikis for every project. Github is also a great community where you find and collaborate a lot of open source projects. 

![](https://github.githubassets.com/images/modules/explore/social.jpg)

#Chrome Dev Tools

It's a set of developer tools built into the Chrome browser. With DevTools you can access the internals of any web application, see how it performs on different screen sizes and change any page. You can edit pages real-time and diagnose problems quickly. It ultimately helps you build better websites and faster. Additional network tools can help you optimise your loading flows while a timeline gives you a knowledge of what the browser is doing at the moment.

![](https://developers.google.com/web/tools/chrome-devtools/images/panels/elements.png)

#React Developer Tools

React is a popular javascript framework among web development last years.  However, Google Chrome Developer tools cannot examine the Dom as React Components. Don’t be confused; there is a Chrome Extension called React Developer Tools that allows you to get into the nitty-gritty of how data is passed through components.

![](https://camo.githubusercontent.com/3fd1137b6b254da8c5596acf7b8583246fd76e29/687474703a2f2f692e696d6775722e636f6d2f6a5969655271692e706e67)

#Pixel Perfect 

This chrome extension helps develop your websites with per-pixel sharpness! It's for web developers and markup designers. PerfectPixel allows developers to put a half-transparent image overlay over the top of the developed HTML and perform pixel perfect comparison among them.

![](http://www.welldonecode.com/img/screenshot.jpg)

#Visual Code Editor

Visual Studio Code is the number one code editor for building and debugging modern web and cloud applications. It’s very customizable, has built-in git, massive list of integrations, powerful autocomplete and debugging features. It’s a powerful multilanguage IDE, super fast and simple. Also, free an open source. 

![](https://code.visualstudio.com/assets/docs/getstarted/userinterface/hero.png)

#Codepen

Codepen it’s amazing web-based and community-driven code editor. You can see right away results of code. It’s a magic place for designers and front end developers where people are sharing and commenting on their front end skills.  It’s a great source of inspiration for new ideas and ways to code.  The editor is used for: prototyping new ideas, instant bug testing, sending clients things to look at, evaluating potential hires and finding inspiration. 


#GraphQL and GraphQL Editor

GraphQL is a query language for APIs. It's very trendy nowadays and recognised by leading tech organisations. GraphQL Editor makes understanding GraphQL schema a lot easier. Plan it out by linking visual blocks and our editor will transform them into a code! Create fake backend out of GraphQL, and you could power up your application.

![](https://thepracticaldev.s3.amazonaws.com/i/l712vn5w612l0qp2q6na.png)(https://app.graphqleditor.com/demo/blog-sample)

#Npm

It's a package manager for JS. It helps to find packages of reusable code and compile them in new ways. It has over 470,000 free code packages in the database to be used by you. This web dev tool is a command-line utility for interacting with a repository that aids in the package. It also has team features with your private namespace.  

![](https://upload.wikimedia.org/wikipedia/commons/thumb/d/db/Npm-logo.svg/1200px-Npm-logo.svg.png)

#Webpack

It's a bundler for javascript and friends which packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through "loaders", modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, CoffeeScript, LESS, ... and your custom stuff.

![](https://scotch-res.cloudinary.com/image/upload/dpr_3,w_350,q_auto:good,f_auto/media/5000/UsIrFFPwStmuuAaidk7k_Screen%20Shot%202017-11-30%20at%204.28.18%20AM.png)

#Figma

Figma is a design app but very trendy and good to collaborate with designers. Every Figma file has Code Mode where a developer can inspect design files. When designer share view-only files with the developer, he will have access to Code Mode where they can examine, comment, and export without having full edit access to the files.

![](https://images.ctfassets.net/1khq4uysbvty/QsIb6oxyNLMrTAkoSAkGX/b722f50d920244dfdf1d20341497924b/Figma_Home_OG.png)

#Web.dev

Every web project needs proper feedback and testing. With this tool, you can check how your website performs according to modern standards. You can measure things: performance, PWA status, accessibility or SEO. Also, you can practice skills: like load speed, network resilience or data security. Check how your website performs over time, and keep track as you learn on your schedule. 

![](https://web.dev/images/social.png)

#Terminal

A terminal is a text-based interface you can type your commands in. A shell takes these commands and tells the operating system to execute them. Getting familiar with tools like Git from the terminal gives you more power and flexibility over GUI. In the end, a GUI is a graphical shell in front of a command-line tool. Being “closer to the metal”, it can also help you to get out of trouble in case a GUI is stuck or messed up. It's an essential productivity tool in a developer's arsenal. 

![](https://help.apple.com/assets/5B9190B30946221279C5A608/5B9190B30946221279C5A60F/en_US/dfa4eabaceda47fa30991ecfd2c28d7c.png)

#Others

- Caniuse.com - are you worried about browser compatibility for some cutting edge ideas? Try this site and see if you can use it. 
- StackOverflow - that site doesn't need explanation ;)
- TinyPNG- Advanced lossy compression for PNG images
- Compressor.io - another image compression tool
- Notion.so -  recording notes, specs, product owner feedback and planning.
- Postman - when working with REST APIs.

Top tools for a junior frontend developer


###Introduction
This article covers the basic introduction and advantages of GraphQL and [GraphQL Editor](https://app.graphqleditor.com) for business users. 

###What is GraphQL?
Have you heard tech terms like frontend, backend or API? Well, those are essential components of every web application. The front end is what you see; the backend is the hidden engine that powers every action of your visual interface. API is a connector in between those two which allows them to communicate. It’s a set of clearly defined methods, definitions and routines how apps communicate with each other.

>#GraphQL is a query language to describe an API

So far REST API was the most popular standard of creating API’s. GraphQL was introduced in 2015 by Facebook as an alternative to REST. Back then It wasn’t just an experiment - it was already in production inside facebook mobile apps since 2012. Just after public release, It became extremely popular, and around that time many companies were working on similar solutions. This technology started to gain attention since it can be used with many other languages and there’re many ready to go libraries to most popular styles. Right now according to Stackshare there’re nearly 2k companies using it. Early adopters included Coursera, Github, ProductHunt, Yelp or Twitter.

![Design Schema](design_schema2.gif "Design Schema")

###Visual tool for app prototyping
GraphQL from its core name is something more than new API standard. Some users describe it as a tool for the specification of new solutions. Thanks to graph sourcing we can visualise existing database schema and show existing solutions on the screen. From the other side, you can prototype new business applications. With visualised graph possibilities are endless. Think about the potential advantages of giving access to internal systems for a business manager at company meeting or speeding up onboarding of new developers. Some companies have significant and complex systems; therefore it slows down digital transformation. Check below how Github’s schema in action.

![Github](github.gif "Github")

###Easy to learn
GraphQL is easy to learn. You have to learn 15-20 definitions to start understanding it. Not joking! Check below a list of the most important ones. Don’t get overwhelmed by too many definitions at the start. Start by checking object type - in definition is a group of fields.

![add node type](add_node_type.gif "add node type")

Basic type definitions

- Type - it's a group of object.
- Input - it's used to create or update objects in database.
- Scalar types - add characteristics for type object.
- Interface - it's a type object that has certain set of the same fields.
- Union - mostly used for search purpose.
- Enum - specific scalar user mostly when dealing with allowed values.

![add node input](add_node_input.gif "add node input")

Graphql is strongly typed, which means that each definition must have a particular type. The Type System comes with the help, which provides several possibilities for defining elements of our API. Another exciting thing about strongly typed is the visual part.

###Communication with all developers
The most important feature of GraphQL for business users is that it’s language agnostic. It’s not created to work with a specific technology. It’s a query language with its own rules which for most popular programming languages. There’re many supportive libraries on the internet for C#/.NET, PHP. Javascript, Java, Python, Ruby and many more. Therefore learning a little bit of schema definition language, you’re able to communicate with all kind of developers. 

###Flexibility
GraphQL is flexible and efficient. In traditional REST approach developers had to send many requests to show data on one screen. It’s not super efficient when it comes to mobile apps - it slows them down and needs more internet data transfer. GraphQL allows a user to create only one endpoint and get exactly required data. Thanks to technology introduced by Facebook engineers communication between client and a server is better optimised.

That’s the power of GraphQL - flexibility. You don’t need to create endpoints for different screens. Various clients can use a once defined schema in a way that they need to.

![graphql vs rest](graphql_vs_rest.png "graphql vs rest")






Is GraphQL Editor a right tool for business users?


Let's explore second and last part of our tutorial of schemas and types

###Interfaces

Like many type systems, GraphQL supports interfaces. An interface exposes a specific set of fields that a type must include implementing the interface. For example, you could have an interface Actor that represents any humankind character in the Movies:

```graphql
interface Actor {
  id: ID!
  name: String!
  friends: [Actor]
  appearsIn: [Movie]!
}
```

This means that any type that implements Actor needs to have these exact fields, with these arguments and return types. Look at the example:

```graphql
type Arnold implements Actor {
  id: ID!
  name: String!
  friends: [Character]
  appearsIn: [Movie]!
}

type James implements Actor {
  id: ID!
  name: String!
  friends: [Character]
  appearsIn: [Movie]!
  wonOscar: Boolean!
}
```
You can see that both of these types have all of the fields from the Actor interface, but also bring in extra fields like wonOscar which is specific to this Actor.

### Union

An interesting mechanism is the Union type, which allows you to represent a group of objects that do not have the same fields. An excellent example is a query to a search engine that can search both the title of the Movie and the Actor's name. Union types are very similar to interfaces, but they don't get to specify any common fields between the types.

```graphql
union SearchResult = Movie | Actor
  
type Query {
  search(text: String!): SearchResult
}

query {
  search(text: "Park") {
    ... on Book {
      title
    }
    ... on Author {
      name
    }
  }
}
```
```graphql
  {
      "data": {
        "search": [
          {
            "name": "Jurassic Park",
          },
          {
            "name": "Jessica Park",
          }
        ]
      }
    }
```
Wherever we return a SearchResult type in our schema, we might get a Movie or an Actor. Note that members of a union type need to be concrete object types; you can't create a union type out of interfaces or other unions.

### Input type

To modify or create new elements in the application via GraphQL, a particular type input was created, which behaves very much like a regular object, with the difference that during the declaration input is used instead of the keyword type. This is particularly valuable in the case of mutations, where you might want to pass in a whole object to be created. In the GraphQL schema language, input types look exactly the same as regular object types, but with the keyword input instead of type:

```graphql
schema {
  query: Query
  mutation: Mutation
}
  
type Mutation {
  createActor(input: ActorInput): Actor
  updateActor(id: ID!, input: ActorInput): Actor
}
  
input ActorInput {
  name: String!
  appearsIn: [Movie]!
}
```

In the above example, you can observe that the createActor and updateActor actions expect the ActorInput object as an argument and return the Actor object. For the declared scheme, creating a new book requires a similar action:

### Lists and Non-Null 

In your query variable declarations, you can apply additional type modifiers that affect the validation of those values.  In the example below we're using a String type and marking it as Non-Null by adding an exclamation mark, ! after the type name. This means that our server regularly requires to return a non-null value for this field, and if it ends up getting a null value that will trigger a GraphQL execution error, letting the client know that something has gone wrong.

```graphql
type Actor {
  name: String!
  appearsIn: [Episode]!
}
```
The Non-Null type modifier can also be used when defining arguments for a field, which will cause the GraphQL server to return a validation error if a null value is passed as that argument, whether in the GraphQL string or in the variables.

Lsts work similarly: We can use a type modifier to mark a type as a List, which means that this field will return an array of that type. In the schema language, it's by wrapping the type in square brackets, [ and ]. It works the same for arguments, where the validation step will expect an array for that value. The Non-Null and List modifiers can be combined. 

```
myField: [String!]
```
```
myField: null // valid
myField: [] // valid
myField: ['a', 'b'] // valid
myField: ['a', null, 'b'] // error
```
```
myField: [String]!
```
```
myField: null // error
myField: [] // valid
myField: ['a', 'b'] // valid
myField: ['a', null, 'b'] // valid
```




GraphQL Tutorial - Schemas and types part 2


In this article, I'll cover a general introduction to backend development without a deep dive into the code. I'll provide you with languages and frameworks that you can learn and use a little bit of graphql as an example. If you're looking for more technical tutorials, please check other posts on our blog or other resources. 

If you're not a software developer terms like backend or front end development can give you a headache. Adding to that a long list of different tools, languages and frameworks it's confusing where to start.  However, there's good news - you don't need to learn coding to understand the basics. It's helpful to know the basics of typical tech stack whether any developer is working around you.

To help you understand more from backend development, we've divided this articles into few sections.

### What is backend?

Imagine a typical web application like Facebook or your online banking service - what comes to your mind? You have the visual part which is designed for human interaction and something behind. That's the easiest way we can describe front end (the visible part - colours, animations, layout, and all the stuff that you can experience) The backend is the internal engine of the application which includes things like the server, the database.

![https://dribbble.com/shots/5455567-Front-end-vs-Back-end](https://cdn.dribbble.com/users/1971934/screenshots/5455567/ezgif.com-resize.gif)

The backend is often described as a "server-side" opposite to "client-side" or "browser side" where the client sends a request to the backend by clicking on a specific button. The backend's the machinery that works silently behind the scenes.

![](https://i.imgur.com/UqIwgQL.jpg)

It's is essential to know that over last ten years that divide has changed a lot due to growing capabilities of Javascript and it's frameworks which can do more on the front end than before. This language can be both used on the front end and the backend by specific frameworks. We'll get back to that later.  

![](https://media3.giphy.com/media/4MwP0n2iPbkcM/giphy.gif)

A modern backend is a mix of the server, APIs, databases and operating systems that power an application's front end. Every app can use very different tools whether it’s the use of cloud-based servers and data warehouses, containerization with a service like Docker, APIs to replace more complex processing or Backend-as-a-Service providers. 

To start things, we’ll break the server side down into four main components: the server, the database, the operating system, and the software. In the next chapters, we'll explain more about each of these components of the backend.

### Servers

When you type any domain into a web browser that means you type server address. If you go deeper into specific sections of that website, you'll see that URL is extended with additional details. This include folder path, subdirectory locations and specific file names. Let's have a look at Google's logo. This particular address contains precise information on where exactly on the server file exists.

```
https://www.google.pl/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png
```

As part of other components, the server is the heart of the system. It could be located locally on your computer or in a modern way in the cloud. You can imagine cloud as a group of connected computers. That network of computers can run various tasks including file storage, security and encryption, databases, email, and web services. The cheapest option of cloud servers is a shared virtual machine, a computer which are running many servers at the same time. More expensive one are dedicated machines which you can rent according to your needs. Shared servers are created in the process of virtualisation. 

![](https://media0.giphy.com/media/xTaWnRA9hNaYkYgGLS/giphy.gif?cid=3640f6095c59a35d3632546277261fcc)

The primary goal of virtualisation is to manage workloads by transforming traditional computing to make it more scalable. In operating system-level virtualisation, it is possible to run multiple operating systems on a single piece of hardware. Virtualisation technology involves separating the physical hardware and software by emulating device using the software.

One of a popular lightweight alternative to virtualisation is containerization. Imagine catching application into a virtual container with its environment. It provides benefits of loading an application onto a virtual machine, as the application can be run on any suitable physical computer without any worries. Containerization has gained recent fame with the open-source technology called Docker. Using containers, you can easily migrate apps between servers. 

![](https://media1.giphy.com/media/6AFldi5xJQYIo/giphy.gif)

As you’ve got the basics about on-site servers, expand your knowledge with a look at virtualisation, how servers get provisioned to house multiple apps, and containerization, another way servers provision their operating systems out to house compartmentalised applications.

### Databases

A database is storage of a collection of data. That may sound overly naive, but it pretty much sums up what any database is. A database could be as primary as a text file with a list of names. Alternatively, it could be as complex as a large, relational database management system, complete with in-built tools to help you maintain the data.

Any time you request something from a website or search a place to stay at Airbnb your front end sends a request to the database and creates a response. The data is transmitted back to the website, and you see the result of your actions. You can also update or edit data in your database from the visual interface. Imagine uploading pictures to Facebook or adding a description to your products in CMS.

A Database Management System (DBMS), is a tool that enables the management and creation of databases. Today most database systems are referred to as a Relational-DBMS, because of their capacity to store related data across multiple tables. When more than two tables contain related data, they have a relationship. You design your database in a way that defines which tables will have to be related. Most popular relational DBMS include Microsoft Access, SQL Server, MySQL.

Alternatively, to related databases we have NoSQL. It's a comprehensive term that doesn't describe any particular database type. It's a group of databases that don't fit into a relational model. Let's explore some examples: 
- Column store database,
- Graph databases that use a graphical model,
- Document store database that uses a document-oriented model,

### Backend developer

Back-end developers work with front-end developers by giving the outward facing web app elements of server-side logic. In other words, back-end dev's create the business logic to make the web app work correctly, and they achieve this through the use of back end scripting languages. Some of the regular responsibilities include: 

- Writing server-side code
- Interacting with database
- Writing code to communicate with the database 
- Deploying the system online so the app can be usable 
- Maintaining security of the code
- Maintaining code to be optimised to handle large traffic volume
- Integrating server-side logic with front end
- Design and implementation of data storage solutions
- Building reusable code and libraries for future use
- Writing documentation for ease of use for new developers


Back-end developers usually work in groups or teams. Within larger organisations, there can be both back-end and front-end engineers, which can include engineers with specific roles like REST API developers or quality assurance or architects.


### Backend  & languages

Back-end developers can learn a variety of languages and frameworks depending on the type of app they’re developing, its specific processing specifications, and what other components already exist on the back end.

Languages will differ in file size, speed, adaptability, how many lines of code required, and the style of coding. Some back-end scripting languages are object-oriented, a method of programming that bundles properties and functions within objects. Different languages may be compiled rather than interpreted, something that affects load speed, readability, and processing power needed to run the app.

Most of the sites are built on PHP, making it one of the most common back-end languages. However, there are plenty of others to choose from. You may want to use the processing power of Python for a data-driven site, or leverage the speed of lightweight languages like Ruby for quick prototyping. It’s up to you and your developers, and every language has its pros and typical applications.

Take a look at a few of the other big hitters in back-end programming, like:

- Java
- C# and C++
- .NET
- Perl
- Scala
- Node.js (and JavaScript)

Code academy - backend development

Let's explore the next stage of our [GraphQL](https://graphqleditor.com/) tutorial -  type system and how it defines what data can be queried. Since GraphQL can be used with any backend programming language, we'll focus mostly on general the concepts.


## Type language 
GraphQL can be used with any language. Since we can't rely on any specific language syntax, to talk about GraphQL schemas, we'll define our simple language. We'll use the "GraphQL schema language" - it's similar to the query and allows us to talk about GraphQL schemas in an agnostic way

## Type system
GraphQL query language is basically about selecting fields on objects. Let's check that on our example:

```graphql
{
  Actor {
    name
    appearsIn
  }
}
```
```graphql
{
  "data": {
    "hero": {
      "name": "Arnold",
      "appearsIn": [
        "TERMINATOR",
        "CONAN",
        "PREDATOR"
      ]
    }
  }
}
```

1. We start with a unique "root" object and select actor field on that
2. For the object returned by actor, we select the name and appearsIn fields

GraphQL query closely matches the result; therefore you can predict what the query will respond without knowing much about the server. But it's helpful to have an accurate description of the data we can ask for - what fields can we choose? What fields are possible on those sub-objects? What kinds of things might they respond? 

Every GraphQL service describes a set of types which ultimately represent the set of potential data you can query on that service. Then, when queries come in, they are validated and executed against that schema.

## Object types and fields 
The essential elements of a GraphQL schema are object types, which describe a kind of object you can fetch from your service, and what fields it has. In the GraphQL schema language, we might represent it like this:

```
type Actor {
  name: String!
  appearsIn: [Movie!]!
}
```
The language is pretty simple, but let's go over it so that we can have a shared dictionary:

1. Actor is a GraphQL Object Type, meaning it's a type with some fields. Most of the types in your schema will be object types.
2. name and appearsIn are fields on the Actor type. That means that name and appearsIn are the only fields that can appear in any part of a GraphQL query that operates on the Actor type.
3. String is one of the built-in scalar types - these are types that resolve to a single scalar object, and can't have sub-selections in the query. We'll go over scalar types later.
4. String! means that the field is non-nullable, saying that the GraphQL service promises always to give you value when you ask. In the type of language, we'll serve those with an exclamation mark.
5. [Movie!]! represents an collection of Movie objects. Since it is also non-nullable, you can regularly expect an array (with zero or more items) when you ask the appearsIn field. And since Movie! is also non-nullable, you can always expect every item of the array to be an Movie object.
Now you know what a GraphQL object type looks like, and how to read the basics of the GraphQL.

## The Query and Mutation types
Most types in your schema will be standard object types, but two types are special within a schema:

```
schema {
  query: Query
  mutation: Mutation
}
```
Every GraphQL service has a query type and don't need to have a mutation type. These types are the same as a regular object type, but they are unique because they define the entry point of every GraphQL query.

```
query {
  hero {
    name
  }
  droid(id: "2000") {
    name
  }
}
```

```
{
  "data": {
    "hero": {
      "name": "R2-D2"
    },
    "droid": {
      "name": "C-3PO"
    }
  }
}
```
That means that the GraphQL service needs to have a Query type with hero and droid fields:

```
type Query {
  hero(episode: Episode): Character
  droid(id: ID!): Droid
}
```
Mutations work similarly - you define fields on the Mutation type, and those are possible as the root mutation fields you can call in your query.

It's essential to master that other than the special status of being the "entry point" into the schema, the Query and Mutation types are the same as any other GraphQL object type, and their fields act precisely the same way.

## Scalar types 
A GraphQL object type has a name and fields, but at some level those fields have to resolve to some particular data. That's where the scalar types come in: they represent the leaves of the query.

In the next query, the name and appearsIn fields will choose to scalar types. We know this because those fields don't have any sub-fields - they are the leaves of the query.

```graphql
{
  Actor {
    name
    appearsIn
  }
}
```
```graphql
{
  "data": {
    "hero": {
      "name": "Arnold",
      "appearsIn": [
        "TERMINATOR",
        "CONAN",
        "PREDATOR"
      ]
    }
  }
}
```

GraphQL comes with a set of default scalar types out of the box:

- Int: A signed 32‐bit integer.
- Float: A signed double-precision floating-point value.
- String: A UTF‐8 character sequence.
- Boolean: true or false.
- ID: The ID scalar type represents a unique identifier, often used to refetch an object or as the key for a cache. The ID type is serialized in the same way as a String; however, defining it as an ID signifies that it is not intended to be human‐readable.

In most GraphQL service implementations, there is also a way to specify custom scalar types. For example, we could define a Date type:

```
scalar Date
```
Then it's up to our implementation to define how that type should be validated serialized or deserialized. For example, you could specify that the Date type should always be serialized into an integer timestamp, and your client should know to expect that format for any date fields.

## Enumeration types 
Also called Enums, enumeration types are a special kind of scalar that's limited to an appropriate set of allowed values. This allows you to:

Validate that any arguments of this type are one of the allowed values
Communicate through the type system that a field will always be one of a finite set of values

```
enum Movie {
  TERMINATOR
  CONAN
  PREDATOR
}
```
It means that anywhere we use the type Movie in our schema, we expect it to be precisely one of TERMINATOR, CONAN, or PREDATOR.

Note that GraphQL service implementations in different languages will have their own programming-specific way to deal with enums. In languages that support enums as a first-class citizen, the application might take advantage of that; in a language like JavaScript with no enum support, these values might be internally mapped to a set of integers.

GraphQL Tutorial - Schemas and Types Part 1


## Fields 

At its purest, GraphQL is about asking for specific fields on objects. Let's start by looking at a very easy query:

```graphql
{
  user {
    name	
  }
}
```
```graphql
{
  "data": {
    "user": {
      "name": "James"
    }
  }
}
```

You can see quickly that the query has the same shape as an output. This is fundamental to GraphQL, because you always get back what you expect. 

The field name returns a String type. The query above is interactive. That means you can change it as you like and see the new result. Try adding an appears. In field to the user object in the query, and see the new result.

In the previous case, we just asked for the name of our user which returned a String, but fields can also commit to Objects. In that case, you can get a sub-selection of fields for that object. GraphQL queries can cross related objects and their fields, allowing customers to get lots of associated data in one request, instead of making many round trips as one would need in a classic REST architecture.

```graphql
{
  player {
    name
    # You can add comments!
    friends {
      name
    }
  }
}
```
```graphql
{
  "data": {
    "player": {
      "name": "James",
      "friends": [
        {
          "name": "Adam"
        },
        {
          "name": "Paul"
        },
        {
          "name": "Chris"
        }
      ]
    }
  }
}
```

Note that in this sample, the friends field returns an collection of items. GraphQL queries look the same for both individual items or lists of items, however we understand which one to expect based on what is indicated in the schema.

## Aliases

If you have a fine eye, you may have discovered that, since the result object fields match the name of the field in the query but don't include arguments, you can't directly query for the same field with various arguments. That's why you require aliases - they let you rename the result of a field to anything you want.

```graphql
{
  bluePlayer: player(team: BLUE) {
    name
  }
  blackPlayer: player(team: BLACK) {
    name
  }
}
```
```graphql
{
  "data": {
    "bluePlayer": {
      "name": "Superman"
    },
    "blackPlayer": {
      "name": "Batman"
    }
  }
}
```

In the previous instance, the **player** fields would have clashed, but since we can alias them to different names, we can get both results in one request.

## Arguments

If the only thing we could do was traverse objects and their fields, GraphQL would already be a beneficial language for data fetching. But when you add the ability to pass arguments to fields, things get much more impressive.

```graphql
{
 player(id: "1") {
    name
    weight
  }
}
```
```graphql
{
  "data": {
    "player": {
      "name": "James",
      "weight": 80
    }
  }
}
```

In practice like REST, you can only pass an individual set of arguments - the query parameters and URL segments in your request. However, in GraphQL, every field and a nested object can get its set of cases, causing GraphQL a total replacement for doing many API fetches. You can even pass arguments into scalar fields, to complete data transformations once on the server, alternately of on each client separately.

```graphql
{
 player(id: "1") {
    name
    height(unit: CM)
  }
}
```
```graphql
{
  "data": {
    "player": {
      "name": "James",
      "height": 180
    }
  }
}
```


Arguments can be of many various types. In the above sample, we have adopted an Enumeration type, which describes one of a finite set of options (in this case, units of length, either METER or FOOT). GraphQL comes with a default set of types, but a GraphQL server can also declare its own custom types, as long as they can be serialized into your transport format.

## Fragments

Let's say we had a moderately complex page in our app, which let us look at two players along with their friends. You can imagine that such a query could quickly get difficult because we would need to repeat the fields at least once - one for each side of the comparison.

That's why GraphQL covers reusable units called fragments. Fragments let you create collections of fields, and then add them in queries where you need to. Here's a sample of how you could solve the above situation using fragments:

```graphql
{
  leftComparison: player(team: BLUE) {
    ...comparisonFields
  }
  rightComparison: player(team: Black) {
    ...comparisonFields
  }
}
fragment comparisonFields on Character {
  name
  friends {
    name
  }
}
```
```graphql
{
  "data": {
    "leftComparison": {
      "name": "Superman",
      "friends": [
        {
          "name": "Lois Lane"
        },
        {
          "name": "Martha Kent"
        },
      ]
    },
    "rightComparison": {
      "name": "Batman",
      "friends": [
        {
          "name": "Joker"
        },
        {
          "name": “Catwoman”
        },
        {
          "name": "Leia Organa"
        }
      ]
    }
  }
}
```


You can see how the above query would be much repeated. The concept of fragments is usually used to split complex application data requirements into tinier pieces, especially when you need to join lots of UI components with different fragments into one initial data fetch.


## Operation name 

Until now, we have been practising a shorthand syntax where we omit both the query keyword and the query name, but in live apps, it's useful to use these to make our code less ambiguous.

Here’s an example that includes the keyword query as operation type and operation name:

```graphql
query PlayerNameAndFriends {
  player {
    name
    friends {
      name
    }
  }
}
```
```graphql
{
  "data": {
    "player": {
      "name": "James",
      "friends": [
        {
          "name": "Adam"
        },
        {
          "name": "Paul"
        },
        {
          "name": "Chris"
        }
      ]
    }
  }
}
```


The operation type is either query, mutation, or subscription and defines what kind of operation you intend to do. The operation type is required unless you're using the query shorthand syntax, in which case you can't supply a name or mutable definitions for your operation.

The operation name is an important and explicit name for your operation. It is demanded in multi-operation documents, but its use is encouraged because it is beneficial for debugging and server-side logging. When something runs crazy either in your network logs or your GraphQL server, it is easier to identify a query in your codebase by name somewhat of trying to decipher the contents. Think of this just like a function name in your desired programming language. For example, in JavaScript we can easily work only with anonymous functions, but when we give a function a name, it's easier to track it down, debug our code, and log when it's called. In the same way, GraphQL query and mutation names, along with fragment names, can be a useful debugging tool on the server side to identify different GraphQL requests.



GraphQL Tutorial - Queries and mutations Part 1

This is a part of a series documenting our startup story. Check more on “My-saas-story.”

Last month it was the first month we entirely used OKR method to focus our growth. I am pleased regarding our results and how we communicate between team members. We had finalized our roadmap and posted in on a website. Also, we added consulting tab (hopefully we’ll start earning some money - fingers crossed). At the end of the month, I’ve found about growth teams and theories from Sean Ellis. I’ve introduced the team to work in agile experimenting mode, and they seem to like it!

The upcoming month we’ll focus on testing new ideas for growth like viral sharing, launching first paid features (backend faker front end queries) and many other small updates ;]

## Development:

We've developed frontend queries to enable fronted users autocomplete query in typescript and receive typesafe response. On backend side we deployed project API and faker Service which soon will be available to all of you. Stay Tuned!

## Blog posts of the month (views)

[/GraphQL-newbie-tutorial-Schema-Definition-SDL/](https://blog.graphqleditor.com/GraphQL-newbie-tutorial-Schema-Definition-SDL/) 1,282
[/levensthein-algorithm-for-better-faker-experience/](https://blog.graphqleditor.com/levensthein-algorithm-for-better-faker-experience/) 404
[/Marketing-automation-From-800k-to-130m-impressions-in-3-months](https://blog.graphqleditor.com/Marketing-automation-From-800k-to-130m-impressions-in-3-months/)/ 307
[](https://blog.graphqleditor.com/power-of-typeof-and-typestyle-in-react-apps/)[/power-of-typeof-and-typestyle-in-react-apps/](https://blog.graphqleditor.com/power-of-typeof-and-typestyle-in-react-apps/) 253
[/graphsourcing-new-way-to-build-systems/](https://blog.graphqleditor.com/graphsourcing-new-way-to-build-systems/) 228

## OKR’s update

OKR’s seems to be a good foundation for the small team to maintain focus. This month we added a minor tweak to precise few positions and to measure many experiments.

|                             | **oct** | **nov** |
| --------------------------- | ------- | ------- |
| github faker stars          | 19      | 24      |
| github diagram stars        | 54      | 219     |
| github graphql-editor stars | 2550    | 2675    |
| blog views (users)          | 1500    | 4153    |
| website views (users)       | 1000    | 2131    |
| blog articles               | 8       | 16      |
| mailchimp subscriptions     | 16      | 147     |
| demo runs (users)           | 0       | 781     |
| outreach to developers      | 700     | 2700    |
| slack users                 | 10      | 14      |
| quality calls/conversations | 10      | 15      |
| experiments                 | -       | -       |

## Join our slack [here](https://join.slack.com/t/graphqleditor/shared_invite/enQtNDkwOTgyOTM5OTc1LWI4YjU3N2U5NGVkNzQ2NzY5MGUxMTJiNjFlZDM1Zjc2OWRmNTI0NDM3OWUxYTk4Yjk3MzZlY2QwOWUzZmM2NDI)!



My saas story nov18 growth team foundation


This article is part of newbie series. In other articles I’ve covered basics of GraphQL, introduction and Schema Definition Language. It has been written by newbie for newbies. Feel free to comment, suggest changes. 

## The basics
    Scalar types
    Int > Integer
    Float > Float
    String > String
    Boolean > Boolean
    ID > ID
    
    Type definitions
    scalar > Scalar type
    type > Object type
    interface > Interface type
    union > Union type
    enum > Enumerable type
    input > Input object type
    
    Type modifiers
    String > Nullable string
    String! > Required string
    [String] > List of strings
    [String]! > Required list of strings
    [String!]! > Required list of required strings

**Example of a GraphQL schema**
```graphql
type Author {
  id: Int!
  firstName: String
  lastName: String
  """
  the list of Books by this author
  """
  books: [Book]
}

type Book {
  id: Int!
  title: String
  author: Author
  pages: Int
}

# the schema allows the following query:
type Query {
  book: [Book]
  author(id: Int!): Author
}
```
**Input Arguments**

```graphql
# Basic Input
type Root {
  users(limit: Int): [User]!
}

# Input with default value
type Root {
  users(limit: Int = 10): [User]!
}

# Input with multiple args
type Root {
  users(limit: Int, sort: String): [User]!
}
# Input with multiple args and default values
type Root {
  users(limit: Int = 10, sort: String): [User]!
}
# or
type Root {
  users(limit: Int, sort: String = "asc" ): [User]!
}
# or
type Root {
  users(limit: Int = 10, sort: String = "asc" ): [User]!
}

# Interfaces


interface Publication {
  title: String!
  releasedDate: String!
}
  
type Magazine implements Publication {
  title: String!
  releasedDate: String!
  version: Int!
}
  
type Book implements Publication {
  title: String!
  releasedDate: String!
  pages: Int!
}

# Unions

union SearchResult = Book | Author
  
type Query {
  search(text: String!): SearchResult
}

query {
  search(text: "Park") {
    ... on Book {
      title
    }
    ... on Author {
      name
    }
  }
}
    

# Enums

enum RGB {
  RED
  GREEN
  BLUE
}
type Root {
  color: RGB
}

# Input Object Types

input ListUsersInput {
  limit: Int 
  since_id: ID
}
type Root {
  users(params: ListUsersInput): [Users]!
}

```

GraphQL newbie tutorial - cheatsheet


## Summary

Hi, I’m Robert - entrepreneur based in Poland. Last seven years I’ve spent working in software development business. Last year I made a transition from the service business to saas. In this article I’ll cover short story, mostly focusing on last year and how we got our first traction. Check more articles and updates on “My saas story.”

## First business.

Just after graduating University in 2011 I’ve started marketing agency with my best friend (lemontea.pl). I wasn’t doing very good since we didn’t have any business experience and decent idea what we want to do. After two years the company made almost no profit, a friend decided to leave the company just for me, and I was there with three developers on the payroll with no proper plan. I’ve decided to focus and brand the team as javascript consulting experts. It took a year to do so but it worked, we were quickly able to win new customers and won prestigious awards for advanced &  animated front end of one project. We were overselling and since I had no experience in it business and project management I’ve decided to sell the company.

## Selling the child.

I did it after 3,5 years from starting my company. It was straightforward because we had a good brand and few enterprise customers waiting to deliver orders. It gave me a massive advantage in negotiations with potential buyers showing them what type of customers I’m able to win. I’ve decided to go with www.tenderhut.com. New owner offered me a decent proposition and a VP of sales position, so I’ve joined the team. It was a newly formed company (30 people), but the founders had many years of experience in the one prominent software development company in Central Europe. Their previous company (SMT Software) has sold for $40M USD.  I’ve spent nearly two years there developing sales & marketing department from scratch to more than ten people on board. The company itself tripled the size concerning headcount and revenue. My new founders wanted to replicate the success of their past employer. 

## Need to change.

But I wanted to change. I didn’t want to do just outsourcing. I felt I’d like to do some more than only selling skilled developers by days. I wanted to focus more on marketing because it was also something I was passionate about over the years. I’ve decided to change and leave the company and search for exciting ideas.  I’ve started working as a freelancer for tech companies helping them develop sales departments. Also, I’ve started talking with my colleague - Artur from Aexol. I thought it could be good to do something together, cause he had considerable experience developing his products - mostly simple mobile apps. I knew that to grow a great product I need a product experienced co-founder.

## Saas ideas.

Before focusing on our final project, we started working on three other ideas. Those projects were cute, but their vision and market were local. We wanted a big hairy audacious goal! The third project was the thing - Artur showed me the idea of visual node designer called www.slothking.online. I thought - funny name and a crazy idea, let’s do it! That time he had a beta version of the app and his developers were using it to speed up the development process. It was a proper MVP with internal users. It was a great idea to start. It was a side project, and I was sharing it with my part-time freelance consulting . That time we didn’t discuss shares or positions. We wanted to deliver excellent value, focus on pure work and stay lean on the money. That time I’ve watched a few YC videos on product market fit, and we started looking for traction

## Searching for market fit.

Working on my new startup gave me huge motivation and a lot of fun. In a few hours, we made the ugliest landing page that we could and started talking with customers. We got a little bit of response, but it wasn’t a thing described in YC videos. We didn’t get that feeling. So we made a better quality version of our landing page. It also didn’t work so well. That time I thought - we need great advisors. It’s my fourth business, and I don’t want to do it myself. I’ve checked my LinkedIn and tried to find someone who I know and might be a great fit. I was looking for someone who has success experience in dev products, saas or high growth companies. I got in touch with Tomasz Karwatka from Divante.co - a global e-commerce software company. He and his brother had launched open source vue store front which had nearly 3k stars on GitHub. That was the team that I was looking for. They agreed to help for small % of shares after hearing about our idea. 

## Finding product market fit?

We decided to meet with guys from Divante online a few times and then set up a meeting in Wroclaw. It was hard to catch up with guys cause they are full time in travel. After our 3 hour meeting, we decided to make a pivot. Our original idea slothking.online was to create an entirely new core system and then prepare it for all programming languages. It was a downside of this idea where we had to customise our tool for every different language. At the meeting, we found that there’s new technology - a GraphQL query language that’s gaining popularity in opposite to REST API. We thought if we could make and GraphQL Visual Editor than add to that fake backend, database and cloud deployment we would achieve our initial idea of Visual Node / Backend Designer. The new plan was born. Next week we had a demo since we were able to re-use our javascript diagram tool. We made nicely looking GitHub repo and posted it on hacker news. That was the thing. We posted it on Saturday 22nd Sept and in one week we had 20k views (12k unique), and 2300 GitHub starts. Till that day we didn’t spend any money. 

My saas story - from IT outsourcing to saas


With the theoretical introduction from the previous post on GraphQL, we can go on to describe an essential part of this standard, namely the type system, which allows you to define the API scheme - GraphQL Schema Definition Language (SDL). It is a special syntax that has been very well documented and created in such a way that you can work with it regardless of the language or framework.

## Type System

GraphQL is strongly typed, which means that each definition must have a particular type. The Type System comes with the help, which provides several possibilities for defining elements of our API. Let’s think about library application (books and authors) declare the first types of our API.
```graphql
type Book {
  id: ID!
  title: String!
  shortDescription: String!
  description: String
  pages: Int!
  isbn: String!
  releaseDate: String!
  isBookOftheYear: Boolean!
  author: Author!
}
  
type Author {
  id: ID!
  name: String!
  bio: String
  sex: String!
  books: [Book!]!
}
```

   
The most important and most often used element of the whole puzzle is `Object Type`, which in the simplest terms is a collection of fields. Above examples: two objects were declared using the `type Book {}` and `type Author {}` definitions, while inside these declarations you can see fields that are of certain types, e.g. `name: String!`, or  `isBookOftheYear: Boolean!`.

## Scalar types

In GraphQL there are several built-in scalar types for field declarations:

- `String` - set of characters in UTF-8 format,
- `Int` - 32-bit integer,
- `Float` - floating point number,
- `Boolean` - value `true` or `false`
- `ID` - a type representing the unique identifier for the object, most often used for re-downloading (used by the cache). It's serialised in the same way as the `String` type.
## Interface

GraphQL's type system features Interfaces. An interface exposes a specific set of fields that a type must include implementing the interface.  For example, we could represent a Publication interface served as a book or magazine. These types share common characteristics, including a title and release date.

```graphql
interface Publication {
  title: String!
  releasedDate: String!
}
  
type Magazine implements Publication {
  title: String!
  releasedDate: String!
  version: Int!
}
  
type Book implements Publication {
  title: String!
  releasedDate: String!
  pages: Int!
}
```
It is very likely that the author could publish both books and magazines, thanks to the interface you do not need to become dependent on a particular type of publication, in this case, we can use a more massive abstraction which is Publication.

## Union

An interesting mechanism is the Union type, which allows you to represent a group of objects that do not have the same fields. An excellent example is a query to a search engine that can search both the title of the book and the author's name.
With this declaration, you can query something like this:
```graphql
union SearchResult = Book | Author
  
type Query {
  search(text: String!): SearchResult
}

query {
  search(text: "Park") {
    ... on Book {
      title
    }
    ... on Author {
      name
    }
  }
}
```
And as a result we will see the answer:
```js
    {
      "data": {
        "search": [
          {
            "name": "Jurassic Park",
          },
          {
            "name": "Jessica Park",
          }
        ]
      }
    }
```
## Declaration scheme

When defining the API scheme, there are two top-level elements available - `query` and `mutation`, which are ordinary objects created in the same way all others. Within them, we declare the possibilities of our API. The definition of the scheme itself is trivial:
```graphql
schema {
  query: Query
  mutation: Mutation
}
  
type Query {
}
  
type Mutation {
}
```
## Query

A query is a mandatory element in the schema and is responsible for reading the API. All defined fields inside this object can be compared to various API endpoints. The accepted principle is that elements issued via query are nouns that explicitly specify the entity to be downloaded - in the above example they are book and author. To better illustrate the whole, you can move the previous definitions of objects to query.
```graphql
schema {
  query: Query
}
  
type Query {
  book(id: ID!): Book
  author(id: ID!): Author
}

type Book {
  id: ID!
  title: String!
  shortDescription: String!
  description: String
  pages: Int!
  isbn: String!
  releaseDate: String!
  isBookOftheYear: Boolean!
  author: Author!
}
  
type Author {
  id: ID!
  name: String!
  bio: String
  sex: String!
  books: [Book!]!
}
```
## Arguments

In some lines you can see the declaration of fields slightly different than in previous cases (e.g. `book (id: String!)`), Where in addition to the field name you can see parentheses with another declaration - it's nothing more than entering an argument to the query - on its basis, you can pass some parameters according to which you want to download data. In the above example, the user's id is expected and the query performed would look something like this:
```graphql
query {
  book(id: "1234") {
    title
    isbn
  }
}
```
## Mutation

`Mutation` is an optional part that allows you to add, edit or delete items in our application via the API. Its definition is identical to the type `query`. The only difference is the principle of defining fields - in contrast to `query` in `mutation`, fields are most often called verbs that are clearly defining a performed action. Complementing the above example, it is worth adding the possibility of creating new books.

## Input Type

Before we go to the example declaration of `mutation`, it's worth to present one more type dropped when discussing all the basic types in the section that pertained to the Type System.
To modify or create new elements in the application via GraphQL, a particular type `input` was created, which behaves very much like a regular object, with the difference that during the declaration `input` is used instead of the keyword `type`.

```graphql
schema {
  query: Query
  mutation: Mutation
}
  
type Mutation {
  createAuthor(input: AuthorInput): Author
  updateAuthor(id: ID!, input: AuthorInput): Author
}
  
input AuthorInput {
  name: String!
  bio: String
  sex: String!
}
```
In the above example, you can observe that the createAuthor and updateAuthor actions expect the AuthorInput object as an argument and return the Author object. For the declared scheme, creating a new book requires a similar action:

```graphql
mutation {
  createAuthor(input: {
    name: String!
    bio: String
    sex: String!
  }) {
    id
    title
  }
}
```


GraphQL newbie tutorial - Schema definition


I’m Robert - co-founder of grapqhleditor.com. We're creating a visual tool for developers that will automate their backend development. I'm sharing our journey as part of my-saas-story. All of our team have long years of experience in the tech industry but none on saas.

It's the first week of November, and we are working the 6th month on our idea. Since then we made a pivot (half sept), and many other things happened. I'll write another post on that. Here wanted to focus on our current state and goals for this quarter. October was an excellent month for us. Check below:

## New blog!

We started a blog.graphqleditor.com. We wrote eight blog posts, published them on few places and that gave us more than 1,5k page views! Below you can see which posts are most popular:
- [Levensthein algorithm for better faker experience](/levensthein-algorithm-for-better-faker-experience/) 555  views
- [Canvas node graph in typescript](/canvas-node-graph-in-typescript/) 423 views
- [Twitter clone with React XP and faker](/twitter-clone-with-reactxp-and-faker/) 415 views
- [Graphsourcing new way to build systems](/graphsourcing-new-way-to-build-systems/) 191 views
- [GraphQL newbie tutorial - introduction](/GraphQL-newbie-tutorial-introduction/) 144 views
- [Typescript backend with slothking](/typescript-backend-with-slothking/) 116 views

## Outreach & Feedback calls

We organized an outreach campaign to front-end developers asking about feedback. We organized ten calls after sending around invites to 1000 people. Those calls were very good. We received a lot of feedback and added those ideas as issues to our GitHub. We had a pleasure to speak with developers from Paypal and Microsoft! It was super exciting!

Some compelling features were around offline version for the enterprise, adding icons to nodes (making them more consumable for non-tech people), generating Interface for frontend or creating fake backend out of the graph. All of them are on our GitHub.

## First OKR’s & Metrics

Together with our advisors, we created a short roadmap for this quarter. It's not 100 ready, but the first version includes our vision, mission and metrics which we want to measure to grow. Below you can find our OKR' results from October. I'll update it every month!

| METRIC                      | COUNT   |
| --------------------------- | ---- |
| github faker stars          | 19   |
| github diagram stars        | 54   |
| github graphql-editor stars | 2550 |
| blog views                  | 1500 |
| website views               | -    |
| blog articles               | 8    |
| mailchimp subscriptions     | 16   |
| demo runs                   | 200  |
| outreach to developers      | 1000 |
| slack users                 | 10   |
| quality calls               | 10   |
| close issues                | 20   |

## Development:

Graphql Editor: Total open issues: 16. Last month we closed ten issuse in our main repo (21 from pivot).

Javascript Diagram: Total open issues: 14. We have rewritten our tool to canvas to handle large schemas. It was an idea by users. Try GitHub schema! IT Rocks!

Team: Artur is working on the front end with few hours of help from Hubert and Kamil is working on backend features.

## Other:
- Launched a slack group (pm me to join). 
- Three guys agreed to contribute
- Created landing page for diagram.graphqleditor.com



My saas story - oct'18 first OKRs and :s


I’m Robert - Head of Growth at grapqhleditor.com. I’m responsible for every non-tech part of the project -  talking with users, building feature roadmap, building traffic and promoting it in tech community. To grow my tech skills I’ve also decided to learn GraphQL. Since I’m a newbie, this tutorial is also for newbies.

## Where GraphQL came from?

GraphQL was introduced in 2015 by Facebook as an alternative to REST. Back then It wasn’t just an experiment - it was already in production inside facebook mobile apps since 2012.  Just after public release, It became extremely popular, and around that time many companies were working on similar solutions. This technology started to gain attention since it can be used with many other languages and there’re many ready to go libraries to most popular styles. Right now according to Stackshare there’re nearly 2k companies using it. Early adopters included Coursera, Github, ProductHunt, Yelp or Twitter.

## What is GraphQL?

To introduce GraphQL we I’ll use an example of data and compare functionality with REST. This example will show you why new technology is more efficient, simpler to use and what was motivation to create it. 

Let’s assume that we are creating a backend for application with two versions (web and mobile). The core of the system will contain information about football players, teams they played and some other details. Mobile version of the application should show less information.

| Web                       | Mobile     | 
| -------------| -------------| 
| Name| Name| 
| Bio| Team (Years)|   
| Team (Description, Years) | Team (Years)|   
| Team (Description, Years) ||   

If we would create API based on REST, therefore, we would need to write two requests:


    GET /player/{id}
    {
      "id": „101”
      "name": „David Beckham”
      "bio": „…”
      „age”: „43”
    }


    GET /player/{id}/teams
    {
      „Teams”: [{
        „id": „201”,
        „name”: „Real Madrid”,
        „description": „…”,
        „goals”: „…”,
        „matches”: „…”,
        „years”: „2003-2007”
      },
      ...
      ]
    }

By looking at the response, you can see that we get more data than we need in both cases. It is essential in mobile apps because of mobile data and the speed of loading.  Of course, we could overcome that by writing different endpoints which will get us only what we want. Another way is to implement API in a way that we could choose what we want I.e. GET /player/{id}/teams?only=name. But that’s hard the solution to maintain in agile software development where requirements are changing every week.


## Opposite to that, we can introduce GraphQL.

Backend with GraphQL is more flexible because it has only one endpoint. Customers write a query and specify what do you want exactly and gets data in JSON. In our football example, we can create queries for each platform (web and mobile).

**Web application:**

    query {
      player(id: "101") {
        name
        bio
        teams {
          title
          description
        }
      }
    }

**Resposne:**

    {
      "data": {
        "player": {
          "name": "David Beckham",
          "bio": "...",
          "teams": [{
            "title": "Real Madrid",
            "description": "..."
          }, ...]
        }
      }
    }

**Mobile app**

    query {
      player(id: "101") {
        name
        teams {
          title
        }
      }
    }

**Resposne:**

    {
      "data": {
        "player": {
          "name": "David Beckham",
          "teams": [{
            "title": "Real Madrid"
          }, ...]
        }
      }
    }

As you can see with each query, we are getting only what we want. That’s the power of GraphQL - flexibility. You don’t need to create endpoints for different screens. Various clients can use a once defined schema in a way that they need to.


## Fewer requests.

In traditional REST approach usually, there are many GET requests to show data on one screen. It’s not super efficient when it comes to mobile apps - it slows them down and needs more internet data transfer. GraphQL allows a user to create only one endpoint. Thanks to technology introduced by Facebook engineers communication between client and a server is better optimised.


## Query language

The most important feature of GraphQL is that it’s language agnostic. It’s not created to work with specific technology. It’s a query language with its own rules which for most popular programming languages. There’re many supportive libraries on the internet for: C#/.NET, PHP. Javascript, Java, Python, Ruby and many more.


## Summary

GraphQL is a query language and runtime that we can use to build and expose APIs as a strongly-typed schema instead of hundreds of REST endpoints. Your clients see the schema. They write a query for what they want. They send it over and get back exactly the data they asked for and nothing more. GrapqhQL advantages:

- fewer data and requests for mobile apps,
- simplicity and visible API structure
- can be used with many technologies
- is used by Twitter, Facebook, Github and many more

Articles written by Robert Matyszewski:

Top GraphQL tutorials reviewed 2019