-
Couldn't load subscription status.
- Fork 2
Repositories
The repository layer in our system serves as a bridge between the business logic and various external services. It is responsible for managing data access and interactions with different storage and processing components. The repository layer consists of several key components:
| Repository | Purpose |
|---|---|
| Database Repositories | Manage database access |
| Routing Repositories | Handle route optimizing and planning |
| Auth Repository | Connects to OIDC Provider for authentication |
| S3 Repository | Manages interactions with S3 Buckets |
├── config # Configuration files
├── internal
│ ├── entities # Domain models (data structures)
│ ├── server # Server setup (HTTP, gRPC, etc.)
│ ├── service # Business logic
│ ├── storage # Repository layer
│ │ ├── storage.go # Interfaces and repository definitions
│ │ ├── postgres # Database repositories
│ │ ├── routing # Routing repositories
│ │ ├── auth # Authentication repository
│ │ ├── s3 # Object storage (S3)
│ ├── ...
└── main.go
For more details on specific repository implementations, refer to the Go Documentation - Internal Storage.
The database repositories are located in internal/storage/postgres/, with separate repository packages representing different database entities such as Tree, TreeCluster, Vehicle, Region, and Sensor. Our system uses sqlc to manage SQL queries and automatically generate Go code, simplifying database interactions and ensuring type safety.
Instead of writing SQL queries directly in Go code, the queries are stored in .sql files within the queries directory. This separation keeps the database logic organized and manageable. From these queries, sqlc generates corresponding Go functions. These generated functions are then used in our repository packages to interact with the database.
We chose sqlc instead of using an ORM because it gives us more control over SQL and avoids the complexity that ORMs can introduce.
For more details on how to use sqlc, see the official documentation.
We use routing repositories to plan the best routes for watering trucks in our smart tree watering system, Green Ecolution.
Routing repositories help find the fastest routes, calculate distances, and optimize trips.
We use external routing services to do this. These services are made to solve difficult routing problems quickly and well. By using them, we don’t need to build everything ourselves. This saves us time and lets us focus on the main parts of our system. We also get better results because these services are already tested and reliable.
Our system uses three external services to plan good routes for watering trucks:
- OpenRouteService (ORS): Finds safe roads for trucks and avoids places like low bridges or blocked streets.
- Valhalla: Changes the route if there is traffic or a road is closed. It also checks how far a truck can go in a set time.
- VROOM: Makes sure all trucks take the best route to water all trees. It gives each truck the closest task.
By using these services together, Green Ecolution waters trees on time, using the best routes, and saves time and fuel.
The authentication repository manages user authentication, token validation, and access control using Keycloak, an identity and access management system. This repository is responsible for:
- Validating OAuth2 tokens.
- Ensuring role-based access control (RBAC).
- Handling user session management.
The S3 repository is responsible for managing object storage operations using AWS S3. It handles file uploads, retrievals, and secure access management. The repository abstracts direct interactions with S3 and provides a structured API for file handling operations.
One example is the storage of route files (GPX files) used for planning the routes of watering vehicles. These files are saved in S3 and can be accessed when needed, for example through a URL.
More details about how we use S3, including how we handle GPX files and create access links, can be found in the S3 chapter.