DEV Community: Amir Maralani

My first Serverless service

Amir Maralani — Mon, 21 Dec 2020 06:33:17 +0000

Recently I was going to run a service on Fandogh Paas with a custom domain and ended up using Cloudflare. When setting up stuff something caught my eye: Workers. I knew about the concept of Serverless a little but due to the circumstances using AWS is somewhat out of reach for me, so why not use this instead?!

I tried to create something with it. But the big question was what to build. Last year I created a little Discord bot to retrieve the current AQI of the provided city but since we are not using Discord anymore it's obsolete. Let's do it serverless this time!

The idea of using serverless to just call another API and pass the response on looks a bit redundant, but I guess it's good enough for learning new stuff. So I got an API token from Air Quality Open Data Platform and started coding.

There's a fair amount of documents and examples on the Cloudflare Workers site, and of course, you will need enough JavaScript knowledge.

Here's my code :

const aqiInfoUrl = "https://api.waqi.info/feed/"

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

/**
 * Respond to the request
 * @param {Request} request
 */
async function handleRequest(request) {
  const queryString = request.url.split('?');
  let city = queryString[1].split('=')[1];

  let response = await getAQIFromAPI(city);
  return new Response(response.data.aqi, {status: 200});
}

async function getAQIFromAPI(city) {
  let fullUrl = aqiInfoUrl + city + '/?token='+ API_TOKEN;
  const response = await fetch(fullUrl);
  return await response.json();
}

What it basically does is that when called, tries to find the city from the query string and sends a request to "https://api.waqi.info/feed/" with the provided city and the token which is saved as an environment variable.

It is not the best way it could be written, but I'm very new to this! Please give me your suggestions in the comment section.

PS: I'm thinking about a Telegram bot using the KV store ... Maybe the next post!

How not to design an Enum (Java)

Amir Maralani — Sun, 29 Nov 2020 06:59:49 +0000

Throughout the years, I've seen and created many Enums in Java. Some of them were very useful, some just avoided a bit of hard-code and a few bad ones.

This is an example of a very bad enum design. I'm not blaming anyone else, I was a contributor to this. But in my defense I was a newbie then. Let's take a look at it :

public enum EventStatusType {
    /**
     * event is processed {0 value in database}
     */
    PROCESSED,
    /**
     *  event is not processed {1 value in database}
     */
    UNPROCESSED,
    /**
     * event is now running {2 value in database}
     */
    IN_PROGRESS,
    /**
     * event has failed {3 value in database}
     */
    FAILED
}

First of all, what's with the name? It's either a Status or a Type, which in this case it's a status, so EventStatus would be a better name.

Then we get to the JavaDocs. They are not explaining anything. Instead of explaining for example what does it mean that the event is in progress they are just a repetition of the values. Also, the mention of what they represent in the database is absolutely useless, redundant, and even incorrect. Useless and redundant because everyone working with enums and saving them by their ordinals in a database should know how they work. Incorrect because if we change the type used in our entity to String, we should not be forced to change the JavaDoc for the enum.

The other utterly annoying thing in this enum is its order. When watching the database to check the status of the events, you encounter some records with statuses of 0, 1, 2, and 3. Your intuition says the 0 is the base value, then the event status would move on to 1 and 2 (or 3). And you are wrong. The base value is 1, then you move to 2 and the final status is either 0 or 3. Very counter-intuitive.

Taking care of the mentioned issues with this code would improve the readability and ease of maintenance.

Do you have any more suggestions? Please share it with me.

Logging all request mappings and their parameters in Spring

Amir Maralani — Sat, 21 Nov 2020 10:30:46 +0000

Today we had a bit of a challenge ahead of our team. The guys in charge of the network and security of our client asked us to provide a list of all URLs that your application accepts, including the parameters.
Since there are tens of controllers in our application that have tens of methods inside them it was not a manual task to do anymore. After a bit of looking around, I decided to implement it using ApplicationListener. Any class implementing ApplicationListener will listen to the corresponding event and when the event occurs, fires the onApplicationEvent method.

