Showing posts with label services. Show all posts
Showing posts with label services. Show all posts

Simple RESTful API on Go (with Gin)

It is very populate to use Go to create microservice applications. And actually there are many benefits when using Go comparing to other technologies: it is easy to start, easy to create, and so cheap to run that on your servers. The last one is one of my favorites. Go application has so small footprint on memory and CPU comparing to Java applications, and the same time runs faster.

In this post, I want to show how to create a simple RESTful web service on Go using awesome Gin library.

First, lets create an main function, that sets up logging, Gin router with registered paths and handlers. Gin provides a simple way to create template-like paths and register a handler for each path.

Now lets create DTOs for our business models, and methods to convert from model to DTO:

Finally, need to create functions to handle requests. Again, super easy with Gin:

And we are done. Well, almost, as those examples don't actual models and functions to work with storage.

SLA

SLA (Service Layer Agreement) for large distributed software is very important. It plays the role of contract between the application and it's clients. It's also not very straightforward to achieve, especially if many components participate in the process. Each component in this case should have even more strict SLA, because the result of each component SLA would sum up. For example, if single call to some service A is resulted in multiple calls to other services, it's important that other services had better SLA in order to keep service A SLA promise.

There might be different types of SLA: resources, availability, durability and performance.
Many systems provides contract on how many resources are available for the client: memory, CPU, disk space etc.
Some websites and services say that their availability SLA is 99.9%, which means that 99.9% of time they going to be available. Actually, that is not very much at all. There is a nice table on Wikipedia with conversion between availability percentage and actual time.

Some services, especially the storage services like S3, have also durabitlity SLA. This to say how rarely the service might lost the data.

Performance SLA is common for running services that need to not only be available, but return response on request within specified period of time. For performance SLA, it is always common to use some percentile of requests that would be handled within SLA. For instance, it might be said that SLA is return response in 10 ms or less for 99.9% of requests.