Go Rest API

For API Documentation, Database Design and Flow :
GO Rest API (Documentation)

Project Goal

As a backend developer, I noticed that most of my college event websites reuse old codebases, especially for the backend API. This makes sense — if something already exists, why rebuild it again? But it also makes me wonder: "How do we build such backend API from scratch?"
At WaoW Tel-U Surabaya Workshop, I took a project to built a backend API to manage article collections.

(Think of API as a "digital waiter"— it takes requests from apps/users, fetches data from the database/kitchen, and serves it in with format requested.)

This project aims to create scalable API system that easily integrates with frontend and automatically synchronizes data to reduce mistakes and disorganized information.
 
 
 

Tech Stack

This project uses various technologies, including:

• Golang: The programming language with simple syntax and concurrency model, which enable efficient handling with complex workflows.
• PostgreSQL: A powerful, open source object-relational database system.
• GORM: A Go ORM (Object-Relational Mapper) that simplified database interactions and reduced boilerplate code.
• GIN : A lightweight Go framework for building high-performance REST APIs.

Features

Multi-Table Management

Built CRUD (Create, Read, Update and Delete) operations for article, categories, and authors with validations (e.g., unique id) to prevent data conflicts.

Search with Filters

Enable filtering (article, category, author) using GORM’s scope feature, replacing raw SQL with Go code for consistency.

Centralized Error Handling

Standardized error responses (e.g., 409 CONFLICT: ID already exists) into a unified JSON format. Helps frontend teams debugged issues instantly without sifting through docs.

Clean Architecture Structure

Organized codebase into different layers. This structure support scalability and flexibility, for example; swapping databases (e.g., PostgreSQL → MySQL) would only change repositories structure.

Reflection

Having experience with Clean Architecture makes the learning curve gentler—allowing me to focus on new challenges, such as managing table relationships.
While the API met stability requirements, I would have prioritized stress testing it earlier to check for bottlenecks. "Anticipating tomorrow" with performance testing is always a good choice, even for a stable system