Skip to main content
gFly v1.15.1
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  1. gFly
  2. /
  3. Greeting Start
  4. /
  5. Directory Structure
Edit page

Directory Structure

Full directory structure of a gFly codebase.

|-- LICENSE
|-- Makefile
|-- README.md
|-- cover.out
|-- go.mod
|-- go.sum
|-- main.go
|-- app
|   |-- README.md
|   |-- console
|   |   |-- README.md
|   |   |-- cli.go
|   |   |-- commands
|   |   |   |-- README.md
|   |   |   |-- db_command.go
|   |   |   |-- hello_command.go
|   |   |   |-- mail_command.go
|   |   |   `-- redis_command.go
|   |   |-- queues
|   |   |   |-- README.md
|   |   |   `-- hello_task.go
|   |   `-- schedules
|   |       |-- README.md
|   |       `-- hello_job.go
|   |-- constants
|   |   |-- README.md
|   |   `-- app_constants.go
|   |-- domain
|   |   |-- README.md
|   |   |-- models
|   |   |   |-- README.md
|   |   |   |-- role_model.go
|   |   |   |-- types
|   |   |   |   |-- user_role.go
|   |   |   |   `-- user_status.go
|   |   |   |-- user_model.go
|   |   |   `-- user_roles_model.go
|   |   `-- repository
|   |       |-- README.md
|   |       |-- init.go
|   |       |-- role_repository.go
|   |       `-- user_repository.go
|   |-- dto
|   |   |-- README.md
|   |   |-- generic_dto.go
|   |   `-- user_dto.go
|   |-- errors
|   |   `-- README.md
|   |-- http
|   |   |-- README.md
|   |   |-- http_helpers.go
|   |   |-- request_helpers.go
|   |   |-- controllers
|   |   |   |-- README.md
|   |   |   |-- api
|   |   |   |   |-- README.md
|   |   |   |   |-- default_api.go
|   |   |   |   |-- generic_list_api.go
|   |   |   |   `-- user
|   |   |   |       |-- create_user_api.go
|   |   |   |       |-- delete_user_api.go
|   |   |   |       |-- get_user_api.go
|   |   |   |       |-- get_user_profile_api.go
|   |   |   |       |-- list_users_api.go
|   |   |   |       |-- update_user_api.go
|   |   |   |       `-- update_user_status_api.go
|   |   |   `-- page
|   |   |       |-- README.md
|   |   |       |-- auth
|   |   |       |   `-- login_page.go
|   |   |       |-- generic_page.go
|   |   |       |-- home_page.go
|   |   |       `-- user
|   |   |           |-- list_page.go
|   |   |           `-- profile_page.go
|   |   |-- middleware
|   |   |   |-- README.md
|   |   |   |-- check_roles_middleware.go
|   |   |   `-- prevent_update_yourself_middleware.go
|   |   |-- request
|   |   |   |-- README.md
|   |   |   `-- user_request.go
|   |   |-- response
|   |   |   |-- README.md
|   |   |   |-- error_response.go
|   |   |   |-- system_info_response.go
|   |   |   `-- user_response.go
|   |   |-- routes
|   |   |   |-- README.md
|   |   |   |-- api_routes.go
|   |   |   |-- routes.go
|   |   |   `-- web_routes.go
|   |   `-- transformers
|   |       |-- README.md
|   |       |-- generic_transformer.go
|   |       `-- user_transformer.go
|   |-- notifications
|   |   |-- README.md
|   |   `-- send_mail_notification.go
|   |-- services
|   |   |-- README.md
|   |   `-- user_services.go
|   `-- utils
|       |-- README.md
|       |-- transform_utils.go
|       `-- validate_utils.go
|-- build
|   |-- README.md
|   |-- app
|   `-- artisan
|-- database
|   |-- MySQL.md
|   |-- PostgreSQL.md
|   |-- README.md
|   `-- migrations
|       |-- mysql
|       |   |-- 000001_create_init_tables.down.sql
|       |   `-- 000001_create_init_tables.up.sql
|       `-- postgresql
|           |-- 000001_create_init_tables.down.sql
|           `-- 000001_create_init_tables.up.sql
|-- docker
|   |-- README.md
|   |-- docker-compose.yml
|   |-- mailpit
|   |   |-- README.md
|   |   |-- authfile
|   |   |-- cert.pem
|   |   `-- key.pem
|   `-- redis
|       `-- redis.env
|-- docs
|   |-- README.md
|   |-- TASKS.md
|   |-- docs.go
|   |-- swagger.json
|   `-- swagger.yaml
|-- public
|   |-- README.md
|   |-- assets
|   |   |-- README.md
|   |   |-- favicon.png
|   |   |-- hero.png
|   |   |-- logo.png
|   |   `-- logo.svg
|   |-- css
|   |   |-- README.md
|   |   `-- style.css
|   |-- docs
|   |   |-- favicon-16x16.png
|   |   |-- favicon-32x32.png
|   |   |-- index.css
|   |   |-- index.html
|   |   |-- swagger-initializer.js
|   |   |-- swagger-ui-bundle.js
|   |   |-- swagger-ui-bundle.js.map
|   |   |-- swagger-ui-standalone-preset.js
|   |   |-- swagger-ui-standalone-preset.js.map
|   |   |-- swagger-ui.css
|   |   |-- swagger-ui.css.map
|   |   `-- swagger.json
|   |-- favicon.ico
|   |-- index.html
|   |-- js
|   |   `-- README.md
|   `-- vendors
|       `-- alpinejs
|           `-- dist
|               |-- cdn.js
|               `-- cdn.min.js
|-- resources
|   |-- README.md
|   |-- app
|   |   `-- README.md
|   |-- tls
|   |   |-- README.md
|   |   |-- localhost.crt
|   |   `-- localhost.key
|   `-- views
|       |-- README.md
|       |-- home.tpl
|       |-- login.tpl
|       |-- mails
|       |   |-- change_password.tpl
|       |   |-- forgot_password.tpl
|       |   |-- master.tpl
|       |   `-- send_mail.tpl
|       |-- master.tpl
|       |-- profile.tpl
|       |-- user
|       |   `-- list.tpl
|       `-- user.tpl
|-- storage
|   |-- README.md
|   |-- app
|   |   |-- README.md
|   |   `-- public
|   |       `-- upload
|   |-- logs
|   |   |-- README.md
|   |   `-- logs.log
|   `-- tmp
|       `-- README.md
|-- test
|   |-- README.md
|   `-- utils
|       |-- transform_utils_test.go
|       `-- validate_utils_test.go
`-- tmp
    |-- README.md
    |-- build-errors.log
    `-- main

The app directory

This is the main directory for the project. This is where files will be created and used throughout your project.

Understanding and placing source files in the correct folders will help us easily understand and manage them effectively. In fact, how to place it is not a mandatory issue. However, unity is needed to create consistency in your project. And this is how gFly is approaching. In addition, the components in the code also have certain close relationships to create logic and ease of understanding. We will clarify in the step “Understanding the lifecycle of a request in gFly”

|-- app
|   |-- console
|   |   |-- commands
|   |   |-- queues
|   |   `-- schedules
|   |-- constants
|   |-- domain
|   |   |-- models
|   |   |   |-- types
|   |   `-- repository
|   |-- dto
|   |-- errors
|   |-- http
|   |   |-- controllers
|   |   |   |-- api
|   |   |   `-- page
|   |   |-- middleware
|   |   |-- request
|   |   |-- response
|   |   |-- routes
|   |   `-- transformers
|   |-- notifications
|   |-- services
|   `-- utils

