Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/redhatinsights/notifications-backend

Backend for the notifications service
https://github.com/redhatinsights/notifications-backend

hacktoberfest quarkus

Last synced: 5 days ago
JSON representation

Backend for the notifications service

Awesome Lists containing this project

README 

        
= Notifications service



== Coding



When using IntelliJ IDEA, use the 'default' style. This is matched by checkstyle, which is invoked when running maven.



=== Multiple API Versions



Notifications might host multiple API versions at the same time. This is done by replacing some calls depending the

requested version. The version is part of the URL (as per platform guidelines). When starting a new version, most of

the APIs have the same implementation. To make the process of adding a new API version as easy as possible the following

strategy is used.



The `@Path` annotation in each resource is moved to an inner class with the version name. e.g.



```java

@Path("api/notifications/v1.0/endpoints")

class EndpointResource {

   @GET

   public void myPath() {

   }

}

```



becomes:



```java

class EndpointResource {



    @Path("api/notifications/v1.0/endpoints")

    public static class V1 extends EndpointResource {



    }



    @Path("api/notifications/v2.0/endpoints")

    public static class V2 extends EndpointResource {



    }



   @GET

   public void myPath() {

   }

}

```



=== Modify an existing API



Consider we want a new implementation of an API, with different behavior and even params.



```java

class EndpointResource {



    @Path("api/notifications/v1.0/endpoints")

    class V1 extends EndpointResource {



    }



    @Path("api/notifications/v2.0/endpoints")

    class V2 extends EndpointResource {



    }



   @GET

   public void myPath() {

   }



   @POST

   public void myOldPostRequest() {

        // ... do some old stuff

   }

}

```



We would update it as follow:



```

class EndpointResource {



    @Path("api/notifications/v1.0/endpoints")

    class V1 extends EndpointResource {

        @POST

       public void myOldPostRequest() {

            // ... do some old stuff

       }

    }



    @Path("api/notifications/v2.0/endpoints")

    class V2 extends EndpointResource {

        @POST

        public List> myNewRequest(@QueryParam int coolParam) {

            // ... New API. Different params, different return value

        }

    }



   @GET

   public void myPath() {

   }

}

```



In this example, we moved the old request of the `V1` class and added the new behavior in `V2`. That's it!



== Enabling the MockServer log during tests



This project uses link:https://www.mock-server.com[MockServer] to mock external services during the tests execution.



The MockServer log is disabled by default to reduce the noise in the application log.

It can be enabled by adding the following argument to the Maven build command:



```

-Dmockserver.logLevel=WARN|INFO|DEBUG|TRACE

```



Details about each MockServer log level are available in the link:https://www.mock-server.com/mock_server/debugging_issues.html[MockServer documentation].



## Usage of the Clowder Config Source



This project uses the Clowder Config Source from https://github.com/RedHatInsights/clowder-quarkus-config-source.

To configure this source to use a different file than `/cdappconfig/cdappconfig.json` you can use the property `clowder.file=/path/to/file.json`.



## Deploying the backend with data on ephemeral



If you deploy `notifications-backend` on ephemeral, the database may not contain all the data you need for your tests.

It is possible to load data on ephemeral when the backend pod starts, but this is restricted to three kinds of database

records: `Bundle`, `Application` and `EventType`.



There are two ways of loading that data, as explained below. Both can be used at the same time as long as the `name`

field is globally unique for each type of database record. If there is no `name` conflict, the data from both sources

will be inserted into the database.



### Loading data using a ConfigMap



The `notifications-backend` ClowdApp template contains an environment variable definition that can be used to load data:



```yaml

env:

- name: NOTIFICATIONS_EPHEMERAL_DATA

  valueFrom:

    configMapKeyRef:

      name: notifications-ephemeral-data

      key: ephemeral_data.json

      optional: true

```



If a `ConfigMap` named `notifications-ephemeral-data` is created by any of the pods present in the ephemeral namespace,

the backend pod will consume that `ConfigMap` as an environment variable and put the value of the `ephemeral_data.json`

key into the `NOTIFICATIONS_EPHEMERAL_DATA` environment variable.



[TIP]

The `ConfigMap` is optional, it is not a requirement for the `notifications-backend` pod deployment.



Here is an example of the `ConfigMap` you could add to your application ClowdApp template:



```yaml

- apiVersion: v1

  kind: ConfigMap

  metadata:

    name: notifications-ephemeral-data

  data:

    ephemeral_data.json: |

      {

        "bundles": [

          {

            "name": "my-bundle",

            "display_name": "My Bundle",

            "applications": [

              {

                "name": "my-app",

                "display_name": "My Application",

                "event_types": [

                  {

                    "name": "my-event-type",

                    "display_name": "My Event Type",

                    "description": "This is my event type"

                  }

                ]

              }

            ]

          }

        ]

      }

```



### Loading data using the persistent `ephemeral_data.json` file



You can also load data on ephemeral by creating a pull request that modifies the https://github.com/RedHatInsights/notifications-backend/tree/master/backend/src/main/resources/ephemeral/ephemeral_data.json[ephemeral_data.json] file which is hosted in this repository.

This file may contain ephemeral data from other applications so please be careful not to delete or edit data that would belong to another team.



Here is an example of the data structure allowed in `ephemeral_data.json`:



```json

{

  "bundles": [

    {

      "name": "my-bundle",

      "display_name": "My Bundle",

      "applications": [

        {

          "name": "my-app",

          "display_name": "My Application",

          "event_types": [

            {

              "name": "my-event-type",

              "display_name": "My Event Type",

              "description": "This is my event type"

            }

          ]

        }

      ]

    }

  ]

}

```



### Generating Jackson Java classes based on JSON requests and responses



For the requests as well as for the responses for querying the IT User Service we can use this online generator to generate the clases by pasting the json files there: https://www.jsonschema2pojo.org/



### Updating the Grafana dashboard on prod



While the Grafana dashboard on stage gets updated automatically after merging a PR that changes the dashboard,

prod still needs to be updated manually. If you want to update the dashboards on prod after you checked that your changes are working on stage,

you need to update the reference in app-interface/data/services/insights/notifications/cicd/ci-int/saas-observability.yml