Services with many collaborators may require unnecessary copy/paste of code to create Version class

[karolkalinski]

Services with many collaborators may require unnecessary copy/paste of code to create Version class. Look at the code below. Each collaborator would be mapped to such a class. I would vote for creating a solution (a Builder? an abstract class?) that would ease the creation of Content-type header value.

package com.ofg.loans.backend.creditlimit.external;

import org.springframework.http.MediaType;

public class Versions {

    private Versions() {
        throw new UnsupportedOperationException("Can't instantiate an utility class");
    }

    private static final String FRAUD_CORE_APP_NAME = "fraud-service";

    private static final String APPLICATION_JSON_HEADER_FORMAT_PREFIX = "application";

    private static final String APPLICATION_JSON_HEADER_FORMAT_SUFFIX = "+json";

    private static final String FRAUD_CORE_APP_V1_JSON_SUBTYPE = "vnd." + FRAUD_CORE_APP_NAME + ".v1"
            + APPLICATION_JSON_HEADER_FORMAT_SUFFIX;

    public static final MediaType FRAUD_CORE_APP_V1_JSON_MEDIA_TYPE = new MediaType(
            APPLICATION_JSON_HEADER_FORMAT_PREFIX, FRAUD_CORE_APP_V1_JSON_SUBTYPE);

    public static final String FRAUD_CORE_APP_V1_JSON = APPLICATION_JSON_HEADER_FORMAT_PREFIX + "/"
            + FRAUD_CORE_APP_V1_JSON_SUBTYPE;
}

[marcingrzejszczak]

Karol take a look at the way you can define the versions in microservice.json file:

    {
        "prod": {
            "this": "foo/bar/registration",
            "dependencies": {
                "users": {
                    "path": "foo/bar/users",
                    "required": true
                },
                "newsletter": {
                    "path": "foo/bar/comms/newsletter",
                    "contentTypeTemplate": "application/vnd.newsletter.$version+json",
                    "version": "v1"                    
                },
                "confirmation": {
                    "path": "foo/bar/security/confirmation",
                    "headers": {
                        "header1": "value1",
                        "header2": "value2"
                    }
                }
            }
        }
    }

you can define it over there without a need to afterwards use it in the code. Would that suit your purpose better?

[karolkalinski]

Thats it. Thanks

On Thu, Jan 15, 2015 at 1:31 PM, Marcin Grzejszczak < notifications@github.com> wrote:

Karol take a look at the way you can define the versions in microservice.json file:

{
    "prod": {
        "this": "foo/bar/registration",
        "dependencies": {
            "users": {
                "path": "foo/bar/users",
                "required": true
            },
            "newsletter": {
                "path": "foo/bar/comms/newsletter",
                "contentTypeTemplate": "application/vnd.newsletter.$version+json",
                "version": "v1"
            },
            "confirmation": {
                "path": "foo/bar/security/confirmation",
                "headers": {
                    "header1": "value1",
                    "header2": "value2"
                }
            }
        }
    }
}

you can define it over there without a need to afterwards use it in the code. Would that suit your purpose better?

— Reply to this email directly or view it on GitHub https://github.com/4finance/micro-infra-spring/issues/177#issuecomment-70079090 .

[karolkalinski]

The propsed solution with contentTypeTemplate has one issue. If you need more then one microservice.json files then you need to rewrite it to all of them.

[nurkiewicz]

You mean there is duplication between various microservice.json files? Indeed, but it also applies to collaborator names, etc. Any idea how can we reduce duplication among microservice.json variants?

[marcingrzejszczak]

It may be difficult since the notion of the microservice descriptor was about a microservice from a point of view of a separate codebase. Now assuming that we create a couple of microservices from the same codebase (i.e. via the plugin based approach) then indeed we may end up with needless copy pasting (only naming would differ).

What do you think about creating a gradle task (plugin?) that would take a template of a microservice.json and by providing in some way (maybe via a gradle ext property) the value of that name would produce microservice.json in the resources?