DEV Community: Augusto Calaca

Kubernetes the basic concepts and elements

Augusto Calaca — Tue, 08 Mar 2022 00:21:31 +0000

Kubernetes is a great option in a project when we want high resilience, availability, and scalability.

Therefore, before starting to use it, it's important to know the main components that make up this technology and their responsibilities.

A Kubernetes cluster consists of a set of machines and each machine on the cluster can take on two roles, the control plane or the worker node.

Control plane

The control plane - it’s the orchestra conductor and it consists of:

API server
- generate the endpoint communication
- it is through it that we communicate with the cluster
- ex: kubectl command
Etcd
- key-value database
- store all data about the kubernetes cluster like data of the deploy, pod, node, service
- just the API server can access the etcd
Kube scheduler
- receive the information of the container and determine in which worker node it will run on
Kube controller manager
- all in Kubernetes works based in controllers and the controller manager is responsible for dealing with the different types of controllers like node controller, replica set, authorization controller, etc

Worker node

The worker node - executes the process and it consists of:

Kubelet
- manage, supervise and ensure the execution of containers on the cluster
- communicate the API server about the states and health of the containers
- inside it has the container runtime which is responsible for executing the containers
- container runtime examples are docker and containerd
Kube proxy
- network communication on cluster

Deployment, replica set and pods

The basic elements to execute the containers are deployment, replica set, and pods

Deployment
- manage the actualizations of the versions
- create a new replica set to manage the new version, remove the deprecated pods and keep the old replica set for eventual rollback
Replica set
- manage pods
- controller replica of the pods, if a pod die other is initialized and executed
- turn the application more resilient
Pods
- the smallest object in the kubernetes cluster
- where the containers are executed
- one container in one pod is good cause we want scale parts of the application and only the container that needs to be scaled
- many containers in one pod are bad cause we do not want to scale all applications at once
- side car pattern - one main container and other with non-functional requirements like collect logs

How to test graphql subscriptions

Augusto Calaca — Mon, 15 Jun 2020 02:50:29 +0000

Just write code isn't enough. We need to test it. The benefits this habit in programming are many ranging from ensure that the code work as designed to gain valuable time when refactoring your codebase.

Before testing we need to understand some things.

The subscribe execute has that signature besides having other fields that we won't need to this example:

// graphql-js

export function subscribe(
  schema: GraphQLSchema,
  document: DocumentNode,
  rootValue?: any,
  contextValue?: any,
  variableValues?: Maybe<{ [key: string]: any }>,
): Promise<AsyncIterableIterator<ExecutionResult> | ExecutionResult>;

Fist our schema with the required definitions, second our graphlq tag string which we will to use the parse function to turn it into a DocumentNode, followed by the rootValue explained later, the contextValue and lastly the variables required by our second argument.
The subscribe execute return a object with three promises: next(), return() and throw(). Let's just stick to the next() function which return our subscription fields once it is performed.

"But where and how do I trigger my subscription?" you may wonder.
Lets us understand the subscribe rootValue argument. The root value represents the "top" of your metaphorical graph of data, and is useful to include functions or data to help resolve the root fields in your schema as Lee Byron explains very well in this comment. That's where we're gonna put our trigger to test our subscription.
The trigger is a PubSub that must be somewhere of the our mutation. Something like:

// UserAddMutation.ts

...
await pubSub.publish(EVENTS.USER.ADDED, { userId: user._id });
...

As soon as this event is triggered all the subscriptions prepared to listen to it will receive the userId value which is the shape of data that should be sent. See the code below:

// UserAddedSubscription.ts

import { subscriptionWithClientId } from 'graphql-relay-subscription';

import UserType from '../UserType';
import * as UserLoader from '../UserLoader';
import pubSub, { EVENTS } from '../../../channels/pubSub';

const UserAddedSubscription = subscriptionWithClientId({
  ...
  subscribe: () => pubSub.asyncIterator(EVENTS.USER.ADDED),
  getPayload: (root) => {
    return { id: root.userId };
  },
  outputFields: {
    user: {
      type: UserType,
      resolve: (root, _, context) => UserLoader.load(context, root.id),
    },
  },
});

export default UserAddedSubscription;

