eBook - ePub

Building Microservices with Go

Name: Building Microservices with Go
Author: Nic Jackson

Nic Jackson

Share book

358 pages
English
ePUB (mobile friendly)
Available on iOS & Android

eBook - ePub

Building Microservices with Go

Nic Jackson

Book details

Book preview

Table of contents

Citations

About This Book

Your one-stop guide to the common patterns and practices, showing you how to apply these using the Go programming languageAbout This Book• This short, concise, and practical guide is packed with real-world examples of building microservices with Go• It is easy to read and will benefit smaller teams who want to extend the functionality of their existing systems• Using this practical approach will save your money in terms of maintaining a monolithic architecture and demonstrate capabilities in ease of useWho This Book Is ForYou should have a working knowledge of programming in Go, including writing and compiling basic applications. However, no knowledge of RESTful architecture, microservices, or web services is expected. If you are looking to apply techniques to your own projects, taking your first steps into microservice architecture, this book is for you.What You Will Learn• Plan a microservice architecture and design a microservice• Write a microservice with a RESTful API and a database• Understand the common idioms and common patterns in microservices architecture• Leverage tools and automation that helps microservices become horizontally scalable• Get a grounding in containerization with Docker and Docker-Compose, which will greatly accelerate your development lifecycle• Manage and secure Microservices at scale with monitoring, logging, service discovery, and automation• Test microservices and integrate API tests in GoIn DetailMicroservice architecture is sweeping the world as the de facto pattern to build web-based applications. Golang is a language particularly well suited to building them. Its strong community, encouragement of idiomatic style, and statically-linked binary artifacts make integrating it with other technologies and managing microservices at scale consistent and intuitive. This book will teach you the common patterns and practices, showing you how to apply these using the Go programming language.It will teach you the fundamental concepts of architectural design and RESTful communication, and show you patterns that provide manageable code that is supportable in development and at scale in production. We will provide you with examples on how to put these concepts and patterns into practice with Go.Whether you are planning a new application or working in an existing monolith, this book will explain and illustrate with practical examples how teams of all sizes can start solving problems with microservices. It will help you understand Docker and Docker-Compose and how it can be used to isolate microservice dependencies and build environments. We finish off by showing you various techniques to monitor, test, and secure your microservices.By the end, you will know the benefits of system resilience of a microservice and the advantages of Go stack.Style and approachThe step-by-step tutorial focuses on building microservices. Each chapter expands upon the previous one, teaching you the main skills and techniques required to be a successful microservice practitioner.

Frequently asked questions

How do I cancel my subscription?

Simply head over to the account section in settings and click on “Cancel Subscription” - it’s as simple as that. After you cancel, your membership will stay active for the remainder of the time you’ve paid for. Learn more here.

Can/how do I download books?

At the moment all of our mobile-responsive ePub books are available to download via the app. Most of our PDFs are also available to download and we're working on making the final remaining ones downloadable now. Learn more here.

What is the difference between the pricing plans?

Both plans give you full access to the library and all of Perlego’s features. The only differences are the price and subscription period: With the annual plan you’ll save around 30% compared to 12 months on the monthly plan.

What is Perlego?

We are an online textbook subscription service, where you can get access to an entire online library for less than the price of a single book per month. With over 1 million books across 1000+ topics, we’ve got you covered! Learn more here.

Do you support text-to-speech?

Look out for the read-aloud symbol on your next book to see if you can listen to it. The read-aloud tool reads text aloud for you, highlighting the text as it is being read. You can pause it, speed it up and slow it down. Learn more here.

Is Building Microservices with Go an online PDF/ePUB?

Yes, you can access Building Microservices with Go by Nic Jackson in PDF and/or ePUB format, as well as other popular books in Computer Science & Programming in Java. We have over one million books available in our catalogue for you to explore.

Information

Publisher

Packt Publishing

Year

2017

ISBN

9781786469793

Edition

Topic

Computer Science

Subtopic

Programming in Java

Index

Computer Science

Designing a Great API

Regardless of whether you are experienced in building APIs and microservices and looking for the techniques on how you can apply them with Go or you are completely new to the world of microservices, it is worth spending the time to read this chapter.

Writing an API contract feels part art, part science and, when you discuss your design with other engineers, you will most certainly agree to disagree, not to the level of tabs versus spaces, but there is certainly something personal about API contracts.

