DEV Community: Mohamed Elmorsy

🚀 Check out my CoderLegion profile & latest post! 🏆 Points: 631 | 🎱 Badges: 4 | 👥 Followers: 1 | 📄 Posts: 1 Latest post: "What is? — A Backend Developer Learning in Public" Read it here: https://coderlegion.com/19549/what-is-a-backend-developer-lear

Mohamed Elmorsy — Fri, 05 Jun 2026 08:58:44 +0000

What is? — A Backend Developer Learning in Public - Coder Legion

## Hello Everyone If this title caught your attention, feel free to hit the ❤️ button — it really helps! Welcome to the **"What is?"** series. In this series, I’ll share everything new I discover during my programming journey as a...

coderlegion.com

What Is GraphQL?

Mohamed Elmorsy — Fri, 05 Jun 2026 07:00:00 +0000

You've been building REST APIs — one endpoint for users, another for posts, another for comments. The client makes three requests, stitches the data together, and half of it gets thrown away because it wasn't needed in the first place.

GraphQL was built to fix exactly that. It gives the client full control over what data it receives. One request. Exactly what you asked for. Nothing more, nothing less.

The Problem REST Couldn't Solve

Before understanding GraphQL, you need to understand the two problems that drove its creation.

Over-fetching

The server returns more data than the client needs.

GET /users/123

Response:
{
  "id": 123,
  "name": "Anne",
  "email": "anne@example.com",
  "phone": "...",
  "address": "...",
  "createdAt": "...",   ← you didn't need any of this
  "updatedAt": "..."    ← but the server sent it anyway
}

The client only needed name and email — but it downloaded the whole object every time.

Under-fetching

One endpoint doesn't return enough, so the client has to make multiple requests.

GET /users/123          → gets the user
GET /users/123/posts    → gets their posts
GET /users/123/followers → gets their followers

Three round trips to the server just to render one screen. On a mobile network, that cost is real.

GraphQL's answer: Let the client write the query. The server returns exactly what was asked.

What Is GraphQL?

GraphQL is a query language for your API and a runtime for executing those queries. It was created by Facebook in 2012, open-sourced in 2015, and is now maintained by the GraphQL Foundation.

Unlike REST, which exposes multiple URL endpoints, GraphQL exposes a single endpoint — typically POST /graphql. The client sends a query in the request body describing exactly what it wants, and the server responds with only that data.

Key characteristics:

Single endpoint — everything goes through POST /graphql
Client-driven — the client defines the shape of the response
Strongly typed — every field has a declared type in the schema
Introspective — clients can query the API to discover its own structure

Core Concepts

1. Schema

The schema is the contract between client and server. It defines every type, every field, and every operation the API supports. It is written in SDL (Schema Definition Language):

type User {
  id: ID!
  name: String!
  email: String!
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
  body: String!
  author: User!
}

type Query {
  user(id: ID!): User
  posts: [Post!]!
}

type Mutation {
  createUser(name: String!, email: String!): User!
  deleteUser(id: ID!): Boolean!
}

The ! means the field is non-nullable — it will never return null.

2. Query

A Query is a read operation — the equivalent of GET in REST. The client specifies exactly which fields it wants:

query {
  user(id: "123") {
    name
    email
    posts {
      title
    }
  }
}

Response:

{
  "data": {
    "user": {
      "name": "Anne",
      "email": "anne@example.com",
      "posts": [
        { "title": "My first post" },
        { "title": "Learning GraphQL" }
      ]
    }
  }
}

One request. Nested data. Only the fields that were asked for.

3. Mutation

A Mutation is a write operation — the equivalent of POST, PUT, or DELETE in REST:

mutation {
  createUser(name: "Anne", email: "anne@example.com") {
    id
    name
  }
}

Response:

{
  "data": {
    "createUser": {
      "id": "456",
      "name": "Anne"
    }
  }
}

4. Subscription

A Subscription is a real-time operation. The client subscribes to an event, and the server pushes data whenever that event occurs — powered by WebSockets under the hood:

subscription {
  newMessage(roomId: "general") {
    content
    sender {
      name
    }
  }
}

The server pushes a new message to every subscribed client as soon as it is sent.

GraphQL vs REST

Feature	REST	GraphQL
Endpoints	Multiple (`/users`, `/posts`, ...)	Single (`/graphql`)
Data shape	Fixed by the server	Defined by the client
Over-fetching	Common	Eliminated
Under-fetching	Common	Eliminated
Versioning	`/v1/`, `/v2/`	Schema evolution via deprecation
Type system	None (unless OpenAPI)	Built-in, strongly typed
Real-time	Requires polling or SSE	Native via Subscriptions
Learning curve	Low	Medium
Best for	Simple CRUD APIs	Complex, nested, or client-diverse data

Using GraphQL in Go

GraphQL over HTTP is just a POST request with a JSON body — no special library needed for the client side.

