Michio JP

Michio JP

1569468375

Tutorial To Apollo GraphQL Federation for Beginners

If you are a beginner in GraphQL, I recommend you to learn the basics of GraphQL from something like this course.

Apollo Federation is an architecture of composing multiple GraphQL services into a single endpoint.

when you start to think about building a microservice, it would be difficult to divide the GraphQL layer for different services. For example, we are dividing it something like this –
This is image title
This may seem to make sense at first. but, the problem is adding a new feature. Let’s say that we want to add top comments in Post. Post-service doesn’t know how to resolve a query for top comments because data about comment will be stored in the Comment Service.

On the other hand, Apollo Federation allows us to extend the Post type in Any Service, Here Comment service with a extend type functionality.
This is image title
Therefore, this keeps all the code for a given feature in a single service and separated from unrelated concerns.

complete source code can be found here

Federation Core Concepts

Mainly, let us see the core concept of apollo federation which compiles different services together to form a single graph

Entities and keys

Firstly, It is a type which is referenced by another service. it creates a connection between services and form a federated graph. entities have a primary key which identifies the specific instance of the type.

entities can be declared by using a keyword @key in the Type

type User @key(fields: "_id") {
   _id : ID
   name : String
   email : String
}

External Type Reference

Once, the entity is declared, other services can reference this type from their own types. Let’s see how the Comment Service refer the User Service in our example

type Comment {
   user: User
}

extend type User @key(fields : "_id") {
   _id : ID @external
}

Likewise, In this example, we have Comment type with a field called user that return the User type. Since User is an entity that lives in another service, we define that type in this service with just enough information to enable composition.

  • extend keyword declares the User is an entity defined elsewhere, here it is User Service
  • The @Key declares the ‘name’. We will use _id to refer to a particular user.
  • The _id field with an @external directive declares the type of _id field(ID ) that is implemented in another service.

On the other hand, To get all the values of Referenced User in Comment Type Definition. we need to write some logic in the Resolver.

Comment: {
        user(comment) {
            return { __typename: "User",_id : comment.userId }
        }
    },
{ __typename: "User",_id : comment.userId }

object is a representation of a User entity. Representations are how services reference each other’s types.

As a result, the gateway will use the representation as an input to the service that owns the referenced entity. So to allow the gateway to get all the values in the referenced service. we need to reference resolver back in the User service.

User: {
        async __resolveReference(object) {
            return await UserModel.getUserById(object._id);
        }
    }

Now, we could get user details in the Comment Type using the reference of it which is a UserID

This is image title

Extending external types

However, Extending external types solves the problem of one to many relationship use-cases. For example, Post can have many comments and a comment belongs to a post. In the previous section, we just saw external type reference. Here we will see Extending external type

For example, we want to add comments field to Post type

extend type Post @key(fields: "_id"){
        _id : ID @external
        comments : [ Comment! ]
    }

we can extend the Post type in the Comment service and extend the type with comments which are the type of Comment

Since the Comment service already had a concept of the Post type from returning it, adding additional fields to the overall type can be done just like it was a normal type.

query plan will fetch the _id field for each Post from the Post service and pass those to the comment service, where you can then access these fields on the object passed into your comments

resolver:

Post: {
        comments(post) {
            return CommentModel.getCommentByPost(post._id);
        }
    }

Building Microservice

complete source code can be found here

Let us build a blog application using apollo federation. it contains three services and an API gateway
This is image title
You can get the source code for each of the services below –

User Service
Post Service
Comment Service

API Gateway

Firstly, we will create a gateway which connects all the services with a single GraphQL endpoint.

Initialize the project and create a file called gateway.js

npm init --yes
npm install @apollo/gateway apollo-server graphql

touch gateway.js

After that, add the following code in gateway.js

const { ApolloServer } = require('apollo-server');

const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
    serviceList: [
      { name: "users", url: "http://localhost:4001/graphql" },
      { name: "posts", url: "http://localhost:4002/graphql" },
      { name: "comments", url: "http://localhost:4003/graphql" },
      // { name: "inventory", url: "http://localhost:4004/graphql" }
    ]
  });
  
  (async () => {
    const { schema, executor } = await gateway.load();
  
    const server = new ApolloServer({ schema, executor });
  
    server.listen().then(({ url }) => {
      console.log(` Server ready at ${url}`);
    });
  })();

we provide serviceList configuration to the Apollo gateway which provides the name and endpoint for each federated services. name is used for error messages and logging.

