Curious Use Cases of GraphQL (and The Future of GraphQL)

Curious Use Cases of GraphQL (and The Future of GraphQL)

In this GraphQL tutorial, we’ll show how developers are using GraphQL as an API gateway to accomplish things that you may have never thought possible. Curious Use Cases of GraphQL (and The Future of GraphQL). As GraphQL moves into the mainstream, the tooling & ecosystem has grown and has made it possible to do much more with GraphQL than using it as just a data layer.

As GraphQL moves into the mainstream, the tooling & ecosystem has grown and has made it possible to do much more with GraphQL than using it as just a data layer. In this talk, I’ll show how developers are using GraphQL as an API gateway to accomplish things that you may have never thought possible.

More details:

When we think of GraphQL at the resolver level, we typically associate some type of database as the resolver data source, but in practice a resolver is simply a function. What this means is that we can do much more with our GraphQL APIs & our resolvers than we ever thought possible, including things like taking existing REST APIs & transforming them into GraphQL APIs (http resolvers), passing the query to Lambda or serverless functions for processing & returning the response via a GraphQL query (for things like AI & ML), geospatial & time-based queries (passing the query to Elasticsearch), & even VR & AR apps (passing in user location / app info & using the subscription to transmit image assets). In this talk, I’ll walk through what this looks like in theory & in practice, demoing 4 different applications that implement this functionality & showing the code that make the magic happen.

GraphQL and Django Tutorial: Should you be using Django with GraphQL?

GraphQL and Django Tutorial: Should you be using Django with GraphQL?

Should you be using Django with GraphQL? Do you need GraphQL with Django? Check GraphQL and Django tutorial to find out how the language can improve your development experience.

For the past 5 years, Django has been the most effective framework for making quick web applications, API Endpoints, or Admin panels for other applications.

One of the biggest advantages of Django is its ability to enable users to write less code and get started quicker, especially if you’re including an admin panel and a fully-manageable database migration process as base functionality.

Django Rest Framework—an external toolkit—makes it easy to build API endpoints. It basically wraps full CRUD API around the Django Model with just a few lines of code.

This means that building any basic CRUD API with Django helps to keep more of a development focus on UI parts, which are key elements of all software products.

Similarly, GraphQL aims to automate backend APIs by providing type strict query language and a single API Endpoint where you can query all information that you need from UI and trigger actions (mutations) to send data to the backend.

My journey with GraphQL started with Facebook’s API, where GraphQL comes from.

Naturally, GraphQL is considered to be very close to the JavaScript world, mostly because browser-based apps are the first adopters of that technology.

That’s why my first GraphQL server+client was done in Node.js and React.js. After having the first app built on top of GraphQL API, I started to use it exclusively for my Web-based projects.

Advantages of GraphQL

As you may have guessed, there is a library for Django to support GraphQL called Graphene Django, which is very similar to the Django Rest Framework.

However, there are significant differences between Django Rest and Django with GraphQL.

The key difference lies in UI usability: with Rest API, you’re getting endless URLs with specific parameter names where you have to check types and specific values.

Meanwhile, with GraphQL you’re defining mutation similar to the code below and getting strictly defined variable names and types, which become part of an automatic GraphQL type validation.

type Mutation {
  userLogin(email: String!, password: String!): UserLoginResponse
}

type UserLoginResponse {
  token: String
  error: Boolean
  message: String
}

GraphQL also comes with another bonus packaged inside its type system. It automatically generates documentation where you can get available queries and mutations with their parameters/return types.

Django Rest also generates some form of documentation, but it is not as usable as the GraphQL Playground displayed below.


If you think this type of interface is available for all kinds of GraphQL endpoints, you’re wrong — this is only available in development mode servers.

In terms of security, having one API Endpoint is naturally more manageable than having hundreds of them—especially when you consider the fact that GraphQL automatically keeps specific type rules and won’t allow requests with incorrect parameter names or values.

Django ❤️ GraphQL

Let’s make a basic setup with Django and GraphQL just to demonstrate how powerful this setup can be. On one hand, you’re getting easy CRUD management with database. On the other hand, you’re getting a very powerful API query language with a single endpoint.

Installation should be very easy. Just follow the steps defined here

The interesting parts are defining GraphQL types and queries in Python. It’s actually based on your database models, but you can also define custom queries without using Django Models.

# schema.py
from graphene_django import DjangoObjectType
import graphene
from .models import Post as PostModel
from .models import User as UserModel

class Post(DjangoObjectType):
    class Meta:
        model = PostModel
        interfaces = (relay.Node,)

    @classmethod
    def get_node(cls, info, id):
        return Post.objects.get(id=id)

class User(DjangoObjectType):
    class Meta:
        model = UserModel
        interfaces = (relay.Node,)

        posts = graphene.List(Post)

    def resolve_users(self, info):
                return Post.objects.filter(user=self)

    @classmethod
    def get_node(cls, info, id):
        return User.objects.get(id=id)