Sending a GraphQL Query

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
)

type GraphQLRequest struct {
    Query     string         `json:"query"`
    Variables map[string]any `json:"variables,omitempty"`
}

type GraphQLResponse struct {
    Data   map[string]any `json:"data"`
    Errors []struct {
        Message string `json:"message"`
    } `json:"errors,omitempty"`
}

func main() {
    url := "https://api.example.com/graphql"

    // 1. Build the request body
    gqlReq := GraphQLRequest{
        Query: `
            query GetUser($id: ID!) {
                user(id: $id) {
                    name
                    email
                    posts {
                        title
                    }
                }
            }
        `,
        Variables: map[string]any{
            "id": "123",
        },
    }

    body, err := json.Marshal(gqlReq)
    if err != nil {
        panic(err)
    }

    // 2. Send the POST request
    resp, err := http.Post(url, "application/json", bytes.NewBuffer(body))
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    // 3. Read and decode the response
    raw, _ := io.ReadAll(resp.Body)

    var gqlResp GraphQLResponse
    if err := json.Unmarshal(raw, &gqlResp); err != nil {
        panic(err)
    }

    // 4. Check for GraphQL-level errors
    if len(gqlResp.Errors) > 0 {
        fmt.Printf("GraphQL Error: %s\n", gqlResp.Errors[0].Message)
        return
    }

    fmt.Printf("Response: %+v\n", gqlResp.Data)
}

Sending a Mutation

gqlReq := GraphQLRequest{
    Query: `
        mutation CreateUser($name: String!, $email: String!) {
            createUser(name: $name, email: $email) {
                id
                name
            }
        }
    `,
    Variables: map[string]any{
        "name":  "Anne",
        "email": "anne@example.com",
    },
}

Building a GraphQL server in Go? The most popular library is gqlgen — it generates type-safe Go code directly from your schema. Install it with go get github.com/99designs/gqlgen.

Summary

Concept	What It Is
GraphQL	A query language and runtime for APIs
Schema	The typed contract defining all available data and operations
Query	A read operation — asks for specific fields
Mutation	A write operation — creates, updates, or deletes data
Subscription	A real-time operation — server pushes events to the client
Single endpoint	All operations go through one URL (`POST /graphql`)

What Is REST API ?

Mohamed Elmorsy — Wed, 03 Jun 2026 14:00:00 +0000

A REST API (Representational State Transfer API) enables communication between a client and a server over HTTP. It exchanges data — typically in JSON format — using standard web protocols, making it one of the most widely adopted architectural styles for building web services today.

If you're wondering what is HTTP method or what is HTTP at all, you can check my previous article What Is HTTP & HTTPS ?.

Key characteristics of a REST API:

Uses standard HTTP methods: GET, POST, PUT, and DELETE
The client sends requests to server endpoints (URLs)
The server responds with the requested data in formats like JSON, XML, HTML, or binary (e.g., images)

Note: REST is an architectural style that defines how APIs should be designed, whereas HTTP is the protocol used to transfer data. They work together, but they are not the same thing.

Common HTTP Methods

1. GET

GET is used to retrieve data from the server without modifying anything. It is idempotent — calling it multiple times produces the same result.

Common response codes:

Status Code	Meaning
`200 OK`	Data found and returned successfully
`404 Not Found`	The requested resource does not exist
`400 Bad Request`	The request was malformed

Example request:

GET /users/123

This request fetches the data for the user with ID 123.

Go implementation:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    client := &http.Client{}
    url := "https://api.example.com/users/123"

    req, err := http.NewRequest(http.MethodGet, url, nil)
    if err != nil {
        panic(err)
    }
    req.Header.Set("Content-Type", "application/json")

    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    fmt.Printf("Response Status: %s\n", resp.Status)
}

2. POST

POST is used to create a new resource on the server. On success, it returns 201 Created, often with a Location header pointing to the newly created resource.

Example request:

POST /users
Content-Type: application/json

{
  "name": "Anne",
  "email": "anne@example.com"
}

This request creates a new user with the provided data.

Go implementation:

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "net/http"
)

type User struct {
    Name  string `json:"name"`
    Email string `json:"email"`
}

func main() {
    url := "https://api.example.com/users"

    user := User{
        Name:  "Anne",
        Email: "anne@example.com",
    }

    jsonData, err := json.Marshal(user)
    if err != nil {
        panic(err)
    }

    resp, err := http.Post(url, "application/json", bytes.NewBuffer(jsonData))
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    fmt.Printf("Response Status: %s\n", resp.Status)
}

3. PUT

PUT is used to update an existing resource or create it if it does not exist. Unlike PATCH, it requires the complete resource to be sent in the request body — it replaces the resource entirely.

Example request:

PUT /users/123
Content-Type: application/json

{
  "name": "Anne",
  "email": "anne@example.com"
}

This request updates the user with ID 123, or creates a new one if that user does not exist.

