Whether it's Docker or Kubernetes (or some flavour thereof), running microservices in containers is a powerful option. It can make it easy to deploy development or test systems, ensuring consistency across your development team. But when you move from consuming to building, particularly when you're building less out-of-the-box containers, there are some deeper elements that you need to be aware of.
JUnit testing just makes sense. But writing tests is certainly a skill and your tests can have a big impact on how you structure your code. Sometimes a sensible bit of refactoring can have a large impact, particularly if the code or unit tests were not written in the best way.
It is inevitable that some code will need to interact with a database, and that database will not be available when the unit tests run. There are multiple approaches for handling code that cannot run in a test.
Recently I've been diving back into running Java outside of the Domino HTTP stack, picking up some work I did quite a few years ago playing with Vert.x and Domino based on Stephan Wissel's blog series on Vert.x and Domino. Quite a few things have happened since I was last working on the project, not least the laptop I had at the time got rebuilt, I have got a new laptop, several version of Eclipse have been released and XPages SDK has been deployed to the Eclipse Marketplace (thanks Jesse Gallagher).
A few weeks ago, IBM announced Watson Workspace, the final name for Project Toscana, and its API Watson Work Services. The product itself has similarities to Slack or Microsoft Teams, but this post is not about discussing a comparison of the products. It's about the API backing it.
Watson Work Services is a REST API that uses GraphQL, a method of querying and posting via REST that focuses on configurability. Whereas traditional REST services have fixed endpoints that take fixed parameters and return fixed data objects, GraphQL is a sort of "API-as-a-service". You call an endpoint, pass a JSON object determining what elements of which data you want to return, include any dynamic variable values. The queries are passed to an engine at a REST service endpoint which parses the JSON passed, replaces any variables with the dynamically passed values, and returns just what the application or user asks for. This may include data from what, in a traditional REST API application, would be from different REST endpoints. For example, to get members and messages from a space, you might need to make a REST call to get the space ID, then another REST call to get its members, and a third to get the messages.