class Query(graphene.ObjectType):
    users = graphene.List(User)

    def resolve_users(self, info):
        return UserModel.objects.all()

schema = graphene.Schema(query=Query)

Now you can very easily query all users with their posts.

The most important thing to remember is that you can query fields you want, which will affect the overall load time and traffic usage on the UI side.

For larger user bases, it’s important to keep traffic low and only query the fields you need. In the case of Rest API, you will get all fields anyway.

query {
  users {
    name
    posts {
      id
    title
    content
    }
  }
}

This is the basic query outcome from the Python definition, which is pretty simple and — compared to Rest API — more expressive than you may think.

What about GraphQL Subscriptions?

GraphQL Subscriptions function as a way to tell the server to retrieve data based on a specific query whenever the data is available.

It all works with WebSockets in near-real time, which means we have to somehow include Django Websockets and configure our backend server for accepting WebSockets.

Basically, GraphQL is just an API query language interpretation that works with any kind of network transportation when handling client and server-side GraphQL language interpretation.

It may seem difficult at first, but there’s an open-source library and Django GraphQL Subscriptions over at the Django Websockets module.

# settings.py

GRAPHENE = {
    'SCHEMA_INDENT': 4,
    'MIDDLEWARE': [
        # Others middlewares
        'graphene_django_subscriptions.depromise_subscription',
    ]
}

This will be enough to handle the subscription schema later on as a Subscription query.
A quick aside: Pinterist actually works entirely on GraphQL Subscriptions, which is all built on top of Django Backend (but probably modified a lot.)

Conclusion

In my opinion, Django with GraphQL is more powerful and extensible than Django with Rest API.

However, it isn’t battle-tested and large companies are still in the process of adopting this kind of combination, but based on what you can get out of this simple configuration, imagine how much more comfortable web development will be when you use Django with GraphQL with modern technologies.

Database Design Tutorial - How to Design & Plan Database for Beginners

Database Design Tutorial - How to Design & Plan Database for Beginners

Learn how to design and plan a database for beginners. This database design course will help you understand database concepts and give you a deeper grasp of database design. Database design is the organisation of data according to a database model. The designer determines what data must be stored and how the data elements interrelate. With this information, they can begin to fit the data to the database model.

Database Design Tutorial - How to Design & Plan Database for Beginners

This database design course will help you understand database concepts and give you a deeper grasp of database design.

Database design is the organisation of data according to a database model. The designer determines what data must be stored and how the data elements interrelate. With this information, they can begin to fit the data to the database model.

⭐️ Contents ⭐
⌨️ (0:00:00) Introduction
⌨️ (0:03:12) What is a Database?
⌨️ (0:11:04) What is a Relational Database?
⌨️ (0:23:42) RDBMS
⌨️ (0:37:32) Introduction to SQL
⌨️ (0:44:01) Naming Conventions
⌨️ (0:47:16) What is Database Design?
⌨️ (1:00:26) Data Integrity
⌨️ (1:13:28) Database Terms
⌨️ (1:28:28) More Database Terms
⌨️ (1:38:46) Atomic Values
⌨️ (1:44:25) Relationships
⌨️ (1:50:35) One-to-One Relationships
⌨️ (1:53:45) One-to-Many Relationships
⌨️ (1:57:50) Many-to-Many Relationships
⌨️ (2:02:24) Designing One-to-One Relationships
⌨️ (2:13:40) Designing One-to-Many Relationships
⌨️ (2:23:50) Parent Tables and Child Tables
⌨️ (2:30:42) Designing Many-to-Many Relationships
⌨️ (2:46:23) Summary of Relationships
⌨️ (2:54:42) Introduction to Keys
⌨️ (3:07:24) Primary Key Index
⌨️ (3:13:42) Look up Table
⌨️ (3:30:19) Superkey and Candidate Key
⌨️ (3:48:59) Primary Key and Alternate Key
⌨️ (3:56:34) Surrogate Key and Natural Key
⌨️ (4:03:43) Should I use Surrogate Keys or Natural Keys?
⌨️ (4:13:07) Foreign Key
⌨️ (4:25:15) NOT NULL Foreign Key
⌨️ (4:38:17) Foreign Key Constraints
⌨️ (4:49:50) Simple Key, Composite Key, Compound Key
⌨️ (5:01:54) Review and Key Points....HA GET IT? KEY points!
⌨️ (5:10:28) Introduction to Entity Relationship Modeling
⌨️ (5:17:34) Cardinality
⌨️ (5:24:41) Modality
⌨️ (5:35:14) Introduction to Database Normalization
⌨️ (5:39:48) 1NF (First Normal Form of Database Normalization)
⌨️ (5:46:34) 2NF (Second Normal Form of Database Normalization)
⌨️ (5:55:00) 3NF (Third Normal Form of Database Normalization)
⌨️ (6:01:12) Indexes (Clustered, Nonclustered, Composite Index)
⌨️ (6:14:36) Data Types
⌨️ (6:25:55) Introduction to Joins
⌨️ (6:39:23) Inner Join
⌨️ (6:54:48) Inner Join on 3 Tables
⌨️ (7:07:41) Inner Join on 3 Tables (Example)
⌨️ (7:23:53) Introduction to Outer Joins
⌨️ (7:29:46) Right Outer Join
⌨️ (7:35:33) JOIN with NOT NULL Columns
⌨️ (7:42:40) Outer Join Across 3 Tables
⌨️ (7:48:24) Alias
⌨️ (7:52:13) Self Join