For us, the event was ContextRefreshedEvent. I wanted to have a list of all request mappings when the application starts up and also I wanted that list updated in case of a context refresh.

So I receive the ContextRefreshedEvent, extract the ApplicationContext, get all handler methods and the request mappings, and finally extract the patterns and method parameters. This is my base implementation :

@Log4j
@Component
public class EndpointsListener implements ApplicationListener<ContextRefreshedEvent> {

    @SneakyThrows
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        ApplicationContext applicationContext = event.getApplicationContext();
        List<Mapping> mappings = new ArrayList<>();
        for (Map.Entry<RequestMappingInfo, HandlerMethod> entry : applicationContext
                .getBean(RequestMappingHandlerMapping.class).getHandlerMethods().entrySet()) {
            RequestMappingInfo requestMappingInfo = entry.getKey();
            HandlerMethod handlerMethod = entry.getValue();
            Mapping mapping = new Mapping();
            mapping.setMethods(requestMappingInfo.getMethodsCondition().getMethods()
                    .stream().map(Enum::name).collect(Collectors.toSet()));
            mapping.setPatterns(requestMappingInfo.getPatternsCondition().getPatterns());
            Arrays.stream(handlerMethod.getMethodParameters()).forEach(methodParameter -> {


                    mapping.getParams().add(methodParameter.getParameter().getType().getSimpleName());

            });
            mappings.add(mapping);
        }

        mappings.sort(Comparator.comparing(o -> o.getPatterns().stream().findFirst().orElse("")));
        log.info(new ObjectMapper().writeValueAsString(mappings));
    }

    @Data
    public class Mapping {
        private Set<String> patterns;
        private Set<String> methods;
        private List<String> params;

        public List<String> getParams(){
            if(params == null) {
                params = new ArrayList<>();
            }
            return params;

        }
    }

}

But there's a problem: we have quite a lot of view controllers defined in our implementation of WebMvcConfigurer. Let's take a look :

@Override
public void addViewControllers(ViewControllerRegistry registry) {
   registry.addViewController("/new").setViewName("home");
   registry.addViewController("/home").setViewName("welcome");
   registry.addViewController("/help").setViewName("help");
   registry.addViewController("/404").setViewName("error_404");
   registry.addViewController("/403").setViewName("error_403");
   registry.addViewController("/405").setViewName("error_405");
   registry.addViewController("/500").setViewName("error_500");

   // The list goes on for 57 more lines
}

These mappings will not show up in the event listener (since there's no method handler I guess). So I had to update my listener to this :

@Log4j
@Component
public class EndpointsListener implements ApplicationListener<ContextRefreshedEvent> {

    private final HandlerMapping viewControllerHandlerMapping;

    public EndpointsListener(HandlerMapping viewControllerHandlerMapping) {
        this.viewControllerHandlerMapping = viewControllerHandlerMapping;
    }

    @SneakyThrows
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        ApplicationContext applicationContext = event.getApplicationContext();
        List<Mapping> mappings = new ArrayList<>();
        for (Map.Entry<RequestMappingInfo, HandlerMethod> entry : applicationContext
                .getBean(RequestMappingHandlerMapping.class).getHandlerMethods().entrySet()) {
            RequestMappingInfo requestMappingInfo = entry.getKey();
            HandlerMethod handlerMethod = entry.getValue();
            Mapping mapping = new Mapping();
            mapping.setMethods(requestMappingInfo.getMethodsCondition().getMethods()
                    .stream().map(Enum::name).collect(Collectors.toSet()));
            mapping.setPatterns(requestMappingInfo.getPatternsCondition().getPatterns());
            Arrays.stream(handlerMethod.getMethodParameters()).forEach(methodParameter -> {
                    mapping.getParams().add(methodParameter.getParameter().getType().getSimpleName());
            });
            mappings.add(mapping);
        }

        ((SimpleUrlHandlerMapping) viewControllerHandlerMapping).getHandlerMap().forEach((s, o) -> {
            Mapping mapping = new Mapping();
            mapping.setMethods(Collections.singleton("GET"));
            mapping.setPatterns(Collections.singleton(s));
            mappings.add(mapping);
        });

        mappings.sort(Comparator.comparing(o -> o.getPatterns().stream().findFirst().orElse("")));
        log.info(new ObjectMapper().writeValueAsString(mappings));
    }

    @Data
    public class Mapping {
        private Set<String> patterns;
        private Set<String> methods;
        private List<String> params;

        public List<String> getParams(){
            if(params == null) {
                params = new ArrayList<>();
            }
            return params;

        }
    }
}

