DEV Community: atanda nafiu

Build Performant Servers with gRPC and Protocol Buffers

atanda nafiu — Thu, 24 Aug 2023 12:36:08 +0000

Streaming large data set have a heavy cost on memory and performance in I/O. The modern serialized and deserialized data method uses protocol buffers, which Google designed. Due to the popularity of microservice architecture systems, it's been difficult to communicate between systems using other communication models as services. Protocol buffers were designed to beat the likes of JSON and XML by removing the responsibility performed by these formats. gRPC is also a communication model that takes the protocol buffer format further. To simplify the developer experience and improve efficiency, gRPC API should uses a protocol buffer for API definition.

What are Protocol Buffers

"Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once. Then you can use specially generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs compiled against the "old" format.” — Google

Protocol buffers, commonly known as Protobuf, are packages designed by Google to serialize structured data like JSON and XML, but strictly typed. Protobuf helps structure data and can be used in languages like Go, Java, Python, etc. Protobuf is crucial in microservices, where much data is transferred across services.

Why Protocol Buffers are Needed

Modern server architectures like gRPC, REST, and GraphQL need fast parsing of serialised and deserialised structured data. Protobuf is used for communication protocols that generate thousands of messages and are available in many languages.

Protobufs help serialized structured data format for packet types that are large messages in size. The data format is used for long-term data storage. Information changes, including new files and deleting existing fields to any protobuf without updating the existing data. Protobuf is used primarily for interchanging structure information, inter-server communication, and archival data storage on disk. Facebook also used a similar protocol called Apache Thrift, and Amazon created ION. Microsoft also used the Bond protocol, offering a concrete RPC protocol stack to a defined gRPC service.

Prerequisites

Basic knowledge of data structures.
A working installation of Go
Basic understanding of Go.
Download the .proto on your machine and download the code extension for easy formatting. # Protocol Buffers Language

Protobuf has a minimalistic language syntax, which means protobuf also has a language type; when protobuf compiles, protobuf generates a file for a specific programming language, but in your case, you will have a .go file with a struct mapping the protocol file.

Types of Protocol Buffers

Scalar value
Enumeration and Repeated value
Nested value

Scalar Values

The types used in the preceding message are scalar; these types are similar to that of Go types. These are int, int32, int64, string, and bool. Below is a comparison of the type and protobuf scalar type.

Go type	Protobuf type
float32	float
float64	double
uint32	fixed32
uint64	fixed64
[ ]byte	bytes

Default values are also given whenever the User doesn't assign a value to the scalar value. The defined scalar type will be set with a default value.

Enumeration and Repeated Values

The enumeration in protobuf gives an ordering number that sets the default value order from zero to n.

syntax = "proto3";
message Scheldule {
    enum month {
        janury = 0
        Febuary = 1;
        March = 2; 
        April = 3;
        May = 4;
        June = 5;
        July = 6;
        August = 7;
        September = 8;
        October = 9;
        November = 10;
        December = 11;
    }
}

You possibly assigned the same value for multiple enumerations members in a situation. protobuf allows aliases to set two different members. Aliases enum looks like this:

enum EnumAllowingAlias {
    option allow_alias = true;
    UNKNOWN = 0;
    STARTED = 1;
    RUNNING = 1;
}

STARTED and RUNNING have the same assigned value. This means both will have the same have; if you remove the duplicated value, you must remove allow_alias. Otherwise, the protobuf compiler will throw an error.

Repeated value

The repeated field is a protobuf's message representing a list with a given key. Repeated areas are similar to an array/list of an element. The duplicated site looks like this:

message PhoneInfo{
    string serialNum = 1;
    int type = 2;
    repeated string name = 3;
}

The last line of code is a repeated field, an array of names. The value could be something such as this ["100.104.112.10", "100.104.112.12"].

Nested Field

Protocol buffers allow a model to be nested. The inner JSON as of a member of outerJSON, and the code looks like this:

message PhoneInfo {
    string serialNum = 1;
    int type = 2;
    repeated Proxy name = 3;
}
message Name {
    string serialNum = 1;
    int type = 2;
}

The nested field of Name type into the phoneInfo.

Let's look at an example of a message from the official page of the protocol buffer with a JSON:

 message person {
    option string name = 1;
    option int32 id = 2;
    option string email  = 3
  }

The preceding example message was defined with a type called person. The JSON type looks like this:

 {
    "person": {
        "name": "atanda0x",
        "id": 1,
        "email": "atandanafiu@gmail.com"
    }
}

Protocol buffers allow change support to compile with JSON style, but structures are the same. Sequential numbers (1,2,3) are given in protobuf order tags to serialize and deserialize data between two systems. The preceding file compiles the message targeted language; the GO struct and field are empty default values.

Protocol Buffer Compiler (protoc)

Protocol buffer compiler uses .proto to transfer data between various systems. The diagram below explains the flow of protobuf in a chosen language. In your case, it's Go.

Environment and Folder Setup

In this section, you will set up the development evniromnet for protobuf project.

Initialize Project

The first step is to initialize a new Go project. Open a new terminal and run the following command to Create a new folder: You can name it whatever you like. Mine will be protocol-buffer:

mkdir protocol-buffer

Next, move into that folder with the following command:

cd protocol-buffer

Then initialize the new Go project with the go mod command:

go mod init github.com/atanda0x/protobu_go

Create Folders and Server/Client Files

Run the following command to create all the folders that will hold the project files:

mkdir protofiles protoServer protoClient

The command above will create three folders:

protofiles - will contain all the protobuf files.
protoServer - will contain server files
protoClient - will contain client files

Install Libraries
You will install the necessary libraries for your project.

Run the following command to install the protobuf compiler on your machine for WSL or check other os installations here:

 apt install -y protobuf-compiler

Then you need to install Go proto plugins using the go get command:

go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.28


go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.2

Once that’s done, create a user.proto file in the protofiles folder in your project and add the following code inside it. This models the User's information. The example includes a few messages:

syntax = "proto3";
package protofiles;
import "google/protobuf/timestamp.proto";
option go_package = "./";

message User {
    string name = 1;
    int32 id = 2;  // Unique ID number for this person.
    string email = 3;

    enum PhoneInfo {
      MOBILE = 0;
      HOME = 1;
      WORK = 2;
    }

    message PhoneNumber {
      string number = 1;
      PhoneInfo type = 2;
    }

    repeated PhoneNumber phones = 4;

    google.protobuf.Timestamp last_updated = 5;
}

message AddressBook {
    repeated User people = 1;
}