Requests can be created from CLI (console) app/console or HTTP request app/http. They are the starting point for receiving requests from users to your application.

The app/http directory handles HTTP communication (request, response, transformer) including all controllers (api or page), routes, and middleware for the web portion of your application.

  • Define HTTP routes and handlers
  • Implement middleware (authentication, logging, etc.)
  • Parse HTTP requests and format responses
  • Direct traffic to appropriate services

The app/console directory contains command-line interfaces, tasks, and scheduled jobs that run outside of HTTP requests

  • Implement CLI commands
  • Define background or scheduled tasks
  • Provide maintenance utilities
  • Execute database migrations or seed scripts

The app/services directory contains the application’s business logic and coordinates between controllers and repositories.

  • Implement business logic
  • Coordinate between various repositories
  • Apply domain rules and workflows
  • Handle transactions and complex operations

The app/domain/models directory contains the core business entities and data structures that represent your application’s domain concepts.

  • Define core business entities
  • Encapsulate domain logic and constraints
  • Represent real-world objects and relationships
  • Provide domain-specific behavior

The app/domain/repository directory defines interfaces for accessing and persisting domain models, abstracting away the actual data storage implementation.

  • Define data access interfaces
  • Abstract storage implementation details
  • Centralize query logic
  • Facilitate testing with mock implementations

The app/dto (Data Transfer Objects) directory contains structures that facilitate data exchange between different layers of the application.

  • Define request/response structures for APIs
  • Standardize data validation
  • Isolate presentation concerns from domain model

The app/notifications directory handles various notification systems such as email, SMS, push notifications, and webhooks.

  • Manage communication channels with users and external systems
  • Implement notification strategies
  • Handle notification templates and delivery

The app/constants directory contains application-wide constant values and enumerations.

  • Define shared constant values
  • Establish enumeration types
  • Centralize error codes and messages

The app/utils directory provides common utility functions and helpers used throughout the application.

  • Provide reusable helper functions
  • Implement cross-cutting concerns
  • Offer common operations that don’t fit elsewhere

