An Ultra-Simplified Introduction to Backend for Frontend Developers
By: Naveen Anto
Tags: Backend Development, Front End Development

Introduces a few backend concepts and jargons to Front-end developers

Disclaimer:

The main aim of this post is just to introduce bits and pieces of backend and is no way a guide to backend development. To add to this, I’m NO EXPERT so read with caution!

Atlantic & Pacific oceans don’t mix

Just like how the entire ocean is just one body of water but there’s an invisible wall between the Atlantic & Pacific ocean, I consider Frontend and Backend development to be like that. They are the same… wait… are they?

Key for the readers:

FED => Front-End Developer | BED => Back-End Developer

MD => My Definition | SJ => Scary Jargons

Part 1: Communicating with Server

Server

From a front-end perspective, a server is a remote computer running some function that can be called from our client-code.

SJ: A cluster is a bunch of servers, used mainly to get some parallel work done.

API

As a developer, we know how to call a function of the class (line 18 & 22). But if the same function exists in the server (remote machine), then we need a mechanism to call the function on the remote server.

MD: This method of a client being able to call a function in the server is defined using an API (Application Programming Interface)

Fig 1.1: Mental mapping from a local function call to GET API call

Fig 1.2: Mental mapping from a local function call to a POST API call

The above diagrams provide one way of thinking about translating a local function call to an API query on a remote server. The URL mapped above follows the REST style of calling a server. However, more client-oriented methods like GraphQL are quickly getting popular.

How the server maps the URL to the appropriate function call is done as part of server code (mostly by frameworks)

SJ:

1. REST is a style of defining the API

2. Swagger is like the server’s personal postman

3. OpenAPI is a set of standardization rules for REST API

Advanced:

One of the main advantages of thinking API, in terms of calling a function, is the ability to relate it to gRPC (where RPC = Remote Procedure Call). gRPC works over HTTP/2 thus provides serverside streaming, multiplexing, etc… In addition, it generates client code to communicate with the server (how cool is that!)

Also, have a lookout for QUIC!

Serialization Deserialization (SerDes)

When calling a local function, the parameter object is shared through the memory.

Fig 2.1: Caller and callee function share object from memory during the local invocation

But when calling a remote function hosted in the server, we need the following two conditions to be satisfied

The parameter sent from the client code (or response from server) has to be converted to bytes so that they can be transferred through the wire (internet) to the remote server Once the bits reach the destination, we need a way to convert the request (or response) bytes to the appropriate object type that our programming language understands

MD: This process of converting the object to strings (or bytes) and converting them back to object is called Serialization and Deserialization respectively. One way that most of us are familiar with is to use JSON.