The above code declares the file as proto3 sytax, and a protofiles package, imports the google/protobuf/timestamp.proto and defiles the file the generated file should be stored—the User message with fields name, id, and email. The phoneInfo enums also have fields , the User and AddressBook was created as a central message with a list of User.

The package proteprofile tells the compiler to add the generating file about the package name. You need to compile it into a Go file, which offers Go access to the User.proto file.

Next, you need to compile the code with this command so the protoc will generate a file that the go files will interact with:

protoc --go_out=. *.proto

Once you run that command in the same directory, it automatically generates a User.pb.go file. Please open the file; you will see that it contains a block of codes generated that looks like this:

The generated block of code needs to be used in the main.go file to Create a protobuf string. Generating user.pb.go gives you the following user types:

An AddressBook structure with a User field.
A User structure with fields for Name, Id, Email, and Phones.
A User_PhoneInfo structure, with fields for Number and Type.
The type Person_PhoneType and a value are defined for each value in the User.PhoneInfo enum.

Server and Client

Now that the protobuf has generated a file to interact with, let’s create the server and client files. The server and client are used to interact with the generated user.pb.go file.

Create a server.go file inside your protoServer folder and paste the following code.

package main
import (
    "fmt"
    pb "github.com/atanda0x/protobuf-go/protofiles"
    "google.golang.org/protobuf/proto"
)
func main() {
    u := &pb.User{
        Id:    1234,
        Name:  "Atanda N",
        Email: "atandanafiu@gmail.com",
        Phones: []*pb.User_PhoneNumber{
            {
                Number: "+234", Type: pb.User_HOME,
            },
        },
    }
    u1 := &pb.User{}
    body, _ := proto.Marshal(u)
    _ = proto.Unmarshal(body, u1)
    fmt.Println("Original struct loaded from proto file:", u)
    fmt.Println("Marshaled proto data: ", body)
    fmt.Println("Unmarshaled struct: ", u1)
}

The code above declares the file as a main.go package, start with package main, protobuf pb were imported from the protofile, imports the proto package . The struct mapped to the given protobuf in protofiles. The User struct is used and initialized. proto_marchal function serialized the struct. The marshalled data is not initiated because the proto library serialized data into binary bytes. Protobuf in Go struct generated by compiling the files, which can be used to create JSON string on the fly.

You need to run/build the file with the terminal. Run the following command to do so:

go build


go run main.go

You will see this output print to the terminal:

Let's modify this example, but you will create another file called main_json.go to a different folder because using the same packages name in one directory will throw an error.

package main
import (
    "encoding/json"
    "fmt"
    pb "github.com/atanda0x/protobuf-go/protofiles"
)
func main() {
    u := &pb.User{
        Id:    1234,
        Name:  "Atanda0x",
        Email: "atandanafiu@gmail.com",
        Phones: []*pb.User_PhoneNumber{
            {
                Number: "+23490", Type: pb.User_HOME,
            },
        },
    }
    body, _ := json.Marshal(u)
    fmt.Println(string(body))
}

Run the command below, and the compile will print a JSON string that can be sent to any client that understands JSON strings.

go run main_json.go

Any programming language can pick JSON strings because it is easier to load data instantly.

The benefit of using a protocol buffer over JSON is that buffer is intended to communicate between two backend systems with less overhead. The binary is less than text, and protocol marshalled data is smaller than JSON strings.

Since protobuf is just a data format used to pass a message between two systems in the form of RPC, which makes it less important if not used in communicating, Google Remote Procedure Call (gRPC) takes it further to scale microservices communication, a client and server talk with each other in protocol buffer.

Introduction to Google Remote Procedure Call (gRPC)

Google Remote Procedure Call(gRPC) is an open-source communication mechanism that sends/receive message between two systems. gRPC uses an architecture that supports authentication, load balancing and health checking. I wrote a step-by-step guide on how to use RPC with Go. In the article, there's a section I use JSON RPC service, which is similar to gRPC.

gRPC was designed to transfer data in the form of protocol buffers. gRPC takes creation one step further(easy to use and elegant), creating APIs to define services and start running them smoothly. The combination of gRPC and protobuf is seamless since multiple programming languages can understand gRPC and protocol buffers provided data structures.

The advantages of gRPC over JSON, HTTP, and REST are as follows:

gRPC uses HTTP/2 instead of traditional HTTP/1.1
gRPC uses a protocol buffer over JSON/XML.
The message is transmitted faster with gRPC.
gRPC has a built-in control flow.
gRPC supports bidirectional streaming.
gRPC uses a single TCP connection for sending and receiving multiple messages between the server and the client over traditional HTTP/1.1

The diagram above shows that any backend system or mobile app can directly communicate with the gRPC server by firing a protobuf request.

Bidirectional streaming with gRPC and Protobuf in Go

Now that you know what gRPC and Protobuf are and what they can do. Let’s create an API-based project. A client sends a money transfer request to the server in this use case. The server does a few tasks and sends those step details back to the server as a stream of responses.

The server needs to notify the client whenever some processing is performed. This is called a server push model. The server can send a stream of results back when a client asks for them only once. This is different to polling, where the client requests something each and every time. This can be useful when a series of time-taking steps need to be done. The gRPC client can escalate that job to the gRPC server. Then, the server takes its time and relays the message to the client, which reads them and does something useful. This concept is similar to Websocket but between any type of platform.

You have installed the Go proto plugins in the protobufs section. The Project outlook

serverPush
├── datafiles
│ └── transaction.proto
│ └── transaction.pb.go
│ └── transaction_grpc.pb.go
└── grpcServer
│ └── main.go
└── grpcClient
  └── main.go

Create the proto file for the project with the message and service defined. Name your file transaction.proto in the protofile directory.

syntax = "proto3";
package protofiles;
option go_package = "./";

message TransferRequest {
    string from = 1;
    string to = 2;
    float amount = 3;
}

message TransferResponse {
    bool confirmation = 1;
}

service MoneyTransfered {
    rpc MoneyTransfered (TransferRequest) returns (TransferResponse);
}

The code above has two messages and one service defined in the protocol buffer file. The exciting part is in the service; it returns a stream instead of a plain response:

    rpc MakeTransaction(TransactionRequest) returns (stream TransactionResponse) {}

Compile the code with the following command below and make sure you're in the protofiles directory:

protoc --go_out=. --go_opt=paths=source_relative     --go-grpc_out=. --go-grpc_opt=paths=source_relative     protofile/transaction.proto

This creates a new file called transaction.pb.go in the datafiles directory. You
Use this file's definitions in the server and client programs, which we will create shortly. Now, write the gRPC server code. This code is a bit different from the previous example because of the introduction of streams.

Creation of server and client files

Let’s create a directory for the server and the client files. The server implements the interface that is generated from protofile.

