I wrote recently about how what most of us build as back-ends aren’t really APIs, but just a back-end that provides data to your Javascript. I’ve emphasized the fact that a basic RESTful back-end is not, in fact, an API, and that there are differences between how you build and run the 2. However, there are also very important similarities to REST back-ends and APIs that you need to remember.
I’ve been sitting down and spending some more time with the Hotwire framework after building an initial proof-of-concept and moving towards a simple 0.1 version of something. I still really like the framework, mostly because it simplifies a lot of development, without feeling like I’m sacrificing anything. Not only am I not doing as much work in the front-end, but the advantage of server-side rendering means there’s little to no state to manage in the front-end, which seems to be a huge part of front-end development. Moving from the “standard” way of writing a static webpage and populating it based on JSON data to rendering the page on the server-side is a change in how back-end development gets approached, but really it’s not as much as you may think. I stand by my comments in my original post – Hotwire is my first choice for a front-end framework.
I was working on hotfix that turned hotter than I wanted during the deployment, all because we missed an important test case that left us scrambling to resolve an issue during the deployment that we should have caught earlier. We got lucky and fixed it during the deployment, but we shouldn’t have been in that position because the scenario that failed was a known requirement, which means we should have tested it. So what happened? Well, point blank, we forgot a test case.
So I was working through an issue where I’m having to put together a multi-table query that gets run as part of a scheduled job, and as I’m taking a break after finding the XML file and getting this query (and resulting data mapping) added to said XML file, I come across this tweet, and it described exactly what I was feeling. Why was I shoving queries into an XML file shunted away in my resources directory instead of just building it in the code? Surely there are better ways to construct SQL queries, right? Well, maybe, but in the end, what I was doing was probably better than I thought it was at the time.
I spent some time playing with Hotwire (for HTML Over The Wire) framework, mostly because it promised building a web application with minimal Javascript. As someone who’s largely a back-end developer and general Javascript non-enthusiast, that fact right there made Hotwire very appealing. Hotwire has absolutely delivered on its minimal Javascrip promise – in fact, I think it’s going to be my first choice for front-end development.
It’s really popular to say we’re writing web services, built on top of RESTful APIs, but the reality is what most of us are really doing is writing web applications that make REST calls back to that app’s server for data, not actually calling a generalized web service with multiple sets of users. That’s fine – I use web applications almost all day just like everyone else. Occasionally we need to actually get some data from another team’s data store, and it’s cool, they have an endpoint you can hit and get it. See? Web services with RESTful APIs. The problem is there’s a difference between, “There’s an endpoint that can give us that data” and running a service who’s purpose is to be used by anyone other than the team that wrote it. Continue reading »
We all screw up, it’s part of life. What’s important that we learn from it all. I’ve found it’s generally better to document the learning, both to help internalize it, and to share it with who I can. I recently worked an issue stemming from automated API call retries that didn’t go nearly as well as it probably should have, and I wanted to take a little time to post-mortem on how everything went, and how it could have gone better. A lot of this is fairly specific to what I was doing with that particular problem, but there’s hopefully some general lessons that can be drawn from the whole ordeal.
We’re all used to dealing with different environments in our code. On the surface, this just means that we need to make sure our code runs fine in all of our environments. But what about the other services that your code is consuming? If your reaction is that it’s the responsibility of the team writing and running that code to make sure that it’s up and running, you’re living in a fantasy. At some point, you have to write (and maintain) your side of the connection to those services, and if something goes wrong, you have to be able to show the issue isn’t on your end. Oh, this is assuming an exact 1-1 match between your environment and their environment (for example, your dev to their dev, your QA to their QA). Even if the external environment doesn’t use the same naming conventions as you, having each of your environments connect to 1 (and only 1) environment of an external service simplifies things exponentially. If people are asking that you update your code to point to other environments of your dependencies, your life gets complicated fast.
Not too long ago, my friend Warren tweeted a link to Atkin’s Laws of Spacecraft Design. That in turn got me thinking about Peter’s Laws: The Creed For The Sociopathic Obssessive Compulsive (which I had in poster form for the better part of a decade), and that inspired me to think of truisms I’ve learned about software development over the years. I may not have enough to fill a full 20+ (or even 40+) item list, but maybe I’ll update and add to it over the years. So without further ado, I present to you, Hydrick’s Laws For Software Development.
During some recent performance testing at work, we noticed an endpoint showing slower than usual response times. Digging into the calls, we found that on slow responses, virtually all the time was spent on waiting for a specific lambda function to return data. Digging into that function we found several calls that appeared to be timing out, and many others that were taking 9-10 seconds. This lead to a day or 2 spent reading up on the workings of AWS lambdas and how they work with Java. What was probably most striking is that while the solution to our problem was eventually findable with some Googling – and the “fix” involved practices that are mentioned in the official AWS documentation – they’re almost mentioned in passing, and don’t call out the performance impacts they have on your billed runtime.