Implement API with authentication and weather integration

[re-nanashi]

Weather API Implementation

For my assessment, I implemented a Weather API service using a modular monolith architecture with a pragmatic approach to Domain-Driven Design (DDD) and Clean Architecture principles.

Architecture

The system is structured into clear layers: API, Application, Domain, and Infrastructure. The API layer handles controllers and DTOs for request and response processing, the Application layer contains business logic and use-case orchestration, the Domain layer defines core business rules and models, and the Infrastructure layer manages external integrations such as persistence concerns.

This layered approach promotes high modularity, clear separation of concerns, and allows the system to be easily evolved into a microservices architecture in the future if needed.

Authentication and Authorization

The system uses JWT-based authentication for secure access control. It also implements basic Role-Based Access Control (RBAC) to manage user permissions and includes simple ownership-based checks to enforce resource-level security where applicable.

Features Implemented

Authentication endpoints include user registration and login, while the weather module provides a protected endpoint to retrieve weather data from an external API.

• POST /api/auth/register → User registration
• POST /api/auth/login → User login
• GET /api/weather → Fetch weather data (protected route)

Performance Enhancements

The weather module includes caching to reduce redundant external API calls and improve response time. Rate limiting is also applied to the weather endpoint to prevent abuse and ensure system stability.

Environment Configuration

The application requires a .env file in the root directory with the following configuration:

# Database
DB_HOST=
DB_PORT=
DB_USERNAME=
DB_PASSWORD=
DB_NAME=

# JWT 
JWT_SECRET=

# Admin
ADMIN_EMAIL=
ADMIN_PASSWORD=

# API Keys
# OpenWeather
WEATHER_API_KEY=

# WeatherAPI (fallback provider)
WEATHER_FALLBACK_KEY=

Design Philosophy

I usually start from monoliths on my projects therefore this system also follows a modular monolith-first approach where each module is self-contained but loosely coupled. This allows for fast development without the overhead of microservices while maintaining clean boundaries between modules.