> ## Documentation Index > Fetch the complete documentation index at: https://docs.fluxend.app/llms.txt > Use this file to discover all available pages before exploring further. # Development > Develop and tinker with Fluxend locally ## Introduction This page will guide you on how to set up Fluxend locally. We assume you're interested in modifying functionality or fixing bugs in either the Frontend or the Backend parts of the application. If you follow to end, you'll fully understand how to make changes in either part. ## Prerequisites Before installing Fluxend, ensure you have the following tools installed and available via your command line interface: * [Docker](https://docs.docker.com/engine/install/): Container platform for running applications * [Docker Compose](https://docs.docker.com/compose/install/): Tool for defining multi-container applications * [Make](https://www.gnu.org/software/make/): Build automation tool for making your life easier * **Git**: Version control system * **Golang:**`^1.23.x` installed and accessible by running `go version` * **Node:**`^20.16.x` installed and accessible by running `node --version` * **Yarn:** Build tool responsible for frontend app * **Goose:** Database migration tool, must be accessible at `goose version` You can verify these tools are installed by running `docker --version`, `docker-compose --version`, `make --version`, and `git --version` in your terminal. ## Setup Once you have all requirements satisfied, follow the [Quickstart](https://docs.fluxend.app/quickstart) guide for initial setup. The basic installation process. The next steps will be different. If you're only interested in `backend`, you can ignore `frontend` and vice versa. Please ensure to set `URL_SCEHEME` to `http` to avoid SSL issues when running application locally ### Backend Our backend app runs a compiled binary inside `fluxend_api` container. If you're interested in changing/developing a feature in this area, you should run this without a container to see realtime changes without having to re-compile each time. \ \ You can following command inside `fluxend` directory to initiate a real-time Golang Echo server ``` go run cmd/main.go server ``` You'll now be able to see all logs and errors as they happen. If you're also working on frontend, you'll need to modify `ENV` for frontend app by modifiying `web/.env` file and point it to `http://api.localhost:8080/` ### Frontend Our frontend app runs on React and using container `fluxend_frontend` In order to see changes realtime, you should first install dependencies by running: ``` cd web && yarn ``` Once this command has finished, you can don't need to worry about dependencies anymore. You can begin running following: ``` yarn run dev ``` ## Architecture This section dives deep into architecture. It will give you an overview of directory structure, design principals, and other related topics. ### File structure ``` ├── bin/ # Backend compiled binaries and executables ├── cmd/ # Application entry points and main functions ├── docs/ # Project docs including swagger and openapi ├── internal/ # Private application code (not importable) │ ├── adapters/ # External service integrations │ │ ├── client/ # HTTP client implementations │ │ ├── email/ # Email service providers (SES, Mailgun etc) │ │ ├── postgrest/ # PostgREST API adapter │ │ ├── sqlx/ # Database driver implementations │ │ └── storage/ # File storage providers (S3, local, etc.) │ ├── api/ # HTTP layer and web framework │ │ ├── dto/ # Data Transfer Objects for API │ │ ├── handlers/ # HTTP request handlers │ │ ├── mapper/ # Data mapping between layers │ │ ├── middlewares/ # HTTP middlewares (auth, logging, etc.) │ │ ├── response/ # Response formatting utilities │ │ └── routes/ # Route definitions and registration │ ├── app/ # Application layer orchestration │ │ └── commands/ # CLI commands │ ├── config/ # Application configuration │ │ └── constants/ # Application-wide constants │ ├── database/ # Database layer │ │ ├── factories/ # Test data factories │ │ ├── migrations/ # Database schema migrations │ │ ├── repositories/ # Data access implementations │ │ └── seeders/ # Database seeding scripts │ └── domain/ # Core business logic (Hexagonal Architecture) │ ├── admin/ # Administrative operations domain │ ├── auth/ # Authentication and authorization domain │ ├── backup/ # Data backup operations domain │ ├── database/ # Database management domain │ ├── form/ # Form handling and validation domain │ ├── health/ # Health checks and monitoring domain │ ├── logging/ # Logging services domain │ ├── openapi/ # Client documentation generation domain │ ├── organization/ # Multi-tenancy and organization domain │ ├── project/ # Project management domain │ ├── setting/ # Configuration management domain │ ├── shared/ # Common domain utilities │ ├── stats/ # Analytics and statistics domain │ ├── storage/ # File storage operations domain │ └── user/ # User management domain ├── pkg/ # Public library code (importable) │ ├── auth/ # Authentication utilities │ ├── errors/ # Error handling utilities │ └── message/ # Message formatting and i18n ├── tests/ # Test files and test utilities └── web/ # React frontend application ├── app/ # Main React application code │ ├── components/ # Reusable UI components │ ├── contexts/ # React context providers │ ├── hooks/ # Custom React hooks │ ├── lib/ # Utility libraries and configurations │ ├── routes/ # Route definitions and page components │ ├── services/ # API service layer │ ├── tools/ # Development and build tools │ └── types/ # TypeScript type definitions ├── public/ # Static assets (images, favicon, etc.) └── test/ # Frontend test files ``` ### Clean Architecture Foundation Our BaaS follows Uncle Bob's Clean Architecture principles with four distinct layers: * Domain Layer (innermost) - Pure business logic, no external dependencies * Application Layer - Use cases and application services * Infrastructure Layer - External concerns (database, web, file system) * Interface Layer - Controllers, presenters, and gateways ### Dependency Rule Source code dependencies must point only toward higher-level policies: * Domain layer has no dependencies on other layers * Application layer depends only on domain * Infrastructure layer depends on application and domain * Interface layer depends on all inner layers ## Debugging You can use `pkg.DumpJSON` to print debug info when dealing with go related issues. We also use [Zerolog](https://github.com/rs/zerolog) so you can use it for printing information. Also, try looking into other files under `pkg` directory. When it comes to frontend, `console.log` is your friend. We'll be updating this section with more helpful resources. ## Go Conventions When writing code, please ensure to follow best practices and write consistent code. ### **Naming Conventions** * **Variables & Functions**: Use `camelCase` for all variables, functions, and methods * **Constants**: Use `PascalCase` for constants * **Types & Structs**: Use `PascalCase` for exported types, `camelCase` for unexported * **Interfaces**: Use `PascalCase` with descriptive names (e.g., `UserRepository`, `EmailSender`) ```go theme={null} var userName string var maxRetryCount int const DatabaseTimeout = 30 type UserService struct{} type emailProvider struct{} func getUserById(id int) (*User, error) {} func (s *UserService) CreateUser(user *User) error {} ``` * **File Names**: Use `snake_case` for all Go files * **Test Files**: Append `_test.go` to the corresponding file name ```go theme={null} // ✅ Good user_service.go user_service_test.go email_sender.go database_connection.go jwt_token_validator.go // ❌ Bad UserService.go user-service.go userService.go ``` ### **Database Management** * **Always Close Connections**: Database connections must be closed properly * **Use defer**: Close connections immediately after opening * **Context Handling**: Use context for timeout management * **Error Handling**: Always check connection errors ### Error Handling * **Same-Line if Statements**: Use inline error checking for cleaner code * **Wrap Errors**: Use `fmt.Errorf` with `%w` verb for error wrapping * **Early Returns**: Return errors early to reduce nesting ```go theme={null} // ✅ Good - Same-line error handling func (s *UserService) CreateUser(user *User) error { if err := s.validator.Validate(user); err != nil { return fmt.Errorf("validation failed: %w", err) } if err := s.repository.Save(user); err != nil { return fmt.Errorf("failed to save user: %w", err) } if err := s.emailSender.SendWelcomeEmail(user.Email); err != nil { // Log error but don't fail the operation log.Printf("failed to send welcome email: %v", err) } return nil } ```