API Gateway – Authentication Across services

In Microservice architecture, it is important to authenticate request across different services. This blog explains Microservices Authentication in detail. To achieve this, Apollo Gateway shares the context across services.

@apollo/gateway makes it easy to reuse the context feature of Apollo to customize what information is sent to underlying services.

const { ApolloServer } = require('apollo-server');
const { ApolloGateway, RemoteGraphQLDataSource } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
     { name: "users", url: "http://localhost:4001/graphql" },
      { name: "posts", url: "http://localhost:4002/graphql" },
      { name: "comments", url: "http://localhost:4003/graphql" },
    // other services
  ],

  buildService({ name, url }) {
    return new RemoteGraphQLDataSource({
      url,
      willSendRequest({ request, context }) {
        // pass the user's id from the context to underlying services
        // as a header called `user-id`
        request.http.headers.set('x-user-id', context.userId);
      },
    });
  },
});

const server = new ApolloServer({
  gateway,
 
  context: ({ req }) => {
    // get the user token from the headers
    const token = req.headers.authorization || '';

    // try to retrieve a user with the token
    const userId = getUserId(token);

    // add the user to the context
    return { userId };
  },
});

server.listen().then(({ url }) => {
  console.log(` Server ready at ${url}`);
});

In this example, buildService return a custom RemoteGraphQLDataSource which allow us to modify the outgoing request with information from the Apollo Service context .request from gateway send x-user-id in the request header across services.

Moreover, To Learn more about buildService or RemoteGraphQLDataSource, read the API Docs

Summary

To sum up, we can build a Microservices using apollo federation which solves the problem of stitching GraphQL to a single endpoint. Several teams can work in different services without any dependency between services.

Originally published by Ganeshmani P at codewall.co.uk

#graphql #apollo #web-development

What is GEEK

Buddha Community

Tutorial To Apollo GraphQL Federation for Beginners
Jeromy  Lowe

Jeromy Lowe

1599097440

Data Visualization in R with ggplot2: A Beginner Tutorial

A famous general is thought to have said, “A good sketch is better than a long speech.” That advice may have come from the battlefield, but it’s applicable in lots of other areas — including data science. “Sketching” out our data by visualizing it using ggplot2 in R is more impactful than simply describing the trends we find.

This is why we visualize data. We visualize data because it’s easier to learn from something that we can see rather than read. And thankfully for data analysts and data scientists who use R, there’s a tidyverse package called ggplot2 that makes data visualization a snap!

In this blog post, we’ll learn how to take some data and produce a visualization using R. To work through it, it’s best if you already have an understanding of R programming syntax, but you don’t need to be an expert or have any prior experience working with ggplot2

#data science tutorials #beginner #ggplot2 #r #r tutorial #r tutorials #rstats #tutorial #tutorials

Willie  Beier

Willie Beier

1596728880

Tutorial: Getting Started with R and RStudio

In this tutorial we’ll learn how to begin programming with R using RStudio. We’ll install R, and RStudio RStudio, an extremely popular development environment for R. We’ll learn the key RStudio features in order to start programming in R on our own.

If you already know how to use RStudio and want to learn some tips, tricks, and shortcuts, check out this Dataquest blog post.

Table of Contents

#data science tutorials #beginner #r tutorial #r tutorials #rstats #tutorial #tutorials

Tutorial: Loading and Cleaning Data with R and the tidyverse

1. Characteristics of Clean Data and Messy Data

What exactly is clean data? Clean data is accurate, complete, and in a format that is ready to analyze. Characteristics of clean data include data that are:

  • Free of duplicate rows/values
  • Error-free (e.g. free of misspellings)
  • Relevant (e.g. free of special characters)
  • The appropriate data type for analysis
  • Free of outliers (or only contain outliers have been identified/understood), and
  • Follows a “tidy data” structure

Common symptoms of messy data include data that contain:

  • Special characters (e.g. commas in numeric values)
  • Numeric values stored as text/character data types
  • Duplicate rows
  • Misspellings
  • Inaccuracies
  • White space
  • Missing data
  • Zeros instead of null values

2. Motivation

In this blog post, we will work with five property-sales datasets that are publicly available on the New York City Department of Finance Rolling Sales Data website. We encourage you to download the datasets and follow along! Each file contains one year of real estate sales data for one of New York City’s five boroughs. We will work with the following Microsoft Excel files:

  • rollingsales_bronx.xls
  • rollingsales_brooklyn.xls
  • rollingsales_manhattan.xls
  • rollingsales_queens.xls
  • rollingsales_statenisland.xls