mkdir -p grpcServer


mkdir -p grpcClient

You cd into them one after the other. In the grpcServer create a main.go file.

package main
import (
    "flag"
    "fmt"
    "log"
    "net"
    "time"
    pb "github.com/atanda0x/protobuf-go/StreamwithGRPC/datafiles"
    "google.golang.org/grpc"
    "google.golang.org/grpc/reflection"
)
var (
    port      = flag.Int("port", 50051, "Server port")
    noOfSteps = 3
)
type server struct {
    pb.UnimplementedMoneyTransactionServer
}
func (s *server) MakeTransaction(in *pb.TransactionRequest, stream pb.MoneyTransaction_MakeTransactionServer) error {
    log.Printf("Got request for money.....")
    log.Printf("Amount: $ %f, From A/c:%s, To A/c: %s", in.Amount, in.From, in.To)
    for i := 0; i < noOfSteps; i++ {
        time.Sleep(time.Second * 2)
        if err := stream.Send(&pb.TransactionResponse{Status: "good", Step: int32(i), Description: fmt.Sprintln("Description of step &d", int(i))}); err != nil {
            log.Fatalf("%v.Send(%v)  = %v", stream, "status", err)
        }
    }
    log.Printf("Successfully transfered amount $%v from %v to %v", in.Amount, in.From, in.To)
    return nil
}
func main() {
    flag.Parse()
    s := grpc.NewServer()
    lis, err := net.Listen("tcp", fmt.Sprintf(":%d", *port))
    if err != nil {
        log.Fatalf("Failed to listen: %v", err)
    }
    pb.RegisterMoneyTransactionServer(s, &server{})
    reflection.Register(s)
    if err := s.Serve(lis); err != nil {
        log.Fatalf("Failed to serve: %v", err)
    }
}

The MakeTransaction in the code above is the function that interests us. It takes a request and a stream as its arguments. In the function, You are looping through the number of steps (here, it is three) and performing the computation. The server is simulating the mock I/O or computation using the time.Sleep function:

stream.Send()

This function sends a stream response from the server to the client. Now, let us compose the client program.

In the generated transaction.pb.go file, you will see the RegisterMoneyTransaferedSever function and MakeTransfer function as part of the MoneyTransferServer interface. MoneyTransferhas the RPC request details. It is a struct that maps to the TransferRequest message defined in the protobuf file:

rpc MakeTransfered(TransferRequest) returns (TransferResponse) {}

The Client file

Create the client file, cd into the grpcClient directory. You should have a main.go file in it.

package main
import (
    "context"
    "flag"
    "io"
    "log"
    pb "github.com/atanda0x/protobuf-go/StreamwithGRPC/datafiles"
    "google.golang.org/grpc"
)
var (
    address = flag.String("add", "localhost:50051", "The address to connect")
)
func ReceiveStream(client pb.MoneyTransactionClient, request *pb.TransactionRequest) {
    log.Println("Started listening to the server stream!!!!")
    stream, err := client.MakeTransaction(context.Background(), request)
    if err != nil {
        log.Fatalf("%v.MakeTransaction(_) = _, %v", client, err)
    }
    for {
        response, err := stream.Recv()
        if err == io.EOF {
            break
        }
        if err != nil {
            log.Fatalf("%v.MakeTransaction(_) = _, %v", client, err)
        }
        log.Printf("Status: %v, Operation: %v", response.Status, response.Description)
    }
}
func main() {
    flag.Parse()
    conn, err := grpc.Dial(*address, grpc.WithInsecure())
    if err != nil {
        log.Fatalf("Did not connect: %v", err)
    }
    defer conn.Close()
    client := pb.NewMoneyTransactionClient(conn)
    from := "1234"
    to := "5678"
    amount := float32(1250.75)
    ReceiveStream(client, &pb.TransactionRequest{From: from, To: to, Amount: amount})
}

The code above ReceiveStream is the custom function written to send a request and receive a stream of messages. It takes two arguments: MoneyTransactionClient and TransactionRequest. uses the first argument to create a stream and listens to it. The client will stop listening and terminate whenever the server exhausts all the messages. Then, an io.EOF error will be returned if the client tries to receive messages. The response logging was collected from the gRPC server. The second argument, TransactionRequest, is used to send the request to the server for the first time.

Open a terminal to run the grpcServer with the command below, run go build before running the actual file.

go build 


go run main.go

Open another terminal for the grpcClient to run the main.go file in it.

go build


go run main.go

The TCP server is running on port 50051. The output of both the server and client looks like this.

The client output:

The server gives a log message to the console at the same time.

The client made a request to grpcServer and passed it all from the A/C number to the A/C number and amount. The server picked up the details, processed them, and responded that everything was ok.

This process happens in sync with the server. The client stays alive until all the streaming messages are sent back. The server can handle any number of clients at a given time. Every client request is considered an individual entity. This is an example of the server sending a stream of responses. Other cases can also be implemented with protocol buffers and gRPC: The client sends streamed requests to get one final response from the server The client and server are both sending streamed requests and responses at the same time.

Conclusion

And that's it! You have just built working bidirectional streaming with gRPC and protobuf. You learned the Google RPC open-source communication tool and protocol buffers, why you should use it in your project compared to other communication models, and how to generate a pb file and interact with it in the client/server files. Using his advance gRPC It supports multiple programming languages and built-in features for load balancing and authentication and supports bi-directional streaming, which you build projects on. gRPC helps developers build efficient and robust distributed systems tailored to specific needs in any programing language of the developer's choice. The choice might depend on project requirements and trade-offs between building distributed systems, compatibility, and ease of use.

Thank you so much for reading. Happy coding!

Beginner's Guide to RPC in Golang: Understanding the Basics

atanda nafiu — Mon, 26 Jun 2023 08:41:27 +0000

In the Information Exchange Model, the client sends a request, and the server responds to the client. The type of data/information exchange is based on a specific format that lets both sides communicate with each other. Presently most applications do not use this model to share but instead call services, as they would call any function.

Remote Procedure Call(RPC) was intended to be the function model for networked systems. Client execute RPC like they call a native function, except client package the function parameter and send them through the network to the server. The server can then unpack this parameter and process the request, executing results to the client.

What is RPC

A Remote Procedure Call is an interprocess communication that exchanges data/information between the sender and receiver in a distributed system. RPC is used in client/server architecture for accessible communication. The primary objective of RPC is to develop the physical and logical layers.

The following list is a basic overview of how the RPC process works:

The RPC client puts together the function and argument required to be sent to the server
The RPC server receives them by dialling the connection
The RPC server executes the remote process
The RPC server responded to the client with the result
The RPC client gets the response from the request duly and uses it then, it moves to the next task.

