What are immutables?

An immutable is a type that can’t be modified after it has been created.

The most common way to define an object in Java is by instantiating a class; Once the class is instantiated, we can modify its properties directly or by calling methods that modify them. Let’s look at an example of a mutable object:

1
2
3
public class MyClass {
  public int value;
}

This is a very simple type that we can instantiate and modify:

1
2
MyClass obj = new MyClass();
obj.value = 4;

Immutables differ from these types in that once instantiated, they can’t be modified (Properties can’t be changed and there are no methods to modify them).

In a previous article, I explained a little about how Language Server Protocol clients work. This time I’m going to explain how we can take advantage of this protocol in Vim.

Installing vim-lsp

Configuring vim-lsp is a little more complicated than installing other plugins, because it requires many pieces to be put together in order for it to work correctly.

Let’s start by installing vim-lsp:

1
2
cd ~/.vim/pack/my-plugins/start
git clone https://github.com/prabirshrestha/vim-lsp.git

There are a lot of IDEs out there that offer features like auto complete, go to definition, etc. Traditionally each IDE has logic for parsing and understanding code in a project, and plugs this understanding into its UI. How good the IDE’s understanding of a particular language together with their user experience are their most powerful selling points.

In the past, different IDEs that supported the same language had their own proprietary code that gave them insights into a programming language.

LSP is an open source standard created by Microsoft. It defines a protocol for a program that understands a programming language to talk to another program (typically an IDE) that wants to take advantage of these features. This protocol allows anybody to build a server that understands a language and make it available to the world. Programmers can leverage these servers to provide powerful tools or IDEs.

The server

The server takes care of understanding the structure of a program and implementing an API to share this understanding.

There are various server implementations out there and they vary widely in the number of features they support.

Helm is a package manager for Charts.

You might already be familiar with package managers like the ones used for Linux distributions (apt, yum, etc.). In Linux, a package manager takes care of installing, updating, configuring and removing packages from a machine. Helm does something similar, but with Kubernetes applications.

Charts are a set of files that describe a Kubernetes application. These files must be laid out in a folder structure that follows a convention that looks like this:

1
2
3
4
5
.
├── Chart.yaml
├── templates
│   └── application.yaml
└── values.yaml

The Chart.yaml contains some information about the Chart. It looks something like this:

I wrote an article not long ago showing how to get started with Kubernetes.

In that article we started pods by passing options as command line arguments to kubectl create. This works for demostration purposes, but it’s not usually the way Kubernetes deployments are managed.

Having files that describe the characteristics of our deployment allows us to add these files to source control, which gives us the benefit of keeping track of changes as well as making it easy to change things like the number of pods without having to remember all other details.

For this article, I’ll assume you already have a Kubernetes cluster and a configured kubectl client. If you don’t have these ready, you might want to take a look at my introduction to Kubernetes to get those set up.

GraphQL advertises itself as a query language for APIs. To understand what this means, let’s compare it with REST.

In REST, we usually have endpoints that give us information about a resource, for example: GET /user/1 could return something like:

1
2
3
4
5
{
  "id": 1,
  "name": "Jose",
  "phone": "999-888-7777"
}

We have multiple endpoints we can use to get different information about different resources. If we need an endpoint that contains information from different resources, we sometimes create endpoints for specific purposes: GET /user/1?includeParents=true. Which could return something like this:

1
2
3
4
5
6
7
8
9
{
  "id": 1,
  "name": "Jose",
  "phone": "999-888-7777"
  "parents": {
    "mom": "Maria",
    "dad": "Carlos"
  }
}

Spring is a very popular Java Framework that is often used to build servers. It’s widely used by many companies because it provides a rich toolbox that can help achieve a great variety of tasks.

In this article, we’re going to learn how to create a simple Spring server using Bazel as build system.

Building the server

If you have never used Bazel, I recommend you take a look at my introduction to Bazel to get familiar with it.

Spring has a tool called spring intializr that helps create a Spring Boot project from scratch. The problem is that at the time of this writing it only supports Maven and Gradle.

In noticed this error when I was trying to create a new GKE cluster:

ERROR: (gcloud.container.clusters.create) ResponseError: code=403, message=Insufficient regional quota to satisfy request: resource “IN_USE_ADDRESSES”: request requires ‘9.0’ and is short ‘1.0’. project has a quota of ‘8.0’ with ‘8.0’ available. View and manage quotas at https://console.cloud.google.com/iam-admin/quotas?usage=USED&project=test-123456

GCP by default has a limit of 8 static global IP addresses per project, we need to raise that limit to make this error go away.

We can see the current limit with this command:

1
gcloud compute project-info describe | grep STATIC_ADDRESSES -C 2

Sadly, there is currently no way to increase quotas from gcloud cli, so we need to use the web UI.

From the console, search for quotas and select the IAM & Admin result:

Kubernetes is an open source system used to automate management of containerized applications. A containerized application, simply means an application that runs inside a container. The management part refers, among other things to:

• Deployment of changes
• Rollbacks
• Load balancing and discoverability
• Secret and configuration management
• Container placement
• Scaling applications

Kubernetes clusters

A Kubernetes cluster is a set of machines that are configured in a way that allows us to tell Kubernetes that we need to run our application without having to worry about exactly where it runs. A Kubernetes cluster consists of two things:

• Control Plane
• Nodes

The Control Plane refers to hosts that are responsible for managing the cluster, while the Nodes are the hosts where applications are run.

Kubernetes Nodes need to have a container management system (Docker, for example) as well as an agent used for communicating with the Control Plane. The name of this agent is Kubelet.

In the beginning of time RPC (Remote Procedure Calls) was the standard way of communicating between remote services. Some time passed and REST (REpresentational State Transfer) took over as the king.

REST and JSON became popular because they made it easy to understand the communication between clients and servers, since JSON is easy for humans to read.

With the rise of Microservices and systems that are increasingly chatty, JSON became a considerable overhead. Transmiting data in a human readable format, as well as serializing and deserializing this data turned out to be very slow. For this reason, different teams started working in more efficient serialization formats (e.g. protobuf, thrift, etc). As part of this revolution, gRPC was born.

gRPC is a recursive acronym that stands for gRPC Remote Procedure Call. It’s a framework for that is supported by many programming languages and provides many features for advanced use-cases.