As we work through this blog post, imagine that you are helping a friend launch their home-inspection business in New York City. You offer to help them by analyzing the data to better understand the real-estate market. But you realize that before you can analyze the data in R, you will need to diagnose and clean it first. And before you can diagnose the data, you will need to load it into R!

3. Load Data into R with readxl

Benefits of using tidyverse tools are often evident in the data-loading process. In many cases, the tidyverse package readxl will clean some data for you as Microsoft Excel data is loaded into R. If you are working with CSV data, the tidyverse readr package function read_csv() is the function to use (we’ll cover that later).

Let’s look at an example. Here’s how the Excel file for the Brooklyn borough looks:

The Brooklyn Excel file

Now let’s load the Brooklyn dataset into R from an Excel file. We’ll use the readxlpackage. We specify the function argument skip = 4 because the row that we want to use as the header (i.e. column names) is actually row 5. We can ignore the first four rows entirely and load the data into R beginning at row 5. Here’s the code:

library(readxl) # Load Excel files
brooklyn <- read_excel("rollingsales_brooklyn.xls", skip = 4)

Note we saved this dataset with the variable name brooklyn for future use.

4. View the Data with tidyr::glimpse()

The tidyverse offers a user-friendly way to view this data with the glimpse() function that is part of the tibble package. To use this package, we will need to load it for use in our current session. But rather than loading this package alone, we can load many of the tidyverse packages at one time. If you do not have the tidyverse collection of packages, install it on your machine using the following command in your R or R Studio session:

install.packages("tidyverse")

Once the package is installed, load it to memory:

library(tidyverse)

Now that tidyverse is loaded into memory, take a “glimpse” of the Brooklyn dataset:

glimpse(brooklyn)
## Observations: 20,185
## Variables: 21
## $ BOROUGH <chr> "3", "3", "3", "3", "3", "3", "…
## $ NEIGHBORHOOD <chr> "BATH BEACH", "BATH BEACH", "BA…
## $ `BUILDING CLASS CATEGORY` <chr> "01 ONE FAMILY DWELLINGS", "01 …
## $ `TAX CLASS AT PRESENT` <chr> "1", "1", "1", "1", "1", "1", "…
## $ BLOCK <dbl> 6359, 6360, 6364, 6367, 6371, 6…
## $ LOT <dbl> 70, 48, 74, 24, 19, 32, 65, 20,…
## $ `EASE-MENT` <lgl> NA, NA, NA, NA, NA, NA, NA, NA,…
## $ `BUILDING CLASS AT PRESENT` <chr> "S1", "A5", "A5", "A9", "A9", "…
## $ ADDRESS <chr> "8684 15TH AVENUE", "14 BAY 10T…
## $ `APARTMENT NUMBER` <chr> NA, NA, NA, NA, NA, NA, NA, NA,…
## $ `ZIP CODE` <dbl> 11228, 11228, 11214, 11214, 112…
## $ `RESIDENTIAL UNITS` <dbl> 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1…
## $ `COMMERCIAL UNITS` <dbl> 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0…
## $ `TOTAL UNITS` <dbl> 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1…
## $ `LAND SQUARE FEET` <dbl> 1933, 2513, 2492, 1571, 2320, 3…
## $ `GROSS SQUARE FEET` <dbl> 4080, 1428, 972, 1456, 1566, 22…
## $ `YEAR BUILT` <dbl> 1930, 1930, 1950, 1935, 1930, 1…
## $ `TAX CLASS AT TIME OF SALE` <chr> "1", "1", "1", "1", "1", "1", "…
## $ `BUILDING CLASS AT TIME OF SALE` <chr> "S1", "A5", "A5", "A9", "A9", "…
## $ `SALE PRICE` <dbl> 1300000, 849000, 0, 830000, 0, …
## $ `SALE DATE` <dttm> 2020-04-28, 2020-03-18, 2019-0…

The glimpse() function provides a user-friendly way to view the column names and data types for all columns, or variables, in the data frame. With this function, we are also able to view the first few observations in the data frame. This data frame has 20,185 observations, or property sales records. And there are 21 variables, or columns.

#data science tutorials #beginner #r #r tutorial #r tutorials #rstats #tidyverse #tutorial #tutorials

Dock  Koelpin

Dock Koelpin

1595808240