Prerequisites

Before getting started, ensure you have the following prerequisites:

Basic knowledge of Go
Go installed on your machine

Step 1: Setting Up Your Project

To begin building your project, follow these steps to set up your project:

Create a new directory for your project, open your terminal, and run the following command:

mkdir -p go-RPC

This will create a new folder name go-RPC in your current directory.

Navigate to the project director by running the following command:

cd go-RPC

Now you are inside the go-RPC directory.

Initialize your new project by running the following command:

go mod init go-RPC

This command creates a new go.mod file, your project's configuration, and the dependency management file.

Following these steps, you will have a new project directory with a go.mod file ready.

This project will have two sub-directory; follow the steps in the preceding to create the sub-directory. You will have an RPC server and RPC client folder that looks like this.

client-server-RPC
├── client
│    └── main.go
└── server
     └── main.go

Step 2: Create The RPC Server

You will create an RPC server to send UTC server time to the RPC client. To build the RPC server, go has two libraries, net/rpc and net/http.

package main
import (
    "log"
    "net"
    "net/http"
    "net/rpc"
    "time"
)
type Args struct{}
type TimeServer int64
func (t *TimeServer) GiveServerTime(args *Args, reply *int64) error {
    // Fill reply pointer to send the data back
    *reply = time.Now().Unix()
    return nil
}
func main() {
    // Create a new RPC server
    timeserver := new(TimeServer)
    // Register RPC server
    rpc.Register(timeserver)
    rpc.HandleHTTP()
    // Listen for requests on port 1234
    l, e := net.Listen("tcp", ":2233")
    if e != nil {
        log.Fatal("listen error:", e)
    }
    http.Serve(l, nil)
}

Explanation:
The Args struct holds information about arguments passed from the client (RPC) to the server. TimeServer number to register with the rpc.Register. Here, the server wishes to export an object of type TimeServer(int64). HandleHTTP registers an HTTP handler for RPC messages to DefaultServer. Then you started a TCP server that listens on port 2233—the http.Serve function is used to serve it as a running program. GiveServerTime is the client's function, and the current server time is returned.

Here are a few points to note:

Args struct has no field because the server code is not expecting any argument from the client
GiveServerTime takes the Args objects and replies pointer object
it sets the reply pointer object
It serves on port 2233

Step 3: Create The RPC Client

You'll create the client to call your server and handle the response here. It also uses the same net/rpc library but with a different method to dial the server.

package main
import (
    "log"
    "net/rpc"
)
type Args struct {
}
func main() {
    var reply int64
    args := Args{}
    client, err := rpc.DialHTTP("tcp", "localhost"+":2233")
    if err != nil {
        log.Fatal("dialing:", err)
    }
    err = client.Call("TimeServer.GiveServerTime", args, &reply)
    if err != nil {
        log.Fatal("arith error:", err)
    }
    log.Printf("%d", reply)
}

Explanation:
The client DialHTTP to connect to the RPC server, which is running on port 2233. Call the Remote function with the Name: function format with args and reply with the pointer object, the client get the data collected into the reply object and call function is sequential.

Note: The client is running as an independent program. Both programs can be on different machines, and the computing can still be shared. This is the core concept of distributed systems. The tasks are divided and given to various RPC servers. Finally, the client collects the results and uses them for further actions. Custom RPC code is only valid when the client and server are written in Go. So to have the RPC server consumed by multiple services, we need to define the JSON RPC over HTTP. Then, any other programming language can send a JSON string and get JSON.

Now you will start the server.go to the program:

go run server.go

Open another terminal tab to start the client.go program:

go run client.go

The client console will give an output of the current UTC.

JSON RPC Using Gorilla RPC

Gorilla also provides an RPC library. It makes it easier for the client and server to be in the same file. You can send a request as JSON and receive a response as JSON.

This section will be a real-world use case. You have a JSON file on the server with Twitter profile details (Name, username, followers, and following). The client requests Twitter information by making an HTTP request. When the RPC server receives the request, it reads the file from the filesystem and parses it. If the Name matches any profile, the server returns the information to the client in JSON format.

You will install Gorilla RPC and Mux library with the following command:

go get github.com/gorilla/rpc


go get github.com/gorilla/mux

Your folder structure should look like this.

JSON-RPC
├── go.mod
├── go.sum
├── twitterProfile.json
└── server
     └── main.go

The JSON data file
Here is a sample data file with a twitterprofile details structure in it.

[
    {
        "name": "Name cannot be black",
        "username": "@hackSultan",
        "followers": "187k",
        "following": "974"
    },
    {
        "name": "Scott Hanselman",
        "username": "@shanselman",
        "followers": "317k",
        "following": "10.5k"
    },
    {
        "name": "Odogwu Machalla",
        "username": "@unicodeveloper",
        "followers": "97k",
        "following": "15.5k"
    },
    {
        "name": "Gbedilodo",
        "username": "@olodocoder",
        "followers": "252",
        "following": "143"
    },
    {
        "name": "Angie Jones",
        "username": "@techgirl908",
        "followers": "114k",
        "following": "626"
    }
]

Implementing The RPC JSON Server

In this example, you must make a few changes to the preceding server example. Including Gorilla
libraries in this example.

package main
import (
    jsonparse "encoding/json"
    "io/ioutil"
    "log"
    "net/http"
    "os"
    "github.com/gorilla/mux"
    "github.com/gorilla/rpc"
    "github.com/gorilla/rpc/json"
)
// Args holds arguments passed to JSON RPC service
type Args struct {
    Name string
}
// TwitterProfie struct holds TwitterProfile JSON structure
type TwitterProfile struct {
    Name     string `json:"name,omitempty"`
    Username   string `json:"username,omitempty"`
    Followers string `json:"followers,omitempty"`
    Following string `json:"following,omitempty"`
}
type JSONServer struct{}
// TwitterProfileDetail
func (t *JSONServer) TwitterProfileDetail(r *http.Request, args *Args, reply *TwitterProfile) error {
    var twitterprofiles []TwitterProfile
    // Read JSON file and load data
    raw, readerr := ioutil.ReadFile("./twitterprofile.json")
    if readerr != nil {
        log.Println("error:", readerr)
        os.Exit(1)
    }
    // Unmarshal JSON raw data into twitterprofiles array
    marshalerr := jsonparse.Unmarshal(raw, &twitterprofiles)
    if marshalerr != nil {
        log.Println("error:", marshalerr)
        os.Exit(1)
    }
    // Iterate over each twitterprofile to find the given twitterprofile
    for _, twitterprofile := range twitterprofiles {
        if twitterprofile.Id == args.Id {
            // If twitterprofile found, fill reply with it
            *reply = twitterprofile
            break
        }
    }
    return nil
}
func main() {
    // Create a new RPC server
    s := rpc.NewServer() // Register the type of data requested as JSON
    s.RegisterCodec(json.NewCodec(), "application/json")
    // Register the service by creating a new JSON server
    s.RegisterService(new(JSONServer), "")
    r := mux.NewRouter()
    r.Handle("/rpc", s)
    http.ListenAndServe(":9000", r)
}

