The hypermedia API has taken a back seat for the last couple of months. I’ve been working on a bunch of projects that have taken my time. I have a couple that have my interest so they’re getting the largest share of my time but yet have so many more to work on. I’ve also got this leadership program I’m participating in that is taking a lot of my time, too. It has had some benefits, but has been a much bigger drain than I thought it would have been. Outside of work I’m booked, too. Church stuff, my outdoor activities, and being a husband and father of two daughters has my time well spoken for.
My main project right now involves trying to create a full stack HTTP API based service app with an AngularJS web app, all-the-while trying to create a complete continuous delivery process for the first time. We’re using Spring Boot with the web starter using REST Controllers. We’re going for the embedded tomcat server deployment. I have to say that I have a good team on this one. It’s new to everyone, but I’ve been able to slowly relax the muscles above everyone’s eyebrows to this point (although I’m sure there have been some bad things said about me at points). We’re really embracing change on this one. We’ve ‘restarted’ several aspects a few times now… especially our testing methodology, and I’m pretty sure we’re still not quite right. Our latest changes is going from using the Spring MVC Mock support in our unit tests to just switching back to using Mockito and doing it the way I’ve always known. I loved the way the mock stuff from Spring gave us a little more coverage (our mappings and path/request parameters were tested as well as our code), but we found today that we were really doing much more integration testing than unit testing. So after a couple hours of working with the developer, we redid a few tests and gave her a blueprint to ‘fix’ all of the others.
Did I mention that this API will be used by basically every new application we make? And, oh yeah, even our legacy apps will be backported to use this API over time. It’s a biggie. So I’m trying to put us just shy of the bleeding edge. I want this system to be modern when it’s released and I want it to be a model of sorts for us. I want it to exhibit all qualities I work towards developing in all of our systems:
- High Performance
- Maintainable
- Scalable
- Highly available
- Reliable
- Manageable
- Secure
- Auditable
That last one has caused me some concerns and I wonder if OCD is just haunting me. This topic is a post on its own so I won’t dive deep here, but think of having a database that you record every API request… not necessarily the content of the request, but more of the ‘usage’. Think of what the government calls ‘metadata’. I was thinking servlet filter that writes to the DB, but then you have the issue of database uptime… it should be good, but its the real world so who knows? Do you want all of your APIs to stop just because someone is patching a DB server? After being concerned with that, I thought about going with a JMS solution, but it’s not that much different. If our provider is down or hanging, we’re screwed just the same… I think. I’m still working on it, but I’m thinking some task executor stuff using Spring Integration would be good as long as we’re tolerant of losing some API log/audit info is tasks are killed. I think I’m OK with that. It should be the exception and it would be a small price to pay for the stability given otherwise. Anyways, like I said, that is an entire post on its own that I might do once I figure it out.
Sometimes, I wonder if this is all easy and I just don’t get it. Right now I think this stuff is hard and I just have to work at it.
Either way, I love this stuff.
What am I watching/reading:
Book: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation – Jez Humble, David Farley
Video: Building a Continuous Delivery Pipeline with Gradle and Jenkins – Peter Niederwieser
mikewitters.com 
Leave a Reply