Posts
-
Lessons learned when building Serverless web applications - Part 2
With Serverless we get rapid provisioning, automation and consumption based billing. This enables new development and release processes that are just not possible with traditional applications and infrastructure. Add to this a DevOps culture and the dream to build, test, and release software faster and more reliably becomes true. This part of the Serverless lessons learned series focusses on Continuous Delivery.
-
Lessons learned when building Serverless web applications - Part 1
During the last couple of years my team has built different Serverless Web applications both on AWS and on Azure. In this series of posts, I would like to share a few lessons learned and patterns that have worked very well for us.
-
Chatbots and virtual assistants for businesses
In my first blog post on Arvato’s blog, I’m explaining how chatbots/virtual assistants can provide great value also in the corporate world. By using more automation and providing a seamless interface, processes become much more efficient. But that’s not all. Read the story here: How virtual assistants can help your team with automation
-
Building a smart Chatbot with ClaudiaJS, Watson NLP and AWS
There are already many examples on how to quickly develop a chatbot with AWS Lambda and API Gateway (see here and here). However, most of them don’t go much further than replying to a few well defined commands. If you want to compete in the brave new bot world, your bot needs to be more than just a new command line interface. It needs to understand human language (NLP) and it needs to be able to have conversations (state, memory). This post shows how to integrate with Watson Conversation and AWS DynamoDB to give your bot natural language understanding and a memory.
-
AWS API gateway as HTTP proxy with Lambda workaround
In addition to invoking Lambda functions and other AWS services such as S3, the API Gateway can also act as a proxy between the user and your http based service. For example if you already have a service based architecture you could integrate it with the gateway to maintain, monitor and secure a public API for your services. However, Amazon’s priorities seem to be on the former two integration methods, because when it comes to the details the HTTP proxy integration is quite painful at the moment. In this post I will highlight some of the pitfalls and provide workarounds.
-
Exposing Spring Actuator endpoints via Jersey
Transparency makes the difference between a system that improves over time in production and one that stagnates on decays.[1]
Spring Boot comes with a number of production ready endpoints that expose information about your application’s configuration and health. This insight is vital for monitoring. By default Spring Actuator functionality is accessible via Spring MVC. This is not ideal when you use Jersey (JAX-RS) as your primary web service framework. In fact, if you use Spring Boot’s Jersey Starter sample project, the endpoints don’t even work out of the box (see Issue #2025). In this post, I’m going to demonstrate how to expose the Actuator endpoints via Jersey.
-
Catch-all error handling for web services with RxClient and Spring Boot
One of Spring Boot’s many sample projects demonstrates how to configure Spring with Jersey. We’re using the JAX-RS API a lot in projects for developing of RESTful web services. It was designed for this specific task from the beginning, rather than retrofitted like Spring MVC was. Jersey also offers a reactive client API which supports a reactive programming model.
In this post I’m going to show how to use the the reactive Jersey client based on RxJava together with Spring Boot. This post will also address how to handle and communicate server side errors back to the client. Specifically there are some issues I’ve discovered which are related to using the reactive Jersey client together with the embedded Tomcat container.
-
Inspect your http requests with httpinspector
Last week at our Hackathon I got my hands dirty with Swift. In particular I was using NSURLConnection to post JSON http requests to a 3rd party web service. The web service wasn’t documented. All I had were a few request examples that I knew were successful before. So I needed my web service client to produce similar http headers and a similar JSON body.
My first attempts caused the server to return a 500 Internal Server Error. Without any more details to go with, I suspected that maybe some header value or JSON value in my http request was formatted incorrectly. In order to confirm my theory, I needed a way to analyze the http request that my application was producing.
Unfortunately I wasn’t able to find a way to make NSURLConnection log out the complete request details including headers and payload. My next attempt was to use Charles, which is a Proxy that can be used to debug HTTP traffic. I was able to see all header values, but for some reason the JSON payload (raw body) was empty. After double and triple checking that I was correctly setting the HTTPBody of NSMutableURLRequest in my code and after changing numerous Charles settings, I still wasn’t able to see the actual payload of my request. Not wanting to lose any more time on this (we only had 2 days in total for our Hackathon projects), I decided to write a simple web server that would just print out all http request details.