Open a terminal to start the server program:

go run main.go

Explanation:
The args and TwitterProfile structs contain information about the JSON arguments passed and the profile structure. You define a remote function called TwitterProfileDetail on a resource called JSONServer. This struct is a service created to register with the RegisterService function of the RPC server. If you notice, you also write the codec as JSON. Whenever you get a request from the client, You load the JSON file called twitterprofile.json into memory and then into the TwitterProfile struct using JSON's Unmarshal method. jsonparse is the alias given for the Go package encoding/json because the JSON package from the Gorilla import has the same Name to remove conflict, use an alias instead.

In the remote function, you set the value of the reply with the matched twiterprofile. The data is filled if the client's name matches any of the twitterprofiles in JSON. If there is no match, the RPC server will return empty data. This way, you can create a JSON RPC to make clients universal. Here, no Go client was written. Any client can access data from the service.

Now that the server is running, you must interact with the client. The client can be a CRUL command since the RPC server is serving a request over HTTP. The twitterprofile name is required to get the details.

Open another terminal with the following command to execute the CRUL request:

curl -X POST \

 http: //localhost:9000/rpc \

 -H 'cache-control: no-cache' \

 -H 'content-type: application/json' \

 -d '{

    "method": "JSONServer.TwitterProfileDetail",

    "params": [

        {

            "name":"Name cannot be blank"

        }

    ],

    "id": "1"

}'

Conclusion

You've learned what an RPC is and how an RPC server and client can be built. The JSON RPC is used as a use case, and the use case JSON RPC uses the Gorilla toolkit. Now you can easily create RPC in your Golang project.

For a better understanding, kindly check more articles on RPC. I hope you enjoy this article. Leave a comment on the part you didn’t understand and smash the like button.

Note:
Prefer JSON RPC when multiple client technologies need to connect to your service.
You can view the source code here.

I'd love to connect with you on. Twitter | Linkedin | Github

Understanding the Role of Middleware in Golang

atanda nafiu — Fri, 09 Jun 2023 20:08:36 +0000

When building an application, a middleware is a code that hooks on the server-based request/response lifecycle, which will then chain the request from the client to the next middleware function and eventually the last function.

This article thoroughly explores basic middleware chaining/multiple middlewares.

What is Middleware

A middleware is an http.handler that wraps another http.handler in a server request/response processing. Middleware can be defined in many components; It sits between the web server and the actual handler. Whenever a handler is defined for a URL pattern, the request hits the handler and executes the business logic. All middleware process these functions:

Process the request from the client before hitting the handler(authentication)
Process the handler function
Process the response for the client
logging.. and so on

In an application with no middleware, if a client sends a request, the request reaches the server and is handled by some function handler, and it is sent back immediately from the server to the client. But in an application with middleware, the request made by the client passes through stages like logging, authenticating, session validation, and so on, then process the business logic. It filters wrong requests from interacting with the business logic.

Basic Middleware

The principle of closure function helps us write middleware. A closure function returns another function. Let's write a basic route handler with the name basicMiddleware.go

 package main
    import (
        "fmt"
        "net/http"
    )
    func logic(w http.ResponseWriter, r *http.Request) {
        fmt.Println("Execute the logic")
        w.Write([]byte("OK!!!"))
    }
    func main() {
        handlerLogic := http.HandlerFunc(logic)
        http.Handle("/", middleware(handlerLogic))
        http.ListenAndServe(":9000", nil)
    }
    func middleware(handler http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            fmt.Println("Middleware execution before request")
            w.Write([]byte("Response in middleware "))
            handler.ServeHTTP(w, r)
            fmt.Println("Middleware execution after response")
        })
    }

When you run the code above with go run basicMiddleware.go and check http://localhost:9000 in your browser for this response.

Response in middleware OK!!!

The console will receive this message:

Middleware execution after response
Middleware execution before request
Execute the logic
Middleware execution after response

Explanation: The function takes in a handler and creates a wrapper to execute some operations before and after calling the handler.

The request comes on a route(middleware).
The middleware handler prints Middleware execution after response, writes a response, and logs the URL path.
Serves the handler, which was passed an argument.
Post execution, the middleware function returns back the handler function to the route.

A Real-world Example of Middleware with Multiple and Chaining Middleware

It is possible to chain a group of middleware with the closure logic we used in the basic. Let us create a bookstore API for saving book details; the API will have one POST method and three fields: book name, the year it was published, and the book's author.
In a scenario, an API developer only allows JSON-type media from the client and must send the server time in UTC back to the client for every request. Using middleware to do this. It takes two functions of middleware, which are:

The first function. Check if the content type is JSON. if not, it won’t allow the request to proceed.
The second function adds a Server-Time(UTC) timestamp to the response cookie.

Let's build our project by creating a file name bookMiddlewareAPI.go or anything you want to name.

package main
import (
    "encoding/json"
    "fmt"
    "net/http"
)
type bookstore struct {
    Name   string
    Year   uint64
    Author string
}
func bookLogic(w http.ResponseWriter, r *http.Request) {
    if r.Method == "POST" {
        var book bookstore
        decoder := json.NewDecoder(r.Body)
        err := decoder.Decode(&book)
        if err != nil {
            panic(err)
        }
        defer r.Body.Close()
        fmt.Printf("God a book %s, that was published in %d. The author of the book is %s\n", book.Name, book.Year, book.Author)
        w.WriteHeader(http.StatusOK)
        w.Write([]byte("201 - Created"))
    } else {
        w.WriteHeader(http.StatusMethodNotAllowed)
        w.Write([]byte("405 - Method Not Allowed"))
    }
}
func main() {
    http.HandleFunc("/bookstore", bookLogic)
    http.ListenAndServe(":9000", nil)
}

You run the code above in your terminal:

go run bookMiddlewareApi.go

Then give a CURL request in another terminal:

 curl -H "Content-Type: application/json" -X POST http://localhost:9000/bookstore -d '{"name":"Lord of the Rings", "year": 1957, "author": "J.R.R.Tolkien"}'

Go gives you the following:

     God a book Lord of the Rings, and was published in 1957. The author of the book is J.R.R.Tolkien