The database directory 

|-- database
|   `-- migrations
|       |-- mysql
|       `-- postgresql

The database folder serves as the central location for:

  • Database connection management
  • Schema migrations
  • Seeding data
  • Query builders or ORM configurations
  • Database models (if not placed in the domain layer)
  • Transaction management

This database/migration directory contains all database migration files organized by database engine. The presence of separate subdirectories indicates the application is designed to work with multiple database systems.

The database/migrations/mysql Directory Contains migration files specifically formatted for MySQL database systems. These files:

  • Define schema changes in MySQL-specific SQL syntax
  • May utilize MySQL-specific features and data types
  • Are executed when the application is configured to use MySQL

The database/migrations/postgresql Directory Contains migration files designed for PostgreSQL database systems. These files:

  • Use PostgreSQL-specific SQL syntax
  • May leverage PostgreSQL-specific features like advanced data types, constraints, and extensions
  • Are executed when the application is configured to use PostgreSQL

The docker directory 

|-- docker
|   |-- README.md
|   |-- docker-compose.yml
|   |-- mailpit
|   |   |-- README.md
|   |   |-- authfile
|   |   |-- cert.pem
|   |   `-- key.pem
|   `-- redis
|       `-- redis.env

The docker directory in this project is dedicated to containerization configurations, allowing the application and its dependencies to run consistently across different environments. Let’s explore this structure in detail:

The Docker configuration serves several critical purposes in the project:

  • Development Environment Standardization: Ensures all developers work with identical environments
  • Dependency Management: Manages external services like Redis and email testing
  • Deployment Preparation: Provides configurations that can be adapted for production deployment
  • Service Isolation: Keeps services separated and independently configurable
  • Infrastructure as Code: Documents the application’s infrastructure requirements

The public directory 

|-- public
|   |-- assets
|   |-- css
|   |-- docs
|   |-- js
|   `-- vendors

The public directory serves as the web server’s document root, containing all static assets directly accessible to client browsers. This folder is a critical component for the frontend aspect of the web application.

The public directory serves multiple critical functions:

  • Static Asset Hosting: Provides direct browser access to images, styles, scripts
  • Application Entry Point: Contains the main file index.html
  • API Documentation Interface: Hosts the Swagger UI for API documentation
  • Third-Party Library Distribution: Contains vendor libraries like AlpineJS
  • Browser Interaction: Everything needed for client-side functionality

Source code related to Frontend such as js, css, assets, html files will all be contained here.

Note
TIP
If you develop Frontend with technologies like ReactJS, VueJS or AnguarJS,… you should specify the build directory to public.

The resources directory 

|-- resources
|   |-- app
|   |-- tls
|   `-- views

The resources directory contains non-public assets and templates that are processed or rendered by the application before being served to users. Unlike the public directory, files in resources are not directly accessible to web browsers but are instead transformed or compiled during the application lifecycle.

The resources directory serves several essential purposes in the application:

  • View Templates: Contains HTML templates that are rendered with dynamic data
  • Email Templates: Provides layouts for system-generated emails
  • Security Assets: Stores SSL/TLS certificates for secure connections
  • Application Resources: Houses miscellaneous resources needed by the application
  • Preprocessing Source: Contains files that may be processed before use

The resources/app directory fulfills several important roles:

  • Frontend Application Source: Contains the source code for your client-side application
  • Framework-Specific Structure: Organizes code according to React, Vue, or Angular conventions
  • Component Architecture: Houses reusable UI components and their related assets
  • State Management: Contains state management code (Redux, Vuex, Pinia, etc.)
  • Client-Side Routing: Includes route definitions and navigation logic
  • Asset Management: Manages frontend assets in a structured way
  • API Integration: Contains services/utilities for backend API communication

The storage directory 

|-- storage
|   |-- app
|   |   `-- public
|   |       `-- upload
|   |-- logs
|   `-- tmp

The storage directory is dedicated to data that is created and managed by the application during runtime. Unlike code files or resources, items in the storage folder are typically generated dynamically, can change frequently, and may need to persist between application restarts.

The storage directory serves several critical functions in the application architecture:

  • Data Persistence: Stores application-generated data that needs to persist
  • Logging: Captures application events, errors, and diagnostics
  • Temporary Storage: Manages ephemeral data needed for processing
  • File Uploads: Securely stores user-uploaded content
  • Cache Storage: Persists cached data to improve performance
  • Session Management: Maintains user session information
  • The app directory contains application resources.
  • The logs directory contains log files.
  • The tmp is temporary folder.

The test & tmp directories 

|-- test

The test directory contains all test-related files and configurations for ensuring the application’s quality, reliability, and correctness. This directory is crucial for implementing a robust testing strategy across different testing levels and methodologies.

gdoc_arrow_left_alt Configuration Create TLS gdoc_arrow_right_alt