By this, I will have a log of all the request mappings and their request parameter types.
The code needs a bit of refactoring for sure:

Method parameters like HttpServletRequest or HttpSession should be ignored.
Parameter names are not logged.
Required status of parameters is not logged.
PathVariables should be logged separately.

The method handler could just give us parameter names like "arg0", "arg1" and etc. But since our parameters are all annotated by @RequestParam we can easily get their names by getting the parameter annotation. This way we could log if the parameter is required or not and if it has a default value. The final code looks like this :

/**
 * A listener to listen on {@link ContextRefreshedEvent}.
 */
@Log4j
@Component
public class EndpointsListener implements ApplicationListener<ContextRefreshedEvent> {
    /**
     * Provides access to all view controllers defined in {@link SpringConfig}.
     */
    private final HandlerMapping viewControllerHandlerMapping;

    /**
     * Constructor.
     *
     * @param viewControllerHandlerMapping View Controller Handler Mapping.
     */
    public EndpointsListener(HandlerMapping viewControllerHandlerMapping) {
        this.viewControllerHandlerMapping = viewControllerHandlerMapping;
    }

    /**
     * On context refresh, get all request handler mappings and create a list.
     * Also get the view controller mappings from {@link #viewControllerHandlerMapping} and add to the list.
     *
     * @param event A {@link ContextRefreshedEvent}.
     */
    @SneakyThrows
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        ApplicationContext applicationContext = event.getApplicationContext();
        List<CustomMapping> mappings = new ArrayList<>();
        for (Map.Entry<RequestMappingInfo, HandlerMethod> entry : applicationContext
                .getBean(RequestMappingHandlerMapping.class).getHandlerMethods().entrySet()) {
            RequestMappingInfo requestMappingInfo = entry.getKey();
            HandlerMethod handlerMethod = entry.getValue();
            CustomMapping mapping = new CustomMapping();
            mapping.setMethods(requestMappingInfo.getMethodsCondition().getMethods()
                    .stream().map(Enum::name).collect(Collectors.toSet()));
            mapping.setPatterns(requestMappingInfo.getPatternsCondition().getPatterns());
            Arrays.stream(handlerMethod.getMethodParameters()).forEach(methodParameter -> {
                CustomParameter parameter = new CustomParameter();
                Annotation[] parameterAnnotations = methodParameter.getParameterAnnotations();
                Arrays.stream(parameterAnnotations).forEach(annotation -> {
                    if (annotation instanceof PathVariable) {
                        PathVariable pathVariable = (PathVariable) annotation;
                        mapping.getPathVariables()
                                .add(new CustomPathVariable(pathVariable.name(), pathVariable.required()));
                    } else if (annotation instanceof RequestParam) {
                        RequestParam requestParam = (RequestParam) annotation;
                        parameter.setName(requestParam.name());
                        String defaultValue = requestParam.defaultValue();
                        if (!defaultValue.equals(ValueConstants.DEFAULT_NONE)) {
                            parameter.setDefaultValue(defaultValue);
                        }
                        parameter.setRequired(requestParam.required());
                        parameter.setType(methodParameter.getParameter().getType().getSimpleName());
                        mapping.getParams().add(parameter);
                    }
                });
            });
            mappings.add(mapping);
        }