CURL response will be:

    201 - Created

Explanation: An API with a POST was created as the allowed method. it will store data in a database. JSON package was imported and used to decode the POST body given by the client. A structure was created to map the JSON body, and JSON got decoded and printed information to the console.

It needs to pass a handler between multiple middleware to chain middleware together, with only one handler involved in the preceding example. and the idea is to pass the main handler to multiple middleware handlers. we’ll complete the code.

package main
import (
    "encoding/json"
    "fmt"
    "log"
    "net/http"
    "strconv"
    "time"
)
type bookstore struct {
    Name   string
    Year   uint64
    Author string
}
func bookLogic(w http.ResponseWriter, r *http.Request) {
    if r.Method == "POST" {
        var book bookstore
        decoder := json.NewDecoder(r.Body)
        err := decoder.Decode(&book)
        if err != nil {
            panic(err)
        }
        defer r.Body.Close()
        fmt.Printf("God a book %s, and was published in %d. The author of the book is %s\n", book.Name, book.Year, book.Author)
        w.WriteHeader(http.StatusOK)
        w.Write([]byte("201 - Created"))
    } else {
        w.WriteHeader(http.StatusMethodNotAllowed)
        w.Write([]byte("405 - Method Not Allowed"))
    }
}
func checkContentType(handler http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        log.Println("Checking the content type middleware")
        if r.Header.Get("Content-Type") != "application/json" {
            w.WriteHeader(http.StatusUnsupportedMediaType)
            w.Write([]byte("415 - Unsupported Media Type, Please send a JSON"))
            return
        }
        handler.ServeHTTP(w, r)
    })
}
func cookieTimer(handler http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        handler.ServeHTTP(w, r)
        cookies := http.Cookie{Name: "Server-Time(UTC)", Value: strconv.FormatInt(time.Now().Unix(), 10)}
        http.SetCookie(w, &cookies)
        log.Println("Currently in the set server time middleware")
    })
}
func main() {
    bookLogicHandler := http.HandlerFunc(bookLogic)
    http.Handle("/bookstore", checkContentType(cookieTimer(bookLogicHandler)))
    http.ListenAndServe(":9000", nil)
}

You run the code above in your terminal:

go run bookMiddlewareApi.go

Then give a CURL request in another terminal:

 curl -i -H "Content-Type: application/json" -X POST http://localhost:9000/bookstore -d '{"name":"Lord of the Rings", "year": 1957, "author": "J.R.R.Tolkien"}'

The output looks like this:

    HTTP/1.1 200 OK
    Date: Tue, 06 Jun 2023 21:56:51 GMT
    Content-Length: 13
    Content-Type: text/plain; charset=utf-8

    201 - Created

If we remove the Content-Type:application/json from the CURL command, middleware blocks us from executing the main handler:

curl -i -X POST http://localhost:9000/bookstore -d '{"name":"Lord of the Rings", "year": 1957, "author": "J.R.R.Tolkien"}'

The output looks like this:

    HTTP/1.1 415 Unsupported Media Type
    Date: Tue, 06 Jun 2023 22:00:11 GMT
    Content-Length: 46
    Content-Type: text/plain; charset=utf-8

    415 - Unsupported Media Type, Please send a JSON

Cookies will be set from the other middleware.

Explanation: checkContentType is the first middleware we added to the preceded code; it checks the content type request and allows or blocks the request from going further. The cookieTimer is the second middleware we added; it was designed to add a cookie to the response with a value of the time in the UNIX epoch. The form of chaining middleware we did is readable for two to three middleware:

func main() {

    bookLogicHandler := http.HandlerFunc(bookLogic)

    http.Handle("/bookstore", checkContentType(cookieTimer(bookLogicHandler)))

    http.ListenAndServe(":9000", nil)

}

Conclusion

This article discussed some essential aspects of building web applications with Go. It is important for a Go developer to know middleware and how to use it. I hope you’ve learned a lot from this article. Feel free to leave a comment on what is not clear to you.

REST API Best Practice: Understanding Verbs and status code

atanda nafiu — Thu, 01 Jun 2023 11:18:45 +0000

Software developers have been working with REST architecture through HTTP and APIs. API isn't just an ordinary interface that you use to interact with the third-party program, communication between programs is done wrongly all because developers use the wrong HTTP status code to express responses. It is more difficult when exposing APIs that clients use to interact with applications in most modern web applications.

In this article, we'll explore in detail the most used REST verbs, the concept of CROS(Cross-Origin Resources Sharing), HTTP status code, and single-page applications with the REST API.

The REST Web Verbs
- REST API Verbs
- Path parameters vs Query parameters
Cross-Origin Resources Sharing(CROS)
HTTP Status Code
REST API With Single Page Application(SPA)
- The Old way of data flow in SPA
- The Modern Way of Data Flow in SPA Through REST
Conclusion

The REST Web Verbs

The information that should be sent when a request is made by the client must include the following:

REST verbs
Header Information
Body(optional)

As a software engineer, you will work with these six REST verbs most of the time. The table below explains the operation, target resources, and what happens if a request fail or succeeds.

Since REST is stateless, the client should find a way to know if the operation was successful or failed. In this case, HTTP has a status code for responses. REST API strictly follow its rule to achieve client-server communication return.

http://HostName/API/endpoint/Query(optonal)
A well-defined REST service has the format above, which consists of the host and API endpoint

REST API Verbs

The REST API design start with the operation definition and the API endpoints the design document should list all the available endpoints for the given resources before implementing the API. To understand the REST verbs we should carefully observe the REST endpoints with examples.

GET
All the browsing on the web is done by performing a GET request to the website server which means GET fetches given resources from the server. A successful GET operation returns an OK (200 status code). GET uses two types of URL queries

Path-based parameter
Query parameter

Path parameters are request parameters attached to a URL that is to a specific rest of API resources. For example, PayPal creates a billing agreement with companies around the world, when a client registers with PayPal for a payment system, they provide a REST API for all the client billing needs and nd, and its GET request for billing looks like this:
/v2/payments/billings-agreements/agreement_Id
when the server sees it, and interprets it as I got an HTTP request for an agreement_Id from the billing agreement. If the request is on the database, it responds to 200 else it sends not-found 400

Query added detailed information to its resources from the server. for example, a movie API fetch, create and update the details of the movie. Query Get request format look like:
/v2/movies/?category=action&released_date=2023
The URL above has a query parameter requesting details from movie resources that satisfied the following conditions:

It should be an Action movie
The movie should have been released in the year 2023

Path parameters vs Query parameters