Great, our subscription is interested this event named EVENT.USER.ADDED being able to listen to it and to receive the userId value through the root field on getPayload function. Finally, the getPayload sends this data to outputFields and resolve the user type.

Notice that for our event to be published our mutation must be executed. In that case, we're gonna put all graphql mutation on rootValue of the subscription like this:

// UserAddedSubscription.spec.ts
...
const contextValue = await getContext({});
const variablesMutation = {
  input: {
    name: 'Awesome Name',
    username: 'awesomeusername',
    email: 'awesome@email.com',
    password: '12345',
  },
};
const variablesSubscription = {
  input: {},
};

// focus here
const triggerSubscription = graphql(schema, mutation, rootValue, contextValue, variablesMutation);
const result = await subscribe(schema, parse(subscription), triggerSubscription, contextValue, variablesSubscription);
...

Notice the parse function and your role on grahql-js.
See also the variablesSubscription and realize that it automatically adds a field named clientSubscriptionId.

Below is the data that we want to receive when our subscription to execute:

// UserAddedSubscription.spec.ts

const subscription = `
  subscription S($input: UserAddedInput!) {
    UserAdded(input: $input) {
      user {
        name
        username
        email
        isActive
        followers {
          totalCount
        }
        following {
          totalCount
        }
      }
    }
  }
`;

In the stretch ahead we checked if the received values by the next() function match the expected values. Realise that the name and username fields are the same as fields passed to variablesMutation so our subscription is receiving the User created at the time of the mutation in real-time.

// UserAddedSubscription.spec.ts
...
expect((await result.next()).value.data).toEqual({
  UserAdded: {
    user: {
      name: 'Awesome Name',
      username: 'awesomeusername',
      email: null,
      isActive: true,
      followers: {
        totalCount: 0,
      },
      following: {
        totalCount: 0,
      },
    },
  }
});
...

The complete code you can see in theses gists: UserAddedSubscription.spec.ts and UserAddedSubscription.ts

GraphQL: understanding node interface.

Augusto Calaca — Wed, 15 Apr 2020 19:04:49 +0000

Overview

To provide options for GraphQL clients to elegantly handle for caching and data refetching GraphQL servers need to expose object identifiers in a standardized way. In the query, the schema should provide a standard mechanism for asking for an object by ID. We refer to objects with identifiers as nodes.

Reserved Types

To a GraphQL Server to be compatible, it must reserve certain types and type names to support the consistent object identification model. We should create the following types:

An interface named Node
The node field on the root query type

Node Interface

The server must provide an interface called Node. That interface must include exactly one field, called id that returns a non-null ID. This id should be a globally unique identifier for the object, and with just this id, the server should be able to refetch the object.

NOTE: If two objects appear in the query, both implementing the Node with identical ids, then the two objects must be equal.

Node root field

The server must provide a root field named node that returns the Node interface. This root field must take exactly one non-null ID argument called id.

When the value returned by the server in the Node's id field is passed as the id parameter to the node root field than this query should refetch the identical object that implements Node.

Now that we have some insight we must answer the following questions:

How and when does Node ID gets created?
When Node ID is used?
How are the nodeDefinitions methods used?

These questions were asked in this post Relay/GraphQL: De-mystifying Node Interface/ID. The present post also answers theses questions besides showing more examples, a generic and scalable form of registering types, how to test your nodeField and a generalization of the Node Interface pattern.

How and when the Node IDs gets created?

A Node ID is created for each GraphQL object declaring GraphQLObjectType for that object. The function globalIdField has the role of auto-generate the node ID when the GraphQL object is created.

import { globalIdField } from 'graphql-relay';
import { IUser } from './UserModel';
import { load } from './UserLoader';

const UserType = new GraphQLObjectType<IUser, GraphQLContext>({
  name: 'User',
  description: 'User data',
  fields: () => ({
    //  auto-generate node ID when the GraphQL object is created
    id: globalIdField('User'),
    ...
  }),
  ...
});

export const UserConnection = connectionDefinitions({
  name: 'User',
  nodeType: GraphQLNonNull(UserType),
});

export default registerTypeLoader(UserType, load);

Further, we will talk about registerTypeLoader.

