Microservices Deployment Cookbook: Deploy and manage scalable microservices

In your STS window, right-click anywhere on the Package Explorer, select New, and then select Maven Project, as shown in the following screenshot:

This will open a popup that will let you chose the type of Maven project you would like to create. We will skip the archetype selection by checking the box that says Create a simple project (skip archetype selection) and then hit Next:

In the next window, enter the following details to create your project:

After you have entered the details, hit Finish:

This will create a simple Maven JAR module with all the required directories in place. Depending on your IDE settings, STS configures your new project with the default Java version. If you have not set any defaults, it will configure your project with Java 1.5. You can verify this by checking your project structure in STS. The following screenshot shows that STS uses Java 1.5 for your project:

We will use Java 8's lambda expressions in other chapters. So let's change the Java version from 1.5 to 1.8. In order to change the Java version, we will configure the maven-compiler-plugin in the pom.xmlfile. Add the following section of code to your pom.xml file's project section:

        <build> 
          <plugins> 
           <plugin> 
              <groupId>org.apache.maven.plugins</groupId> 
              <artifactId>maven-compiler-plugin</artifactId> 
            <version>3.5.1</version> 
            <configuration> 
              <source>1.8</source> 
              <target>1.8</target> 
            </configuration> 
           </plugin> 
         </plugins> 
        </build> 

Save your pom.xml file, right-click on your project, choose Maven, and then hit Update Project... or use the keyboard shortcut Alt + F5. This will automatically change your project's Java version to 1.8.

Our microservice project is now ready to play with.

Create a Java class called com.packt.microservices.geolocation.GeoLocationApplication.java and give it an empty main method:

        package com.packt.microservices.geolocation;  
          public class GeoLocationApplication {  
            public static void main(String[] args) { 
            // left empty intentionally 
           } 
          } 

Now that we have our basic template project, let's make our project a child project of Spring Boot's spring-boot-starter-parent pom module. This module has a lot of prerequisite configurations in its pom.xml file, thereby reducing the amount of boilerplate code in our pom.xml file. At the time of writing this, 1.3.6.RELEASE was the most recent version:

        <parent> 
          <groupId>org.springframework.boot</groupId> 
          <artifactId>spring-boot-starter-parent</artifactId> 
          <version>1.3.6.RELEASE</version> 
        </parent> 

After this step, you might want to run a Maven update on your project as you have added a new parent module. If you see any warnings about the version of the maven-compiler  plugin, you can either ignore it or just remove the <version>3.5.1</version> element. If you remove the version element, please perform a Maven update afterward.

Spring Boot has the ability to enable or disable Spring modules such as Spring MVC, Spring Data, and Spring Caching. In our use case, we will be creating some REST APIs to consume the geolocation information of the users. So we will need Spring MVC. Add the following dependencies to your pom.xml file:

        <dependencies> 
          <dependency> 
            <groupId>org.springframework.boot</groupId> 
            <artifactId>spring-boot-starter-web</artifactId> 
          </dependency> 
        </dependencies> 

We also need to expose the APIs using web servers such as Tomcat, Jetty, or Undertow. Spring Boot has an in-memory Tomcat server that starts up as soon as you start your Spring Boot application. So we already have an in-memory Tomcat server that we could utilize.

Now let's modify the GeoLocationApplication.java class to make it a Spring Boot application:

        package com.packt.microservices.geolocation; 
        import org.springframework.boot.SpringApplication; 
        import org.springframework.boot.autoconfigure
         .SpringBootApplication; 
          @SpringBootApplication 
          public class GeoLocationApplication { 
            public static void main(String[] args) {
            SpringApplication.run(GeoLocationApplication.class, args); 
           } 
          } 

Now that our Spring Boot application is all set to run, let's see how to run our microservice. Right-click on GeoLocationApplication.java from Package Explorer, select Run As, and then select Spring Boot App. You can also choose Java Application instead of Spring Boot App. Both the options ultimately do the same thing. You should see something like this on your STS console:

