Database Migration tools for Mongo DB

When it comes to the problem of migrating database structure, some of you may think about relational databases: there is a strict schema, and to remove something(field, table, index, etc.), you need to take action: execute an SQL statement. But when you work on schema-less databases, it may look like you don’t need those migrations. But to be honest, are schema-less database are schemaless? In fact, you have more freedom in column and document-based database, but sooner or later you will have to modify some of the results of your work: remove the index, transform column format, etc. That’s why with the help of this article I would like to review the available tools for Mongo migrations. Mongobee If you use Spring in your project, then MongoBee should be the most suitable tool for you. The idea is that you write Java methods(changesets), which describe what changes need to be done. The method annotated by @ChangeSet is taken and applied to the database. Mongobee stores changesets history in dbchangelog collection. If you are a Spring guy, and like Java config among others, then you should choose this tool. You have two options how to run Mongobee - inside Spring container...

How to map Spring Boot properties to Java class

Have you ever had a need to use some values from application.properties or **application.yml? How did you take them out? Personally, I always used @Value annotation: @Value("${graphite.host}") private String graphiteHost; It wasn’t the best way to work with my properties. However, I didn’t know a better approach. Then, I found @ConfigurationProperties - annotation from Boot package, which has everything you need to map your properties. Given Let’s say, your application.yml looks like following: graphite: enabled: true host: localhost port: 2003 amountOfTimeBetweenPolls: 20000 When You need to create a bunch of classes, which you will be autowiring in all parts of your code. I’m using Project Lombok for skipping java formalities, if you are not, then create getters and setters for your classes. package org.rngr.properties; import lombok.Data; import org.springframework.boot.context.properties.ConfigurationProperties; import javax.validation.constraints.NotNull; @ConfigurationProperties(ignoreUnknownFields = true) @Data public class ApplicationProperties { @NotNull private GraphiteProperties graphite; } Pay attention to @ConfigurationProperties annotation, it’s playing a key role here. Don’t forget about subclass: package org.rngr.properties; import lombok.Data; @Data public class GraphiteProperties { private boolean enabled; private String host; private int port; private int amountOfTimeBetweenPolls; } In the end, you need to enable configuration properties: package org.rngr; import lombok.extern.slf4j.Slf4j; import org.rngr.config.*; import org.rngr.properties.ApplicationProperties; import org.springframework.beans.factory.annotation.Autowired; import...

How to trace your logs using SLF4J MDC

How do you use your logs for searching problem requests? For instance, you got a problem response, with all headers, response body, and you need to find appropriate logs. How would you do that? Personally, I found it useful to write some words about MDC - Mapped Diagnostic Context. Shortly, it is a concept of mapping request specific information. Usage We will configure MDC in Spring Boot application. We will use SLF4J on top of Logback implementation. Using it all together, we will create a unique requestId for each request in our system. Components We will use 4 components here: Spring Boot, Slf4j, Logback and Java Spring Boot Spring Boot will be used for managing dependency injection and registering pure Java Filter. Slf4j Simple Logging Facade is used for following abstraction principles. Additionally, MDC class is located inside slf4j dependency. Similar classes are inside log4j and logback dependencies. Logback Logback is used as one of logging providers Pure Java Java is used for writing simple Java Filter. Affected files MDCFilter package org.startup.queue.filter; import org.slf4j.MDC; import org.springframework.stereotype.Component; import javax.servlet.*; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.io.IOException; import java.util.UUID; @Component public class MDCFilter implements Filter { @Override public void init(FilterConfig filterConfig) throws ServletException...

Trying Amazon API Gateway, Lambda and DynamoDb

At the beginning of June 2016, I visited a JavaDay conference in Lviv, where I listen to a talk about serverless architecture. Today I’d like to try serverless. According to Martin Fowler, serverless is an architecture, which uses third party services or a custom code on ephemeral containers, best known as Amazon Lambda. So, I understand it as an idea to run your backend code on demand: there won’t be any real servers like EC2, Amazon infrastructure will start a container, which will run your Lambda function. Consider reading this article for explanations. I’d like to try this infrastructure. I decided to use Amazon API Gateway and Amazon Lambda for analyzing GitHub repositories: after each push to the repository I will examine all .md files and store them to Amazon Dynamo Database. More generally, I’ll create a backend part for a self-written blogging platform. Who knows, maybe I will write a frontend part soon. General plan The approach isn’t clear enough, so let’s clarify what do we need: We want to save articles on GitHub We need to have an API for our blog Since we need to have a good latency for API, reading articles from GitHub is not...

11 short stories about creating good pull requests

Once upon a time there was a good developer. He produced a good code, had good relations with his teammates and never break the master branch. This guy followed 11 rules and lived a long - long life. So I’m posting them here, in case someone will have a good reason to improve his way of working on pull requests. Make them small If you plan to change your source code, don’t make significant changes with dozens of classes involved. Make a granular, little changes containing < 10 files. It’s important because your teammates will do a review, and in a case of big pull requests it’ll take time to understand what you wrote, why you wrote it, and find possible bugs. By making smaller pull requests, you let your teammates review your code more precisely and find possible mistakes there. Give an initial point If you failed with small pull requests or not, always help your reviewers with a starting point. Where should they start? What unit of logic should they review first? It won’t be a problem for you to give this information and your teammates will review your PR’s faster. Write couple of comments If needed, support...