When the Node ID is used?

Well, we already know that Node ID is used for refetch. But when exactly does a refetch occurs?
The First GraphQL request to fetch data is not a refetch and Node IDs have not been generated so far. The refetch occurs when on the client-side we already have GraphQL objects with Node IDs and, for instance:

we request more data for an existing GraphQL object, which can arise from another component relying on the same GraphQL object but requiring different pieces of data of that object
when the server-side object data has been changed
when to change the parameters used to fetch the original GraphQL object.

How are nodeDefinitions methods used?

For GraphQL types that you want to refetch you request to auto-generate a Node ID for the object during creation, as seen above, and you also need to tell GraphQL how to map globally the Node ID provided during refetch into actual data objects and their GraphQL types. You do this defining the interfaces field on GraphQLObjectType.

// UserType.ts
import { globalIdField } from 'graphql-relay';
import { IUser } from './UserModel';
import { load } from './UserLoader';
import { nodeInterface } from '../../interface/NodeDefinitions';

const UserType = new GraphQLObjectType<IUser, GraphQLContext>({
  name: 'User',
  description: 'User data',
  fields: () => ({
    id: globalIdField('User'),
    ...
  }),
  // use nodeInterface for re-fetching this GraphQL type by node ID
  interfaces: () => [nodeInterface],
});

export const UserConnection = connectionDefinitions({
  name: 'User',
  nodeType: GraphQLNonNull(UserType),
});

export default registerTypeLoader(UserType, load);

The nodeDefinitions has this format and export nodeField, nodeFields and nodeInterface.

// nodeDefinitions.ts
import { nodeDefinitions } from 'graphql-relay';
import { idFetcher, typeResolver } from './nodeRegistry';

export const { nodeField, nodesField, nodeInterface } = nodeDefinitions(
  idFetcher,
  typeResolver,
);

Be aware that nodeDefinitions to tell GraphQL how performs the mapping the Node ID and has two methods:

the first receive the globalId, we map the globalId into its corresponding data object and with it can actually be able to read the GraphQL type and id of the object using fromGlobalId function. We will call it the idFetcher.
the second receive the result object and Relay uses that to map an object to its GraphQL data type. So if the object is an instance of User, it will return UserType and so on. We will call it the typeResolver.

See below how to implement the methods explained above:

// nodeRegistry.ts - that not scale well
import { fromGlobalId } from 'graphql-relay';
import User, * as UserLoader from '../modules/user/UserLoader';
import UserType from '../modules/user/UserType';
// many imports...

export const idFetcher = async (globalId: string, context: GraphQLContext) => {
  const { id, type } = fromGlobalId(globalId);

    if (type === 'User') {
      return UserLoader.load(context, id);
    }
    // many ifs...
    // all the loads of your project
    ...

    return null;
};

export const typeResolver = object => {
    if (obj instanceof User) {
      return UserType;
    }
    // many ifs...
    // all the types of your project
    ...

    return null;
}

Realize that this implementation can be improved.

After that, expose the node and your other queries on QueryType:

// QueryType.ts
import { GraphQLID, GraphQLString, GraphQLNonNull, GraphQLObjectType, GraphQLInputObjectType, GraphQLInterfaceType } from 'graphql';
import { connectionArgs, fromGlobalId, globalIdField } from 'graphql-relay';

import { nodeField, nodesField } from '../interface/NodeDefinitions';
import { GraphQLContext } from '../types';

import UserType, { UserConnection } from '../modules/user/UserType';
import { UserLoader } from '../loader';

export default new GraphQLObjectType<any, GraphQLContext>({
  name: 'Query',
  description: 'The root of all... queries',
  fields: () => ({
    id: globalIdField('Query'),
    node: nodeField,
    nodes: nodesField,
    users: {
      type: GraphQLNonNull(UserConnection.connectionType),
      args: {
        ...connectionArgs,
        filters: {
          type: new GraphQLInputObjectType({
            name: 'UserFilters',
            fields: () => ({
              search: {
                type: GraphQLString,
              },
            })
          }),
        }
      },
      resolve: (_, args, context: GraphQLContext) => UserLoader.loadAll(context, args),
    },
    ...
  }),
});