If you look closely at the console logs, you will notice that Tomcat is being started on port number 8080. In order to make sure our Tomcat server is listening, let's run a simple curl command. cURL is a command-line utility available on most Unix and Mac systems. For Windows, use tools such as Cygwin or even Postman. Postman is a Google Chrome extension that gives you the ability to send and receive HTTP requests. For simplicity, we will use cURL. Execute the following command on your terminal:

      curl http://localhost:8080

This should give us an output like this:

      {"timestamp":1467420963000,"status":404,"error":"Not
      Found","message":"No message available","path":"/"}

Create a Controller class called com.packt.microservices.geolocation.GeoLocationController.java, which will be responsible for basic CRUD operations for the geolocation of all users:

        package com.packt.microservices.geolocation; 
 
        import org.springframework.web.bind.annotation.RequestMapping; 
        import org.springframework.web.bind.annotation.RestController; 
 
        @RestController 
        @RequestMapping("/geolocation") 
        public class GeoLocationController { 
 
        } 

There are two things to note here. The @RestController annotation indicates that we are going to use this controller to expose our REST APIs. It implicitly adds the @ResponseBody annotation to all controller methods as that is something you would want to do when exposing your REST APIs using Spring MVC. The @RequestMapping annotation specifies where your HTTP resource is located. We are setting @RequestMapping on the controller level to apply it to all controller methods.

Before we jump into creating our APIs, we will need some classes for the domain object and service. Let's start with creating our domain object. Assume that our GeoLocation consists latitude and longitude. We will be defining both latitude and longitude as double to provide better precision. Now we will have to say which user's geolocation it is. So we might want to add a userId. We also need to say at what time the user was at the geolocation. So we might want to add a timestamp in EPOCH time format. The timestamp will be of type long. This is how your plain old java object (POJO) class will look:

        package com.packt.microservices.geolocation; 

        import java.io.Serializable; 
        import java.util.UUID; 
 
          public class GeoLocation implements Serializable { 
 
            private static final long serialVersionUID = 1L; 
   
           private double latitude; 
           private double longitude; 
           private UUID userId; 
           private long timestamp; 
   
          public double getLatitude() { 
            return latitude; 
          } 
   
          public void setLatitude(double latitude) { 
            this.latitude = latitude; 
          } 
   
          public double getLongitude() { 
           return longitude; 
          } 
   
          public void setLongitude(double longitude) { 
            this.longitude = longitude; 
          } 
   
          public UUID getUserId() { 
           return userId; 
          } 
   
          public void setUserId(UUID userId) { 
           this.userId = userId; 
          } 
   
         public long getTimestamp() { 
          return timestamp; 
         } 
   
         public void setTimestamp(long timestamp) { 
          this.timestamp = timestamp; 
         } 
        } 

As you can see, we have used the java.util.UUID class to represent the userId, assuming that this UUID uniquely identifies a user. We will not be creating the user POJO as it is out of scope for this recipe.

In an ideal scenario, one would be using a NoSQL or relational database to store the geolocations. In this case, NoSQL sounds more suitable due to several reasons, including the fact that our data is time series data, in JSON format, unstructured but will change over time and we will have a humongous amount of data.

For simplicity purposes, we will be storing our geolocations in an in-memory java.util.List<GeoLocation> collection. Let's create our repository that holds all our geolocation objects, com.packt.microservices.geolocation.GeoLocationRepository.java:

        package com.packt.microservices.geolocation; 
 
        import java.util.ArrayList; 
        import java.util.Collections; 
        import java.util.List; 
 
        import org.springframework.stereotype.Repository; 
 
        @Repository 
        public class GeoLocationRepository { 
 
          private List<GeoLocation> geolocations = new
          ArrayList<GeoLocation>(); 
   
            public void addGeoLocation(GeoLocation geolocation) { 
              geolocations.add(geolocation); 
            } 
   
           public List<GeoLocation> getGeoLocations() { 
              return Collections.unmodifiableList(geolocations); 
           } 
         } 

Now let's take a look at how your Service interface will look:

        package com.packt.microservices.geolocation; 
 
        import java.util.List; 
 
        public interface GeoLocationService { 
 
          public GeoLocation create(GeoLocation geolocation); 
          public List<GeoLocation> findAll(); 
        }  

Both our repository and service have a very simple interface. Ideally in real-time applications, you might want to add more complicated methods that not only perform CRUD operations but also sort, filter, select only specific fields, and so on. Now let's take a look at our com.packt.microservices.geolocation.GeoLocationServiceImpl.java class:

        package com.packt.microservices.geolocation; 
 
        import java.util.List; 
 
        import org.springframework.beans.factory.annotation.Autowired; 
 
        import org.springframework.stereotype.Service; 
 
        @Service 
        public class GeoLocationServiceImpl implements
        GeoLocationService { 
   
          @Autowired 
          private GeoLocationRepository repository; 
 
          @Override 
          public GeoLocation create(GeoLocation geolocation) { 
           repository.addGeoLocation(geolocation); 
           return geolocation; 
          } 
 
          @Override 
          public List<GeoLocation> findAll() { 
            return repository.getGeoLocations(); 
          } 
        }

Now that our domain and service classes are all set to go, let's modify our Controller class to save and find geolocations. Add the following snippet into your Controller class body:

        @Autowired
        private GeoLocationService service;

        @RequestMapping(method = RequestMethod.POST, produces = "application/json", consumes = "application/json")
        public GeoLocation create(@RequestBody GeoLocation geolocation) {
          return service.create(geolocation);
        }
  
        @RequestMapping(method = RequestMethod.GET, produces = "application/json")
        public List<GeoLocation> findAll() {
          return service.findAll();
        } 

Let's try to create two geolocations using the POST API and later try to retrieve them using the GET method. Execute the following cURL commands in your terminal one by one:

      curl -H "Content-Type: application/json" -X POST -d'{"timestamp": 1468203975, "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", "latitude": 41.803488, "longitude": -88.144040}' http://localhost:8080/geolocation

This should give you an output similar to the following (pretty-printed for readability):

        { 
         "latitude": 41.803488, 
         "longitude": -88.14404, 
         "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", 
         "timestamp": 1468203975 
        } 
 
 
        curl -H "Content-Type: application/json" -X POST -d '{"timestamp": 1468203975, "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", "latitude": 9.568012, "longitude": 77.962444}' http://localhost:8080/geolocation

This should give you an output similar to the following (pretty-printed for readability):

{
          "latitude": 9.568012,
          "longitude": 77.962444,
          "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
          "timestamp": 1468203975
        }

To verify whether your entities were stored correctly, execute the following cURL command:

      curl http://localhost:8080/geolocation

This should give you an output similar to the following (pretty-printed for readability):

        [ 
        { 
          "latitude": 41.803488, 
          "longitude": -88.14404, 
          "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", 
          "timestamp": 1468203975 
        }, 
        { 
          "latitude": 9.568012, 
          "longitude": 77.962444, 
          "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", 
          "timestamp": 1468203975 
        } 
        ]

Before we set up the WildFly Swarm project, we have to fix the missing web.xml error. The error message says that Maven expects to see a web.xml file in your project as it is a WAR module, but this file is missing in your project. In order to fix this, we have to add and configure maven-war-plugin. Add the following code snippet to your pom.xml file's project section:

        <build> 
          <plugins> 
            <plugin> 
              <groupId>org.apache.maven.plugins</groupId> 
              <artifactId>maven-war-plugin</artifactId> 
              <version>2.6</version> 
              <configuration> 
                <failOnMissingWebXml>false</failOnMissingWebXml> 
              </configuration> 
            </plugin> 
           </plugins> 
        </build> 

After adding the snippet, save your pom.xml file and perform a Maven update. Also, if you see that your project is using a Java version other than 1.8, follow the Creating a project template using STS and Maven recipe to change the Java version to 1.8. Again, perform a Maven update for the changes to take effect.

Now, let's add the dependencies required for this project. As we know that we will be exposing our APIs, we have to add the JAX-RS library. JAX-RS is the standard JSR-compliant API for creating RESTful web services. JBoss has its own version of JAX-RS. So let's add that dependency to the pom.xml file:

        <dependencies> 
          <dependency> 
            <groupId>org.jboss.spec.javax.ws.rs</groupId> 
              <artifactId>jboss-jaxrs-api_2.0_spec</artifactId> 
              <version>1.0.0.Final</version> 
              <scope>provided</scope> 
          </dependency> 
        </dependencies> 

The next step toward creating the GeoLocation API using Wildfly Swarm is creating the domain object. Use the com.packt.microservices.geolocation.GeoLocation.java file from the previous recipe.

Now that we have the domain object, there are two classes that you need to create in order to write your first JAX-RS web service. The first of those is the Application class. The Application class in JAX-RS is used to define the various components that you will be using in your application. It can also hold some metadata about your application, such as your basePath (or ApplicationPath) to all resources listed in this Application class. In this case, we are going to use /geolocation as our basePath. Let's see how that looks:

       package com.packt.microservices.geolocation; 
 
       import javax.ws.rs.ApplicationPath; 
       import javax.ws.rs.core.Application; 
 
       @ApplicationPath("/geolocation") 
         public class GeoLocationApplication extends Application { 
 
          public GeoLocationApplication() {} 
         } 

There are two things to note in this class; one is the Application class and the other is the @ApplicationPath annotation-both of which we've already talked about.

Now let's move on to the resource class, which is responsible for exposing the APIs. If you are familiar with Spring MVC, you can compare Resource classes to Controllers. They are responsible for defining the API for any specific resource. The annotations are slightly different from that of Spring MVC. Let's create a new resource class called com.packt.microservices.geolocation.GeoLocationResource.java that exposes a simple GET API:

        package com.packt.microservices.geolocation; 
 
        import java.util.ArrayList; 
        import java.util.List; 
 
        import javax.ws.rs.GET; 
        import javax.ws.rs.Path; 
        import javax.ws.rs.Produces; 
 
        @Path("/") 
        public class GeoLocationResource { 
 
         @GET 
         @Produces("application/json") 
         public List<GeoLocation> findAll() { 
           return new ArrayList<>(); 
         } 
        } 

All the three annotations, @GET, @Path, and @Produces, are pretty self explanatory.

In order to make it a microservice using Wildfly Swarm, all you have to do is add the wildfly-swarm-plugin to the Maven pom.xml file. This plugin will be tied to the package phase of the build so that whenever the package goal is triggered, the plugin will create an uber JAR with all required dependencies. An uber JAR is just a fat JAR that has all dependencies bundled inside itself. It also deploys our application in an in-memory Undertow server. Add the following snippet to the plugins section of the pom.xml file:

        <plugin> 
          <groupId>org.wildfly.swarm</groupId> 
          <artifactId>wildfly-swarm-plugin</artifactId> 
          <version>1.0.0.Final</version> 
          <executions> 
            <execution> 
              <id>package</id> 
              <goals> 
                <goal>package</goal> 
              </goals> 
            </execution> 
          </executions> 
        </plugin> 

Now execute the mvn clean package command from the project's root directory, and wait for the Maven build to be successful. If you look at the logs, you can see that wildfly-swarm-plugin will create the uber JAR, which has all its dependencies. You should see something like this in your console logs:

After the build is successful, you will find two artifacts in the target directory of your project. The geolocation-wildfly-0.0.1-SNAPSHOT.war file is the final WAR created by the maven-war-plugin. The geolocation-wildfly-0.0.1-SNAPSHOT-swarm.jar file is the uber JAR created by the wildfly-swarm-plugin. Execute the following command in the same terminal to start your microservice:

      java -jar target/geolocation-wildfly-0.0.1-SNAPSHOT-swarm.jar

After executing this command, you will see that Undertow has started on port number 8080, exposing the geolocation resource we created. You will see something like this:

Execute the following cURL command in a separate terminal window to make sure our API is exposed. The response of the command should be [], indicating there are no geolocations:

      curl http://localhost:8080/geolocation

Now let's build the service class and finish the APIs that we started. For simplicity purposes, we are going to store the geolocations in a collection in the service class itself. In a real-time scenario, you will be writing repository classes or DAOs that talk to the database that holds your geolocations. Get the com.packt.microservices.geolocation.GeoLocationService.java interface from the previous recipe. We'll use the same interface here.

Create a new class called com.packt.microservices.geolocation.GeoLocationServiceImpl.java that extends the GeoLocationService interface:

        package com.packt.microservices.geolocation; 
 
        import java.util.ArrayList; 
        import java.util.Collections; 
        import java.util.List; 
 
        public class GeoLocationServiceImpl implements
        GeoLocationService { 
   
          private static List<GeoLocation> geolocations = new 
           ArrayList<>
          (); 
 
         @Override 
          public GeoLocation create(GeoLocation geolocation) { 
            geolocations.add(geolocation); 
            return geolocation; 
          } 
 
         @Override 
          public List<GeoLocation> findAll() { 
            return Collections.unmodifiableList(geolocations); 
          } 
        } 

Now that our service classes are implemented, let's finish building the APIs. We already have a very basic stubbed-out GET API. Let's just introduce the service class to the resource class and call the findAll method. Similarly, let's use the service's create method for POST API calls. Add the following snippet to GeoLocationResource.java:

       private GeoLocationService service = new
       GeoLocationServiceImpl(); 
 
       @GET 
       @Produces("application/json") 
       public List<GeoLocation> findAll() { 
         return service.findAll(); 
       } 
   
       @POST 
       @Produces("application/json") 
       @Consumes("application/json") 
       public GeoLocation create(GeoLocation geolocation) { 
         return service.create(geolocation); 
       } 

We are now ready to test our application. Go ahead and build your application. After the build is successful, run your microservice: let's try to create two geolocations using the POST API and later try to retrieve them using the GET method. Execute the following cURL commands in your terminal one by one:

          curl -H "Content-Type: application/json" -X POST -d '{"timestamp": 1468203975, "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", "latitude": 41.803488, "longitude": -88.144040}' http://localhost:8080/geolocation

This should give you something like the following output (pretty-printed for readability):

{
          "latitude": 41.803488,
          "longitude": -88.14404,
          "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
          "timestamp": 1468203975
        }

        curl -H "Content-Type: application/json" -X POST -d '{"timestamp": 1468203975, "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", "latitude": 9.568012, "longitude": 77.962444}' http://localhost:8080/geolocation

This command should give you an output similar to the following (pretty-printed for readability):

        { 
          "latitude": 9.568012, 
          "longitude": 77.962444, 
          "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", 
          "timestamp": 1468203975 
        }

To verify whether your entities were stored correctly, execute the following cURL command:

         curl http://localhost:8080/geolocation

This should give you an output like this (pretty-printed for readability):

        [
          {
             "latitude": 41.803488,
             "longitude": -88.14404,
             "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
             "timestamp": 1468203975
          },
          {
            "latitude": 9.568012,
            "longitude": 77.962444,
            "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
            "timestamp": 1468203975
          }
        ]

Create a Dropwizard configuration class. This is used to store any meta-information or resource information that your application will need during runtime, such as DB connection, Jetty server, logging, and metrics configurations. These configurations are ideally stored in a YAML file, which will then be mapped to your Configuration class using Jackson. In this application, we are not going to use the YAML configuration as it is out of scope for this book.

Let's create an empty Configuration class called GeoLocationConfiguration.java:

         package com.packt.microservices.geolocation; 
 
         import io.dropwizard.Configuration; 
 
         public class GeoLocationConfiguration extends Configuration { 
 
         } 

The YAML configuration file has a lot to offer. Take a look at a sample YAML file from Dropwizard's Getting Started documentation page to learn more. The name of the YAML file is usually derived from the name of your microservice. The microservice name is usually identified by the return value of the overridden method public String getName() in your Application class. Now let's create the GeoLocationApplication.java application class:

        package com.packt.microservices.geolocation; 
 
        import io.dropwizard.Application; 
        import io.dropwizard.setup.Environment; 
  
        public class GeoLocationApplication extends
        Application<GeoLocationConfiguration> { 
    
          public static void main(String[] args) throws Exception { 
            new GeoLocationApplication().run(args); 
          } 
 
          @Override 
          public void run(GeoLocationConfiguration config, Environment 
             env) throws Exception { 
             env.jersey().register(new GeoLocationResource()); 
          } 
        } 

There are a lot of things going on here. Let's look at them one by one. Firstly, this class extends Application with the GeoLocationConfiguration generic. This clearly makes an instance of your GeoLocationConfiguraiton.java class available so that you have access to all the properties you have defined in your YAML file at the same time mapped in the Configuration class. The next one is the run method. The run method takes two arguments: your configuration and environment. The Environment instance is a wrapper to other library-specific objects such as MetricsRegistry, HealthCheckRegistry, and JerseyEnvironment. For example, we could register our Jersey resources using the JerseyEnvironment instance. The env.jersey().register(new GeoLocationResource()) line does exactly that. The main method is pretty straight-forward. All it does is call the run method.

Before we can start the microservice, we have to configure this project to create a runnable uber JAR. Uber JARs are just fat JARs that bundle their dependencies in themselves. For this purpose, we will be using the maven-shade-plugin. Add the following snippet to the build section of the pom.xml file. If this is your first plugin, you might want to wrap it in a <plugins> element under <build>:

    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-shade-plugin</artifactId>
      <version>2.3</version>
      <configuration>
        <createDependencyReducedPom>true</createDependencyReducedPom>
        <filters>
          <filter>
            <artifact>*:*</artifact>
            <excludes>
              <exclude>META-INF/*.SF</exclude>
              <exclude>META-INF/*.DSA</exclude>
              <exclude>META-INF/*.RSA</exclude>
            </excludes>
          </filter>
        </filters>
      </configuration>
      <executions>
        <execution>
          <phase>package</phase>
          <goals>
            <goal>shade</goal>
          </goals>
          <configuration>
            <transformers>
              <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" />
              <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
    <mainClass>com.packt.microservices.geolocation.GeoLocationApplication</mainClass>
              </transformer>
            </transformers>
          </configuration>
        </execution>
      </executions>
    </plugin>
 

The previous snippet does the following:

It creates a runnable uber JAR that has a reduced pom.xml file that does not include the dependencies that are added to the uber JAR. To learn more about this property, take a look at the documentation of maven-shade-plugin.

It utilizes com.packt.microservices.geolocation.GeoLocationApplication as the class whose main method will be invoked when this JAR is executed. This is done by updating the MANIFEST file.

It excludes all signatures from signed JARs. This is required to avoid security errors.

Now that our project is properly configured, let's try to build and run it from the command line. To build the project, execute mvn clean package from the project's root directory in your terminal. This will create your final JAR in the target directory. Execute the following command to start your microservice:

      java -jar target/geolocation-dropwizard-0.0.1-SNAPSHOT.jar server

The server argument instructs Dropwizard to start the Jetty server. After you issue the command, you should be able to see that Dropwizard has started the in-memory Jetty server on port 8080. If you see any warnings about health checks, ignore them. Your console logs should look something like this:

We are now ready to test our application. Let's try to create two geolocations using the POST API and later try to retrieve them using the GET method. Execute the following cURL commands in your terminal one by one:

        curl -H "Content-Type: application/json" -X POST -d '{"timestamp": 1468203975, "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", "latitude": 41.803488, "longitude": -88.144040}' http://localhost:8080/geolocation

This should give you an output similar to the following (pretty-printed for readability):

{
          "latitude": 41.803488,
          "longitude": -88.14404,
          "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
          "timestamp": 1468203975
        }

        curl -H "Content-Type: application/json" -X POST -d '{"timestamp": 1468203975, "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", "latitude": 9.568012, "longitude": 77.962444}' http://localhost:8080/geolocation

This should give you an output like this (pretty-printed for readability):

{  
          "latitude": 9.568012,
          "longitude": 77.962444,
          "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
          "timestamp": 1468203975
        }

To verify whether your entities were stored correctly, execute the following cURL command:

      curl http://localhost:8080/geolocation

It should give you an output similar to the following (pretty-printed for readability):

[
          {
            "latitude": 41.803488,
            "longitude": -88.14404,
            "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
            "timestamp": 1468203975
          },
          {
            "latitude": 9.568012,
            "longitude": 77.962444,
            "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
            "timestamp": 1468203975
         }
       ]

Let's create our controller com.packt.microservices.geolocation.GeoLocationController.java with a stubbed-out GET API:

      package com.packt.microservices.geolocation; 
 
      import static spark.Spark.*; 
 
      public class GeoLocationController { 
 
        public static void main(String[] args) { 
          get("/geolocation", (req, resp) -> "[]"); 
        } 
      } 

The quickest way to test this is by running this class as a Java application. If you get SLF4J errors in your console after you start the application, add the following Maven dependency to your pom.xml file and restart your application:

      <dependency> 
        <groupId>org.slf4j</groupId> 
        <artifactId>slf4j-simple</artifactId> 
        <version>1.7.21</version> 
      </dependency> 

The slf4j-simple dependency routes all the SLF4Jlog messages to the System.err stream.

Your console logs should look something like this after the restart:

From the logs, we can clearly see that the service is running on port 4567.

Execute the following curl command in a terminal window to make sure our API is exposed. The response of the following command should be [], indicating there are no geolocations:

      curl http://localhost:4567/geolocation

Now let's finish building the APIs. We already have a very basic stubbed-out GET API. Let's just introduce the service class to the controller and call the findAll method. Similarly, let's use the service's create method for POST API calls. Before we do that, we need to do one more thing. By default, SparkJava does not perform JSON serialization and deserialization. We will be using a library called gson to do that. So add the following dependency to your pom.xml file:

        <dependency>
          <groupId>com.google.code.gson</groupId>
          <artifactId>gson</artifactId>
          <version>2.7</version>
        </dependency>

Now let's replace the main method of GeoLocationController.java with this:

    public static void main(String[] args) {
      GeoLocationService service = new GeoLocationServiceImpl();
      Gson gson = new Gson();
    
      get("/geolocation", (req, resp) -> {
        return service.findAll();
      }, gson::toJson);
    
      post("/geolocation", (req, resp) -> {
        return service.create(gson.fromJson(req.body(), GeoLocation.class));
      }, gson::toJson);
    }

Execute the following cURL commands in your terminal one by one:

        curl -H "Content-Type: application/json" -X POST -d '{"timestamp": 1468203975, "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", "latitude": 41.803488, "longitude": -88.144040}' http://localhost:4567/geolocation

This should give you an output similar to the following (pretty-printed for readability):

        {
          "latitude": 41.803488,
          "longitude": -88.14404,
          "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
          "timestamp": 1468203975
        }

        curl -H "Content-Type: application/json" -X POST -d '{"timestamp": 1468203975, "userId": "f1196aac-470e-11e6-beb8-9e71128cae77", "latitude": 9.568012, "longitude": 77.962444}' http://localhost:4567/geolocation

This should give you an output like this (pretty-printed for readability):

        {
          "latitude": 9.568012,
          "longitude": 77.962444,
          "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
          "timestamp": 1468203975
        }

To verify whether your entities were stored correctly, execute the following cURL command:

      curl http://localhost:4567/geolocation

It should give you output similar to the following (pretty-printed for readability):

        [
          {
            "latitude": 41.803488,
            "longitude": -88.14404,
            "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
            "timestamp": 1468203975
          },
          {
            "latitude": 9.568012,
            "longitude": 77.962444,
            "userId": "f1196aac-470e-11e6-beb8-9e71128cae77",
            "timestamp": 1468203975
          }
       ]