Hi there 👋

I already had a library that I wanted to convert to Typescript. I picked Rollup.js to do my build process. First I installed the following packages: > npm i -E -D rollup typescript @rollup/plugin-commonjs\ @rollup/plugin-node-resolve rollup-plugin-typescript2\ rollup-plugin-peer-deps-external I ended up with: * [email protected] * [email protected] * [email protected] * [email protected] * @rollup/[email protected] * @rollup/[email protected] Then I created a tsconfig.json: { "compilerOptions": { "outDir": "build", "module": "esnext", "target": "es5", "lib": ["es6", "dom", "es2016", "es2017"], "sourceMap": true, "allowJs": false, "declaration": true, "moduleResolution": "node", "forceConsistentCasingInFileNames": true, "noImplicitReturns": true, "noImplicitThis": true, "noImplicitAny": true, "strictNullChecks": true, "suppressImplicitAnyIndexErrors": true, "noUnusedLocals": true, "noUnusedParameters": true, "esModuleInterop": true, "allowSyntheticDefaultImports": true }, "include": ["src"], "exclude": ["node_modules", "build"] } Also a rollup....

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....

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....

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....

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....