On playground take any id returned by UserList and pass it to node query, as this:

query Node {
    node(id: "VXNlcjo1ZTgyNGM4YTUwZjcwMzdhMjhmZDdmZWU=") {
    id
    __typename
  }
}

The result on __typename should be the User indicating the GraphQL type of the node.
Well, you just realized how both Node ID and nodeDefinitions are used \o/.

Now, we will go into a part about how you can improve its implementation.

Register Type Loader

To all GraphQL types that the server should be able to refetch you must register your type and load GraphQL.
This may involve many imports, many ifs and fast growth of nodeRegistry as it was shown previously. We want to prevent this situation because it does scale well.
In order to avoid the manual register on the nodeRegistry file, we use an object named typesLoaders that assigns a type and a load GraphQL through a function called registerTypeLoader. See again the snippet UserType.ts how simple it is to use it. So, the nodeRegistry just uses that object bringing it with the function getTypesLoaders. Check down its implementation:

// registerTypeLoader.ts
import { GraphQLObjectType } from 'graphql';
import { Load } from '../types';

type TypeLoaders = {
  [key: string]: {
    type: GraphQLObjectType,
    load: Load,
  };
};

const typesLoaders: TypeLoaders = {};
export const getTypesLoaders = () => typesLoaders;
export const registerTypeLoader = (type: GraphQLObjectType, load: Load) => {
  typesLoaders[type.name] = {
    type,
    load,
  };

  return type;
};

Use that function to type that you want that should be able to refetch, for instance: UserType.ts, PostType.ts, TransacationType.ts and so on.

// nodeRegistry.ts - clean implementation
import { fromGlobalId } from 'graphql-relay';
import { getTypesLoaders } from './registerTypeLoader';
import { GraphQLContext } from '../types';

const typesLoaders = getTypesLoaders();
// How to return an object given its globalId
// Is used to take the ID argument of the node field and use it to resolve an object
export const idFetcher = async (globalId: string, context: GraphQLContext) => {
  const { type, id } = fromGlobalId(globalId);
  const data = await typesLoaders[type].load(context, id);

  return data;
};

// How to return a GraphQL type given an object
// Allows your GraphQL server to work out which GraphQL type of object was returned
export const typeResolver = object => typesLoaders[object.constructor.name].type || null;

Much more structured and clean code, isn't it?

Test node field

To test if your node query works you can try a test by an inline fragment or spread fragment. Here we will show both.

// NodeDefinitions.spec.ts
import { graphql } from 'graphql';
import { toGlobalId } from 'graphql-relay';
import { schema } from '../../schema/schema';

it('should load User by inline fragment', async () => {
  const user = await createUser();

  const query = `
    query Node($id: ID!) {
      node(id: $id) {
        id
        ... on User {
          name
          username
          isActive
          __typename
        }
      }
    }
  `;

  const rootValue = {};
  const context = await getContext();
  const variables = {
    id: toGlobalId('User', user.id),
  };

  const result = await graphql(schema, query, rootValue, context, variables);
  expect(result.data!.node.id).toBe(variables.id);
  expect(result.data!.node.name).toBe(user.name);
  expect(result.data!.node.username).toBe(user.username);
  expect(result.data!.node.isActive).toBe(user.isActive);
  expect(result.data!.node.__typename).toBe('User');
});

Like we already registered the GraphQL type User and define the nodeField on Query we can test if the node brings the data correctly. First we create a user, after we define the query, a root value which can be an empty object, a context which must be similar to the passed on the your server, the variables that your query needs in that case the id. To execute the query we put that informations into graphql and finally we can to compare the returned data to verify if it is correct or not.

// NodeDefinitions.spec.ts
import { graphql } from 'graphql';
import { toGlobalId } from 'graphql-relay';
import { schema } from '../../schema/schema';

it('should load User by spread fragment', async () => {
  const user = await createUser();

  const query = `
    query Node($id: ID!) {
      node(id: $id) {
        id
        ...userFields
        __typename
      }
    }

    fragment userFields on User {
      name
      username
      isActive
    }
  `;

  const rootValue = {};
  const context = await getContext();
  const variables = {
    id: toGlobalId('User', user._id),
  };

  const result = await graphql(schema, query, rootValue, context, variables);
  expect(result.data!.node.id).toBe(variables.id);
  expect(result.data!.node.name).toBe(user.name);
  expect(result.data!.node.username).toBe(user.username);
  expect(result.data!.node.isActive).toBe(user.isActive);
  expect(result.data!.node.__typename).toBe('User');
});

