DEV Community: Edidiong Etuk

GraphQL and Python Series (Expressive Introduction)

Edidiong Etuk — Sun, 28 Jun 2020 22:30:27 +0000

GraphQL and Python Series (Expressive Introduction)

This is part 1 of an ongoing series to introduce you to using GraphQL and Python. Hopefully, at the end of this series, you will be able to build a GraphQL Backend with Django and Graphene.

GraphQL Introductions

GraphQL is a strongly typed language and is an alternative to REpresentational Transfer(REST).

Missing explanation: Try and explain why GraphQL was created and why it's an alternative to REST. PayPal Engineering Medium article can help.
An example of a GraphQL query us as follows:

{
    allFilms {
        films {
            title
    }
  }
}

GraphQL Type Schema

We'd mostly be using two types in GraphQL, the Object Type and the Scalar Type.
Object types can contain their own set of subfields, generally speaking, they have to be an object.

Scalar types are built-in GraphQL data types, and they are five in number: integers, floats, strings, booleans and ids(these are unique strings). Now, these are the standard five, but they can be extended and still be Scalar Types as we will in this article.

CRUD Operations in GraphQL

Create Read Update Delete(CRUD) functionalities are done in GraphQL using two operations: Query and Mutations. Just like we've done above, reading data(R) is done normally using queries. But to write or change data, we need a GraphQL operation called Mutation.
In summary, CUD - is covered by mutations while R - is covered by queries. The codes below are examples of using mutation to create, update and delete objects respectively

mutation {
    createBaby(bodyInfo: {
        name:"Edidiong",
        votes: 1
  })  {
      name
      votes
  }
}

mutation {
    upvote(name: "Edidiong") {
        name
        votes
    }
}

mutation {
    remove(name: "Edidiong") {
        name
        votes
    }
}

You notice when reading data, you don't need to use query keyword but in creating, updating or deleting data, you use the mutation keyword so the engine knows you're doing a mutation.

Intro to Graphene/GraphQL In Python

By now you have seen how to do queries and mutations in Vanilla GraphQL(borrowing the word Vanilla from JavaScript), let's see how to perform GraphQL in Python.

Query Operation

To create a query, you, first of all, need a root query(this point will be explained in the code session below). Also, GraphQL uses the OOP structure to work so if you're not familiar with OOP, you may find it difficult to follow.

Code

Create a new file called schema.py and rewrite these codes here into the file.

import uuid
import json
from datetime import datetime
import graphene

class User(graphene.ObjectType):
    id = graphene.ID(default_value=str(uuid.uuid4()))
    username = graphene.String()
    created_at = graphene.DateTime(default_value=datetime.now())


class Query(graphene.ObjectType):
    users = graphene.List(User, limit=graphene.Int())
    hello = graphene.String()

    def resolve_hello(self, info):
        return "world"

    def resolve_users(self, info, limit=None):
        return [
            User(id="1", username="Khalid", created_at=datetime.now()),
            User(id="2", username="Ann", created_at=datetime.now()),
            User(id="3", username="fred", created_at=datetime.now()),
            ][:limit]


# Query of users
schema = graphene.Schema(query=Query, auto_camelcase=True)
result = schema.execute(
    '''
    {
        users {
            id
            username
            createdAt
        }
    }
    '''
)
dict_result = dict(result.data.items())
print(dict_result)

Let's break down the code above to grasp what was done.

User

A User class was created that inherited from the graphene.ObjectType. Almost all of the GraphQL types you define will be object types(only a few percentages will be Scalar Types). Object types have a name, but most importantly describe their fields.

So the User class contains the id, username and date the account was created all. You will notice id and username are default scalar types(the .ID() and .String()), we are adding .DateTime() as a scalar type(Dive deep into the Graphene source code to see all available Scalar types).

Query

Earlier, we learnt that to create a query in graphene, we first need a root query. The class Query is that root query. We have two class attributes defined in the query: hello and users. More about the hello query later.
The users attribute takes in the User class and a limit argument, these two are what we would use in our actual GraphQL query. The users' details will be returned in a List structure.

