Notes along the reimplementation

[ShevaXu]

Introduction

The Hipster Shop at https://github.com/GoogleCloudPlatform/microservices-demo is a great demo for learning microservices, including:

• gRPC https://grpc.io/
• kubernetes https://kubernetes.io/
• Istio https://istio.io/
• Go (my personal preference :P)

This issue is open for tracking the process of the reimplementation.

[ShevaXu]

gPRC Setup

• Getting protoc (from https://github.com/protocolbuffers/protobuf)

#!/usr/bin/env bash

VER=3.6.1
PLATFORM=osx-x86_64
wget "https://github.com/protocolbuffers/protobuf/releases/download/v3.6.1/protoc-$VER-$PLATFORM.zip"

• then https://github.com/grpc/grpc-go

go get -u github.com/golang/protobuf/{proto,protoc-gen-go}
go get -u google.golang.org/grpc
protoc --go_out=plugins=grpc:. *.proto

[ShevaXu]

Project Layout

The original project for reference is a mono-repo with services implemented in different languages (Go, Node.js, Java ...). One of my goal is to rewrite them all in Go (might be easier for single-developer or team with few devs) with Go modules (as an experiment).

The first thing to deal with is the project layout w.r.t. go.mod, and it settled with two separate repos:

• the core repo (this repo) for proto files & shared packages across services (encouraging sharing infrastructure-related code, e.g., logging & tracing); it has a single root go.mod for services to depend on;
• the services repo, https://github.com/practigo/hs-services, although they do not need to reside in the same repo; each service has its own go.mod for build.

The services codebase should have no exported pkg for sharing thus their go.mods are just for reproductible builds. The core can be imported like this:

import "github.com/practigo/hipstershop/genproto"

[ShevaXu]

Services Tree

• leaves: no (internal) deps
  • shipping (Go)
  • payment
  • email
  • currency (API)
  • cart (redis)
  • ad
• branch:
  • checkout (Go)
  • recommendation
• root: frontend (Go)

So the first to reimplement are the leaves. And shipping/payment are the test-bed for Go/non-Go service migrations.

The core repo just contains the proto file/definition and the generated .go file for import's sake.

[ShevaXu]

Project Layout

The first thing I had to deal with is the project layout w.r.t. go.mod, and end up with two separate repos:

I talked with the member from the original repo and got some useful feedback:

• they would only use replace directive locally as maintainers, and remove it before commit;
• they agree "multiple modules on a monorepo == pain".

Technically adding the replace into go.mod in VCS should work (across dev team and on build system); and I found this on Go module wiki:

replace also can be used to inform the go tooling of the relative or absolute on-disk location of modules in a multi-module project, such as: replace example.com/project/foo => ../foo

And more about multi-mods-repo here.

[ShevaXu]

Shipping Service

The original shipping codebase is in Go so I just got rid of all the tracing codes to make it go build-able. And then

go mod init github.com/practigo/hipstershop/shippingservice

To debug the gPRC (make a call), I found BloomRPC quite useful (GUI like Postman but for gRPC). Other tools like gRPCurl also worth trying.

[ShevaXu]

Payment Service

The original payment service is in Node.js. With the shipping service in Go already, migrating one from another language turned out easy. Actually simply replacing the shipping proto implement (from main.go) with the payment's interfaces provided a runnable boilerplate already. That's one good thing about gPRC - the generated codes give both servers and clients. (Consider adding a tool to generate boilerplate directly from the proto or proto-generated go file.)

The Charge method is the only one to implement. It depends on a credit card checking module and I found some equivalents in Go (e.g., github.com/durango/go-credit-card). The sub-pkg creditcard serves as a wrapper that just returns a mock UUID as transaction ID for now but can connect to real charging service in the future.