soccer

README

Soccer

This repository contains a monorepo for Soccer related projects.

Usage

When someone clones your monorepo, they will need to rebuild the go.work file as follows:

go work init
go work use -r .

Creating a package

To create a new package

mkdir -p ./pkg/<package-name>

Initialize the package with a go.mod file

go mod init -C ./pkg/<package-name> github.com/ocrosby/soccer/pkg/<package-name>

Add the new package to the go.work file

go work use ./pkg/<package-name>

Creating a tag

git tag v0.1.0
git push origin --tags

Every time you publish new changes, run that again, updating the version number (0.1.0, 0.1.1, 0.1.2, etc.)

Project Structure

In a monorepo setup for Go projects, whether to use a single go.mod at the root or individual go.mod files in each cmd service directory depends on the structure and dependencies of your projects. Here are considerations for both approaches:
Single go.mod at the Root

Simplicity: A single go.mod file simplifies dependency management by having a unified set of dependencies for all projects within the monorepo.

Consistency: Ensures all projects within the monorepo use the same versions of dependencies, which can help in avoiding compatibility issues.

Tooling: Simplifies tooling and scripting around builds, tests, and dependency updates. Individual go.mod Files in Each cmd Service Directory

Isolation: Allows each service to manage its dependencies independently, which is useful if the services are intended to be deployed or versioned separately.

Flexibility: Services can upgrade their dependencies independently, reducing the risk of conflicts or forced updates across unrelated services.

Microservice Architecture: Fits well with a microservice architecture where services are loosely coupled and may have different lifecycles and dependency requirements.

Decision Factors

Project Size and Complexity: For smaller or tightly coupled projects, a single go.mod may be sufficient. For larger, more complex projects with loosely coupled services, individual go.mod files may offer better flexibility and isolation.

Dependency Management: Consider whether you prefer centralized management of dependencies or if you need the flexibility to manage dependencies per service.

Deployment and Versioning: If services are deployed and versioned independently, separate go.mod files might be more appropriate.

it Given the structure of your monorepo and the presence of a cmd directory that suggests potentially multiple services, if these services are intended to be independently deployable or have significantly different dependencies, it might be beneficial to have individual go.mod files for each service. This approach provides greater flexibility and isolation for dependency management, which can be advantageous in a microservices architecture.

BDD Testing with Godog

Install the latest version of the Godog CLI

go install github.com/cucumber/godog/services/godog@latest

Run the tests

godog

Docker Build Issues

Given your monorepo structure and the details provided, the best approach for building Docker images involves a few key steps to ensure efficiency, maintainability, and scalability. Here's a detailed plan:

1. Centralize Docker Build Context: Use the root of the monorepo as the Docker build context. This allows all Dockerfiles, regardless of their location within the repository, to access the entire codebase and any shared resources or configurations.

2. Parameterize Build Arguments: Utilize build arguments (--build-arg) in your Docker build commands to dynamically specify environment configurations, versions, or any other necessary parameters. This enhances flexibility across different environments (development, testing, production) without hardcoding values.

3. Optimize Dockerfile for Caching: Structure your Dockerfile to leverage Docker's layer caching mechanism effectively. Copy and install dependencies before copying the entire application code to avoid unnecessary rebuilds of dependencies.

4. Multi-Stage Builds: Implement multi-stage builds in your Dockerfile to minimize the final image size by separating the build environment from the runtime environment. This approach allows you to include only the compiled binaries and necessary runtime dependencies in the final image.

5. Consistent Directory Structure: Maintain a consistent directory structure within your Docker images. This simplifies the process of running the containers and managing volumes or configurations, especially when dealing with multiple services or applications within the monorepo.

6. Documentation and Comments: Document the build process and any specific commands or configurations directly within the Dockerfile and accompanying documentation. This is crucial for onboarding new developers and ensuring clarity across the team.

7. Automate Builds with CI/CD: Integrate Docker image building and pushing into your CI/CD pipeline. Use scripts or CI/CD pipeline configurations to automate the building of images based on changes to specific directories or files within the monorepo.

8. Versioning and Tagging Strategy: Implement a consistent versioning and tagging strategy for your Docker images. This could involve using semantic versioning, git commit hashes, or environment-specific tags to easily identify and rollback to specific image versions if necessary.

Building the tds-college-conference-service image

make build SERVICE=tds-college-conference ENV=dev

Running the tds-college-conference-service container

make run SERVICE=tds-college-conference ENV=dev

Running Tests

To run the integration tests for location-service

go test -tags=godog ./services/location-service/features

Building the location service image

docker build -f services/location-service/Dockerfile -t location-service:latest .

Dealing with Docker

Cleaning up dangling images

docker image prune

References

• Test Containers for Go
• Project Documentation
• How to use Godog for BDD development in Go
• Example Go Monorepo
• Go Project Structure Monorepo
• How to create and use a Go monorepo
• Getting started with multi-module workspaces in Go
• Get familiar with workspaces
• How I write HTTP services in Go
• Local Development of Go Applications with Testcontainers
• Logging HTTP Requests in Go
• Swagger UI

Documentation

Overview

Copyright © 2024 Omar Crosby <omar.crosby@gmail.com>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.