DEV Community: Enrique Riesgo

Back to Java

Enrique Riesgo — Wed, 03 Nov 2021 08:50:54 +0000

I stopped learning and programming Java and JEE 12 years ago. Since then, too many things had happened in the field and today I am starting a collection of posts trying to refresh my knowledge about the technology that was revolutionary in the 90's and mainstream in the 00's.

So today, I will start with the basics.

What is the current version of Java

According to dev.java latest version of Java is 17. Wow! I was once certified in JSE 1.4 👴🏻 There is a good collection of articles there about how to learn Java in that web page, that covers from the basics to the JVM. If I finally want to fully refresh my Java dev skills probably I would start there.

However, I was more interested in understanding the history and evolution of Java since version 1.4 to nowadays to catch up fast on the features that were added and how to leverage them. So the answer is in the Wikipedia's article about version history. If you are planning to recycle yourself, it is worth to spend some time to see the evolution and features that were added in every version. And probably you will need a bit more time to understand the impact of every feature.

I found the following as the most relevant features introduced during these years:

J2SE 5.0: introduction of generics and metadata (aka annotations)
Java SE 6: Support for pluggable annotations
Java SE 7: JVM support for dynamic languages
Java SE 8: Language-level support for lambda expressions and default methods, Project Nashorn (which I know that is now depretated)
Java SE 9: Modularization of the JDK under Project Jigsaw

In my light reading exercise I did not find any deep transformation in the language after Java SE 10, but I may be completely wrong.

BTW, Oracle is still the owner of the Java trademark.

What about Java Enterprise Edition

This will be covered in a future blog entry, but let's anticipate a few spoilers:

Java Platform, Enterprise Edition (Java EE) was maintained by Oracle until version 8
On September 12, 2017, Oracle Corporation announced that it would submit Java EE to the Eclipse Foundation. Oracle owns the trademark for the name "Java" and renamed the Java EE platform to Jakarta EE. Latest version of Jakarta EE is 9.1 (May 25 2021), with JDK 11 support
In parallel, Microprofile project was created as an open forum to optimize Enterprise Java for a microservices architecture by innovating across multiple implementations and collaborating on common areas of interest with a goal of standardization.

What do you think? Any important topic I am missing? I appreciate your feedback

Performance vs unit tests: An AWS SDK for JavaScript dilemma

Enrique Riesgo — Wed, 21 Oct 2020 13:07:44 +0000

When using AWS SDK for JavaScript service objects we are typically facing two contradictory recommendations.

In one hand, as recommended by AWS Lambda Developer Guide, we want to create service objects during initialization of the lambda, so they stay in memory and we can reuse them in every invocation, and we then avoid the associated and hidden overhead of creating new objects for every request/response. Quoting original text:

When the handler finishes processing the first event, the runtime sends it another. The function's class stays in memory, so clients and variables that are declared outside of the handler method in initialization code can be reused. To save processing time on subsequent events, create reusable resources like AWS SDK clients during initialization. Once initialized, each instance of your function can process thousands of requests.

On the other hand, if you are unit testing your services, and using aws-sdk-mock for doing so, we have probably noticed that you have to initialize the AWS service you are mocking inside the function being tested. Otherwise, that service is not mocked. Official documentation is very clear on that:

NB: The AWS Service needs to be initialized inside the function being tested in order for the SDK method to be mocked
e.g for an AWS Lambda function example 1 will cause an error region not defined in config whereas in example 2 the sdk will be successfully mocked.

Example 1:
var AWS      = require('aws-sdk');
var sns      = AWS.SNS();
var dynamoDb = AWS.DynamoDB();

exports.handler = function(event, context) {
 // do something with the services e.g. sns.publish
}
Example 2:
var AWS = require('aws-sdk');

exports.handler = function(event, context) {
 var sns      = AWS.SNS();
 var dynamoDb = AWS.DynamoDB();
 // do something with the services e.g. sns.publish
}

Any caveout?

In order to cope with this two somehow incompatible requirements I found a valid pattern that seems to accommodate both requirements: the creation of a Singleton object that conditionally creates new clients when you are (unit) testing your code and you need those clients to be created in every test, BUT creates and reuses the client in other cases, as AWS recommends for general use in Lambda functions.

const enableLoggingDebug = Boolean(process.env.EnableLoggingDebug == "true");
const enableAwsMocking = Boolean(process.env.EnableAwsMocking == "true");

const REGION = process.env.REGION;

const AWS = require("aws-sdk");

let lambdaClient;
let dynamoDBdocumentClient;

exports.SmartLambda = () =>
  enableAwsMocking
    ? new AWS.Lambda()
    : typeof lambdaClient == typeof undefined
    ? (lambdaClient = new AWS.Lambda())
    : lambdaClient;

