Google App Engine makes it easy to deploy NodeJS applications. The GAE Standard Environment and SDK support NodeJS out of the box. This makes Google App Engine a great choice ahead of competitors such as Heroku, AWS or Microsoft Azure. Unfortunately though, there’s no support for managing secrets in Google App Engine. When I deployed Dog n Bone to GAE, I found this single shortcoming the main source of complexity.
There are however some workarounds. None of them is particularly nice though.
When I built out Dog n Bone – a browser phone powered by Twilio, I found that behavior on providing an incorrect accountSid / authToken was not quite what I expected. This post details how I detected Twilio API login failures in Dog n Bone.
Twilio uses ClientCapability tokens to grant access to API features. The back end obtains a ClientCapability object using a Twilio accountSid and authToken. It sets scopes on the ClientCapability to grant only necessary permissions on that account. API requests in the front end authenticate using the JWT created from the CapabilityToken. This mechanism allows the front end to authenticate to the API without exposing the Twilio accountSid / authToken.
This article demonstrates some more advanced test first React practices. Specifically, API calls and mocks.
React is a great choice for writing test first client side Javascript. The test ecosystem is mature enough to enable test first development of complex components. This article shows how to build a React component test first and introduces supporting test libraries Jest and Enzyme. In the next article we’ll look at more advanced testing including API testing and module mocking.
CRUD REST services are the backbone of a microservice architecture. If we want to use microservices rather than monolithic applications, it’s essential that we can create a basic service with a minimum of effort. Spring Boot can be used to quickly create and deploy a new web service. Spring Data REST can be used to build out the REST interface based on a database entity model. Using both together allows us to create a running RESTful web service with zero custom Java code and no tricky XML.
This article describes how to build a RESTful web service as an executable JAR that provides CRUD operations against a single MySQL database table.
This demo can be downloaded from GitHub in the Spanners Demo Application version 4.0 (spanners-api module). You can run the working example as a docker-compose stack, along with the associated MySQL database and the Spring MVC web app that consumes the service (see the previous post on docker-compose for details on how to run this).
The Node.js website describes it as having “an event-driven, non-blocking I/O model that makes it lightweight and efficient”. Sounds lovely, but what’s it actually for?
Modulus’s excellent blog post – An Absolute Beginner’s Guide to Node.js provides some rather tasty examples. After covering the trivial examples (Hello world! and simple file I/O), it gets to the meat of what we’re about – an HTTP server. The simple example demonstrates a trivial HTTP server in Node.js in 5 lines of code. Not 5 lines of code compiled to an executable or deployed into an existing web server. 5 lines of code that can be run from a simple command. It then goes on to describe the frameworks and libraries that let you do really useful stuff.
This looks just the thing for implementing a new feature in the Spanners demo app: push notifications to all logged-in users when a spanner is changed.
The Tomcat7 plugin for Maven has a number of uses. In a previous post, I’ve looked at using it to deploy a build to an embedded Tomcat server for integration testing with Selenium.
A more simple use case is to simply deploy (or undeploy) a built artifact (war) to a Tomcat installation on a local machine or on a remote server.
The following examples are available to download from the Spanners Demo on GitHub.
The MockMVC class allows tests to be run against a real Spring application context without actually having to run the complete application in a Servlet container
Integration tests are a valuable tool in the development of robust, quality software. Once each individual component has been unit tested, the integration test gives some confidence that the system stack as a whole does what is expected. Like unit tests, a great deal of the value of integration tests comes from the regression suite that they create. After any defect fix or enhancement to software, the unit and integration tests confirm that all existing features do exactly what they did before. If these tests are automated, they cost nothing to run and they’ll stay silent unless a defect is discovered.
I’ve looked at unit testing a few times in the past but this post explains how to integration test the full stack – database, Java application and web server. In this case, I’m running the tests as part of the Maven build lifecycle. As usual, I’m working from the Spanners demo (available for download), mainly working against the spanners-struts web component.