        ((SimpleUrlHandlerMapping) viewControllerHandlerMapping).getHandlerMap().forEach((s, o) -> {
            CustomMapping mapping = new CustomMapping();
            mapping.setMethods(Collections.singleton("GET"));
            mapping.setPatterns(Collections.singleton(s));
            mappings.add(mapping);
        });

        mappings.sort(Comparator.comparing(o -> o.getPatterns().stream().findFirst().orElse("")));
        log.info(new ObjectMapper().writeValueAsString(mappings));
    }

    /**
     * Custom mapping class.
     */
    @JsonInclude(JsonInclude.Include.NON_EMPTY)
    @Data
    public class CustomMapping {
        private Set<String> patterns;
        private Set<String> methods;
        private List<CustomParameter> params = new ArrayList<>();
        private List<CustomPathVariable> pathVariables = new ArrayList<>();
    }

    /**
     * Custom Parameter class
     */
    @JsonInclude(JsonInclude.Include.NON_NULL)
    @Data
    public class CustomParameter {
        private String name;
        private String type;
        private String defaultValue;
        private Boolean required;
    }

    /**
     * Custom path variable class.
     */
    @JsonInclude(JsonInclude.Include.NON_NULL)
    @AllArgsConstructor
    @Data
    public class CustomPathVariable {
        private String name;
        private Boolean required;
    }
}

But what if they are changed? What if we add a new controller the day after we declare our URLs to the security guys? So instead of logging the results, I will keep them as a list and write a rest controller for accessing them.

The code is also available as a gist.

Assertion vs Assumption when writing tests (JUnit)

Amir Maralani — Mon, 16 Nov 2020 07:27:23 +0000

Most of the developers are familiar with the concept of assertion in test writing. Assertion is the process of making sure some condition is met. Most of the times the condition is a kind of check for the result of the tested unit. For example an array being empty, of a variable being filled with the proper value. Check this example, let's write a simple calculator class. This class has two methods: add and multiply. add method simply adds two integers and returns the result, but the multiply method uses the add method for multiplication.


public class Calculator {

    public int add(int a, int b) {
        return a + b;
    }

    public int multiply(int a, int b) {
        int result = 0;
        for (int i = 0; i < b; i++) {
            result += add(result,a);
        }
        return result;
    }
}

For the add method my unit test would be like this :

@Test
public void testAdd() {
    int a = ThreadLocalRandom.current().nextInt();
    int b = ThreadLocalRandom.current().nextInt();
    int result = calculator.add(a, b);

    Assertions.assertEquals(a + b, result);
}

For any two given integers, the result of add method should be equal to adding them together.
My unit test for multiply method would be like this:

    @Test
    public void testMultiply() {
        int a = ThreadLocalRandom.current().nextInt();
        int b = ThreadLocalRandom.current().nextInt();

        int multiplicationResult = calculator.multiply(a, b);

        Assertions.assertEquals(a * b, multiplicationResult);
    }

It works, but there's something to note. We know that the multiply method heavily relies on the add method. If add is not working, there's no point in testing the multiply. For our example, it would not hurt much but in real-world problems, it may affect test time and resources heavily. What can we do? We can use Assumption.

@Test
public void testMultiply() {
    int a = ThreadLocalRandom.current().nextInt();
    int b = ThreadLocalRandom.current().nextInt();
    int additionResult = calculator.add(a, b);

    Assumptions.assumeTrue(a + b == additionResult);

    int multiplicationResult = calculator.multiply(a, b);

    Assertions.assertEquals(a * b, multiplicationResult);
}

When assuming, you check the prerequisites of the test, if they are not available or do not have the expected value, there's no point in continuing with the test. In the above example, we first make sure that the add method is working properly.

Why not just assert them? The difference is if the assertion fails the test will fail but if the assumption fails the test will be ignored. Although in many tests they are asserted, that's not the way it should be. We do not want to test the functionalities of other methods, but we want to be sure that they are working properly.

If the tests are well written for all the parts of code, the part which makes the assumption fail would have proper tests that would fail.

For example, if our add method is not working properly, the testAdd would fail and the testMultiply would be ignored.