The methods we have created in this Query class are called resolvers. Resolvers are functions that resolves a value for a type or field in a schema. Simply put, resolvers are what return objects or scalar from our query. To name a resolver, it has to have the word resolve_ in its name(just like how Test Driven Development in Python) are. We also set a default value for the limit parameter.

Schema

To execute the code we've written, we will use the Graphene Schema. The graphene schema can execute operations(query, mutation and subscription) against the defined types. Looking up type definitions and answering questions about the types through introspection are advance use cases of the schema.
The schema has a query parameter which we will pass our class Query into as an argument. This query argument is the entry point for fields to read data in our Schema.

Execute

To provide the result, we use the execute method in the Schema class. In this method, we will provide the query in a GraphQL format but since we're using Python, it will be wrapped in a Block comment. In GraphQL, it is standard to use camelCase names. So our Fieldnames are transformed in Schema's TypeMap from snake_case to camelCase and this is made possible because of the auto_camelcase argument and it set to True by default.
The effect is seen in our query as created_at is changed to createdAt following the camelCase convention.

Result

You should have a response like the image below

Include The Result Image.

To better format the result, we use the json.dumps method so as to use the indent parameter in this method. Alter the print statement above to the one below and run it to see the newly formatted result.

print(json.dumps(dict_result, indent=2))

Include The Result Image.
If you have a result similar to the image above, congratulations.

The limit parameter is by default set to None so the output shows all the users in the resolver. If we set a limit to 1 as we do in the code below, we see it returns just a single query.

result = schema.execute(
    '''
    {
        users(limit: 1) {
            id
            username
            createdAt
        }
    }
    '''
)

Note: The (limit: 1) is used because of the users attribute in the class Query. We had defined limit as a scalar type inside the users: which is what made (limit: 1) work.

Also, we created a hello resolver. We will say this is our hello world in Graphene. To run the hello query, replace the previous query with the one below:

{
    hello
}

Include The Result Image.
The image above is a result of the query.

We have been able to understand everything there is about queries. Now let's move to mutations.

Mutation Operations

Remember when we said to create queries we need a root query, in mutations, it's sorta different. The Mutation is a convenience type that helps us build a Field which takes Arguments and returns a mutation Output ObjectType. This means to perform CUD operations, we need to pass arguments to a mutation. To pass in arguments to a mutation we need to pass in an inner Arguments class.

Code(mutation)

Add these new classes into the schema.py file but arrange the classes to be on top of another.

class CreateUser(graphene.Mutation):
    user = graphene.Field(User)

    class Arguments:
        username = graphene.String()


    def mutate(self, info, username):
        user = User(id="4", username=username, created_at=datetime.now())
        return CreateUser(user=user)


class Mutation(graphene.ObjectType):
    create_user = CreateUser.Field()

Also, comment out the previous schema and append this to the end of the file.

# Mutation
schema = graphene.Schema(query=Query, mutation=Mutation)
result = schema.execute(
    '''
    mutation {
        createUser(username: "Edidiong") {
            user {
                id
                username
                createdAt
            }
        }
    }
    '''
)

Let's break down the code above to grasp what was done.

CreateUser

The CreateUser class inherits from graphene's Mutation class and creates a Field that is available on an ObjectType. The ObjectType here is our User class.

Arguments

Arguments inner class passes the attribute username to the CreateUser class and this username is gotten from the resolver. This attribute is a Scalar Type(String) and it's the arguments we use for the mutation Field.

The mutate method is a resolver method for the Mutation class. It performs data change and returns the output which in this case the username, id and created_at are the data change and a new user is returned.

Mutation

The Mutation class takes in the CreateUser class and mounts it as a Field. Like we know, almost all GraphQL types you define will be ObjectType. Refer to the Mutation Operation header to understand what happens behind the engine of the Mutation class.

Schema(mutation)

We already know about the Schema class and query parameter. The mutation parameter describes the entry point for fields to create, update or delete data in our API. We pass in the Mutation class as an argument to the mutation argument so as to perform CUD operations with it(in our case it's only Create we've done).