This second test is just to check that our node also works with spread fragment and has the same behavior as the first. However, the test fulfills its role of checking if it works for both types of query.

Recently the relay team made a commit named @refetchable support for @fetchable types in which they add the @fetchable directive. It has the role to define the schema to specify that a GraphQL type is refetchable and what field should be used to refetch it. Therefore, this is a generalization of the pattern explained in this post. Instead node on QueryType we must define foo root field could implement refetchable on top of our custom Foo Node Interface. It's basically the node interface with different field names.

Conclusion

Declare globalIdField on your GraphQL type to make GraphQL auto-generate a unique global Node ID for your GraphQL object during creation and ensure that it must be refetched.
Implement nodeDefinitions methods to map Node ID back to the corresponding server-side object, which you then can use to return other or updated attributes when a refetch provides the Node ID.
Use nodeInterface on your GraphQL type to instruct GraphQL to use the nodeDefinitions implementation to resolve between Node ID and actual server-side objects.
Use the registerTypeLoader to avoid the manual register on the nodeRegistry file and make the code more organized and scalable.
Use tests to avoid unwanted behaviors.
There was a generalization in the pattern.

Resources

How to test your relay components with relay-test-utils and react-testing-library

Augusto Calaca — Thu, 20 Feb 2020 22:04:20 +0000

This blogpost is an improvement over a thread I did on twitter some time ago.

// Detect dark theme var iframe = document.getElementById('tweet-1191733748481613825-69'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1191733748481613825&theme=dark" }

Now I show a similar example but with the use of relay hooks and a little more information.

If you need to refactor code and have no tests to offer you coverage and security, unfortunately, you will be in trouble. Tests really improves the stability of the codebase and helps with changing the internal implementation of the components.

Relay-test-utils

Testing applications that are using relay may be challenging, but the relay-test-utils makes things a lot easier.
It provides imperative APIs for controlling the request/response flow and additional API for mock data generation.

There are two main modules that you will enjoy using in your tests:

createMockEnvironment
mockPayloadGenerator

The createMockEnvironment nothing more than an implementation the Relay Environment Interface and it also has an additional mock layer, with methods that allow resolving/reject and control of operations (queries/mutations/subscriptions).

The mockPayloadGenerator is to improve the process of creating and maintaining the mock data for tested components
it can generate dummy data for the selection that you have in your operation.

Consider that we want to test if this transaction listing goes as expected:

The code above use the hooks useLazyLoadQuery and usePaginationFragment to load a transactions list in which each has the user who is sending fromUser, the user who is receiving toUser, the value, the cashback (5% of the value) and any message.

RelayMockEnvironment

CreateMockEnvironment is a special version of Relay Environment with an additional API methods for controlling the resolving and rejection operations. Therefore the first thing we should do is tell jest that we don't want the default environment but our environment provided by relay-test-utils.


jest.mock('path/to/Environment', () => {
  const { createMockEnvironment } = require('relay-test-utils');
  return createMockEnvironment();
});

The relay team is very concerned with reducing the preparation time of the test environment so that the developer can focus on actually testing its components. That way, from there we can already test our component.

With React-testing-library

Reject

Here we use object destructuring to capture the value of getByText from our render() function.
Let's use rejectMostRecentOperation first and we check if the component raises the error or not. In the first tests, I always like to test cases where the component may fail.

import React from 'react';
import { render, cleanup } from '@testing-library/react';
import { MockPayloadGenerator } from 'relay-test-utils';
import { useRelayEnvironment } from 'react-relay/hooks';
import TransactionList from '../TransactionList';

afterEach(cleanup);

it('should reject query', () => {
  const Environment = useRelayEnvironment();
  const { getByText } = render(<TransactionList />);

  Environment.mock.rejectMostRecentOperation(new Error('A very bad error'));
  expect(getByText('Error: A very bad error')).toBeTruthy();
});

