One of my favorite things about Golang is the concept of interface. It’s also one of my grievances every time I see them used as C#/Java interfaces. It’s typical to see a colossal interface defined at a package level file, for example, a package that defines CRUD operations for a User. package db import "context" // User -- type User struct { ID int Email string } // UsersDb pointless interface type UsersDb interface { Get(ctx context.Context, id int) User Create(ctx context.Context, user User) User Update(ctx context.Context, id int, user User) User Delete(ctx context.Context, id int) bool } //... then we have the actual struct that "implements" the interface What benefit does this bring to the package? Some say mocking capabilities. From what I’ve seen to mock that kind of package, you need a generator that generates and updates the mocks. ...

I found different posts that tell you how to mock Axios using Jest & Typescript. The only difference in this post is that, when I use Axios, I like to use it as a function rather than calling axios.get or axios.post. Imagine you have this Axios request that you want to mock in your tests: //src/index.ts import axios from "axios"; export interface Post { userId: number; id: number; title: string; body: string; } const DummyRequest = (id: number): Promise<Post> => { return axios({ method: "GET", url: `https://jsonplaceholder.typicode.com/posts/${id}`, }).then((response) => { return { ...response.data }; }); }; export default DummyRequest; Install jest and jest-ts and initialize jest-ts ...

Photo by Alexander Andrews on Unsplash Lately, I’ve been thinking that most of the software I’ve done consist of stitching of API’s. Imagine you work on the team that is in charge of handling payments. It doesn’t matter if you’re working on the front-end or the back-end, it usually goes like this: We (the company you work for) have a new payment provider. We must integrate with their API. We must accommodate our business logic to their API. You have to take consideration of several layers in between, this list includes but is not limited to: validation, logging, error handling, persistence, a source of truth, actual business logic. Almost everything becomes a cross-cutting concern, authentication, logging, caching; however, in the end, the hardest part is making sense or making an abstraction of the new API to conform to the company business logic. ...

Resilience means the capacity to recover quickly from difficulties. Circuit breaker pattern is a good practice for resilience. When working with distributed systems, you want resilience. If you’re working with “micro-services,” you probably have faced with the problem of a service going down. When X service goes down, and Y and Z depend on X, every internal exception could potentially start taking other services down. If you don’t work with micro-services, you might still have an integration with a payment provider (PayPal, Stripe, Google Play, etc.). What happens when any of those providers goes down? Imagine a request comes to your internal service, then your service makes a request to Stripe, then Stripe takes 30 seconds to tell you there was something wrong. How many requests have queued up in 30 seconds in your service? ...

In this blog post, I will try to demonstrate how to setup a working environment with StackExchange.Redis package is communicating to a Redis box using SSL through STunel. By the end of this post, you will have a working environment on Vagrant like this: ...