Execute(mutation)

The execute in mutation also does the same thing as execute in query: to read the query from a GraphQL format into a Python format so as a result can be gotten.
The only difference is the way to write the call. The mutation keyword comes in just like we were told earlier in the article. From the previous Execute header, we understand how (username: "Edidiong") comes about.

Result

We should have a result similar to the image below.

Include The Result Image.

Subscription Operations

Next Steps

Next, we will talk about Building GraphQL Backends with Django and Graphene. If you liked the article upvote and either drop a comment below or send me a mail

Basics of Pytest

Edidiong Etuk — Tue, 16 Jun 2020 13:25:32 +0000

In the previous article I wrote about Linting with Travis in Python, we introduced pytest for checking lints, but question what is Pytest? Pytest is a testing framework just like the in-built unittest which allows us to write test codes using python.

Why We're Here

Pytest doesn't force you to abandon the Python way of writing code, unlike python's inbuilt test module that forces you to follow the Java culture. This is because it is based on Erich Gamma's JUnit and Kent Beck's Smalltalk testing framework. We're here to embrace a new way of life in test-driven developments.

Getting Started with pytest

Pytest is a command-line tool that discovers Python tests and executes them. It's easy to get started with. Follow these steps to continue:

Create a virtual environment using python3 -m venv testing and activate it(Linux and Windows use different methods to activate the venv).
Ensure you have pytest installed, use pip install pytest if you haven't done so already.
Ensure pytest is available in the command line using pytest -h
Create a file called test_basic.py, and add the following functions in it:

    def test_dev():
        stdout = "DEV Community"
        assert stdout == "DEV Community"

    def test_exponent():
        exponent = 3**3
        assert exponent == 9

Now on your terminal, run your test using pytest test_basic.py
You should see a result like below:

Output

If you have the output above, congratulations, you have successfully run your first test with Pytest, it's that easy. You can see how many tests passed and how many failed and also the line throwing the error.

Also, the test_basic.py .F [100%]. When a test runs successfully, It uses the period(full stop) to show that it didn't fail, but when it fails, it uses the F to show failure. This list shows you the outputs from a Pytest build:

. - test passed
F - test failed
E - Exception
s - test skipped
x - expected failure (broken now but will fix)
X - unexpected pass (should have failed)

Layouts And Conventions

When testing with Pytest, there are few conventions you should follow:

The testing directory needs to be named tests.
Test files need to be prefixed or suffixed with test; for example, test_basic.py or basic_test.py
Test functions need to be prefixed with test_; for example test_hello. If it is named testhello.py, Pytest won't see it.
Test classes need to be prefixed with Test; for example TestCase.
If test subdirectories don't have __init__.py, you can't use the same filename in different directories.

So the most basic structure of a project to be tested is as seen below;

Project
\---proj
    |   proj_file.py
    |   __init__.py
    |
    \---test
            test_proj_file.py

Differences with unittest

Python has an inbuilt utility for testing called unittest module. Here are some of the differences.

Code Difference

import unittest

class TestExponent(unittest.TestCase):
    def test_exponent(self):
        exponent = 3**3
        self.assertEquals(exponent, 9)


class TestDev(unittest.TestCase):
    def test_dev(self):
        stdout = "DEV Community"
        self.assertIs(stdout, "DEV Community")

In another directory, create a new python file called test_basic and copy and paste the above code into it. Then run it with python -m unittest.

Pythonic Culture

Like we earlier said, the unittest uses a Java coding culture. What this means is unittest forces the use of classes and class inheritance. Python standardly isn't a strong OOP language so beginners and even intermediates may have a hard time using the unittest module. The unittest module focuses on OOP making testing an obstacle to newbies. For experienced developers, OOP isn't a problem but using classes and inheritance to write a simple test is absurd! Pytest follows Python's culture in making things simple(check out the Zen of Python: import this in the python shell will show more.)

Multiple Assertions