Graph Databases, GraphQL and Dgraph [Tutorial]

In the first quarter of 2020, I had the experience of being in a short term advisory role for a company that had built a type of Linkedin product for a specific vertical market. They had done a valiant job, but it was clear that scalability was a problem and they had created a problem for themselves by having used MongoDB as the datastore.

The client knew this and wanted to do a rebuild using the neo4j, but despite its popularity, I am not a big fan of it as an implementation of a graph database for a variety of reasons, one of which is that it is written in Java. This led me to hunt around for alternatives which ultimately led me to Dgraph, which I initially liked because it was written in golang but I was won over by just how well the system is built and thought out.

In the process of thinking about Dgraph, they released a private beta for their managed GraphQL backend service called Slash GraphQL. This really caught my attention as it allowed me to just dive in and try out some ideas without having to deal with learning how to install the system. So with that as some preview, I went ahead and signed up for the private beta, I was immediately accepted, I don’t know if there is any real threshold to get access other than they want your information, but a small price to pay.

Let’s cover a bit of the ecosystem before we dive in. While GraphQL has become something of a standard for working with Graph databases, that isn’t what it was developed to do, so Dgraph set out to make something that was more specifically suited by modifying GraphQL into GraphQL± and I assume the ± in the name is in reference to the fact that they added and removed features from it.

When working with Dgraph you can use either GraphQL or GraphQL±, but keep in mind that those languages are really targeted to backend developers and this new Slash GraphQL environment is targeted at full-stack developers.

So with all that said, let’s get into it when we first login we see the following screen:

The quickstart video is definitely worth a few minutes to get a sense of what is going on, in addition, you should read the in-process, quick start guide for Slash GraphQL.

The quick start guide has some specific examples and a working ToDo app at the end that you can check out, but I wanted to build something from scratch. I gave it a lot of thought as to various clever things I could do, but ultimately I decided to use the example in the quick start to provide consistency. If you are familiar with GraphQL, then the syntax is easy.

If you aren’t, but know how to code and know JSON, then it’s not too hard to figure out. This is probably a good time to note some distinguishing characteristics of Dgraph.

Dgraph doesn’t not run on top of another DBMS, it manages data in a way the is optimized for how GraphQL stores and retrieves data. That means you don’t have to deal with creating the schema for the underlying DBMS and then doing it in GraphQL and try to keep them in sync whenever you need to make a change. That means that Slash GraphQL empowers you to only deal with GraphQL schemes without knowing anything about the database.

With that said, let’s create our schema:

#graphql #lowcode #nocode #pros-of-graphql #tutorial-for-beginners #tutorial #learn-to-code #design

Michio JP

Michio JP

1569468375

Tutorial To Apollo GraphQL Federation for Beginners

If you are a beginner in GraphQL, I recommend you to learn the basics of GraphQL from something like this course.

Apollo Federation is an architecture of composing multiple GraphQL services into a single endpoint.

when you start to think about building a microservice, it would be difficult to divide the GraphQL layer for different services. For example, we are dividing it something like this –
This is image title
This may seem to make sense at first. but, the problem is adding a new feature. Let’s say that we want to add top comments in Post. Post-service doesn’t know how to resolve a query for top comments because data about comment will be stored in the Comment Service.

On the other hand, Apollo Federation allows us to extend the Post type in Any Service, Here Comment service with a extend type functionality.
This is image title
Therefore, this keeps all the code for a given feature in a single service and separated from unrelated concerns.

complete source code can be found here

Federation Core Concepts

Mainly, let us see the core concept of apollo federation which compiles different services together to form a single graph

Entities and keys

Firstly, It is a type which is referenced by another service. it creates a connection between services and form a federated graph. entities have a primary key which identifies the specific instance of the type.

entities can be declared by using a keyword @key in the Type

type User @key(fields: "_id") {
   _id : ID
   name : String
   email : String
}

External Type Reference

Once, the entity is declared, other services can reference this type from their own types. Let’s see how the Comment Service refer the User Service in our example

type Comment {
   user: User
}

extend type User @key(fields : "_id") {
   _id : ID @external
}

Likewise, In this example, we have Comment type with a field called user that return the User type. Since User is an entity that lives in another service, we define that type in this service with just enough information to enable composition.

  • extend keyword declares the User is an entity defined elsewhere, here it is User Service
  • The @Key declares the ‘name’. We will use _id to refer to a particular user.
  • The _id field with an @external directive declares the type of _id field(ID ) that is implemented in another service.