Query parameters are used to fetch multiple resources based on query parameters but if a client needs a single resource with specific URL information, it is best advised to use path-based parameters to specify the resources.

POST
post method is used to create new resources on the server. A successful post-operation returns a 201 status code. we'll use examples of previous movie creation, post request update multiple resources: /v2/movies.
The POST request json body looks like this:


 JSON
{"name": "The woman king", "year": 2023, "Director ": "atanda0x"}

This creates a new movie in the database, it has an "id" assigned to the record so when GET calls the resources, the URL is created, and the post is done only once. Note that we entered the incorrect release year, in other to update the resources we use the PUT request

PUT
The put method is similar to that of the post method. it is used to replace the resources that already exist in the database. The main difference between the is idempotent, POST call creates two instances with the same data but PUT update a single resource that already exists:
/v2/movie/4289
with a JSON body that looks like this:


 JSON 
{"name": "The woman king", "year": 2022, "Director ": "atanda0x"}

The movie id is 4289. it updates the movie by "year:2022". PUT has a drawback which it updates the entire movie resources with the new one, and this is bad for a reason, the PATCH fixes this.

PATCH
PATCH came into play with the little setback of the PUT. It's similar to PUT except it won't replace the whole record with a new one. Since we need to change a column as the name implies it patches the column that is being modified: /v2/movies/4289
it JSON body looks like this:


 JSON
{"ISBN":  "13337646743"}

It tells the server, to search for the book with Id 4289, and modify this column with the given value. Both PUT and PATCH return a 200 status code for success and a 404 for not-found.

DELETE
The DELETE method is used to delete resources that are no longer needed from the database. It has some similarities to PUT but without a body. It only needs an Id of the resources to be deleted, since the resources are deleted any GET request call from a client returns a 404 not-found.

OPTION
The OPTIONS method is not mostly used in all other API development. Given that it tries to know all available methods define in the server. We can describe it as a menu card in a restaurant, and then ordering available items. It is best practice to implement the OPTIONS method on the server.

Cross-Origin Resources Sharing(CROS)

The OPTIONS method led to cross-origin resource sharing. CROS is a protocol that enables controlled access to resources from any origin (schema, domain, port) other than its own from which a browser need to permit the loading of resources. Initially, browser security prevents clients from making a cross-origin request that is when a site loaded with a URL xyz.com can only make an API call to its host, and if a client need to request data from another URL abc.com, the second server should have a mechanism to recognize xyz.com to get its resources.

This logic explains the image above.

xyz.com request OPTION method on the abc.com server
abc.com send a header: Access-control-Allow origin: http://xyz.com in response to the client
xyz.com can access the resources on abc.com without restriction that calls the REST method
In some cases abc.com may feel like giving all its resources to any host after one initial request which it set access to * which means to any.

HTTP Status Code

HTTP works with Request & Response Model whenever a request is sent a response with a status code is received through this model. There are a few families of HTTP status codes, each family has different status and meaning. We concentrate on the most common families, which range from 100 to 500

1xx family(Informational)
Communicates transfer, protocol-level information family. They indicate that the server has received the request and is continuing the process. This family code is purely temporary and is given while the request processing continues. 100, 101, 102, and 103 fall under this family. A client doesn't encounter these much, as it's not the final request response.

100(Continue Operation) is an initial part of the request that has been received by the server and the client can proceed or ignore the response if the request has already finished.
102(Processing Operation) is returned when the server has accepted the full request but has not yet completed it, and the response is not available yet.
103(Early Hints) was intended to be used to allow a client to preload resources, while the server prepares a response. Like a primary user with the link header.

2xx family (successful)
200 and 201 fall under the success family. They indicate that an operation was successful. Plain 200 (Operation Successful) is a successful CRUD Operation:

200 (Successful Operation) is the most common type of response status code in REST.
201 (Successfully Created)is returned when a POST operation successfully creates a resource on the server
204 (No content) is issued when a client needs a status but does not have any data back.
205(Reset Content) is issued that the client should reset the document that this request.
206(Partial Content) is a response to a Range header sent from the client when requesting only a part of the resource.
226(IM response) is issued when the server has successfully fulfilled a GET request for a resource, and the response is a representation of the result of one or multiple instances applied to the current instance.

3xx family (redirection)
These status codes are used to convey redirection messages. The most important ones are 301 and 304:

301(Moved Permanently) is issued when a resource is moved permanently to a new URL endpoint. It is essential when an old API is deprecated. It returns the new endpoint in the response with the 301 status. By seeing that, the client should use the new URL in response to achieving its target.
304(Not Modified) status code indicates that content is cached and no modification happened for the resource on the server. This helps in caching content at the client and only requests data when the cache is modified.

4xx family (client error)
These are the standard error status codes that the client needs to interpret and handle further actions. These have nothing to do with the server. A wrong request format or ill-formed REST method can cause these errors. Of these, the most frequent status code API developers use are 400, 401, 403, 404, and 405:

400 (Bad Request) is returned when the server cannot understand the client's request.
401 (Unauthorized) is returned when the client is not sending the authorization information in the header.
403 (Forbidden) is returned when the client has no access to a certain type of resource.
404 (Not Found) is returned when the client request is on a resource that is nonexisting.
405 (Method Not Allowed) is returned if the server bans a few methods on resources. GET and HEAD are exceptions.

5xx family (server error)
These are the errors from the server. The client request may be perfect, but due to a bug in the server code, these errors can arise. The commonly used status codes are 500, 501, 502, 503, and 504:

500 (Internal Server Error) status code gives the development error which is caused by some buggy code or some unexpected condition.
501 (Not Implemented) is returned when the server is no longer supporting the method on a resource.
502 (Bad Gateway) is returned when the server itself got an error response from another service vendor.
503 (Service Unavailable) is returned when the server is down due to multiple reasons, like a heavy load or maintenance.
504 (Gateway Timeout) is returned when the server is waiting a long time for a response from another vendor and is taking too much time to serve the client.

REST API With Single Page Application(SPA)

Instead of building with the traditional UI way(request web page), SPA makes the building of UI a different way. There are many frameworks with the likes of Reactjs, Vuejs, Angulajs, and so on used to develop web page UIs rapidly and pretty simple. All frameworks help to implement one design pattern that is not requesting the web page but only REST API. Frontend is considered a separate entity that needs to talk to the backend only using REST API can achieve this. There are two ways data flow in SPA

The Old way of data flow in SPA

Request a web page from the server
Authenticate and show the dashboard UI
Allow the user to modify and save
Request as many web pages from the server as needed to show individual pages.

The Modern Way of Data Flow in SPA Through REST