In this chapter, we will look at the two most popular options, which are RESTful and RPC. We will examine the semantics of each approach, which will equip you with the knowledge to argue your case when the inevitable discussion (read argument) occurs. Choosing between REST or RPC may be entirely down to your current environment. If you currently have services running that implement a RESTful approach, then I suggest you stick with it, likewise if you now use RPC. One thing I would suggest is that you read the entire chapter to understand the semantics, pros, and cons of each approach.

RESTful APIs

The term REST was suggested by Roy Fielding in his Ph.D. dissertation in the year 2000. It stands for Representational State Transfer and is described as:

"REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security and encapsulate legacy systems."

Having an API that conforms to the REST principles is what makes it RESTful.

URIs

One of the main components in the HTTP protocol is a URI. URI stands for Uniform Resource Identifiers and is the method by which you will access the API. You may be asking what the difference between a URI and a URL (Uniform Resource Locator) is? When I started to write this chapter, I wondered about this myself and did what any self-respecting developer would do, which is to head over to Stack Overflow. Unfortunately, my confusion only grew as there were lots of detailed answers, none of which I found particularly enlightening. Time to head over to the inner circle of hell also known as W3C standards to look up the RFC for the official answer.

In short, there is no difference, a URL is a URI that identifies a resource by its network location, and it is acceptable to interchange the terms when describing a resource entirely.

The clarification document published back in 2001 (http://www.w3.org/TR/uri-clarification) goes on to explain that in the early to mid-90s there was an assumption that an identifier is cast into one or two classes. An identifier might specify the location of a resource (URL) or its name (Uniform Resource Name URN) independent of location. A URI could either be a URL or a URN. Using this example, http:// would be a URL scheme and isbn: a URN scheme. However, this changed over time and the importance of the additional level of hierarchy lessened. The view changed that an individual scheme does not need to be cast into one of a discrete set of types.

The conventional approach is that http: is a URI scheme and urn: is also a URI scheme. URNs take the form urn:isbn:n-nn-nnnnnn-n, isbn: is a URN namespace identifier, not a URN scheme or a URI scheme.

Following this view, the term URL does not refer to a formal partition of URI space rather, URL is an informal concept; a URL is a type of URI that identifies a resource via its network location.

For the rest of this book, we will use the term URI and when we do we will be talking about a method to access a resource that is running on a remote server.

URI format

RFC 3986, which was published in 2005 https://www.ietf.org/rfc/rfc3986.txt, defines the format that makes valid URIs:

 URI = scheme "://" authority "/" path [ "?" query] ["#" fragment"] 
URI = http://myserver.com/mypath?query=1#document

We are will use the path element in order to locate an endpoint that is running on our server. In a REST endpoint, this can contain parameters as well as a document location. The query string is equally important, as you will use this to pass parameters such as page number or ordering to control the data that is returned.

Some general rules for URI formatting:

A forward slash / is used to indicate a hierarchical relationship between resources
A trailing forward slash / should not be included in URIs
Hyphens - should be used to improve readability
Underscores _ should not be used in URIs
Lowercase letters are preferred as case sensitivity is a differentiator in the path part of a URI

The concept behind many of the rules is that a URI should be easy to read and to construct. It should also be consistent in the way that it is built so you should follow the same taxonomy for all the endpoints in your API.

URI path design for REST services

Paths are broken into documents, collections, stores, and controllers.

Collections

A collection is a directory of resources typically broken by parameters to access an individual document. For example:

 GET /cats -> All cats in the collection 
GET /cats/1 -> Single document for a cat 1

When defining a collection, we should always use a plural noun such as cats or people for the collection name.

Documents

A document is a resource pointing to a single object, similar to a row in a database. It has the ability to have child resources that may be both sub-documents or collections. For example:

 GET /cats/1 -> Single document for cat 1 
GET /cats/1/kittens -> All kittens belonging to cat 1 
GET /cats/1/kittens/1 -> Kitten 1 for cat 1

Controller

A controller resource is like a procedure, this is typically used when a resource cannot be mapped to standard CRUD (create, retrieve, update, and delete) functions.

The names for controllers appear as the last segment in a URI path with no child resources. If the controller requires parameters, these would typically be included in the query string:

 POST /cats/1/feed -> Feed cat 1 
POST /cats/1/feed?food=fish ->Feed cat 1 a fish

When defining a controller name we should always use a verb. A verb is a word that indicates an action or a state of being, such as feed or send.

Store

A store is a client-managed resource repository, it allows the client to add, retrieve, and delete resources. Unlike a collection, a store will never generate a new URI it will use the one specified by the client. Take a look at the following ex...