Weather Monitoring Application with Microservice Architecture

This is a weather monitoring application with microservice architecture. It is a simple application that allows users to monitor the weather at the user's current location, a location searched by the user, or historical weather data for a location.

Design and Architecture

Functional Requirements

• The application retrieves weather data from sensors and stores it in a database.
• The application shows the current weather at the user's current location.
• The application shows the current weather at a location searched by the user.
• The application shows historical weather data for a location.
• The application alerts the user when the weather is bad.
• The application allows the user to set preferences for weather alerts.

Microservices

• Data collection service: This microservice collects weather data from sensors and stores it in a database. The scope of this microservice is limited to data collection and storage. The communication pattern used by this microservice is asynchronous messaging.
• Current weather service: This microservice retrieves the current weather from the database and shows it to the user. The scope of this microservice is limited to obtaining the user's current location using IP-API and retrieving the current weather from OpenWeatherMap. The communication pattern used by this microservice is synchronous request-response.
• Realtime weather service: This microservice retrieves the current weather of a location based on the search query of the user and shows it to the user. The scope of this microservice is limited to retrieving the current weather of a location from OpenWeatherMap. The communication pattern used by this microservice is synchronous request-response.
• Historical weather service: This microservice retrieves historical weather data for a location based on the search query of the user and shows it to the user. The scope of this microservice is limited to retrieving historical weather data for a location from OpenWeatherMap. The communication pattern used by this microservice is synchronous request-response.
• Alert service: This microservice retrieves the current weather from the sensors and checks if the weather is bad. If it is, the alert service sends an alert to the user. The scope of this microservice is limited to accepting weather data and sending alerts. The communication pattern used by this microservice is asynchronous messaging.
• User preferences service: This microservice allows the user to set preferences for weather alerts. The scope of this microservice is limited to storing user preferences. The communication pattern used by this microservice is asynchronous messaging.

Communication Patterns

The communication pattern used in the weather monitoring system is a mix of synchronous request/response and asynchronous messaging. Synchronous request/response is used when a microservice needs to get data from another microservice in real-time. Asynchronous messaging is used when a microservice needs to send data to another microservice, but the response can be delayed.

Sequence Diagram

sequenceDiagram
    participant Frontend
    participant Current weather service
    participant IP-API
    participant Realtime weather service
    participant Historical weather service
    participant OpenWeatherMap
    participant Sensors
    participant Data collection service
    participant Database
    participant Alert service
    participant User preferences service

    Frontend->>Current weather service: GET /current-weather
    Current weather service->>IP-API: GET /json
    IP-API-->>Current weather service: Response with user's current location
    Current weather service->>OpenWeatherMap: GET /weather
    OpenWeatherMap-->>Current weather service: Response with current weather
    Current weather service-->>Frontend: Response with current weather

    Frontend->>Realtime weather service: GET /real-time-weather
    Realtime weather service->>OpenWeatherMap: GET /weather
    OpenWeatherMap-->>Realtime weather service: Response with current weather
    Realtime weather service-->>Frontend: Response with current weather

    Frontend->>Historical weather service: GET /historical-weather
    Historical weather service->>OpenWeatherMap: GET /onecall
    OpenWeatherMap-->>Historical weather service: Response with historical weather
    Historical weather service-->>Frontend: Response with historical weather

    Sensors->>Data collection service: Publish weather data
    Data collection service->>Database: Store weather data

    Sensors->>Alert service: Publish weather data
    Alert service->>Frontend: Send alert if weather is bad

    Frontend->>User preferences service: POST /user-preferences
    User preferences service->>Alert service: Publish user preferences

Architecture Diagram

graph TD
    subgraph User
        A((Frontend))
    end

    subgraph Microservices
        B(Current weather service)
        C(Realtime weather service)
        D(Historical weather service)
        F(User preferences service)
        E(Alert service)
        G(Data collection service)
    end

    subgraph Databases
        H[(Database)]
    end

    subgraph APIs
        I[IP-API]
        J[OpenWeatherMap]
    end

    subgraph Sensors
        K{Sensors}
    end


    A---B
    A---C
    A---D
    A---F

    B---I
    B---J
    C---J
    D---J

    K-->G
    G-->H

    K-->E
    E-->A
    F-->E

Limitations

The limitations around communication for microservices include increased complexity, potential latency, and the need for error handling. Because each microservice is a separate process, there is a potential for increased latency in communication between microservices. Additionally, error handling must be carefully implemented to ensure that failures in one microservice do not propagate to other microservices. Finally, the increased complexity of microservice-based architectures can make them harder to design, develop, deploy, and maintain than monolithic architectures.

Implementation

Microservices

Three microservices were implemented:

• Current weather service: This microservice obtains the geographic coordinates of the user's current location using IP-API and retrieves the current weather from OpenWeatherMap. The frontend sends requests to this microservice by using the GET /current-weather endpoint. The microservice responds with the current weather in JSON format.

• Realtime weather service: This microservice retrieves the current weather of a location from OpenWeatherMap based on the given location entered by the user. The frontend sends requests to this microservice by using the GET /real-time-weather endpoint. The microservice responds with the current weather in JSON format.

• Historical weather service: This microservice retrieves historical weather data for a location from OpenWeatherMap based on the given location and UNIX timestamp entered by the user . The frontend sends requests to this microservice by using the GET /historical-weather endpoint. The microservice responds with historical weather data in JSON format.

Video

https://user-images.githubusercontent.com/68151686/233834316-3862b7b4-f5a6-4278-b460-c8b91acd3ae8.mp4

Dependencies

The following dependencies were used in the implementation of the microservices:

• Node.js
• React
  • express
  • axios
  • dotenv

Deployment

First navigate to the src directory of the microservice you want to deploy.

cd src

Then run the following command in separate terminals to start the microservices.

node current.js
node realtime.js
node historical.js

And run the following command in the root directory to start the frontend.

npm start