From a presentation I did at Silicon Valley Code Camp 2014
Rapid Application Development Defined
Rapid Application Development (RAD) is a loaded term, meaning many things to many people. Let me start of by clarifying what I mean by RAD — RAD does not mean code like hell, nor does it does not mean employing a tool that codes for you. When I say RAD, I am referring to the practice of leveraging existing services, components, patterns and practices to maximize the code that relates to your domain, and minimize boilerplate or commodity feature development. For example, code in your application that marshals XML or JSON has no customer value nor does it have a developer benefit. It’s tantamount to creating TCP packets in your code to send a request to a service. Sounds ridiculous, yet I have seen this practice over and over. Not only is it a waste of time, it’s error prone, and unmaintainable. As an application developer, you are not being paid to build commodity services…
Commodity Services Abound
There are a plethora of frameworks and platforms in every technology stack that attempt to address this and other commodity needs for the application developer. Over time, the things we feel we need to code ourselves today become as preposterous as the TCP packet example – more and more moves down the stack into framework or platform components and services. It’s the natural evolution of software, especially in the new world order of open source and massive developer contribution and collaboration (thanks Github!).
While it is wonderful that your current and future needs are being addressed by others, much of the developer effort starts to shift to finding the project that has a solution for you and how you can use it, if at all. Making sense of it all can be daunting. Fun facts, as of Oct 2014:
- NPM hosts 97,613 packages
- PyPI hosts 49,603 packages
- Maven Central hosts 87,864 packages
- Ruby Gems hosts 89,387 packages
- Nuget hosts 27,580 packages
This is both the beauty and the chaos of the world of open source.
Frameworks Abound
Frameworks play a large role in helping tame this chaos. They typically provide a collection of curated Components that work seamlessly together. As well, these frameworks provide implied (or explicit) patterns and practices to help maintain good architecture and maintainability. Some will go so far as endorsing other combinations of components in use for known use cases.
The Era of The Platform
Platforms go beyond software components and frameworks. Platforms typically add more commodity services beyond pure software components, including
- Development Tooling
- Deployment Automation and Services
- Systems Management
- Testing Infrastructure
- Maintenance of Framework Components
- Versioning and Release Management
Platforms are trying to create cohesive technology experiences for developers and businesses so that you choose them as your one-stop-shop. This used to be restricted to the likes of IBM and Microsoft, but now it’s a much more diverse and heterogeneous world where cherry-picking best-of-breed software and patterns is the norm.
Less for you to worry about, more time to focus on your domain!
Making Good Choices
As a developer or (gasp!) software architect embarking on technology choices, you have a huge responsibility. You don’t want to paint yourself into a corner with a framework that is simple but potentially limited in functionality, yet you don’t want to choose something feature-rich but overwhelming complex and gnarly. Questions to ask yourself:
- What do I need from the framework in the short term?
- What might I need from the framework in the future?
- How has the framework evolved, will it continue?
- Are there enough people skilled in the use of this framework?
- Is the documentation and support good?
- Is it an ordeal or a joy to work with?
- Is there a platform behind this framework?
Spring? For Real?
Every time I tell someone I’m giving a talk on Spring with the word “Rapid” in the same sentence thinks a few things, some of which are not always uttered out loud:
- you are mad
- you are old
- you have so many other options, why suffer?
The short answer is, Spring has everything I know I will need down the road as the apps and services I work on evolve. It has the patterns in place that provide sensible architecture and make extending it straightforward. It gives me the flexibility to do anything that any other framework does.
Yes, it used to be DEATH BY A THOUSAND CONFIGURATION FILES but now there’s a a way to make things more cohesive and productive – Spring Boot.
So what does Spring Boot do to accelerate your development? The Spring Platform consists of components and frameworks that are useful in and of themselves, but are brought together through Spring Boot in a way that lends itself to true RAD. The framework is road-tested, and continues to be actively developed, keeping up with the latest technologies and patterns (Big Data, Reactive, HATEOS, Microservices, Cloud-deployed) and actively partnering with other OSS projects.
What is Boot?
Spring Boot has been explained many times and probably better than what I am about to, so please take Josh Long‘s word over mine but I’ll give it a shot. In essence Spring Boot provides:
- Dependency Management “Simplification”
- Automatic Component Configuration
- Cross-cutting infrastructure services
- Deployment and Packaging alternatives
How does it do it? The simple answers are (respectively),
- “Starter Packs” of dependencies
- Convention-based configuration
- Production-ready services such as metrics, health, app lifecycle.
- Maven and Gradle plugins
Starter Packs
Starter Packs bring together Spring and Third-Party dependencies needed to do something functionally. Examples of a starter pack include
- Web
- Data
- Security
- Test
A starter pack is essentially a manifest (in the form of a maven POM) that defines what each pack requires in and of itself. You simply include the starter pack you need in your app’s POM (or Gradle file).
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency>
The Magic of @EnableAutoConfiguration
The key to ending the suffering of the DEATH BY A THOUSAND CONFIGURATION FILES is to use the @EnableAutoConfiguration annotation. This is the big hint that Boot uses to start performing various incantations and magic upon your application such that you should not, ever, never, seriously never need an xml configuration file. Beyond not needing an XML configuration file, you don’t need that much configuration even outside of files. Here’s how it works: Boot scans your classpath to see what kind of goodies you’ve included, and attempts to auto-configure for those. It also scans your application to see what @Beans are in place and which aren’t (but perhaps should be?) and backs off (respecting your config) or autoconfigures according to convention. Finally, you can help Boot with your application-specific settings (like DataSource config, ports, etc) with your application.yml or application.properties.
To understand why this is significant, it helps to remember how things were before this.
Traditional Spring Way
- Configure Web Container
- Create Web Project
- Configure POM/Gradle/Ant dependencies (with versions) build and and packaging (150 lines +)
- Configure web.xml with Spring context config files, dispatcher servlet, servlet mapping, Spring security Filter, etc..
- Write Controller, Service, Repository Beans and Domain Objects
- Configure *.xml files (Or annotated @Configuration Beans) with
- Bean definitions,
- View resolvers,
- content-negotiation,
- controller mapping,
- resource handling,
- error handlers,
- db pooling,
- connections,
- profiles,
- transactionmanager,
- jdbc templates or JPA config.
- Write code to create/update schema from script
- Package WAR file
- Deploy to running Web Container.
Spring Boot Way
- Use/Include Spring Boot Starter Parent in pom/Gradle, add Spring Boot Starter Web and JPA
- Write Controller, Service, Repository Beans and Domain Objects
- Write Application class with @EnableAutoConfiguration
- Run
I’m not kidding, you actually get to just write code for your app.
Infrastructure Services
Infrastructure services are things you don’t think about until after you deploy your app into the world, and realize you don’t know what the heck is going on out there. It’s something you now can throw in right away, leverage what is provided, and then enhance them according to your own needs. Including the Spring Actuator Starter give you (among other things):
- Audit
- Metrics
- Guages
- Tracing
- Configuration Views
- Remote management via SSH
Packaging Alternatives
As noted before, Spring Boot provides Maven and Gradle plugins that give you a couple packaging alternatives for you application.
Package as a JAR
- Choose embedded container (Jetty, Tomcat)
- Configure container programmatically and/or via application config
- Run using java –jar
Package as a WAR
- No web.xml required
- Spring Dispatcher Servlet is auto-configured
- Deploy to any Servlet container
Enough Talk
In the end, it developers don’t like reading manuals (or long blog posts), they want code! I created a project to demonstrate using Spring Boot to make a halfway non-trivial application that goes beyond “Hello World”.
Just clone it locally to give it a spin, or fork it if you want to hack on it/
git clone git@github.com:hoserdude/to-boot.git
The app was cobbled together in about 2 days, which goes to show how productive Boot can be, or if you are faster than me, how slow I am.
To-Boot was meant to demonstrate the following
- Boostrapping (POM, Application.class)
- Controllers (Routes, Marshalling, Resource Handling)
- Views (Thymeleaf, AngularJS)
- APIs (Swagger, DTO definition, Content Negotiation)
- Security
- Persistence (Config, Repositories, Domain Beans)
- Application Structure, DI
- Monitoring and Metrics
- Deployment Options
I welcome contributions to this example if anyone feels something can be improved or added to it.
Enjoy.