How to use Apollo Server 2 and GraphQL

How to use Apollo Server 2 and GraphQL

Learn GraphQL, Apollo Server 2, and Black-box Testing. In this tutorial I will be showing you how to use Apollo Server 2 and GraphQL. Understanding of GraphQL by setting up your GraphQL schema that represents the structure of your data set, furthermore, we will do this by looking at TypeDefs (type definitions). We will be using Jest to test our data sources, and then we will be creating black-box tests (snapshots) to test our typedefs & resolvers -- which will be hooked up to fixture files (mock data).

In this video I will be showing you how to use Apollo Server 2 and GraphQL. You will gain an understanding of GraphQL by setting up your GraphQL schema that represents the structure of your data set, furthermore, we will do this by looking at TypeDefs (type definitions). Once we have created our schema the next step will be to let Apollo Server know how to interact with that schema, essentially how to execute queries. To do this we will use something called a resolver, a resolver essentially tells Apollo how to fetch data, moreover how to fetch data for a particular type. Once we have setup our resolvers we will look at data sources. Data sources are nothing more than a class that sets out our scaffolding for making requests to external APIs (in our case). Although we just touch the surface of what a data source can do by using RESTDataSource, they can do much more.

Towards the end of this video, we will be using Jest to test our data sources, and then we will be creating black-box tests (snapshots) to test our typedefs & resolvers -- which will be hooked up to fixture files (mock data). For a quick TLDR of what we have done, skip to 2:58:49 - I essentially went with the format of 'schema (typedefs) -- resolvers -- datasources'.

⏳ Timeline
0:00:00 - Reviewing where we left off
0:03:19 - Quick look over the UI of the first tutorial
0:03:30 - Github repo of the first project
0:04:06 - Reviewing the read me
0:04:21 - Initial setup for our application
0:04:36 - Creating our package.json file
0:07:01 - Optional chaining import!
0:09:46 - Installing all our packages
0:10:26 - Creating our server.js file
0:11:11 - Setting up ApolloServer
0:12:41 - Setting up our typedefs
0:12:51 - Setting up our resolvers
0:13:30 - Quick talk about how GraphQL handles field requests
0:15:47 - Similarities between GQL & RPC
0:18:07 - Adding typedefs within (typedefs/index.js)
0:19:02 - Creating our Article object type
0:20:22 - Defining an instance of an executable query
0:21:32 - Adding more fields to our Article object type
0:26:25 - Creating our essential .babelrc file
0:26:55 - Starting our server!
0:27:25 - Exploring Graphiql on port 4000
0:33:55 - Executing a dummy query
0:36:10 - Hooking up our resolvers
0:37:49 - Exploring resolver arguments
0:39:54 - Logging our executable query arguments
0:40:19 - Exploring the context argument
0:44:09 - Creating our datasource files
0:49:01 - Implementing the hackernews.js datasource
0:52:30 - Explaining RESTDataSource
1:00:01 - Adding methods to our datasource
1:03:36 - Adding a transformer method
1:05:06 - Adding our datasource to our index.js
1:06:01 - Accessing our datasource via the context argument
1:07:21 - Adding all datasources to the context
1:09:51 - Our first successful query via Graphiql!
1:10:56 - Adding more resolvers
1:13:22 - Adding more executable queries into our typedefs
1:15:12 - Debugging syntax errors
1:18:08 - Succesful query responses
1:23:08 - Async resolver explained
1:27:23 - Testing our allArticles resolver
1:31:23 - Adding the New York Times datasource
1:40:03 - Adding the fixture files for testing
1:43:23 - Testing the HackerNews datasource
2:02:03 - Looking at the Apollo documentation for testing
2:06:13 - Testing the HackerNews queries
2:28:48 - Running our black-box tests
2:40:32 - The difference in mocking return objects/arrays
2:43:38 - Checking our coverage levels
2:45:05 - Testing the New York Times datasource
2:49:00 - Testing the New York Times queries
2:52:25 - Checking coverage, nearly at 100%
2:55:15 - 100% test coverage (unit & black-box tests)
2:55:50 - Quick look at aliases
2:58:49 - TLDR: overview of the project!
3:08:00 - Signing off!