On the other hand, To get all the values of Referenced User in Comment Type Definition. we need to write some logic in the Resolver.

Comment: {
        user(comment) {
            return { __typename: "User",_id : comment.userId }
        }
    },
{ __typename: "User",_id : comment.userId }

object is a representation of a User entity. Representations are how services reference each other’s types.

As a result, the gateway will use the representation as an input to the service that owns the referenced entity. So to allow the gateway to get all the values in the referenced service. we need to reference resolver back in the User service.

User: {
        async __resolveReference(object) {
            return await UserModel.getUserById(object._id);
        }
    }

Now, we could get user details in the Comment Type using the reference of it which is a UserID

This is image title

Extending external types

However, Extending external types solves the problem of one to many relationship use-cases. For example, Post can have many comments and a comment belongs to a post. In the previous section, we just saw external type reference. Here we will see Extending external type

For example, we want to add comments field to Post type

extend type Post @key(fields: "_id"){
        _id : ID @external
        comments : [ Comment! ]
    }

we can extend the Post type in the Comment service and extend the type with comments which are the type of Comment

Since the Comment service already had a concept of the Post type from returning it, adding additional fields to the overall type can be done just like it was a normal type.

query plan will fetch the _id field for each Post from the Post service and pass those to the comment service, where you can then access these fields on the object passed into your comments

resolver:

Post: {
        comments(post) {
            return CommentModel.getCommentByPost(post._id);
        }
    }

Building Microservice

complete source code can be found here

Let us build a blog application using apollo federation. it contains three services and an API gateway
This is image title
You can get the source code for each of the services below –

User Service
Post Service
Comment Service

API Gateway

Firstly, we will create a gateway which connects all the services with a single GraphQL endpoint.

Initialize the project and create a file called gateway.js

npm init --yes
npm install @apollo/gateway apollo-server graphql

touch gateway.js

After that, add the following code in gateway.js

const { ApolloServer } = require('apollo-server');

const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
    serviceList: [
      { name: "users", url: "http://localhost:4001/graphql" },
      { name: "posts", url: "http://localhost:4002/graphql" },
      { name: "comments", url: "http://localhost:4003/graphql" },
      // { name: "inventory", url: "http://localhost:4004/graphql" }
    ]
  });
  
  (async () => {
    const { schema, executor } = await gateway.load();
  
    const server = new ApolloServer({ schema, executor });
  
    server.listen().then(({ url }) => {
      console.log(` Server ready at ${url}`);
    });
  })();

we provide serviceList configuration to the Apollo gateway which provides the name and endpoint for each federated services. name is used for error messages and logging.

API Gateway – Authentication Across services

In Microservice architecture, it is important to authenticate request across different services. This blog explains Microservices Authentication in detail. To achieve this, Apollo Gateway shares the context across services.

@apollo/gateway makes it easy to reuse the context feature of Apollo to customize what information is sent to underlying services.

const { ApolloServer } = require('apollo-server');
const { ApolloGateway, RemoteGraphQLDataSource } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
     { name: "users", url: "http://localhost:4001/graphql" },
      { name: "posts", url: "http://localhost:4002/graphql" },
      { name: "comments", url: "http://localhost:4003/graphql" },
    // other services
  ],

  buildService({ name, url }) {
    return new RemoteGraphQLDataSource({
      url,
      willSendRequest({ request, context }) {
        // pass the user's id from the context to underlying services
        // as a header called `user-id`
        request.http.headers.set('x-user-id', context.userId);
      },
    });
  },
});

const server = new ApolloServer({
  gateway,
 
  context: ({ req }) => {
    // get the user token from the headers
    const token = req.headers.authorization || '';

    // try to retrieve a user with the token
    const userId = getUserId(token);

    // add the user to the context
    return { userId };
  },
});

server.listen().then(({ url }) => {
  console.log(` Server ready at ${url}`);
});

In this example, buildService return a custom RemoteGraphQLDataSource which allow us to modify the outgoing request with information from the Apollo Service context .request from gateway send x-user-id in the request header across services.

Moreover, To Learn more about buildService or RemoteGraphQLDataSource, read the API Docs

Summary

To sum up, we can build a Microservices using apollo federation which solves the problem of stitching GraphQL to a single endpoint. Several teams can work in different services without any dependency between services.

Originally published by Ganeshmani P at codewall.co.uk

#graphql #apollo #web-development