We can also check if the error occurs in the expected operation.


it('should reject query with function and render error with name of the operation', () => {
    const Environment = useRelayEnvironment();
    const { getByText } = render(<TransactionList />);

    Environment.mock.rejectMostRecentOperation((operation) =>
      new Error(`A error occurred on operation: ${operation.fragment.node.name}`)
    );

    expect(getByText('Error: A error occurred on operation: TransactionListQuery')).toBeTruthy();
  });

Resolve

To use resolveMostRecentOperation is as simple as reject.
We check if the component show loading transactions... on the screen while waiting by data and resolve a query.
Finally, we solve the query by putting our mock resolver to the generate.


it('should render success TransactionList', async () => {
    const Environment = useRelayEnvironment();
    const { getByText } = render(<TransactionList />);
    expect(getByText('loading transactions...')).toBeTruthy();

    Environment.mock.resolveMostRecentOperation(operation =>
      MockPayloadGenerator.generate(operation, {
        PageInfo() {
          return {
            hasNextPage: false,
            hasPreviousPage: false,
            startCursor: "YXJyYXljb25uZWN0aW9uOjA=",
            endCursor: "YXJyYXljb25uZWN0aW9uOjE="
          }
        },
        TransactionEdge() {
          return [
            {
              cursor: "YXJyYXljb25uZWN0aW9uOjA=",
              node: {
                id: "Q2xpZW50OjE=",
                fromUser {
                  user: "George Lima",
                  username: "georgelima",
                },
                toUser {
                  user: "Augusto Calaca",
                  username: "augustocalaca",
                },
                value: 1000,
                cashback: 50,
                message: 'A gift on your birthday'
              }
            },
            {
              cursor: "YXJyYXljb25uZWN0aW9uOjE=",
              node: {
                id: "Q2xpZW50OjI=",
                fromUser {
                  user: "Bori Silva",
                  username: "bori",
                },
                toUser {
                  user: "Augusto Calaca",
                  username: "augustocalaca",
                },
                value: 500,
                cashback: 25,
                message: 'This transaction yielded cashback'
              }
            }
          ]
        }
      })
    );

    expect(getByText('FromUser')).toBeTruthy();
    expect(getByText('Name: George Lima')).toBeTruthy();
    expect(getByText('Username: georgelima')).toBeTruthy();

    expect(getByText('ToUser')).toBeTruthy();
    expect(getByText('Name: Augusto Calaca')).toBeTruthy();
    expect(getByText('Username: augustocalaca')).toBeTruthy();

    expect(getByText('Value: 1000')).toBeTruthy();
    expect(getByText('Cashback: 50')).toBeTruthy();
    expect(getByText('Message: A gift on your birthday')).toBeTruthy();


    expect(getByText('FromUser')).toBeTruthy();
    expect(getByText('Name: Bori Silva')).toBeTruthy();
    expect(getByText('Username: bori')).toBeTruthy();

    expect(getByText('ToUser')).toBeTruthy();
    expect(getByText('Name: Augusto Calaca')).toBeTruthy();
    expect(getByText('Username: augustocalaca')).toBeTruthy();

    expect(getByText(/Value: 500/)).toBeTruthy();
    expect(getByText(/Cashback: 25/)).toBeTruthy();
    expect(getByText(/Message: This transaction yielded cashback/)).toBeTruthy(); // this is a default message
  });

Conclusion

This is probably the baseline rule to follow when it comes to testing your relay components.
You can follow the whole the code used above on post through this link.

SEO: some things you must know

Augusto Calaca — Tue, 11 Feb 2020 19:27:11 +0000

SEO (Search Engine Optimization)

You must have heard about SEO, but what is it? What are your main concepts? Keep reading that I'll share what I learned in the last days.

Firstly, why is SEO important? Well... Your digital business needs to be found and accessed by your potential customers. SEO is an interesting topic, an essential part of web designing, fundamental strategy to reach top positions in search engines and should be given its due importance because:

