Introduction This guide demonstrates how to set up and use GORM with Golang Migrate to manage your PostgreSQL database. Follow along to see the code in action and get your environment running. Prerequisites Go installed on your system. Docker installed and running. Project Structure Here is the final directory structure: . ├── .env ├── Makefile ├── cmd │ └── cli │ └── main.go ├── docker-compose.yml ├── go.mod ├── go.sum └── internal ├── db │ └── migrations │ ├── 20240608192206_create_users_table.down.sql │ └── 20240608192206_create_users_table.up.sql ├── models │ └── models.go └── repositories └── repositories.go 8 directories, 10 files Step 1: Initialize Your Project 1. Initialize the Go module: ...

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.config.js: ...

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