Architect Tips

  I don't know if I am not able to perform search on Internet (I doubt it) but every examples of websocket chat created with Lambda was all created using Node.js. And I can cheat on Java, that's my love. So I decided to transform the usual chat into a Java project, by of course performing some changes in order to be easy to check if it works.  THE IDEA The idea behind the project is simple: a simple WebSocket API exposed with api gateway with 4 different route and a unique Lambda who is in charge to serve each request. The change I made is about the name registration: instead of just propagate the message to other connected users, I want to have the way to register a name for chat users so every time a message is published, the receiver can see who sent the message. As I said in other project, this is to be intended for testing purpose, so there are really infinite ways to do have the same behavior maybe in a better way. THE PROJECT The entire project is based on cloud formati...

  Working in cloud and in general in a distributed system, means that code is executed among different services which have different loggers and maybe different location where this log are placed. To understand the code flow (because if you have a problem, maybe you can't read all the code), you need an instrument to build who is calling what and when in order to check which is the bottleneck or where your error is located. If you have a legacy application, the way is to create such a trace information spread all over different calls (which means using a Logger Context for internal and header for external call) and then use a log collector to visualize all the information, grouped by this trace. If you are working with a Spring application there are some libraries that do it for you: you add them in maven dependencies and collect logs with specific tools (kibana or similar) and then you have the flow. You can also use some agent (like datadog agent) that collect information directl...

  Logging what is happening in your application, should be always the first thing you need to setup: to understanding what is going wrong, the best way to do it is to investigate log files. In cloud environment it is more required because code is not working on your local machine, so using the CloudWatch (at first sight) should be the tool you will use. LAMBDA ENVIRONMENT Lambda comes with his own log, which is powerful of course but has is limitation. It is embedded in the context you receive in your handler and you can use it of course public APIGatewayProxyResponseEvent handleRequest ( final APIGatewayProxyRequestEvent input , final Context context) { LambdaLogger logger = context.getLogger() ; Map<String , String> headers = new HashMap<>() ; headers.put( "Content-Type" , "application/json" ) ; headers.put( "X-Custom-Header" , "application/json" ) ; APIGatewayPro...

Upgrading JVM is always a "huge pain" and the more big your application is, the more "complicated" will be the upgrade. Convincing management why the update is important, is even more difficult because they tend to suppose it is just "a cost" and probably not really required. But they are wrong because the enhancement among different jvm is incredible, especially if we talk about memory. AN EXAMPLE Let's suppose we have a very simple Lambda function that just implements a partially CRUD operations for a DynamoDB table named query. The function is exposed through API gateway and the driver for the behavior is the http method. The code is pretty simple: based on the method, a service (findService) is called to retrieve all elements (for GET) or to insert (for PUT) The "retrieve all" is implemented with a full scan operation, which is not optimal of course but as you know this is intended to be for testing purpose. public class App implements Re...