Request the HTML template to the browser in one single go.
Query the JSON REST API to fill a model(data object)
It adjusts the UI according to the data in the model(JSON)
When a user modifies the UI, the model(data object) should change automatically.

Communication happens only in the form of the RET API, the client takes care of the logical representation of data. It causes The system to move from Response Oriented Architecture(ROA) to Service Oriented Architecture (SOA)

Conclusion

I hope you get to learn from this article teaches you about REST API, HTTP status code, REST verbs, and building with SPA. It's a long read, and I hope you find it worth it.

Kindly share your suggestion and comments, feedback in the comment section below.

You can also learn more about REST API on different platforms on the web browser.

Web Services

atanda nafiu — Wed, 17 May 2023 16:57:25 +0000

Testing and processes in web service are still much more complex with advancements in technology. The tech giants have raised the bar by addressing the need for application development, and its scale from the likes of Amazon, Google, Facebook, and Microsoft is exactly what makes web services possible.

Understanding how web service works, and what it takes to bring these processes to life. You will get to know in this article.

What are web services
How The Web Service Works
Different Types of Web Services
SOAP(Simple Object Access Protocol)
REST(Representational State Transfer)
WSDL(Web Service Description Language)
The Difference Between Web Services and Web API
Conclusion

What are web services

A web service is a service software that is available on the internet either private or public networks, which uses a standardized messaging protocol to communicate with different computer systems. It makes peer-to-peer communication easier and not platform specific. The web service uses a standardized XML messaging system and JSON to transfer machine-processable file format through HTTP.

How The Web Service Works

A client invokes a series of web services by sending an XML message(request) to the server and then waiting for a corresponding response in the same format which hosts the web services. These requests are made possible through RPC(Remote Procedure Calls), RPC calls to methods are hosted by a web service. For example, Google provides a cloud platform that runs apps, host site, and store data via cloud.google.com. The programming language with the likes of Golang, Python, and more would have the ability to communicate with the web service.
It is more like a road between two endpoints where messages are transferred smoothly, and two individual programmable entities communicate with each other through API(Application programmable interface).

Different Types of Web Services

These are prominent ones that have evolved:

UDDI(Universal Description Discovery and Integration): UDDI is an XML-based(Extensible Markup Language) standard for publishing, detailing, and recovery of information about web services. It's mainly an internal registry for businesses globally. This includes XML schema for SOAP messages that define a set of documents to describe the business and service information. Before you can publish your business entity and web service to a public registry, you must first register the business entity with a UDDI registry. UDDI registries come in two forms, public and private registries. Both comply with the same specifications. A public registry is a collection of peer directories that contain information about businesses and services, while a private registry enables you to publish and test your internal business application in a secure, private environment.

XML-RPC(Remote procedure call):
XML-RPC is one of the simplest and foolproof XML protocols to exchange data between a wide variety of devices on a network. It's a remote procedure call that uses HTTP as the transport and XML as the encoding. Rpc gives developers a mechanism for defining interfaces that can be called over a network. The interface can be as simple as a function call or as complex as a large API.

SOAP(Simple Object Access Protocol):
SOAP is an XML-based protocol for accessing data and documents over HTTP or SMTP(Simple Mail Transfer Protocol). It has some specifications that could be used across all applications. Exchanging data between applications is crucial in today's world, but data exchange between these heterogeneous applications would be complex. SOAP was designed to work with XML over HTTP and has some sort of specification that could be used across all applications.

REST(Representational State Transfer):
REST is a web standard-based architecture that uses HTTP protocol. It defines a set of methods to build a web API (Application Programming Interface) due to its simplicity and client fondly nature. The main benefit of REST is statelessness, which means does not store any information about the client, instead, every request contains information for the server to process its request.
Objects in REST are always manipulated from the URL(Uniform Resources Identifier)/IDs and payloads are used to send and return information that is too large to be handled as a parameter. The payload is of a variety of different forms including XML, JSON, and HTML.

WSDL(Web Service Description Language): WDDI Is an XML-based interface description language that tells the client application the functionality offered by a web service. WSDL description of a web service that provides a machine-processable description of how the service can be called structure to return parameters it's expected. It specifies the method of the service and the location of the service with the following elements types, messages, port type, and binding.

The Difference Between Web Services and Web API

Both web service and web API are modern software architectures, that are mistaken for each other which makes it difficult to distinguish.
We talked about web services at the beginning of this article.
A web API is a protocol that allows applications to communicate with different applications that can be exposed through local files, such as (.H file in C/C++ program and .go in Golang to allow two local application)ons to communicate with each other and it doesn't require a network to communicate with a single device.
With the explanation above it comes down to that a web service is a protocol and standard use for exchanging data between systems or applications, it must be accessed through the internet, whereas web API is a software interface that allows two applications to interact with each other over the Internet.

Conclusion

Web services and web API makes the Internet more accessible than ever before through different medium, with the help of tech giants companies advancing the web service and more accessible over the Internet, though it's still complex. But is rapidly growing over time.

If you're looking to improve your knowledge or you want to explore web services it is advised you dive in and enjoy the world of web services.

DEV Community: atanda nafiu

Build Performant Servers with gRPC and Protocol Buffers

What are Protocol Buffers

Why Protocol Buffers are Needed

Prerequisites

Types of Protocol Buffers

Scalar Values

Enumeration and Repeated Values

Repeated value

Nested Field

Protocol Buffer Compiler (protoc)

Environment and Folder Setup

Initialize Project

Create Folders and Server/Client Files

Server and Client

Introduction to Google Remote Procedure Call (gRPC)

The advantages of gRPC over JSON, HTTP, and REST are as follows:

Bidirectional streaming with gRPC and Protobuf in Go

Creation of server and client files

The Client file

Conclusion

Beginner's Guide to RPC in Golang: Understanding the Basics

What is RPC

Prerequisites

Step 1: Setting Up Your Project

Step 2: Create The RPC Server

Step 3: Create The RPC Client

JSON RPC Using Gorilla RPC

Implementing The RPC JSON Server

Conclusion

Understanding the Role of Middleware in Golang

What is Middleware

Basic Middleware

A Real-world Example of Middleware with Multiple and Chaining Middleware

Conclusion

REST API Best Practice: Understanding Verbs and status code

Table of Contents

The REST Web Verbs

REST API Verbs

Path parameters vs Query parameters

Cross-Origin Resources Sharing(CROS)

HTTP Status Code

REST API With Single Page Application(SPA)

The Old way of data flow in SPA

The Modern Way of Data Flow in SPA Through REST

Conclusion

Web Services

Table of Contents

What are web services

How The Web Service Works

Different Types of Web Services

The Difference Between Web Services and Web API

Conclusion