exports.SmartDocumentClient = () =>
  enableAwsMocking
    ? new AWS.DynamoDB.DocumentClient({ region: REGION })
    : typeof dynamoDBdocumentClient == typeof undefined
    ? (dynamoDBdocumentClient = new AWS.DynamoDB.DocumentClient({
        region: REGION,
      }))
    : dynamoDBdocumentClient;

AWS.config.logger = enableLoggingDebug ? console : AWS.config.logger;

So, with this sample Singleton object, every time you have to invoke a Lambda function or get a document from DynamoDB you just need to use SmartLambda or SmartDocumentClient and do the expected function call.

As said, instead of creating new objects to ensure your unit tests work, as we can see in the next piece of code:

const response = await new AWS.Lambda().invoke(params).promise();

You can use this singleton, so your code will look clean, will be efficient and your Jest unit tests will perfectly work:

const { SmartLambda } = require("./../../../utils/aws-clients");

// ...

const response = await SmartLambda().invoke(params).promise();

One final take away

Did you know that you can enable logging on SDK and see API calls you make with the SDK for JavaScript? Our singleton object above is conditionally activating this logging functionality based on a environment variable and sending it to console:

AWS.config.logger = enableLoggingDebug ? console : AWS.config.logger;

So, for example when a Lambda function is invoked you can see response code, elapsed time and other information about the request and response.

[AWS lambda 200 3.352s 0 retries] invoke({
  FunctionName: 'arn:aws:lambda:us-east-1:123456789012:function:test-API',
  Payload: '***SensitiveInformation***',
  InvocationType: 'RequestResponse'
})

You can see more information about this in the AWS SDK for JavaScript Developer Guide

What JavaScript features can we use with AWS lambdas

Enrique Riesgo — Wed, 30 Sep 2020 13:37:33 +0000

Most of you know that latest version of ECMAScript is 2020, which brought us many very interesting features.

One of the my favourite is optional chaining, a feature that saves us a lot of effort when dealing with multiple nested objects that can be nullish. As per the spec proposal, “an optional chain is a chain of one or more property accesses and function calls, the first of which begins with the token ?.”.

This is, instead of a long and conditional statement like

let result;
if (something && something.record && something.record.field) {
  result = something.record.field;
} else {
  result = "";
}

You have a more elegant

const simpleResult = something?.record?.field || "";

So... ready to start refactoring your old-fashined and chatty AWS lambda code with optional chaining? Stop! 🛑 Have you considered that it is a quite new feature that it may not be supported yet by the lambda AWS running engine?

The question is, how can I know what are the JavaScript features that I can use while developing AWS Lambdas?

The answer is simple and it takes you just a couple of clicks. Let me show you how:

Check what is the NodeJS version you lambdas is running on. You can see that from the AWS console, or in the AWS documentation.
Look at the greate node.green table where you can see the features that you are looking for and its compatibility with your version of NodeJS.

Back to my "optional chain" case, I have seen that my lambdas are running on node 12, and looking at the compatibility table for that feature I have saddly realized that it is not supported 😢. I will have to wait until AWS adds node 14 runtime.

Meanwhile we can keep learning and figuring out how to improve our code.

I hope this helps!

Happy learning and experimentation!

dotenv and relative paths

Enrique Riesgo — Fri, 25 Sep 2020 17:08:30 +0000

Most of you are using dotenv, the famous "zero-dependency module that loads environment variables from a .env file into process.env".

Although I usually work in serverless environments like the combo node.js/AWS Lambda where dotenv is not required, we use it for running local Express wrappers to the node.js lambdas and to control the environment while doing unit tests.

Unless you have a clear and well know pattern for using it, you can fall into the trap of thinking that dotenv works like the built-in require function and accepts relative paths. Proximity with with require statements doesn't help. Something like:

const { myfunction } = require("../mymodule.js");
require("dotenv").config({ path: `../.env.test` });

But, this will not work.

You know why? Dotenv does only accept absolute paths when it is configured. The official docummentation is not very clear on that and you can spend a few hours trying to figure out why your environment variables are not loaded in our unit tests.

So my recommendation is to ellaborate your own working dotenv piece of code, save it safe, and reuse it every time you need to set the environment variables of your node.js apps.

This is an example of the approach I follow.

const { myfunction } = require("../mymodule.js");
require("dotenv").config({ path: __dirname + `/../.env.test` });

Notice we use __dirname function to get the path of the current module and then we append the relative path to the .env config file.

I hope this helps you and never get stuck with this trap.

Happy coding!

What do you do with our printed technical books when they get outdated?

Enrique Riesgo — Tue, 22 Sep 2020 12:38:54 +0000

Hi, this is my very fist post here, and I wanted to try something different.

Probably we can see multiple categories like classic software engineering books that never get (very) outdated (e.g. DDD, XP, GOF, POSA), but I was also thinking in those hard-cover copies of Oracle 8 or Java SE 1.2 technical books.

These categories need different approach? ♼ Paper Recycling Bin? Any stories to share?