Go implementation:

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "net/http"
)

type User struct {
    Name  string `json:"name"`
    Email string `json:"email"`
}

func main() {
    client := &http.Client{}
    url := "https://api.example.com/users/123"

    user := User{
        Name:  "Anne",
        Email: "anne@example.com",
    }

    jsonData, err := json.Marshal(user)
    if err != nil {
        panic(err)
    }

    req, err := http.NewRequest(http.MethodPut, url, bytes.NewBuffer(jsonData))
    if err != nil {
        panic(err)
    }
    req.Header.Set("Content-Type", "application/json")

    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    fmt.Printf("Response Status: %s\n", resp.Status)
}

4. DELETE

DELETE is used to remove a resource identified by its URI. On successful deletion, the server returns 200 OK (with a response body) or 204 No Content (with no body).

Example request:

DELETE /users/123

This request deletes the user with ID 123.

Go implementation:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    client := &http.Client{}
    url := "https://api.example.com/users/123"

    req, err := http.NewRequest(http.MethodDelete, url, nil)
    if err != nil {
        panic(err)
    }
    req.Header.Set("Content-Type", "application/json")

    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    fmt.Printf("Response Status: %s\n", resp.Status)
}

Summary

Method	Purpose	Success Code
`GET`	Retrieve a resource	`200 OK`
`POST`	Create a new resource	`201 Created`
`PUT`	Update or replace a resource	`200 OK`
`DELETE`	Remove a resource	`200 OK` / `204 No Content`

Understanding these four methods covers the majority of real-world REST API interactions. In a future article, we'll dive into PATCH (partial updates), authentication with API keys and JWT, and how to handle errors properly on both the client and server sides

REST is powerful, but what if the server could give you exactly what you ask for — nothing more, nothing less? That's the promise of GraphQL. Next up, we break it down.

What Is Websocket ?

Mohamed Elmorsy — Tue, 02 Jun 2026 13:00:00 +0000

What Is WebSocket?

You open a live football score page. The score updates every few seconds — but you never clicked refresh. You open a chat app and your friend's message appears instantly. You watch a real-time stock dashboard and the numbers change as trades happen.

None of this is possible with plain HTTP. Every one of those features runs on WebSocket.

The Problem HTTP Can't Solve

HTTP follows a strict rule: the client asks, the server answers, the connection closes. This works perfectly for loading pages and fetching data. But it falls apart for anything real-time.

Before WebSocket, developers hacked around this with two approaches:

Polling

The client asks the server "any updates?" every few seconds — whether there are updates or not.

Client → "Any new messages?"  Server → "No."
Client → "Any new messages?"  Server → "No."
Client → "Any new messages?"  Server → "Yes! Here's one."

Wasteful. Most requests are empty. Latency depends on the poll interval.

Long Polling

The client sends a request and the server holds it open until it has data to send, then responds and the cycle repeats.

Client → "Any updates?"
Server → [holds the connection...]
Server → [holds the connection...]
Server → "Here's data!"  → connection closes
Client → "Any updates?"  → starts again

Better, but still fundamentally request/response. Every delivery requires reconnecting.

WebSocket's answer: Open one persistent connection. Both sides can send data at any time, in any direction, without asking permission first.

What Is WebSocket?

WebSocket is a communication protocol that provides a persistent, full-duplex channel over a single TCP connection. It was standardized in 2011 as RFC 6455.

Full-duplex means both the client and server can send messages simultaneously and independently — like a phone call, not a walkie-talkie.

Key characteristics:

Persistent connection — stays open until explicitly closed
Full-duplex — server and client both push freely, no turn-taking
Low overhead — no HTTP headers on every message, just a small frame
Real-time — sub-millisecond latency for live data
Built on HTTP — starts as an HTTP request, then upgrades

How WebSocket Works: The Upgrade Handshake

WebSocket does not replace HTTP — it starts with HTTP, then upgrades the connection.

Step 1 — The Client Sends an Upgrade Request

GET /chat HTTP/1.1
Host: api.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

The key headers are Upgrade: websocket and Connection: Upgrade. They tell the server: "I want to switch protocols."

Step 2 — The Server Accepts

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Status code 101 Switching Protocols — the only time you'll see that number. From this point on, the HTTP handshake is over. The TCP connection stays open and is now a WebSocket channel.

Step 3 — Full-Duplex Communication

Client → "Hello!"
Server → "Hi! 3 users online."
Server → "New message from Bob: 'Hey everyone'"   ← server pushes without being asked
Client → "Got it, thanks."
Server → "Bob has left the chat."                 ← server pushes again

When to Use WebSocket

WebSocket is not a replacement for HTTP. Use the right tool for the right job:

Use Case	Use HTTP	Use WebSocket
Fetching user profile	✓
Submitting a form	✓
Live chat		✓
Real-time notifications		✓
Live sports scores		✓
Stock price dashboards		✓
Multiplayer game state		✓
Collaborative editing		✓
File upload	✓
Fetching an API resource	✓