Once you inherit from TestCase, you are required to understand(and remember) most of the assertion methods used to test results. In our code difference session, we see we used two different asserts compared to the single assert we used in our actual code. Some asserts can be found here

Comparison Engine

pytest provides a rich comparison engine on failures when compared to unittest. It's more like a verbose but pytest even has a verbose flag to see more of what your code is doing. That's some cool stuff if you ask me. Lol, for definition sake, verbose is: ...

Extendability

Pytest is extendable, it's not limited like unittest. This means you can use pytest past its basic uses. You can alter its engine.

Summary of the differences

unittest is Non-PEP 8 compliant(Python's own culture)
unittest is "Classy" - Matt Harrison
So many assert methods to remember

Some Points To Note About Assert

How assert Works

So far, we can say the pytest replaces the Java way with the Python way and also replaces over .. assert statements to just one assert. Pytest uses an import hook (PEP 302) to rewrite assert statements by introspecting code(AST) runner has collected.

Careful Handling

Don't wrap assertion in parentheses. Parentheses are by default a truthy tuple. Add the code below to our test_basic.py:


def test_almost_false():
    assert (False == True)

You will get a warning like the one in the picture below.

Ability to specify a message

You can specify a message in assert statements. Note for test_almost_false function, once you specify a message, it changes from a failed test to pass with a warning. This isn't efficient and in subsequent articles, we will explain how to handle this expected failure. Reediting the test_basic.py file:

def test_dev():
    """Checks if Hello World is the result."""
    stdout = "DEV Community"
    assert stdout == "DEV Community"

def test_exponent():
    """Checks if the exponential is equal 9."""
    exponent = 3 ** 3
    assert exponent == 9, "Value should be 9"

def test_almost_false():
    assert (False == True, 'Should be false')

We should have a result like an image below:

In the next part of our testing journey, we will talk about the extensibility of pytest: debugging, test selection, and marking and fixtures.

Linting Python Codes Better with Travis

Edidiong Etuk — Thu, 14 May 2020 02:26:04 +0000

When contributing to open source organizations, one will notice the need to follow coding standards and conventions to have your pull request reviewed and possibly merged.
It's the same with mature companies, and a lot of startups too: they all like to follow the coding standards of their chosen programming language.
This process is what is referred to as linting. When organizations lint their codes, everybody is happy because coding standards are followed.
But can we have this same setup in our private accounts? Can operate like these organizations in our repositories?
The answer is yes we can and I will show you if you stick around.

At the end of this tutorial we will:

understand what linting is
setup and Integrate TravisCI to our repositories
use Travis CI to lint Python codes using flake8 and pylint

What is Linting

Linting is referred to as the process of analyzing source code to flag programming errors and stylistic errors.
Linting, when done properly, can detect formatting discrepancy, errors in your program and ensure you adhere to coding standards and conventions.
Linters (a tool for linting) ensures you follow best practices, makes your code readable and easy to maintain and possibly save time.
Organizations use CI tools to automate their linting and also ensure that future contributors to that codebase follow lint rules.

Every language uses their own set of lines so I'd just list three linters with three programming languages below:

Python: pylint, flake8, bandit
Golang: go-critic, go-vet, golangci-lint(this contains all the linters in Go language)
JavaScript: ESLint, JSLint.

For the focus of this tutorial, we will focus on linting python codes.

Setup TravisCI and Integrate TravisCI to your repositories

In the previous section, we talked about organizations using CI tools to automate their linting. But what is CI?

Continuous integration is a software development practise where developers regularly merge their code changes into a central repository, after which automated builds and tests are run.
Continuous integration most often refers to the build or integration stage of the software release process and entails both an automation component (e.g. a CI or build service) and a cultural component (e.g. learning to integrate frequently).
Travis CI (c'mon it's in the name) is one of those tools used by organizations to automate their testing for lint. A lot of open source organizations use Travis for their automation and we will mimic them in automating our check for lint.

Travis CI has all the required steps to set up in their documentation so it will be redundant to have to type it out here. Do check out their documentation here.
Once you're done with this, Travis is all set up and linked with your account.
To integrate Travis with your repositories, you need to add a .travis.yml file in your project-level directory to trigger a Travis CI build.

Linting Python Codes with Travis CI

Now we made mention of linters in Python earlier, so we'd pick two from there and use: flake8 and pylint. We will check the following code with the packages.

import json
class Dog:


    def __init__(self, name, age):
        """Initialize name and age attributes."""
        self.dog_name = name
        self.dog_age = age
        self.name = "Rambo"
        self.age = 12


    def sit(self):
        print(f"{self.dog_name} is now sitting")


    def roll_over(self):
        print(f"{self.dog_age} rolled over!")

my_dog = Dog("Maxwell", 6)

Save the above code in a new file called app.py Then we create a requirements.txt file with the contents below

pytest-pylint==0.16.1
pytest-flake8==1.0.5

We choose these packages because Travis CI will need to run a test and what better package to use that pytest package.
Pytest is used for running tests and will be expanded upon in subsequent articles.

Note: The following sessions should be done individually. Use the flake8 package first, watch the results and after you fix it, return your code to the format above and test with pylint.
This is done so you see the differences between both packages and you choose the one you love the most.

Flake8

Flake8 is a tool for style guide enforcement. This means flake8's principal purpose to ensure you style your codes properly.
It's "the wrapper which verifies pep8, pyflakes and circular complexity".
To set it up in Travis, create a Travis YAML file as you were told above and add the following code to it.

language: python
python: "3.8"

install:
    - pip install -r requirements.txt
scripts:
    - pytest --flake8

language: this tells Travis to use a python as the programming language for this build.
python: here you choose the version you want to test your code with, it supports all python version from 2.7 to present but we're testing our codes with python version 3.8.
install: We're installing the packages we already defined in our requirements.txt file. We want to install the packages in Travis environment so it can be accessed.
scripts: Here, we're executing the pytest --flake8 package we installed. This package is pytest and flake8 rolled in one. Meaning it will test all .py files in the code against the flake8.

Pylint

Pylint is a bit different from flake8, it's the full dose really: it checks style guide, programmatic errors and follows best practices.
Some even say pylint is too strict in its rules (well it's true and you'd see it) so some people use black instead of pylint.
We'd do the same setup as above
Edit the file .travis.yml above to use pylint,

language: python
python: "3.8"

install:
    - pip install -r requirements.txt
scripts:
    - pytest --pylint

It follows the same explanation as to the above and this time we're executing pylint to check instead of flake8.

Results

When we commit the above code to the repository, Travis builds the environment needed to test the code against either flake8 or pylint.
If you use the flake8 package, you should get the following error:

If you use the pylint package, you should get the following error:

Now pylint has an annoying C103: Constant name "my_dog" doesn't conform to UPPER_CASE naming style (invalid-name) rule.
I don't like so we will choose to ignore that particular error, and we do that by ...

So the final code for that passes both flake8 and pylint is as below:

"""This module is an attempt to practise class in python."""


class Dog:
    """A simple attempt to model a dog."""

    def __init__(self, name, age):
        """Initialize name and age attributes."""
        self.dog_name = name
        self.dog_age = age
        self.name = "Rambo"
        self.age = 12

    def sit(self):
        """Simulate a dog sitting in response to a command."""
        print(f"{self.dog_name} is now sitting")

    def roll_over(self):
        """Simulate a dog sitting in response to a command."""
        print(f"{self.dog_age} rolled over!")


my_dog = Dog("Maxwell", 6)

Now if we push our codes to the git repository, the tests pass successfully. If you check the email linked to your git account, you should see a congratulatory message saying you've fixed the build.

Conclusion

We have seen what linting is, how to add Travis CI to our git environment, and used the linters in Python to test our code against Python rules.
You should know you can also use Travis to test if your code does what it is supposed to do. That is called Test-Driven Development and we will talk a lot about that in our upcoming Pytest series.

Till then, enjoy the power of automation!