In the not too distant past I sold the powers that be at my workplace on my building an API layer for some of our databases in order to make future projects easier. That of course led to doing research on what I was to use to build such a thing. I ended up playing with a few different tools and landed on Spring Boot as a favorite. Admittedly one of the reasons I gave it a shot was due to my dislike of having to edit XML configuration files. But once I started working with it I found it to be perfect for the type of system I wanted to build. It took care of a crap ton of boilerplate and configuration and then stood back to watch me code in the business logic and ended up being perfect for the Microservices Architecture I wanted to roll out.
So I've given out some pretty hefty praise thus far, but I suppose you're wondering specifically how I came to these conclusions. One of the best demonstrations of this is to look at a simple method from one of my controllers I've got setup.
There are a couple of things to notice in the Git Gist above including a number of interesting annotations that help make everything rather easy. The first of these you'll notice is that @Autowired annotation above my DataSource object. The use of that allows the application to take the configuration I have setup in my application.properties file and then automatically configure the datasource with those settings in mind. That configuration file is incredibly easy to set up as it just looks like this:
spring.datasource.driverClassName=net.sourceforge.jtds.jdbc.Driver
spring.datasource.url=jdbc:jtds:sqlserver://server/database
spring.datasource.username=username
spring.datasource.password=password
The @RequestMapping, @ResponseBody, and @RequestParam annotations are pretty self explanatory which then leaves the JdbcTemplate object. Since ultimately most of the functionality of a web service like this is to simply push data around where it needs to go, being able to call store procedures in a way that isn't super verbose is certainly a win. In the case above we're sending an email and password parameter over to the database and getting back data about a 'consumer.' The consumer is then built into an object through the use of a RowMapper and then returned. Were we attempting to select a bunch of customers this method wouldn't change at all, save for returning a whole List<Consumer> object instead of a single Consumer.
Lastly on this ramble I want to touch on how neat this is for microservices. For example in the application I'm building there are a couple of different databases I wish to push data back and forth from, and those databases have very different purposes. I could build one monolithic application to handle all of it, or I could take a more incremental approach and build each logical piece together as separate services (which is what I decided to do). Spring boot makes this easy to implement because you can export jar files that have an embedded tomcat instance built into them. This allows you to take that jar file on to more or less the server of your choice (with java installed of course) and just kick off the jar. When you need to redeploy something you merely need to stop the jar, replace it and kick it off again. As you can imagine it would be quite easy to automate this via script or your favored management tool. You also gain a bit of resilience with this model as one service need not affect the others if it goes down, be it for maintenance or some sort of catastrophic event. Instead of losing everything you lose functionality for one logical business interest. I could ramble on Microservices for another few paragraphs but instead of punishing you with that I offer you an excellent article on the subject.
That concludes my gushing about Spring Boot. Granted my exposure and use of it is pretty cursory but the experience has been positive thus far. Feel free to comment or email me if you have any questions or opinions to share. Happy coding!
So I've given out some pretty hefty praise thus far, but I suppose you're wondering specifically how I came to these conclusions. One of the best demonstrations of this is to look at a simple method from one of my controllers I've got setup.
There are a couple of things to notice in the Git Gist above including a number of interesting annotations that help make everything rather easy. The first of these you'll notice is that @Autowired annotation above my DataSource object. The use of that allows the application to take the configuration I have setup in my application.properties file and then automatically configure the datasource with those settings in mind. That configuration file is incredibly easy to set up as it just looks like this:
spring.datasource.driverClassName=net.sourceforge.jtds.jdbc.Driver
spring.datasource.url=jdbc:jtds:sqlserver://server/database
spring.datasource.username=username
spring.datasource.password=password
The @RequestMapping, @ResponseBody, and @RequestParam annotations are pretty self explanatory which then leaves the JdbcTemplate object. Since ultimately most of the functionality of a web service like this is to simply push data around where it needs to go, being able to call store procedures in a way that isn't super verbose is certainly a win. In the case above we're sending an email and password parameter over to the database and getting back data about a 'consumer.' The consumer is then built into an object through the use of a RowMapper and then returned. Were we attempting to select a bunch of customers this method wouldn't change at all, save for returning a whole List<Consumer> object instead of a single Consumer.
Lastly on this ramble I want to touch on how neat this is for microservices. For example in the application I'm building there are a couple of different databases I wish to push data back and forth from, and those databases have very different purposes. I could build one monolithic application to handle all of it, or I could take a more incremental approach and build each logical piece together as separate services (which is what I decided to do). Spring boot makes this easy to implement because you can export jar files that have an embedded tomcat instance built into them. This allows you to take that jar file on to more or less the server of your choice (with java installed of course) and just kick off the jar. When you need to redeploy something you merely need to stop the jar, replace it and kick it off again. As you can imagine it would be quite easy to automate this via script or your favored management tool. You also gain a bit of resilience with this model as one service need not affect the others if it goes down, be it for maintenance or some sort of catastrophic event. Instead of losing everything you lose functionality for one logical business interest. I could ramble on Microservices for another few paragraphs but instead of punishing you with that I offer you an excellent article on the subject.
That concludes my gushing about Spring Boot. Granted my exposure and use of it is pretty cursory but the experience has been positive thus far. Feel free to comment or email me if you have any questions or opinions to share. Happy coding!
No comments:
Post a Comment