Rule of thumb: If the server needs to push data to the client without the client asking first — use WebSocket. Everything else — use HTTP.

WebSocket in Go

The standard library does not include a WebSocket implementation. The most widely used package is gorilla/websocket.

go get github.com/gorilla/websocket

Building a WebSocket Server

package main

import (
    "fmt"
    "log"
    "net/http"

    "github.com/gorilla/websocket"
)

// upgrader converts an HTTP connection into a WebSocket connection
var upgrader = websocket.Upgrader{
    CheckOrigin: func(r *http.Request) bool {
        return true // allow all origins in development
    },
}

func handleWS(w http.ResponseWriter, r *http.Request) {
    // 1. Upgrade the HTTP connection to WebSocket
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println("Upgrade error:", err)
        return
    }
    defer conn.Close()

    fmt.Println("Client connected:", conn.RemoteAddr())

    // 2. Read and echo messages in a loop
    for {
        messageType, msg, err := conn.ReadMessage()
        if err != nil {
            log.Println("Client disconnected:", err)
            break
        }

        fmt.Printf("Received: %s\n", msg)

        // 3. Send a response back to the same client
        if err := conn.WriteMessage(messageType, msg); err != nil {
            log.Println("Write error:", err)
            break
        }
    }
}

func main() {
    http.HandleFunc("/ws", handleWS)
    log.Println("WebSocket server running on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Building a WebSocket Client

package main

import (
    "fmt"
    "log"

    "github.com/gorilla/websocket"
)

func main() {
    // 1. Dial the WebSocket server (handles the upgrade handshake automatically)
    conn, _, err := websocket.DefaultDialer.Dial("ws://localhost:8080/ws", nil)
    if err != nil {
        log.Fatal("Connection error:", err)
    }
    defer conn.Close()

    // 2. Send a message to the server
    if err := conn.WriteMessage(websocket.TextMessage, []byte("Hello from client!")); err != nil {
        log.Fatal("Write error:", err)
    }

    // 3. Read the server's response
    _, msg, err := conn.ReadMessage()
    if err != nil {
        log.Fatal("Read error:", err)
    }

    fmt.Printf("Server replied: %s\n", msg)
}

Broadcasting to All Connected Clients (Hub Pattern)

Real-world apps need to send messages to all connected clients — not just echo back to one. The standard pattern in Go is a Hub:

package main

import (
    "log"
    "net/http"

    "github.com/gorilla/websocket"
)

// Hub manages all active WebSocket connections
type Hub struct {
    clients    map[*websocket.Conn]bool
    broadcast  chan []byte
    register   chan *websocket.Conn
    unregister chan *websocket.Conn
}

func newHub() *Hub {
    return &Hub{
        clients:    make(map[*websocket.Conn]bool),
        broadcast:  make(chan []byte),
        register:   make(chan *websocket.Conn),
        unregister: make(chan *websocket.Conn),
    }
}

// Run listens for events and manages the client list
func (h *Hub) Run() {
    for {
        select {
        case conn := <-h.register:
            h.clients[conn] = true
            log.Println("Client registered:", conn.RemoteAddr())

        case conn := <-h.unregister:
            if _, ok := h.clients[conn]; ok {
                delete(h.clients, conn)
                conn.Close()
                log.Println("Client unregistered:", conn.RemoteAddr())
            }

        case msg := <-h.broadcast:
            // Send the message to every connected client
            for conn := range h.clients {
                if err := conn.WriteMessage(websocket.TextMessage, msg); err != nil {
                    h.unregister <- conn
                }
            }
        }
    }
}

var upgrader = websocket.Upgrader{
    CheckOrigin: func(r *http.Request) bool { return true },
}

func handleWS(hub *Hub, w http.ResponseWriter, r *http.Request) {
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println("Upgrade error:", err)
        return
    }

    hub.register <- conn

    defer func() {
        hub.unregister <- conn
    }()

    for {
        _, msg, err := conn.ReadMessage()
        if err != nil {
            break
        }
        hub.broadcast <- msg
    }
}

func main() {
    hub := newHub()
    go hub.Run()

    http.HandleFunc("/ws", func(w http.ResponseWriter, r *http.Request) {
        handleWS(hub, w, r)
    })

    log.Println("Chat server running on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

HTTP vs WebSocket

Feature	HTTP	WebSocket
Connection	Opens and closes per request	Stays open persistently
Direction	Client → Server only	Both directions simultaneously
Latency	Per-request overhead	Near zero after handshake
Overhead	Full headers on every message	Small frame header (~2–10 bytes)
Use case	Data fetching, CRUD	Real-time, push, streaming
Protocol upgrade	—	Starts as HTTP, upgrades via `101`
State	Stateless	Stateful

Summary

Concept	What It Is
WebSocket	A protocol for persistent, full-duplex TCP communication
Full-duplex	Both sides can send messages simultaneously
Upgrade handshake	An HTTP `101` exchange that converts the connection
Hub pattern	A Go struct that manages all connections and broadcasts
`gorilla/websocket`	The standard Go library for WebSocket servers and clients

What Is HTTP & HTTPS ?

Mohamed Elmorsy — Sun, 31 May 2026 14:00:00 +0000

Every time you open a browser and visit a website, something invisible but essential happens in the background — your browser and the server are having a conversation. The rules that govern that conversation are called HTTP. And when that conversation needs to be private, we add a layer of security on top, giving us HTTPS.

This is the foundation every web developer should understand before writing a single line of backend code.

What Is HTTP?

HTTP stands for HyperText Transfer Protocol. It is an application-layer protocol that defines how messages are formatted and transmitted between a client (like your browser) and a server (the machine hosting a website or API).

Think of HTTP as a language — both the client and server speak it so they can understand each other. Without HTTP, a browser would have no standard way to ask for a webpage, and a server would have no standard way to respond.

Key characteristics:

Stateless — each request is independent; the server has no memory of previous requests
Text-based — requests and responses are human-readable plain text
Request/Response model — the client always initiates; the server always responds

Want a visual walkthrough? Traversy Media's HTTP Crash Course & Exploration is one of the best video explanations out there. Highly recommended before moving on.

How HTTP Works: The Request/Response Cycle

Every HTTP interaction follows a strict two-step pattern.

Step 1 — The Request

The client (your browser or app) sends a request to the server. A raw HTTP request looks like this:

GET /users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer <token>

It has three parts:

Part	Example	Purpose
Request Line	`GET /users/123 HTTP/1.1`	Method + path + protocol version
Headers	`Content-Type: application/json`	Metadata about the request
Body	`{ "name": "Anne" }`	Data sent with the request (POST/PUT only)

Step 2 — The Response

The server receives the request, processes it, and sends back a response:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "Anne",
  "email": "anne@example.com"
}

It has three parts too:

Part	Example	Purpose
Status Line	`HTTP/1.1 200 OK`	Protocol version + status code
Headers	`Content-Type: application/json`	Metadata about the response
Body	`{ "id": 123, ... }`	The actual data returned

HTTP Status Codes

Status codes are the server's way of telling the client what happened. They are grouped into five families:

![[Pasted image 20260529223910.png]]

Range	Category	Common Examples
`1xx`	Informational	`100 Continue`
`2xx`	Success	`200 OK`, `201 Created`, `204 No Content`
`3xx`	Redirection	`301 Moved Permanently`, `304 Not Modified`
`4xx`	Client Error	`400 Bad Request`, `401 Unauthorized`, `404 Not Found`
`5xx`	Server Error	`500 Internal Server Error`, `503 Service Unavailable`

Rule of thumb: If it starts with 4, you (the client) did something wrong. If it starts with 5, the server broke.

Making HTTP Requests in Go

Go's net/http package gives you everything you need. Here is a complete example that makes a GET request and reads the response body:

package main

import (
    "fmt"
    "io"
    "net/http"
)

func main() {
    resp, err := http.Get("https://api.example.com/users/123")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    // Read the response body
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        panic(err)
    }

    fmt.Printf("Status : %s\n", resp.Status)
    fmt.Printf("Body   : %s\n", string(body))
}

You can also inspect headers directly:

fmt.Println(resp.Header.Get("Content-Type"))

What Is HTTPS?

HTTPS is simply HTTP with a security layer on top — specifically TLS (Transport Layer Security), the modern successor to SSL.

Without HTTPS, all data travels as plain text. Anyone sitting between the client and server — on a public Wi-Fi network, for example — can read it. HTTPS solves this by encrypting the data before it travels.

HTTPS gives you three guarantees:

Confidentiality — data is encrypted; no one in the middle can read it
Integrity — data cannot be tampered with in transit without detection
Authentication — you can trust you are actually talking to the right server

How HTTPS Works: The TLS Handshake

Before any encrypted data is sent, the client and server perform a TLS handshake — a brief negotiation to agree on encryption settings and verify identities.

Here is a simplified view of the steps:

1. CLIENT HELLO  →  "Here are the TLS versions and ciphers I support."

2. SERVER HELLO  ←  "OK, let's use TLS 1.3 and this cipher suite."
                    "Here is my SSL certificate (signed by a trusted CA)."

3. CLIENT        →  Verifies the certificate is valid and trusted.
                    Generates a session key and sends it encrypted.

4. BOTH SIDES       Derive the same symmetric session key.

5. ENCRYPTED        All further communication is encrypted.
   CHANNEL ✓

After the handshake, everything works exactly like regular HTTP — except every message is encrypted. That is all HTTPS is: HTTP + TLS encryption.

HTTP vs HTTPS

Feature	HTTP	HTTPS
Port	`80`	`443`
Encryption	✗ None	✓ TLS/SSL
Data in transit	Plain text	Encrypted
Certificate required	✗	✓ (from a CA like Let's Encrypt)
URL prefix	`http://`	`https://`
Browser indicator	⚠ Not Secure	🔒 Secure
SEO ranking	Lower	Higher (Google preference)
Use case	Internal tooling only	Everything public-facing

Practical note: There is no valid reason to use plain HTTP for a public-facing service in 2025. Free SSL certificates are available from Let's Encrypt. Tools like Caddy and Nginx handle the setup automatically.

Making HTTPS Requests in Go

Go's http.Get and http.Client use HTTPS by default when you pass an https:// URL — no extra setup needed. The TLS handshake happens automatically under the hood.

package main

import (
    "fmt"
    "io"
    "net/http"
)

func main() {
    // Go handles TLS automatically — just use https://
    resp, err := http.Get("https://api.example.com/users/123")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        panic(err)
    }

    fmt.Printf("Status : %s\n", resp.Status)
    fmt.Printf("Body   : %s\n", string(body))
}

If you need to skip TLS verification in a local development environment (never in production), you can configure the transport:

package main

import (
    "crypto/tls"
    "fmt"
    "io"
    "net/http"
)

func main() {
    // ⚠ Only use InsecureSkipVerify in local dev — never in production
    transport := &http.Transport{
        TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
    }
    client := &http.Client{Transport: transport}

    resp, err := client.Get("https://localhost:8443/health")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    body, _ := io.ReadAll(resp.Body)
    fmt.Printf("Status : %s\n", resp.Status)
    fmt.Printf("Body   : %s\n", string(body))
}

Summary

Concept	What It Is
HTTP	The protocol defining how clients and servers communicate
Request	A client message containing a method, path, headers, and optional body
Response	A server reply containing a status code, headers, and optional body
Status Code	A 3-digit number telling the client what happened
HTTPS	HTTP with TLS encryption layered on top
TLS Handshake	A negotiation that sets up the encrypted channel before data flows

What Is an API? — A Complete Guide for Developers

Mohamed Elmorsy — Mon, 25 May 2026 12:58:06 +0000

APIs are everywhere — every time you check the weather, stream a video,
or place an order online, an API is working behind the scenes. In this
post, I'll break down what APIs are, how they work, their types, and at
the end, we'll build a simple one with Go.

What Is an API?

API stands for Application Programming Interface. It's a set of
rules and structures built to make it easy for applications and systems
to talk with each other.

Think of it like this — imagine you're at a restaurant:

You (the client) place an order with the waiter
The waiter (the API) conveys your request to the chef
The chef (the server) prepares the food and gives it back to the waiter
The waiter delivers it back to your table (the response)

That's exactly how APIs work in software — the API takes a request,
sends it to the server, retrieves the data, and returns the response.

What Are APIs Used For?

APIs are the backbone of modern software. Almost every app or website
you use depends on them:

Google — YouTube, Search, Gemini — all communicate with servers through APIs
Netflix — streams video content by fetching data from its servers via APIs
Amazon — processes orders, payments, and inventory through APIs
Your browser — uses APIs to fetch web pages from servers
This platform — uses APIs to load posts, comments, and profiles

As you can see, APIs are almost everywhere.

How Do APIs Work?

APIs operate through a request-response cycle between a client and a server:

Request — the client sends a request to an API endpoint (a URL)
Processing — the API forwards the request to the server
Response — the server processes it and sends back the data
Delivery — the API returns the server's response to the client

This communication happens over HTTP/HTTPS, with security handled
via headers, tokens, or cookies.

Types of API Architectures

APIs come in many types. The 7 most common ones are:

API Type	Description
REST	Uses HTTP methods (GET, POST, PUT, DELETE). Stateless and widely used for web APIs.
SOAP	XML-based protocol with strict standards. Common in enterprise and legacy systems.
gRPC	High-performance RPC framework by Google using Protocol Buffers. Great for microservices.
WebSocket	Full-duplex persistent connection. Ideal for real-time apps like chat.
WebHooks	Event-driven — server pushes data to a URL when something happens. No polling needed.
GraphQL	Query language for APIs. Client requests exactly the data it needs, nothing more.
WebRTC	Peer-to-peer communication for real-time audio, video, and data in the browser.

I'll write a dedicated post explaining each one in depth — follow me
if you're interested.

API Authentication

One thing you'll always deal with when working with APIs is
authentication — proving who you are before accessing data.
The most common methods are:

API Keys — a simple token passed in the request header. Easy but less secure.
JWT (JSON Web Token) — a signed token containing user info. Common in REST APIs.
OAuth 2.0 — used when you want to log in with Google/GitHub. More complex but very secure.

API Integration

API Integration connects two or more systems so they can exchange
data automatically. Examples:

Connecting an e-commerce store to a payment gateway (Stripe API)
Syncing a CRM like Salesforce with a marketing platform
Sending automatic emails when a user signs up (SendGrid API)

API Testing

Before shipping an API, you need to test it. The main types of testing are:

Unit Testing — test individual endpoints in isolation
Integration Testing — test how multiple services work together
Security Testing — check for vulnerabilities like unauthorized access
Performance Testing — measure how the API handles load

Popular Tools

Tool	Purpose
Postman	Manual and automated API testing
SoapUI	SOAP & REST API testing
JMeter	Load and performance testing
Apigee	Enterprise API management

Let's Build a Simple REST API in Go

Enough theory — let's build one. We'll create a simple REST API that
returns a list of users using only Go's standard library.

Setup

mkdir go-api && cd go-api
go mod init go-api

main.go

package main

import (
    "encoding/json"
    "fmt"
    "log"
    "net/http"
)

type User struct {
    ID    int    `json:"id"`
    Name  string `json:"name"`
    Email string `json:"email"`
}

var users = []User{
    {ID: 1, Name: "Mohamed", Email: "mohamed@example.com"},
    {ID: 2, Name: "Ali", Email: "ali@example.com"},
}

func getUsers(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(users)
}

func getUser(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    idStr := r.URL.Query().Get("id")
    for _, u := range users {
        if fmt.Sprintf("%d", u.ID) == idStr {
            json.NewEncoder(w).Encode(u)
            return
        }
    }
    http.Error(w, "User not found", http.StatusNotFound)
}

func main() {
    http.HandleFunc("/users", getUsers)
    http.HandleFunc("/user", getUser)

    log.Println("Server running on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Run it

go run main.go

Test it

# Get all users
curl http://localhost:8080/users

# Get a specific user
curl "http://localhost:8080/user?id=1"

Response

[
  { "id": 1, "name": "Mohamed", "email": "mohamed@example.com" },
  { "id": 2, "name": "Ali", "email": "ali@example.com" }
]

That's a working REST API in Go — no frameworks, just the standard library.

TL;DR

An API lets two systems communicate with each other
They work through a request → process → response cycle
The 7 main types are REST, SOAP, gRPC, WebSocket, WebHooks, GraphQL, WebRTC
Authentication is handled via API Keys, JWT, or OAuth
You can build a basic REST API in Go with just the standard library

Resources

I built this example using Go's standard library to show how it works
under the hood — but I'm curious: do you prefer using a framework
like Gin or Fiber for your APIs? Let me know why in the comments!

Follow me for Part 2 where I'll dive deep into REST vs GraphQL and
build a more complete API with authentication in Go.

Mohamed ElmorsyFollow

A human who is in love with code. I'll share every bit of knowledge along my path — until I die.

What is Go? — The Language Google Built to Fix Everything

Mohamed Elmorsy — Sun, 24 May 2026 08:29:36 +0000

Go is a high-level, general-purpose programming language that is statically typed and compiled. It was designed at Google in 2007 by Robert Griesemer, Rob Pike, and Ken Thompson.

It was built to combine the best of two worlds:

The speed and static typing of C
The readability and simplicity of Python

What does it offer over other languages?

Why Go?

No more npm install fatigue: The standard library is massive.
Built-in Concurrency: Goroutines make scaling easy.
Fast Compilation: It feels like a scripting language but runs like C.

Go has a large and active community, and a powerful standard library — which is a huge deal if you're coming from JavaScript or TypeScript, where everything depends on npm packages. In Go, you can build a production-ready HTTP server with zero external dependencies.

It also has an almost linear learning curve. The language is intentionally small — there are very few concepts to learn before you can start building real things.

Go's biggest superpower: Concurrency

This is where Go truly stands out from almost every other language.

Go has built-in concurrency through goroutines and channels. A goroutine is like a lightweight thread — you can run thousands of them simultaneously with almost no memory overhead. This makes Go extremely powerful for building APIs, microservices, and any system that needs to handle many things at once.

Compare that to JavaScript, which is single-threaded, or Java, where threads are expensive. Go was designed from day one with concurrency in mind.

See the difference in code
Standard call:
findUser(1)

Concurrency call:
go findUser(1)

(Yes, it's really that simple!)

How simple is it to get started?

Here's a working HTTP server in just a few lines:

package main

import (
    "log"
    "net/http"
)

func main() {
    mux := http.NewServeMux()

    mux.HandleFunc("POST /", func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        w.Write([]byte("Hello"))
    })

    log.Fatal(http.ListenAndServe(":8080", mux))
}

With just these few lines, you have a server running on port 8080 — no need to install any packages or use a framework. That's Go's philosophy: simple by default, powerful when you need it.

Where does Go shine?

If you think Go's simplicity means it's weak or can't handle complex systems — you're completely wrong.

I first realized the power of Go when I replaced a Node.js service with a Go binary. The memory usage dropped significantly, and the code was actually easier to read and maintain.

Go is used to build some of the most demanding software in the world:

Docker — the entire container ecosystem is built in Go
YouTube — uses Go for backend services handling billions of requests
Uber — uses Go for its geofence service, which handles real-time user location and product availability
Twitch — uses Go to handle massive live-streaming infrastructure
Kubernetes — the most widely used container orchestration platform, written entirely in Go

Wrapping up

Go was built to solve real problems: slow compile times, complex concurrency, and bloated dependencies. It succeeds at all three. Whether you're building a small CLI tool or a system serving millions of users, Go scales with you.

In the next episode, we'll dive into Go's type system — how it thinks differently from what you're used to, and why that's actually a good thing.

If you found this helpful, drop a like and follow the series — more episodes are coming. 🚀

References & Further Reading

What do you think?

If you're coming from JavaScript, Python, or Java — what is the one thing that has kept you from trying Go? Or, if you're already a Gopher, what's the one feature you wish every other language had?

Let's chat in the comments! 👇

What is? — A Backend Developer Learning in Public

Mohamed Elmorsy — Fri, 22 May 2026 16:08:56 +0000

Hello Everyone 👋

If this title caught your attention, feel free to hit the ❤️ button — it really helps!

Welcome to the "What is?" series.

In this series, I’ll share everything new I discover during my programming journey as a learner, just like many of you. The goal is simple: learn together and explain concepts in the easiest way possible.

This series will mainly focus on Backend Development because that’s the field I’m currently learning and working in 😂.

Most of the posts will be about:

Golang
Backend fundamentals
APIs
Databases
Authentication
WebSockets
Testing
And other backend-related topics

I believe these posts can help developers who are just getting started.

Why Am I Writing This Series?

“If you can't explain it simply, you don't understand it well enough.”
— Often attributed to Albert Einstein

One of the best ways to truly understand something is to explain it to someone else.

Writing these posts pushes me to:

Understand topics more deeply
Simplify complicated concepts
Practice communication skills
Document my learning journey

Sometimes documentation feels overwhelming, and beginner tutorials skip important details. I want this series to be beginner-friendly and focused on real understanding instead of just copying code.

What You Can Expect

The goal is to create posts that are:

Simple and direct
Beginner-friendly
Focused on understanding concepts
Based on real learning experiences

I’ll try to explain things the way I wish they had been explained to me when I started learning backend development.

Follow My Journey 🚀

If you like the idea, feel free to connect with me:

This is my first post on DEV Community, and I’m excited to start this journey with you.

See you in the first "What is?" post �

DEV Community: Mohamed Elmorsy

🚀 Check out my CoderLegion profile & latest post! 🏆 Points: 631 | 🎱 Badges: 4 | 👥 Followers: 1 | 📄 Posts: 1 Latest post: "What is? — A Backend Developer Learning in Public" Read it here: https://coderlegion.com/19549/what-is-a-backend-developer-lear

What is? — A Backend Developer Learning in Public - Coder Legion

What Is GraphQL?

The Problem REST Couldn't Solve

Over-fetching

Under-fetching

What Is GraphQL?

Core Concepts

1. Schema

2. Query

3. Mutation

4. Subscription

GraphQL vs REST

Using GraphQL in Go

Sending a GraphQL Query

Sending a Mutation

Summary

Further Reading & Watch

What Is REST API ?

Common HTTP Methods

1. GET

2. POST

3. PUT

4. DELETE

Summary

What Is Websocket ?

What Is WebSocket?

The Problem HTTP Can't Solve

Polling

Long Polling

What Is WebSocket?

How WebSocket Works: The Upgrade Handshake

Step 1 — The Client Sends an Upgrade Request

Step 2 — The Server Accepts

Step 3 — Full-Duplex Communication

When to Use WebSocket

WebSocket in Go

Building a WebSocket Server

Building a WebSocket Client

Broadcasting to All Connected Clients (Hub Pattern)

HTTP vs WebSocket

Summary

Further Reading & Watch

What Is HTTP & HTTPS ?

What Is HTTP?

How HTTP Works: The Request/Response Cycle

Step 1 — The Request

Step 2 — The Response

HTTP Status Codes

Making HTTP Requests in Go

What Is HTTPS?

How HTTPS Works: The TLS Handshake

HTTP vs HTTPS

Making HTTPS Requests in Go

Summary

Further Reading & Watch

What Is an API? — A Complete Guide for Developers

What Is an API?

What Are APIs Used For?

How Do APIs Work?

Types of API Architectures

API Authentication

API Integration

API Testing

Popular Tools

Let's Build a Simple REST API in Go

Setup

main.go

Run it

Test it

Response

TL;DR

Resources

Mohamed ElmorsyFollow

What is Go? — The Language Google Built to Fix Everything

What does it offer over other languages?

Why Go?

Go's biggest superpower: Concurrency

How simple is it to get started?