When building a message consumer you need to handle the various errors that will inevitably occur during message processing. If you’re using Amazon SQS as your message broker it provides some built-in support for error handling that you can utilise. But, if you want to handle all types of errors efficiently you should also add your own custom error handler. This post explains how you can do both these things, including how to classify message processing errors.
WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.
In my first post on the topic of JSON Schema I outlined the limitations of specifying data-formats by example, described how schema languages help address this, and provided an introduction to the not so well known schema language for JSON – JSON Schema.
In that first article I stated my intention to document non-trivial JSON data-format I specified in the future using JSON Schema in addition to using specification-by-example, whether it be for an API resource or a message payload. When you adhere to this you quickly realise that while producing a JSON Schema is valuable, to increase the value you’ll additionally want to extend the tests for your JSON producing components to automate the following:
This follow-up, second post on JSON Schema, provides example code for implementing the above such tests using Java, JUnit and an open-source library for JSON Schema Validation.
This is a short post on a couple of approaches to managing the rate of message consumption, their differences and how to choose between them.
XML has a supporting schema-language in the form of the XML Schema. What you may be unaware of is that JSON has one too.
Read-on to find out more and why you might want to use it if you’re not already.
As an online business grows in popularity it can highlight scalability problems in your architecture. Certain hardware and/or software components can struggle to keep up with increased demand and it may not be easy or cost-effective to address this by extending them in their present form, especially when the demand is ‘spiky’ in nature. My team was recently faced with such an issue. We decided to engineer our way out of the problem by designing a more scalable replacement solution. Key technical requirements for the new solution included the throughput and latency of a public web API. In this post I share details of how you can measure these performance characteristics of an API using Apache JMeter, and in the process I identify a very useful supporting JMeter plugin.
JMeter – Throughput per second graph
My team and I design and build a lot of REST APIs during the course of our work, to expose functionality and data to client systems, and to integrate our back-end services with one another. I was therefore interested in learning more about Amazon’s recently launched API Gateway service. This is a short post summarising the role and major features of Amazon API Gateway based on my own preliminary research and trialling. I also briefly cover what the service is not designed to support, and consider possible future use-cases.
The success of an online service with millions of users worldwide, and an interactive audience of several thousand, depends on a well architected and engineered software platform. Our engineering team has recently updated the software stack we use to build and deploy back-end (JVM-based) services for such an online service. In this post I share the choices we made, as well as some of the background (motivation behind the project, benefits we were looking to gain). This might help if you’re undertaking a similar strategic review and update of the software stack and deployment approach for your back-end services in the near future.
I’ve recently designed and built an open source API client for the REST API of a major enterprise video and webcast service, for use by its customers. It was a rewarding exercise that has helped me gain some valuable additional practical experience of emerging technology and tools for building and testing apps. This post outlines the value of the API client, its design, the technologies and tools I used, and how I rate them. I’ve open sourced the code to allow customers, and others, to view and reuse what I’ve built.
Over the course of the last month or so, I’ve invested some time familiarising myself with the major new features in Java 8, learning how to apply them, and understanding the benefits which can be gained from using them. As part of this exercise I’ve produced some code examples (see below) for the following features:
This is the next in a series of posts on RESTful web API design based on my experience of designing and building a set of public RESTful web services for a popular online platform. This post highlights the importance of upfront design of a separate model for REST resources, and contains suggestions on how to implement such a resource model in an API service’s application architecture.