increase the volume of organic traffic and ensure more visibility for your web pages since The top 3 organic results (#1, #2, #3) capture 61% of clicks;
gain more visits;
increase credibility;
social promotion;
lead to better user experience;
important role in improving the business.

SERP (Search Engine Results Page)

It's the page that brings the information and links related to a search. Google improves its algorithm in order to bring a better user experience, that's why robots change so much. Knowing what google robots are looking for on your site helps you to leave exactly what they need to index your content as relevant.

Be careful, giving only what the bots want can be a shot in the foot, so always focus on having quality content. Another factor is that your page needs to have the right semantics and keywords. Ranking your website will be a consequence.

Title

The search engines understand that what is in the title of a page are words that are very relevant to the subject that is being treated there and give greater weight to links where the used words are between tags <title>. Its function is to take to the reader to the content. So, put the main words of your website’s content in the title, but don’t be wordy.

<title>Api reference experimental - Relay</title>

<title>Suspense for data-fetching - React</title>

Meta tags

It helps the search engine to know better about your content. The <meta> tags always go inside the <head> element.
Google does not use the keywords meta tag in web ranking. They do, however, impact the click-through rate from the search engine, which can impact positively on a particular’s page relevancy as judged by the end-user.

Meta description

It is a basic summary of the HTML document. So, it is necessary to describe the content clearly and objectively inserting the keywords.
Define keywords for search engines:

<meta name="keywords" content="React, Relay, GraphQL, JavaScript">

Define a description of your web page:

<meta name="description" content="Tutorials about React, Relay and GraphQL">

Meta Viewport

The viewport is the user's visible area of a web page. It varies with the device and will be smaller on a mobile phone than on a computer screen. Then, it gives the browser instructions on how to control the page's dimensions and scaling.

<meta name="viewport" content="width=device-width, initial-scale=1.0">

The width=device-width part sets the width of the page which will vary depending on the device.

The initial-scale=1.0 part sets the initial zoom level when the page is first loaded by the browser.

Meta Robots

It tells the search engine how to crawl and index your site.

<meta name="robots" content="index, follow" />

Params meaning

index - no problems index the page.
follow - follow any links on the page as part of crawling.
noindex - it stops the page from being indexed.
nofollow - don't follow any links from this page as part of crawling.

URLs

Incomprehensible or very long URLs are bad. Remember that google highly values the user experience. URLs with words relevant to the content and structure of the site help visitors navigate your site. So, always prefer short URLs, related to the title, including keywords and avoid numbers or repeated words. Separate the words with - because the google robots ignore spaces.

Avoid:

https://reactnavigation.org/blog/2020/02/06/react navigation 5.0.html

Nice:

https://relay.dev/docs/en/experimental/api-reference

Responsiveness

Only optimized for a desktop it's not enough. The adaptability of content and websites for different devices is a positive point considering that the reading experience must be practical and pleasant. That consequently leads to more interactive traffic.

Page Speed

Besides The pages need to be fast. The longer your page takes to load the more impatient the user will get and will leave your website soon. Length of stay on the site is another ranking factor. If the user stays on your site for a long time it can be interpreted that its content is interesting.

Images friendly

Images enrich your content, however, robots google cannot process them. The only way for search engines to discern your content is through textual descriptions. So, it is important to pay attention to the src and alt attributes. Use short, descriptive alternative file names and text.

Src

Specifies the URL of an image. Try to use keywords but don't overdo it. Less is sometimes more.

Alt

Specifies an alternate text for an image. Very useful:

accessibility: screen readers read and recite alt text to the user;
description for broken images;
image description for google searches.

Avoid:

<img src="image1.jpg">
<img src="image2.jpg">
<img src="picture3.jpg">
<img src="generic-name.jpg">
<img 
  src="some-very-very-long-sentence.jpg" 
  alt="very long alternative text that would be considered spam"
>

Nice:

<img src="descritive-name.jpg" alt="short and objective description">
<img src="lemons.jpg" alt="two whole lemons and one halved">
<img 
  src="alt-importance.jpg" 
  alt="the illustration above shows the use of a good alternative text"
>

HTTPS

Make your site secure. The HTTPS guarantees security, authenticity, and trust for those searching online. Having it is another attribute to increasing the ranking of your website.

Conclusion

There is more do it, what was explored above are just a few points.
However, it is very likely that your website will appear at the top of the SERP list instead of page 2 of google.