By Vlad Ionescu, Java Developer, Cognizant Softvision

So far in this series, we discussed how we can define interfaces as a type for lambda expressions, how to actually construct the lambdas themselves, and dove further into functional interfaces and what functional interfaces Java 8 provides for us. In this final article, we cover method references and collections for each iteration, and give a brief introduction to streams.

Let’s get started with method references. View the example below.

In the above image, we’ve defined a static method called “printMessage” which prints out to the console the text “Hello.” In the “main” method, we created a thread and passed it as an argument to a lambda expression that executes our previously defined method. In the previous articles we revealed that, instead of a “Runnable,” we can pass in a lambda since “Runnable” is an interface with only one abstract method called “run.” The code we want to execute in the lambda expression is the method call for “printMessage.” Running the above code would print out “Hello” from a new thread.

Now, a method reference means that, if we have a lambda expression that takes no parameters and just calls a method as its body, then we can use an alternate way to achieve the same thing. See below.

In the example above, instead of the lambda expression, we used the class name, “MethodReference,” followed by two colon symbols and then the method we want to call. This would look like: MethodReference::printMessage

Now let’s look at some other examples. Consider the below class.

Remember this example from our previous articles? We defined a list of cars for which we want to print out all the cars in it. We’re doing that by calling the “perform” method which takes in the list of cars, the condition (which is always true in our case, because we want to print out all the cars), and the action we want to execute (in our case, printing the cars to the console). Running the above would print:

The lambda that we pass in to the “perform” method looks like this: car -> System.out.println(car). So, the lambda takes in one parameter and executes an action on it (the printing to the console). Similar to the previous case where we used a method reference for a lambda with no input parameters and just a method call, we can use a method reference here too. The difference here is we’re not invoking a static method, but the method “println” on the “System.out” object. If we have a look over the documentation we can see that “System.out” is an object of type “PrintStream.”

In addition, looking into the PrintStream class, we can see a “println” method defined there which takes in an “Object” as the input parameter.

Switching back to our code, the method reference would look like this:

The method reference call from the above is composed of the instance of the class we want to execute the method on, “System.out,” followed by two colons, followed by the method itself we want to execute, “println.” We can see that there are no input parameters passed to this syntax as they are when using lambdas. This is because the “perform” method takes in as the last parameter a “Consumer” of “Cars” which is a functional interface that defines a method that takes in an input parameter of type “Car” and returns nothing. Thus, when using the method reference, the compiler automatically deduces that the action passed in, the “System.out::println”, has to be executed over a “car” object.

Now let’s talk about looping through a list of objects in Java. Prior to Java 8, there were two ways of doing that. Let’s see an example below.

We will be using the same list of “car” objects as we did in our previous examples. The first method for looping through this list is using the “for in” loop.

In the above picture, we start with an index equal to zero and iterate through all the items from the list, one by one. For each of these elements, we will print them out to the console.

Another method we could use for looping is the “for each” loop. See below.

In the above picture, for each car in the “cars” list, we will also print it out to the console. This form is a shortened one compared to the first one, achieving the same result.

Java 8 introduced a new way of iterating through a collection of items, the “forEach” one. See below as an example.

Each “Iterable” contains now a “forEach” method which is used to iterate through the elements of a collection. The method receives as an input parameter a “consumer.” In the picture above, the consumer is a lambda that consists of an input parameter of type “car” — the current element being iterated from the list, and the action — printing out to the console the current “car” object.

The first two methods of looping through a list of elements are called external iteration and this third method is called internal iteration. With the external iteration, the user who writes the code has full control of the iteration, meaning: stating where it should start, where it should end, etc. All of this is done in a sequential order.

In the internal iteration, one specifies only the intent of the iteration and not how to actually do it. The runtime could choose to use several threads to compute this, one of them handling the first two elements of the list, the second thread handling the next five elements, for example, and so on. This way facilitates a parallel approach of iterating through a list of elements, thus leveraging the multi-core processors computers have nowadays.

The above lambda can also be replaced with a method reference as shown below.

Lastly, let’s talk about “streams.” The best way to explain this concept is through an example. Let’s take our well known “cars” example. Let’s say we have a list of “cars” for which we want some work done. For this, we employ three people — one for fixing the engine, one for changing the tires, and one for painting each car red. So what we can do is to talk to each person and say: here are the cars. First, go fix the engine. And, so, the employee will go and fix the engine for each of the cars. Then, we can talk with the second person and tell them to change the tires for each of the cars. And last, talk with the third employee and ask them to paint each car red. We could take this approach, but we made three iterations, one for each employee to go through the list of cars and do their one job. This doesn’t seem very efficient. Another way to think of this is to have some people in a specific place (each one performing its own unit of work) and all the cars lined up like in an assembly line. Then, each of the cars passes by each individual, whereby they perform their duty. When a car passes through all of the employees (aka, each unit of work) then the process of work on it is done. See the picture below where the squares represent the cars.

This is a good analogy of what streams are. They let you build this “assembly line” on a collection of elements. Then, you can call different operations, aka units of work, to perform different tasks on each element of the list (these are the employees who repair the car from the above example). Let’s switch to code and see how that looks.

In the above image we have the same list of “cars” objects on which we want to perform two operations: one for choosing only the cars that have the model starting with “X” and one for printing these cars to the console. We want the output of the first operation, filtering out the cars, to be stored in a list. The first approach we discussed would mean that first, we would iterate through the list of cars to take into consideration only the cars that start with “X” and then we would iterate again through this new returned list in order to print them out to the console. Again, this doesn’t seem very efficient. What we can do instead is to build that “assembly line.” Refer to the picture below.

In Java 8, each collection has an additional method called “stream()” which creates the “assembly line.” What follows after “stream()” are the operations that we want to perform on each element of the list. The first operation is the “filter” one which accepts a “Predicate.” We talked about predicates early in this series of articles, and established that this is a functional interface with a method that accepts one input parameter and returns a boolean. So, we will define a lambda expression that, in our example, takes in a “car” object and returns whether or not that car model starts with “X.” Then, the result of the first operation goes as the input for the second operation. The first operation returns a stream containing the filtered cars. Then, “forEach” of these cars, we will print them out to the console — the second operation.

We can think of the “stream” as a view of the collection on which we invoke it. The stream will always have a source, the backing collection itself. A “stream” is composed of three parts: the collection on which is executed, the set of operations we want to use to process the collection and a terminal operation. The terminal operation is the one that triggers the stream to be executed. In our example, the terminal operation we used is “forEach.” There are others, as well. If the terminal operation wasn’t invoked, then nothing would have happened with the collection, even though we called the “stream()” method and did several processings on it.

Let’s have a look at another example.

In the above picture, we used the same collection on which we invoked the “stream()” method, did the same filtering, but instead of printing to the console the cars that start with “X,” we added them to a new list using the “collect” method. This method is also a terminal operation.

In the example below, we use another terminal operation, called “count.” We count the elements that result after applying the filter on the stream.

In this article series, we saw how lambdas enable the use of functional programming in Java by passing in directly the behavior we want to execute instead of an object containing the behavior. Using lambdas transforms our code into a more readable and concise code, compared to the use of anonymous inner classes which look more like code spaghetti. The use of out-of-the-box functional interfaces that Java 8 brings to the table facilitates the declaration of lambda expressions without the need for the programmer to create one each time. Last but not least, lambdas play a huge role when dealing with streams, enabling us to use them as inputs for different kinds of processings like filtering, adding elements to a new list, and much more.

Article Sources

https://www.youtube.com/@Java.Brains

Series Sections

Part one — fundamentals

Part two — more on lambdas

Part three — lambdas and functional interfaces

Switching from Java 7 to Java 8: Part 4 was originally published in Cognizant Softvision Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Vlad Ionescu, Java Developer, Cognizant Softvision

With the release of Java 8 came lambdas, which give programmers a way to pass in a behavior in functional programming. In parts one and two of this series, we talked about how we can define interfaces as a type for lambda expressions and how to actually construct the lambdas themselves. We also covered an exercise where we implemented some functionality in Java 7 and then transformed it using Java 8.

Besides marking an interface with “@FunctionalInterface” annotation for declaring a lambda, Java 8 came with an out-of-the-box feature, where it exposes several functional interfaces already ready to use. For most of the cases, we do not have to declare our own interfaces just to use for a lambda. Certainly we can do that, as we covered this in our previous articles, but only if we need this for some complex scenario where the already defined interfaces won’t do the job.

In the previous article, we concluded with a picture displaying how short and clean the code is when written with Java 8, as shown below.

Leveraging existing functional interfaces, it turns out that we can “clean up” this code a little more and make it more Java 8 user-friendly.

For printing out cars based on a condition, we needed to define our own functional interface. See below.

We do not need to do this anymore. What does this interface do? It declares a method that takes in one argument and returns a boolean. Java 8 already comes in with an interface that does just that, the “Predicate” functional interface. Below you’ll find the definition for it from the documentation.

As we can see, this interface is marked with “@FunctionalInterface” annotation and contains only one abstract method (it also contains other default method, but this is not relevant for our case) called “test(T t)” that takes in one parameter and returns a boolean.

We can replace our implementation to use the “Predicate” interface instead of the “Condition” one. See below.

Notice that the rest of the code did not change. Since the “Predicate” interface uses the same abstract method called, “test()”, as we did before in our own interface, we can still use this one to filter based on the condition. The lambda expression remains the same also, since we’re coding to an identical interface.

The “Predicate” interface is part of the “util.function” package which contains a whole lot more of other functional interfaces as well. Below is a snippet of this package.

In the code from above, we are still printing out to the console directly from the method. Let’s change that and pass in this behavior as a lambda expression, rather than hard-coding it in the method. Maybe, later on, we would want to log the car in a file or save it in a Db. For that, we would need to create three separate methods to accomplish these scenarios. Instead, we can define the behavior and just execute it in this method. Then, we will let the caller of the method define each behavior he wants in particular for each case: write the car to the console, save it in a database, or write to a file. Let’s transform the code as in the image below.

In the above picture, we refactored the method’s name to “perform()”, since we don’t just print out to the console, but rather we execute whatever behavior is passed in to the method. Besides the other two already defined parameters, we also passed in an extra argument, the “Consumer.” According to the documentation, this functional interface defines one abstract method, called “accept(T t)”, which takes in one argument and returns nothing.

We parameterized the generic Consumer interface with “Car”, so the “accept(T t)” method will accept a “car” object. Then, the caller of this method will have to also pass in the behavior itself which, in our case, is to print out to the console. See the picture below.

In the first piece of code from above, we sort out the cars and then we “perform” on the “cars” list of objects, a behavior for printing them all out to the console (the condition we pass in is always true).

In the second piece of code, we “perform” a filter on the “car” list of objects to accept only the ones whose “model” start with “X”. Then, as a behavior, we print them out to the console.

Besides these two functional interfaces (“Predicate” and “Consumer”), we can mention some others which cover the most important use cases of defining lambda expressions in practice:

• “Supplier<T>” has the method T get() — functional interface used to define a lambda expression that just returns something and no input parameters are required.
• “Function<T, R>” has the method R apply(T) — functional interface used to define a lambda expression which requires one input parameter of type “T” and returns something of type “R.”
• “BiFunction<T, U, R>” has the method R apply(T t, U u) — functional interface used for defining a lambda where we need two input parameters of type “T”, respectively “U”, and returns something of type “R.”

Now let’s talk a little bit about exception handling when using lambdas. Let’s consider the following scenario: we have a list of numbers and a factor and we want to write a method that performs an operation between each number in the list and the factor. See below.

In the above example, the operation we chose to perform between each number of the list and the factor is “sum.” The output for each summing will be:

With the above design for modeling the “process” method, it doesn’t leave us with much choice, if we want to pick another operation, let’s say division. For that to work, we would need to change the method and accept a behavior as a parameter instead of hardcoding the behavior directly in the method. In our case, the behavior would be printing out to the console each number “operated” with the factor. So, the operation would take in two parameters and return nothing. We already have an interface defined for this in Java 8, called BiConsumer. See below.

In the above picture, we iterate through each number in the list and accept the behavior given by the caller. An example of the caller, using the “sum” operation, would be as shown below.

But we can also invoke the “process” method with a different operation, division, for example. See below.

Let’s use the latter one, and running the above code would print out:

But what if we were to change the “factor” variable from its value two to zero? Running the code with this new value will print out the following exception:

We tried to divide something by zero and we got an exception. In order to mitigate this, we need to handle the exception with a “try/catch” block, but the question is: where exactly do we put this? There are a couple of places where we can insert that block. The most obvious one is when we invoke the “accept” method of the “BiConsumer.” Since that is the place where the lambda expression gets executed, the intuitive way is to wrap the “accept” method into a “try/catch” block, as seen below.

Then, for each number we divide by zero with, we will catch the exception. The following displays the output after running the above code.

So this would work, but what happens if we change back the operation from division to sum? Then the “try/catch” block is useless in this case because the code will never throw a division by zero exception for this operation. Moreover, this exception will only be thrown in the case of the division and not any other operation, so it doesn’t quite make sense to wrap the “accept” method with a “try/catch” block just for this particular case. This seems like a poor design decision.

Another way to achieve the same thing would be to use the “try/catch” block at the caller level. The advantage of this method would be that we can choose to or not to use it depending on the operation in question. Thus, for the division operation we choose to use it, but for the sum operation, we’re not. The following shows how it would look in the case where the caller uses the division operation.

The “process” method will just “accept” the lambda expression and won’t handle anything related to exceptions.

This approach would work too but, the downside of it is, that the short lambda expression we’ve written in the beginning, now transformed into a code spaghetti.

Even though there isn’t quite a standard way to handle exceptions when using lambdas, there is a third method, a better way, which leverages the previous method. We still have to use a “try/catch” block, since this is the only way to handle exceptions in Java (we don’t want to throw them up in the calling chain), but we will create a separate method for that, in order not to bloat the original lambda with this structure too.

Let’s start small and define a method that takes in a lambda expression and returns a new different lambda expression. This will act basically like a wrapper or decorator over the original lambda. See below.

In the above picture we are returning a new “biConsumer.” We defined a new lambda that takes in two parameters, “a” and “b” and doesn’t return anything but instead, it uses the original “biConsumer” to accept as input parameters the input parameters we defined in the new lambda. Calling this method with the original lambda as the input parameter, where we’re printing out to the console the division between the list of numbers and the factor, will give us the same output as it did when we hadn’t used this method. Thus, the method acts just like a wrapper over the lambda, and not influencing anything for the moment. See below.

The output after calling the above will still be:

But what if we change back the “factor” variable to have the value equal to zero? Then we will have the same problem as before where the exception is not caught and the code run results in an “ArithmeticException” error.

Having this wrapper method defined, we can now include the “try/catch” block inside it and handle whatever exceptions we want, including this one. See below.

Basically, we’re returning in the same way the new lambda expression as before, but now we’re surrounding it with the exception handling mechanism. Running the above code, but with the “factor” variable changed back to zero, would print:

Even though this third method of handling lambda exceptions looks like the second approach in terms of applying the “try/catch” block, this one gives us much more flexibility and cleaner code from a design point of view.

Next, we will have a look over the “this” reference, and how it behaves, when talking about lambdas. We will make a comparison between the “this” reference in the anonymous classes and lambdas. Let’s start with the former.

Below we will define an interface that declares one method, called “process”, which takes in one parameter of type “int”, and doesn’t return anything.

Then, we will define a method, “doProcess”, that takes in a parameter of type “Process” and an “int” and invokes the “process” method on the interface.

In the “main” method, we will make an instance of the class where we defined the above “doProcess” method, and call the method with an anonymous implementation for the “Process” interface.

In the above implementation of the “process” method, we’re printing out the value of “i” and the “this” object reference. See the output below.

The “this” object reference from inside the “process” method points to the instance of the anonymous class defined inline. This is not something related to Java 8, and this behavior was there in the prior versions as well.

Now let’s change the implementation using an anonymous class with a one using lambdas:

The whole class looks like this:

We can see that trying to print out the “this” reference from inside a lambda results in a compile error saying that “article.ThisReference.this cannot be referenced from a static context”. This error is happening because the “this” reference from inside the lambda is not referring to the context inside the lambda (as it did before with the anonymous class where it referred to the actual instance of the anonymous class), but rather to the “this” reference of the object from the “ThisReference” class where the “main” method resides. Since it’s referring to that, we cannot use the ”this” reference from inside a static context, because static deals with classes and “this” deals with objects.

However, we can extract the call of the “doProcess” method inside a non-static method and try to reference the “this” from there. See below.

We’ve created an “execute” method from which we invoke the “doProcess” method. Inside the lambda, we are printing out to the console the “this” reference and notice that this line doesn’t show as an error anymore, since the “execute” method it’s an instance method, a non-static one, essentially. Running the above code would print out:

Let’s double check what we’ve previously said that the “this” reference from inside the lambda expression is the same with the instance’s class one. See below.

In the above picture, we’re printing out the value of “this” from the “execute” method and also from the lambda expression. Running the above would print out:

As we can see, the value for the “this” reference is the same in both cases.

In the next and final article, we cover more about concepts and structures when dealing with lambdas.

Switching from Java 7 to Java 8: Part 3 was originally published in Cognizant Softvision Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Vlad Ionescu, Java Developer, Cognizant Softvision

In the first article of this series, we scratched the surface on the topic of lambdas as they pertain to Java 8. In this article, we will continue to dive further into lambdas.

Lambdas vs. Anonymous Inner Classes

In the example above there are two ways of printing out “Hello World” to the console. One way is by creating a new class, “HelloWorldSalutation,” that implements the Salutation interface and provides the logic in that class. In the second way, we do not create a new class, but rather a lambda expression that is assigned to the same interface type, “Salutation.” It is almost like we’ve created an inline implementation of the “Salutation” interface using lambda.

In a manner of speaking we did just that. This can be done in Java without using lambda expressions, but rather with anonymous inner classes. In the example below, we defined an inline implementation for the “Salutation” interface.

Both the lambda expression and the anonymous inner class will print out “Hello World” to the console. With some stretching, we can affirm that the lambda expression is a sugar syntax for the inline implementation using an anonymous class. For the most part, you can think of these two ways to be identical, a different way of achieving the same stuff, but behind the scenes, they are not the same and do have subtle differences.

Since we have already defined previously a method that invokes the “perform()” method on an instance of the “Salutation” interface, and both the lambda expression and the anonymous inner class are of the same type, “Salutation,” we can use that method to print out to the console “Hello World.” See below.

Type Inference

Let’s use the following example to illustrate this concept.

In the above, we have defined a functional interface for a lambda that calculates the length of a String. The interface contains a method that takes in a String and returns an integer. Executing this code will print out nine to the console. In the previous article we discussed how the compiler can infer some information about the lambda expression based on the interface and its only method defined. As an example, in the definition of the above lambda expression, there is no need to explicitly use the keyword “return.” This information has been deducted from the method signature, “int getLength(String s).” It turns out that besides this information, it can also deduct the type of the arguments that are passed through the lambda expression. Therefore, there is no need to explicitly declare “String s” in the definition of the lambda expression.

The above will also work and the compiler will not complain about it. One last thing we can do to shorten the syntax further is to also remove the parentheses at the end. See below.

And this is the shortest form that a lambda expression can take. Removing the parentheses will only work if we have only one input parameter. Otherwise, the compiler will give an error.

So, we’ve defined a lambda expression that is in fact a function that takes in one String parameter and returns an integer. We know that based on the abstract method defined in the interface.

How does the compiler correctly resolve the lambda definition? It infers all the necessary information based on the method defined in the interface. Because of this, we can pass in the lambda expression as an input parameter to a method that prints out the execution of the lambda expression. See below.

Runnable Using Lambdas

There is a reason why lambda expressions have been built on top of an interface and not on something new, created specific for this purpose. The main reason is for backwards-compatibility. If, for example, we have a library or other code that accepts as an input parameter an interface which has only one abstract method defined, then we can not only pass a concrete implementation of that class, but also a lambda expression. This is a huge advantage to leverage existing code when using it with lambdas. One example of this kind of existing interface is “Runnable.”

Prior to Java 8, one way to create a thread was to implement the interface “Runnable.”

In the picture above, “MyRunnable” implements the “Runnable” interface and overrides the mandatory method “run().” Then, in the main method, we create a new “Thread” and pass in this “Runnable” as an argument to the thread. The last step is to start the thread.

The output would be:

Another way to work with “Runnable” before Java 8 is to use it as an anonymous inner class, instead of creating a new class in a separate file. See below an example of that.

In the above picture, we defined inline a new “Runnable” and implemented the “run()” method. The last step, the same as in the first case, is to start the tread. The output would be:

In Java 8 we can leverage lambdas to achieve the same functionality. The code for this becomes simpler and is just two lines. See below.

In the above example, in the first line of code, we instantiate a thread to which we pass in a lambda expression. Since the “Runnable” interface contains just one abstract method, “run(),” we can do that. The signature of the “run()” method is “public void run().” Thus, is a method that takes no input parameters and returns nothing. The lambda for this would be “() -> {my_code_here}.” Since we have just one line of code in our implementation of the lambda, namely printing out to the console the text “Printed inside a lambda”, we can remove the brackets and replace the “my_code_here” with the “System.out.println(…)” command. Thus, becoming:

The second line of code from the above picture just starts the thread, the same as in the previous two cases. The output would be:

Functional Interface

Throughout this series, we’ve talked about the functional interface being an interface that has only one abstract method. Let’s take, for example, our old “Salutation” class and see how it looked. See below.

Let’s take the “Main” class and define two lambda expressions, one for printing out to the console “Hi!” and the other one, “Hello!”

We can see that no errors are shown in the program, and running this would print out:

But what if we decide to add another method to the “Salutation” interface? Let’s call it “other()”.

We can see now that, in the main program, the lines defining the lambda expressions are marked with errors:

We know that we’ve created that specific interface with the whole purpose of defining lambda expressions. But there are no guarantees that another developer won’t come later on and add different methods for his needs. To prevent this scenario, there is a way to enforce the interface to not allow any other methods than one abstract method and basically mark it as a functional interface. The interface can be annotated with “@FunctionalInterface.”

Notice now that the error has been shifted from the lambda expressions definition to the actual interface that defines how the lambda should look. This shift comes very much in hand when we talk about third party libraries that are used by a client and lambda expressions are defined using one interface. If someone else from the development team came in and added another method, then all the clients that use that library would have their code broken. To prevent that, we mark the interface as a “Functional Interface” and the code won’t compile at the development side if someone adds other methods in there.

Let’s remove the extra method in the interface.

The “@FunctionalInterface” annotation is not a mandatory one for defining lambda expressions, but is a best practice to use it because of the reasons explained above.

In the next section of this article we will discuss a small exercise where we want to implement a couple of things first using Java 7 and then transform the code into Java 8 to achieve the same functionality.

For this exercise, let’s use a sample class called “Car” with getters, setters, a constructor, and an override of the “toString()” method.

In the “main” method let’s instantiate a list of cars using the following values.

Let’s define a method that prints out this list of cars to the console.

The first thing we want to do with this list is to sort it by the car’s brand name (using Java 7). What we need to do for this is to create a comparator in which we specify the sorting condition. We can do this inline, by using an anonymous class and override the “compare()” method, as shown below.

The “compare()” method takes in two arguments of type “Car” and returns an integer depicting if the brand name is greater, equal or less than, in a lexicographical order, the other brand name we compare with. After invoking this method, the output would be:

The second thing we want to do on this list is to print out all the cars that meet up a condition. For this, we can define a method that accepts a condition, and based on that condition, if it’s true or false, we print out the cars. Therefore, in order to model the condition itself, we can define an interface that takes one method. This method would return a boolean (we want it to return true or false every time) and will take in an argument of type “Car.” We want to create the condition based on the “Car” object. This would look something like this:

Then, the print method for all the cars using a condition would look like this:

The above method will print all the cars that meet the condition. Let’s have a look over an invocation call of this method below.

When we invoke the method, we need to create a condition using an anonymous inner class and implement the actual filter. In our case, we would like to take into consideration only the “Car” objects for which “model” property starts with “X.” Therefore, if the “model” starts with “X” then we will print them out. See below the result of this method call.

Now, let’s have a look at the same examples, but using Java 8 instead of Java 7. This implementation also will be based on the same “Car” object. Based on this, we will populate a list of cars with the same values as we did for the Java 7 example.

The first thing we did before was to sort the list based on the car’s brand. If in Java 7 we used an anonymous inner class to define an inline comparator based on the brand, now, in Java 8, we can replace that with a lambda expression. We can do that, because the “Comparator” interface defines only one abstract method, called “compare().” Below is the Java 8 definition of the “Comparator” interface as it is described in Oracle’s documentation.

In previous sections of this article, we discussed that, as a best practice, this class is marked also with “@FunctionalInterface” annotation. Since it’s a functional interface, we can define a lambda expression for the comparator like below:

Invoking the above method in the main class will result in the same output. See below.

Now let’s take a look at printing out only some specific cars from the list that meet up a condition. We went earlier through an example of how we can achieve that using Java 7. For Java 8 we will use a lambda expression for that, as we did for the previous example where we sorted out the list of cars based on the brand name.

The definition of the method stays the same as in Java 7. We defined a method that takes in a list of cars and a condition, and when the condition is met for that particular car, we print it out to the console. See below.

However, when we invoke this method, we can use a lambda expression for defining that condition, instead of using an anonymous inner class. See below.

Let’s remember that in the beginning of this exercise, using Java 7, we defined a method that prints out to the console all the cars.

But we also have a method that prints out conditionally. This seems like redundant code. We can replace the “printAllCars(List<Car> cars)” method with the conditional one to which we pass in, as a condition, the value of true — meaning that we want to display the cars all the time. The invocation of this method would look like this:

Notice the lambda expression, “p -> true,” one of the shortest and concise lambda expressions you can write. The condition will always evaluate to true, printing out all the cars.

As a result, the whole code looks more clean and short and easy to follow. One downside of this approach would be the learning curve for this lambdas might be a bit steep, until you get used to it. See below the whole code in Java 8 for this exercise.

In the next article we will dive in more into functional interfaces and what functional interfaces Java 8 provides for us out-of-the-box.

Article sources

[1] https://www.youtube.com/@Java.Brains

Switching from Java 7 to Java 8: Part 2 was originally published in Cognizant Softvision Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lambdas fundamentals

By Vlad Ionescu, Java Developer, Cognizant Softvision

In 1991, James Gosling of Sun Microsystems created Java, a programming language. Java allows one to write a program and run it on multiple operating systems. The first publicly available version of Java (Java 1.0) was released in 1995, but it was years later that Java became more widely known, with the release of Java 5.[1] This version is still used on some old legacy banking systems that are complex and therefore more challenging to switch to a newer system. The most commonly used Java versions are 6 and 7, and they brought many improvements compared to their older siblings. However, Java 8 was a turning point from all previous versions in paradigm-shifting and implementing various programming approaches already available in other programming languages.

Java 8 came with a lot of cool features like lambdas, functional interfaces, optionals, streams, default methods, and so on. In this first edition of a four-part article series, we will scratch the surface of the topic of lambdas.

Why lambdas in the first place?

Lambdas have several advantages, with the topmost being the following:

1. They enable the use of functional programming in a programming language that is object oriented (OOP) by default.

2. As a consequence, you can write more readable and concise code, thus avoiding the boiler plate, spaghetti code.

3. They enable the use of parallel processing, thus leveraging the multiple cores each computer has nowadays, making the code run faster.

What is the difference between functional programming and object oriented programming?

Anything that can be done using functional programming can also be done using object oriented ones. This begs the question, do we even need functional programming? Yes. Functional programming is not a means to replace object oriented programming. Functional programming can be thought of as a new paradigm of writing better and more understandable code. At the end of the day, whether it’s functional programming or OOP, the code is being translated into machine (assembly) code. Therefore, there are some scenarios when writing functional programming code results in a more clean and readable code than using object oriented programming.

What are lambdas?

You can think of lambdas as a way to pass in a behavior in functional programming.

How do you pass in a behavior using OOP (prior to Java 8)?

Everything in OOP is a class or an object. Code blocks are “associated” with classes or objects. You cannot have a piece of action, i.e. a function/method that is isolated. This is because OOP “thinks” in terms of nouns or things, rather than actions or verbs.

Let’s use the following example:

In the above picture we have a “Saluter” class with one “salute()” method. Then, in the main method, we create an instance of this class and invoke the method on it. This will print out “Hello World.” But, “the salute()” method does only one thing– it prints out “Hello World.” What if we wanted to do different things based on an input? We could have this method take an input parameter and, based on it, do a switch. For each switch case, for example, we would print something else. Even though this would work, it is not a very elegant solution and we will end up with spaghetti code inside the “salute()” method.

Another way of doing this, in Java 7, is to pass in a behavior. The behavior would be a specific implementation of an interface that has one method. In our case let’s call it “perform()”. Then, each implementation of this interface would perform its own specific action, for example, printing out “Hello World.” In the end, “the salute()” method of the “Saluter” class would just invoke the perform() method on the specific instance of the interface. Let’s see how all these pieces tie together.

The “salute(…)” method from the “Salutater” class now takes one input parameter of type Salutation. This is the interface we’ve previously talked about which abstracts in fact the behavior we pass in. See below the interface that contains one method called perform().

The “main(…)” method creates two salutation types, one of type “HelloWorldSalutation” and the other one of type “HiSalutation.” See below the implementations for these two types, along with the “perform()” method.

Then the “Saluter” object invokes the “salute()” method for each one of them.

How do we pass in a behavior using lambdas (Java 8)?

Now that we’ve taken a look at how to pass in behavior using Java 7, let’s consider if that method solved our problem. It did, but we didn’t quite pass in a behavior, but an object that has a behavior, on which we’ve executed the behavior. This resulted in extra code written for something simple we want to achieve. It would be nice if we could have a method that receives an action as a parameter and inside the method we just execute that action. Below is an example of what this would look like:

In Java 8 we can do that using lambdas. These are just functions that do not belong to a class, but exist in isolation. Moreover, these functions can be treated as values, meaning they can be assigned to a variable which can be used throughout the code. The following is a rough example of that.

In the above picture we try to assign the method perform(), that prints out “Hello world!”, to a variable called “blockOfCode.” This is possible in Java 8 using lambdas. Going on, we will analyze the above piece of code and see how we can write a lambda expression based on it.

First, we can remove the keyword “public”. Since the “public” keyword is used in a context of a class member and lambdas are just functions in isolation, we don’t need that keyword. Next let’s have a look at the name of the method. Its name is “perform.” Since, using this method, we assign it to another variable, we don’t need two names. The method itself will be held in the “blockOfCode” variable name. Using this name, the method can be referenced in other places in the code. Therefore, we can take out the “perform” name too. Let’s see what we have left so far:

We have a method that returns void and prints out “Hello world!” which is assigned to a variable called “blockOfCode.”

We can take this a little bit further. In Java 8 the compiler is smart enough to deduct the return type based on the actual code. Since it sees that the code only prints out to the console, it deducts that the return type is void. Thus, the return type can also be taken out. See the end result below:

These are the elements that you need to provide in order to write a lambda expression. We took the “perform()” method and transformed it into a lambda expression. We didn’t have to specify the “public” keyword, the method’s name, or even its return type. What remains are the open and closing parentheses for the input parameters and the actual block of code. We almost have the full correct syntax for writing a lambda expression except for one minor tweak. We need to add an “arrow” in order to separate the input parameters from the actual block of code. See how a lambda expression looks like in Java 8 below:

For the above example we can do one more tweak. If the block of code of the lambda expression contains only one line, then we can remove the curly braces. Then the lambda expression will look like this:

In our example, this is also a valid lambda expression and both of these ways of writing it are correct.

For the examples above, we’ve used the IntelliJ IDE. You may have noticed there are some red lines or some highlighted red words. This means that the syntax is not correct. This is true and has been done intentionally.

If you have been following along until now, you may also have noticed that we haven’t talked about the type that this variable should have. Since Java is a strongly typed language, we cannot have a variable without defining its type. This also applies to lambdas. We’ll get to that a little bit later in the article, but for now let’s assume it has a type and it’s not important at the moment. All we care about is the code on the right side of the equal sign. With that in mind, let’s have a look at some other examples of lambda expressions.

In the above we defined two more lambda expressions and assigned them to the other two variables. One of the lambdas prints out the same “Hello World!” while the other prints out “Hi!”. But what if we want our lambda expression to take in some input parameters? How would we accomplish that?

Since the opening and closing parentheses we talked about earlier are for input parameters, we can insert ours there.

In the above lambda expression we’ve defined an input parameter “a,” that will be taken into consideration into the lambda’s block of code and will return this value multiplied by 2. Notice the “return” keyword inside the block. This is exactly the same way as you would return from a method’s block of code.

Earlier in this article we discussed how Java is smart enough to deduct the return type. This also stands true in our case. If the lambda’s block of code has only one line, then the “return” keyword can be omitted along with the curly braces.

Note: It is forbidden to have the “return” keyword without the curly braces.

Let’s look at another example, a lambda expression that sums up two numbers:

The above lambda takes in as input parameters, “a” and “b” and returns the sum of those two.

Here’s another example where we want to safely divide two numbers:

Since the block of code of the lambda expression contains more than one line, we need to enclose it in curly braces.

What type do we use for lambda expressions?

Let’s get back to the lambda expression type and see how we can define it. Since we want to attach the lambda expression to a variable, we need to declare its type. Let’s get back to our working code where we passed in a salutation type, and in the end it printed out to the console “Hello World!”.

We want to define the lambda expression for printing out “Hello World!”, which we know how to do, and also assigning it a type. In general, there are a few steps we need to take in order to define the type of a lambda expression:

1. First thing we need to do is to create an interface. The name for it is not important.

2. The second thing we need to do is to create a method which has the same signature as the lambda expression we declared. In our case, the lambda expression prints out to the console a simple text, so, in terms of signature, it takes no parameters and returns void. Therefore, the method we create in the interface needs to also take no parameters and return void. As in the case of creating the interface, the name of the method is not important here as well.

See below the final form of the code. Notice that the red lines have disappeared from the lambda expression definition, meaning it is syntactically correct.

If we were to add a parameter to the lambda expression, say “int i,” this would not work since the type assigned doesn’t declare a method which takes one input parameter. See below the error we would receive:

Now let’s fix the other examples of lambdas expressions we’ve presented so far and assign them the right type. The “HelloWorldSalutationFunction” type and “HiSalutationFunction” type will adhere to the same functional interface we defined above, since they take no input parameters and print out a specific message to the console.

The “doubleNumberFunction” takes an integer as input parameter and returns its value multiplied by two. We will assume that the value returned is an integer, too. We need to define a specific functional interface for that.

The lambda expression will look like this:

The “addNumbersFunction” takes in two integers as input parameters and returns the sum of those. We will assume that the result is an integer, too. We also need to define a specific functional interface for this scenario since the method from the functional interfaces we already have don’t match the signature we need in this case.

The lambda expression will look like this:

The last example we’ve talked about is the “divideFunction.” Since the result of the division is a real number and not an integer, we need to define a different functional interface. The signature of the method will take in two integers and return a double.

The lambda expression will look like this:

Remember that the first thing we need to do when assigning a lambda expression to a type is to create an interface of that type. This step is, in fact, optional if we already have an interface that has a method with the same signature we need. In one of the previous examples, we had a lambda that printed out “Hello World” to the console and we’ve created an interface for it.

We can do that, but we can also reuse the existing “Salutation” interface which contains one method with the signature we need for printing out “Hello World” to the console.

The lambda expression will look like this:

If we were to add another method to the “Salutation” interface, then we would get an error when we use that type for the lambda expression. See below:

We will receive the following error:

Therefore, the interface needs to have only one abstract method in order to be able to assign it as a type for a lambda expression. Otherwise, it would not know which one of the methods it should use in order to correctly resolve the lambda expression.

Let’s look at the following piece of code:

We have a concrete implementation of the “Salutation” interface called “HelloWorldSalutation,” which we instantiate in the first line of code. The second line of code declares a lambda expression which assigns it to a variable of the same type, Salutation. How do we print out to the console “Hello World” in the first case? We need to call the perform method on the object instance. See below:

Since “HelloWorldSalutation” provides an actual implementation of the “perform()” method which prints out to the console, invoking “perform()” in this instance will leverage that implementation.

But what if we want to invoke the lambda expression from the second line of code to do the same thing? Since it is also an object of type Salutation, we can call the perform() method on this instance as well. See below:

Notice that there isn’t any syntax error displayed in this case. Since the interface we used for the lambda expression has one public method called perform(), we can call it. But in this scenario, we don’t have a “concrete” implementation of the “Salutation” interface as in the first case, but rather we defined a function, the lambda expression, which acts like the concrete implementation of the interface.

This is how we invoke a lambda expression to be executed — we call the method that it’s exposed in the interface on the instance variable which lambda expression is assigned to. Both lines of code from above will print out to the console “Hello World.”

Let’s go back to the previous examples we’ve talked about so far, and complete the code with invoking the lambda expressions.

The first example used the “Hello World” and “Hi” lambda expressions. They look like this:

These expressions use the following interface:

The code for invoking the following lambdas looks like this:

The output after invoking lambdas is below:

This is the full circle flow of defining a lambda expression, declaring its associate interface, and invoking the lambda.

In our second example, we looked at how we could double a number using a lambda expression.

The associated interface for it looked like this:

The code that invokes the lambda is pretty similar with the one from the first example, but now, since we return a new doubled value, we assign it to a variable. See below:

After invoking the above code, it will print out to the console the following:

In the third example, we defined a lambda that calculated the sum of two numbers.

For this we defined the following interface:

Below is the code for invoking this lambda with two arguments.

The above will print out 7 to the console.

In the last example we had a look over the division of two integers. The lambda expression looked like this:

The interface for defining the above lambda looks like this:

The invoking of the lambda expression dividing two numbers looks like the below:

The result for the above invocation is the following:

In this article we explained the basics of lambdas. We learned the anatomy of this concept introduced in Java 8 by detailing how to define a lambda and its associated interface and how to later invoke it.

In the next part in this series, we will dive further into this function and explain more about what happens behind the scenes when we define a lambda. We will also have a look into some of the out-of-the-box functional interfaces that help us when defining lambdas.

Article sources

[1] https://www.vogella.com/tutorials/JavaIntroduction/article.html

[2] https://medium.com/@kasunpdh/java-lambda-expressions-3195f677ed38

[3] https://www.vogella.com/tutorials/JavaIntroduction/article.html

Switching from Java 7 to Java 8 — Part One was originally published in Cognizant Softvision Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

An API, or Application Programming Interface, is a connection between two or more computers, respectively software applications. These connections have simple, well-defined rules that explain how computers or software applications communicate with each other. The use of APIs has been growing over the years, and as organizations move further to the cloud-native path, the use of APIs will continue to grow — along with potential security risks.

Today, APIs can face a lot of challenges when it comes to security. But before we dive into security issues, we must first understand what an API is and the role an API plays today. This white paper, API Security Challenges, covers the basics of APIs, including their evolution, how they work, and common protocols and architectures before discussing security challenges. We then present common API security vulnerabilities and types of attacks so that we can focus on making the attacker’s job more difficult.

Click here to download API Security Challenges.

API Security Challenges was originally published in Cognizant Softvision Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

When researching ways of writing cleaner and more robust code, there is a multitude of materials that debate the existence of this concept in an object-oriented language. This can be surprising since in practice we see “null” everywhere, yet these blogs, articles, and videos make it seem like it’s the enemy of beautiful, resilient code.

So, what are the reasons why “null” might be considered “bad?” What, if anything, can we do about it?

The quick conclusion

For the impatient among us, the quick conclusion is that completely eliminating “null” is pretty much impossible for a language that already supports it. In such cases, even avoiding “null” might be more effort than it’s worth, especially in a language where this concept already permeates everywhere, including its base libraries. However, reducing its usage could allow programmers to develop some good, worthwhile practices.

The problems

There are several reasons why “null” is said to be a “bad” concept:

1. Ambiguous at best

A “null” value tries to represent several concepts (“nothing,” “undefined,” “not valid,” etc.) under the same umbrella. The way to interpret such a value varies greatly, not just from person to person, but also depending on the situation or context in which it is being used.

While this doesn’t seem to be a huge problem at face value, the more insidious issue is that it hides intent from the caller. This forces the caller to look into the implementation details, debug, and check for the real meaning behind that value. If the caller fails to take action, then the only alternative is to assume the meaning and possibly miss the correct way to handle it.

For business-related classes, a value of “null” often doesn’t really make sense. It’s an ambiguous technical term related to implementation, while a business class should reflect an object in reality. For instance, if a method searches for an employee and doesn’t find anything, returning “null.” What does a “null” employee even mean? Of course, a caller might be confused when receiving such a value, forcing the focus to be switched from handling an employee business object to a technical “null” value.

2. Guard clauses

Once a method is capable of returning “null” in any of its branches, it can lead to a lot of bloat in the code. This is also a bit irresponsible because returning “null” passes the handling of an internally invalid or unexpected state from the method to its callers, forcing the callers to deal with details they should not even know about. Now all callers are forced to check for, handle, and possibly even propagate “null” to its own callers. And if a caller fails to do so, then the runtime–and the clients–will surely notice the crash caused by the missing check.

Fortunately, recent versions of the .NET framework compilers can help identify where a guard clause might be needed by statically checking for possible “null” usages.

3. A special case that is a bit too special

Although there are plenty of examples of special values, using “null” requires a lot more consideration and mental modeling when using it.

An empty string or the PI constant are special values, but the difference is that any method that you can call on a random string, you can also call on an empty string as well. Any method you can call on a number you can also call on the PI constant. “Null,” however, is quite the opposite; it tries to represent a lack of value while being assigned just like a normal value. For example, you can do anything with an employee object unless it’s “null,” “ToLower” can be used on any string unless it’s “null,” and it is highly likely you will only get this feedback at runtime when it can be too late to return to normal operations.

Also, there’s plenty of inconsistencies throughout frameworks and languages on how to handle operations that involve “null” values. The .NET framework has always been pretty consistent on that front fortunately.

Some proposed solutions

1. Optional types

Optional types have been suggested as an alternative to “null” by wrapping a value into an object that also exposes, for example, a Boolean indicating if a value is present or not. Although this does solve the problem of the polymorphic nature of “null,” since optional types are often provided as a templated class, in practice it does little to solve the aforementioned issues because:

a) Optional types just replace checks for “null” with checks on the Boolean property of the optional type

b) Using optional types suffers from the same issue of proliferation along the call chain as “null”

c) Just replacing a generic “null” with another generic optional type is often not enough. For example, when a search for a user yields no results one might want to return a generic anonymous user with part of the functionality of a normal user.

2. Throwing exceptions

Instead of propagating “null” or optional types we could throw exceptions in case a rule or result is not what we expected. At first glance this looks like a good approach, and for cases where the invalid value is truly unexpected an exception is a good practice. However, careful consideration must be taken into what really is an unexpected event.

Exceptions are often misused and overused as crude ways to change the control flow of a business operation. There are not that many errors that are completely unrecoverable and must result in a full stop of an operation. Remember that not all errors are exceptions.

For example, let’s say that we save some configuration for a user in a file and we have a method that reads the configuration from that file on user login. From the business’ point of view, does it make sense to prevent a user login because the configuration file could not be opened? Site owners would not want to prevent users from using their shop for that reason and would much rather use a default set of configurations.

Knowing the business domain and talking to business experts will convert a lot of those exceptions into alternative error handling procedures. Still, this seems to be a common and easy trap to fall into, and some languages have dropped exception handling altogether (for example, GO).

3. Avoiding “null” as much as possible

We’ve already covered that avoiding “null” completely is not possible, since the .NET framework itself and its base class libraries make no effort to specifically avoid “null.” That being said, what would it take to significantly reduce the usage of “null,” especially in the core business implementation, which is part of the software where changes occur more often? Well, it takes a lot of attention and communication combined with implementing some basic patterns to isolate the business core as much as possible. Some examples of steps that can be taken are:

a) Since we have no control over third party libraries, we could (and likely should), hide them behind something. The adapter pattern comes to mind and this is, in general, a good approach whether we try to avoid “null” or not.

Another good approach would be to implement an architectural pattern. For instance, the “Onion” architectural pattern is good at isolating business code from the rest of the system. Remember that database, UI, and file systems are all like external libraries that usually have little or nothing to do with the core business.

b) Dependency injection has seen a lot of adoption, in part encouraged by the framework itself as, for example, ASP.NET Core already comes with a built-in dependency injection container. Therefore, since an unregistered dependency just replaces the “null” reference exception with a different exception type, we can try to validate the registered dependencies. The built in dependency container from ASP.NET Core can validate its dependencies at startup, although with some limitations. One limitation of this approach is that dependencies directly injected in controllers are not validated because of the special way they are registered in the default ASP.NET dependency container.

c) Carefully watch for any call to the base class library for methods that might return null (for example, FirstOrDefault in a LINQ expression). Unfortunately, this is harder to do by hiding it behind an adapter since it’s such a common and basic functionality (it’s part of the base class library, after all).

Nix “null”

Unfortunately, for .NET avoiding “null” is impossible. But in all other cases, trying to avoid “null” as much as possible can significantly reduce code clutter and bring what actually matters to the forefront– without getting lost in lots of easily avoidable statements. It also encourages business code isolation from the rest of the system, while helping programmers adopt good patterns and practices. So while avoiding “null” is challenging, it’s worth it.

What’s all the fuss about “null”? was originally published in Cognizant Softvision Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Tudor Blaga, QC Engineer, Cognizant Softvision

As more organizations are moving towards a micro-service and service-oriented architecture, the need for effective API testing is becoming more and more critical.

Part one of this series covered API basics, REST API, endpoints, web services, and methods. In this second half, we will explore API testing approaches and testing types. We will also reveal some commonly used API testing tools that can help ensure software applications’ smooth functionalities.

How to approach API testing

All API tests should begin with a clearly defined scope of the program as well as a full understanding of how the API is supposed to work. Start with gathering the following information:

• Information about what endpoints are available for testing
• Information about what response codes are expected for successful requests
• Information about what response codes are expected for unsuccessful requests
• Information about what error messages are expected to appear in the body of an unsuccessful request
• Information about the defined input parameters

Once factors like the above are understood, testers can perform the test and compare the expected results to the actual results. Tests should include information on responses like:

• The value of the response/reply time
• Data quality, which is a measure of the condition of data based on factors such as accuracy, completeness and consistency
• Confirmation of authorization
• Error codes
• Status codes

You can find a complete list for API response status codes here.

Types of API testing

Functional testing ensures the API performs exactly as it is supposed to. This test analyzes specific functions within the codebase to guarantee that the API functions within its expected parameters and can handle errors when the results are outside the designated parameters.

Load testing
The point of load testing is to measure where the limit of system performance under high load lies. That’s why we measure response times, throughput, server conditions, etc., while increasing the number of calls.

Soak testing
Load tests that run over a long period of time can reveal system instabilities like API memory leaks. So when you have a weekend ahead, leave automated soak tests running. On Monday, it will show you whether any unwanted behavior has emerged.

Stress testing
The idea is to gradually increase the count of virtual users to find the point at which the API starts throwing errors, slows down, or stops responding.

Spike testing
Contrary to stress testing, here an API undergoes a sudden spike of users. Spike testing checks whether the API is able to stabilize and return to normal functioning after that.

Scalability testing
You want to be sure that your system performance scales according to the changing load. To do so, increase the number of incoming requests and monitor whether it causes a proportional increase in response time.

Peak testing
Similar to soak testing, here you subject your API to the heaviest load while reducing the time of the attack.

Validation testing
Validation testing includes a few simple questions that address the whole project. The first set of questions concerns the product: Was the correct product built? Is the designed API the correct product for the issue it attempts to resolve? Was there any major code bloat — production of code that is unnecessarily long, slow and wasteful — throughout development that would push the API in an unsustainable direction?

Penetration testing
Penetration testing builds upon security testing. In this test, the API is attacked by a person with limited knowledge of the API. This enables testers to analyze the attack vector from an outside perspective. The attacks used in penetration testing can be limited to specific elements of the API or they can target the API in its entirety.

Reliability testing
Reliability testing ensures the API can produce consistent results and the connection between platforms is constant.

Where do you need API testing?

API testing is needed when an application’s functionality is dependent on the integration of multiple APIs. It is needed to ensure that the APIs are working properly and returning the expected results. At points it is also needed:

• During the development process to identify and fix bugs and errors in an early state
• Before deployment to ensure that the APIs are ready for production and will function correctly in the live environment
• After deployment to monitor the APIs for any issues and ensure that they continue to function properly
• Whenever there are changes to services to ensure that no new issues have been introduced
• When integration with third-party APIs is developed to ensure that the integration is successful and that third-party APIs are working properly
• For performance testing, to identify bottlenecks and measure the scalability of the APIs

API testing must be an ongoing process throughout the development cycle and maintenance of the API.

Choosing the right tools

One of the most common struggles of API testing is choosing the right tool. There is no general proper tool for testing. The term “right tool” for API testing is not determined by a particular tool, but rather determined by some key considerations, such as:

• Basic API Requirements: Does it support the majority of the HTTP requests? Can settings and artifacts be imported from one project/test to another to save time?
• Complexity: Make sure the skillsets in your team are able to learn and use the software in the shortest time possible.
• CI/CD Integration: Check its list of integrations to see if the tool works with CI systems your team is using like Jenkins or Bitbucket, and also if it’s native to avoid extra time trying to configure everything.
• Interoperability: Can the tool be connected to communication platforms like Slack; project management systems like Jira; Git for version control or your team’s toolchain?
• Non-technical Friendly: Read the tools’ documentation to see if they support BDD conventions and are able to export easy-to-understand reports.

Recommended Resources

Here is a list of API testing tools that are the most commonly used:

Postman

Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs — faster. For more details visit the Postman website.

Jmeter

Jmeter is easy to use, with a rich interface, able to run on Mac and Windows and has integration with Swagger and RAML formats

Rest-assured

Initially created for performance testing, Rest-assured transformed to an easy to use functional testing tool. Cache and offline replay of test results. Automation works with CSV files of other types of files to create unique parameters values for the API tests at Speed.

Soap UI

A java domain specific language test tool that enables REST services in a simple manner. It is most commonly used to validate responses from requests. Soap UI supports all the REST requests (POST, GET, PUT, DELETE, OPTIONS, PATCH, and HEAD).

Karate

A headless functional testing tool dedicated to API testing, Karate allows users to test REST and SOAP APIs and Web Services with no hassles.

Talend API tester — Free edition

Talend API tester is an API testing tool that assists users in creating scenarios for API-based BDD tests simply without writing definition steps. Formerly known as Restlet, it interacts with REST or simple HTTP APIs through a visual and easy to use GUI. This extension is excellent to use while testing a platform without needing authorization keys in most of the executed calls.

Airborne

Airborne is an API automation testing framework with a Ruby-based RSpec-driven framework. Since Airborne is a programming framework, it has no user interface apart from the text file to create code. In addition, to use Airborne, testers need to remember a few critical methods in the toolset and some Ruby and RSpec fundamentals.

Insomnia

Insomnia is a free cross-platform desktop application that takes the pain out of interacting with and designing HTTP-based APIs. Insomnia combines an easy-to-use interface with advanced functionality like authentication helpers, code generation, and environment variables.

API Fortress

Testers and developers can create and automate functional tests since API Fortress is a continuous platform for API testing. It has an easy-to-use UI for any skill level and supports Test REST, SOAP, GraphQL, and microservices.

Advantages of API Testing

Let’s highlight a few of the major advantages that API testing brings:

API testing plays a crucial role in ensuring the functionality and reliability of APIs. This approach allows for faster and more efficient testing of the application as the API can be tested independently from the user interface.

API testing can also be used to test performance by simulating various loads and stress testing, making repetitive testing easier for changes and updates. It facilitates compatibility testing across different platforms and devices and helps ensure compliance with industry standards and regulations.

API testing is a cost-effective and efficient method, enabling early detection of bugs and errors and reducing the cost of fixing them later in the development process. It also enables testing of the integration between different systems to ensure they work together seamlessly, as well as the security of the code to protect against unauthorized access.

API Appreciation

APIs are an essential part of modern software development, helping easy integration and communication between different applications and systems. As the demand for interoperability and data exchange is continuously growing, APIs will continue to play a critical role in enabling innovation in businesses and applications development, thus making API testing an absolutely crucial process to ensure that the applications are working as expected.

While APIs may not wear capes, they are the true heroes of our connected world. So next time you place a food order through your favorite app or search for cats of the ‘gram’, take a moment to thank the little API that made it possible.

The Unsung Hero of our Connected World was originally published in Cognizant Softvision Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Tudor Blaga, QC Engineer, Cognizant Softvision

Application Programming Interfaces, or APIs, are an important and integral part of modern software development, helping different applications and technologies interact and share data between them.

This two-part article will cover API basics, benefits, testing approaches, tools, and best practices. The following, part one, explores what an API is and dives into the methods, web services, and how the software development process benefits from using APIs.

What is API?

API is the messenger that takes requests and tells a system what you want to do, and then returns the response back to you.

For an example, the most common analogy is to imagine that you are in a restaurant with a menu in front of you. The kitchen is the part of the system which will prepare your order. The crucial link in communicating your order to the kitchen is missing, and this is where the waiter (the API) steps in. The waiter acts as the messenger, taking your request (your order) and communicating it to the system (the kitchen) on what actions to take. The waiter then returns the response back to you (the food).

A technical definition for Application Programming Interface (API):

An API serves as a software interface that enables two applications to communicate with each other without any need for user involvement. It comprises multiple functions and procedures (code) that can be easily accessed and executed, facilitating communication and data exchange between two or more software programs.

An illustration of a functioning API can be seen through the example of booking.com. This platform gathers information from multiple hotel, apartment, and vendor sources. For instance, when you book a hotel room, you input details such as the number of days you need the room for, room options, breakfast offerings, etc. This, in turn, presents you with various room options and their availability. In this scenario, the application interacts with APIs from multiple vendors, providing access to their data.

What is API Testing?

API testing is a type of software testing that doesn’t use a Graphical User Interface (GUI) and cannot be done at a front-end level.

The API lies at the heart of an application, sandwiched between the data layer, the service layer (API), and the presentation layer (UI/GUI). As a middleware, it serves as the connecting link between these layers and enables communication between two software programs.

The purpose of API testing is to evaluate the Application Programming Interface and ensure that it delivers the expected functionality, performance, reliability, and security. This is achieved by sending requests to one or more API endpoints and comparing the response to the expected outcome.

What is REST API?

Imagine you are searching for videos of cats on YouTube. You type “cats” into the search field and upon hitting enter, you are presented with a list of videos about cats. This is how a REST API endpoint operates. You send a request for information, and in return, you receive a list of results from the service you are making the request to.

The anatomy of a Request is as follows:

• The endpoint
• The method
• The headers
• The body (data)

What is an Endpoint?

An API endpoint is a digital spot where the API can receive requests related to a particular resource hosted on its server. It comprises a uniform resource locator (URL) which provides the location of the resource on the server. An endpoint is a part of the API, while the API as a whole is a set of guidelines that enable multiple applications to share resources.

What is a method?

The method is the request type that you send to a server. The available methods are as follows:

GET:

This request is used to get a resource from a server. If you perform a `GET` request, the server looks for the data you requested and sends it back to you. In other words, a `GET` request performs a `READ` operation. This is the default request method.

Example: GET /store/inventory, which is an operation that returns inventory items from somewhere

POST:

This request is used to create a new resource on a server. If you perform a `POST` request, the server creates a new entry in the database and tells you whether the creation is successful. In other words, a `POST` request performs a `CREATE` operation.

Example: POST /store/order, which is an operation that places and order for something

PUT / PATCH:

These two requests are used to update a resource on a server. If you perform a `PUT` or `PATCH` request, the server updates an entry in the database and tells you whether the update is successful. In other words, a `PUT` or `PATCH` request performs an `UPDATE` operation.

Example: PUT /itemId, which is an operation that updates the information regarding a particular item by id

DELETE:

This request is used to delete a resource from a server. If you perform a `DELETE` request, the server deletes an entry in the database and tells you whether the deletion is successful. In other words, a `DELETE` request performs a `DELETE` operation.

Example: DELETE /store/order/{orderId}, which is an operation that deletes a purchase order by id.

These methods provide the meaning regarding the request that you are performing. Those operations are named CRUD operations. CRUD is an abbreviation for CREATE, READ, UPDATE, and DELETE.

Web Services vs. Web API

Web Services and Web API both serve the purpose of facilitating communication between the client and the server. The main distinction between them lies in the manner of communication. To communicate effectively, each of them requires a request body that can be processed in a specific language. Additionally, there are differences in terms of security, speed of communication with the server, and response time to the client.

Web Services:

• Web Services use XML for encoding and therefore offer higher security.
• In addition to SSL for data transmission, Web Services also provide WSS for enhanced security.
• Web Services are a subset of Web APIs, only offering three styles of use (SOAP, REST, and XML-RPC).
• Web Services require a network connection to function.
• Web Services allow for “One Code different applications,” meaning a single, generic code can be used across various applications.

Web API:

• The use of JSON (JavaScript Object Notation) in a Web API contributes to its speed advantage.
• Web API is faster than other technologies like XML due to JSON being a lighter weight data format.
• Web API encompasses the functionality of Web Services, including all styles such as JSON-RPC.
• The need for a network connection is not always required for Web API to function.
• The level of interoperability supported by a Web API can vary depending on the specific system or application.

Key takeaways

APIs are an essential part of modern software development, helping easy integration and communication between different applications and systems. REST APIs are the most popular architecture style for web APIs. Endpoints and methods are fundamental concepts in API design, allowing different software programs and applications to access and manipulate specific resources from the servers.

As demand for interoperability and data exchange is continuously growing, APIs will continue to play a critical role in enabling innovation in businesses and applications development, thus making API testing an absolutely crucial process to ensure that the applications are working as expected. We expand on this in part two of this article.

The Unsung Hero of our Connected World was originally published in Cognizant Softvision Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many people have the wrong opinion when it comes to the work of a QA. Most believe that a QA engineer runs after bugs all day, every day. But is bug hunting the only thing that a QA has to do? Let’s shed some light on what a manual Quality Assurance tester really does.

There are several other tasks a QA engineer performs each day. We also encounter obstacles that block the flow of the testing process, making our work even more interesting.

I. DOCUMENTATION (Or lack of it)

The first step to start the testing process is to study the available documentation. Mock-ups, PRDs, frameworks, UI//UX, you name it. All of these types of documents are useful in order to understand the product.

As we all know, documents may contain designs, specifications in regards to the expected behavior of the product in test, and the Acceptance Criteria that needs to be fulfilled before launching the product to the users. There is no doubt that a good testing process begins with good documentation.

But what happens if there is no written information about the product? What if most of the documentation is not ready/accessible? Let’s review the following cases and some best practices to handle them:

a. Lack of documentation: You just found out that a new app is being developed and you will be in charge of testing it. The first thing you do is ask a bunch of questions about the app. Unfortunately, your thrill is gone when you find out that there is no documentation to read, so you won’t get the answers you looked forward to.

What can you do? Ask the Development Engineering or Product Management team about the development progress of the app. You might be lucky enough to get pieces and bits of the app while the development is still ongoing. You’re able to gain a general idea about the product and can start creating basic QA documentation (such as Test Plans). This way you will already be prepared when more details become available and will only have to update the QA documents you previously started writing. This is an important step since involving the QA early in the process can have a significant impact on the project, but it’s often forgotten or undervalued. (Search for the “Early Testing Principle” to learn more about the importance of involving QA early in the process).

b. Outdated documentation: You consider yourself fortunate enough because you got your hands on some documentation. This is until you read it and realize that it is obsolete and the information contained doesn’t correlate with the little information you received when you started working on the project. This can mean only one of two things: either the most recent documentation is placed somewhere else or the existing documents were not updated with the latest decisions.

What can you do? Ask for updated documentation. If this is not possible, there are two paths you can take:

1. One way is to escalate this issue to upper management (either your team lead, coordinator, project manager, etc). The advantage, in this case, is that you will benefit from your manager’s guidance on any escalation points.
2. The other way is to escalate this by yourself and ask for a meeting with the Development Engineering and Product Management teams. During this meeting, you can ask questions in order to clarify which of the information should still be used. If major decisions about the product are a work in progress, ask for an ETA.

Keep in mind that approaching this case varies from one project to another. Thus, before assessing the right course of action, assess the specifics of your project and setup.

c. Restricted documents: The project you are now working on is either top secret or maybe somebody just forgot to give you access rights to the documents. Either way, you are blocked and cannot continue with your work.

What can you do? There is only one way to gain access to the documents you need, and that is by asking for them. First, you can ask the others involved in the project, such as your Team Lead or Project Manager. If they can’t help you, reach out to someone from the project who is in a timezone close to you and can provide you the permissions to read the documents. Depending on the project and your team’s communication channels, you can use instant chat apps (such as Slack) or emails to contact the individuals who can grant you access to the documentation.

II. UNREALISTIC SCHEDULE

Setting an unrealistic schedule happens more often than you think. There may be countless reasons why production rushes to launch the product to the users, from the engineering availability to financial risks or current events. Even though all the reasons are valid, having a tight deadline doesn’t help you much with the testing process.

What can you do? Since you will need to work on a tight schedule, you won’t be able to go through all the testing phases you would normally go through. Because of this, you will have to take full advantage of the available timeline. This means that prioritization and estimation are important and helpful actions to resort to in these special cases. With testing prioritization, you can plan the testing process by ranking the tasks from mandatory to nice to have. Although it’s a subjective action, proper estimation can help with predicting how much effort (time, money, etc.) is required in order to accomplish the testing tasks. Gather the key people working on the project and perform a risk assessment together. Make sure that you all reach the same outcome; everybody understands the consequences of a rushed launch and has a backup plan if the worst-case scenario happens after launching the product.

III. DEFECTIVE COMMUNICATION

Before launching the product to the users, there is a lot of work that has to be done by the teams involved in the project. Each team has a specific scope, but in the end, they all must join forces and work together so that the final product is successful.

However, there are times when people fail to communicate effectively. Many factors can lead to miscommunication, from cultural differences to lack of context to poor or underdeveloped soft skills, and so on.

What can you do? There are easy ways that can help you improve communication between you and your colleagues. Apply the following strategies:

1. Involve yourself as soon as possible in the process. Ask if there are any meetings where QA could participate, even if there is little to nothing to test at the moment. By attending the meetings, you will be up to date in regards to the decisions and changes that impact the product, so you will be able to also adjust the Testing Plan and keep track of the latest resolutions. Use these meetings to ask questions and note down every little aspect that can be useful for your work. Don’t be afraid to raise concerns if you have any. Involving yourself during the meetings creates connections with your colleagues and they will appreciate your interest and engagement.

2. Ask the right questions. Try to avoid questions that might receive short answers and ask open questions. Open questions usually require long answers. Long answers might provide you with enough information so that you don’t have to come back and ask for more details. Experienced testers can also use their intuition and request information on areas that they already know may raise difficulties, based on their background knowledge.

Asking the right questions can also help when the people that share and exchange information are located in different time zones. This is especially important because miscommunication, besides causing frustration, can also lead to delaying the work for an entire day.

3. Provide constant feedback. Feedback is a crucial step toward growth and development, so why not use it to improve communication between colleagues? Giving and receiving feedback opens communication between people, but can also backfire if those involved in the project don’t deliver the feedback properly. Make sure your feedback doesn’t come off as accusatory or focused on any one individual. Instead, you can provide value in your feedback by being specific, issue-focused, and respectful. You can also provide suggestions for improving the communication between the teams. Try being objective rather than subjective when providing feedback to your colleagues.

The scenarios above might be helpful if the client is willing to make an effort to improve communication with the team. Unfortunately, there are clients that offer little to no information. Below are a few ways you can handle this difficulty:

1. Propose a testing process if there isn’t one already. If there is one, maybe it’s worth looking through ways of simplifying it. Try reaching an agreement that works for all the parties involved in the project. Keep it simple and focus the process around mandatory tasks.

2. Ultimately, if the client is not receptive to any of your suggestions to improve communication, you can write down a list of risks that can affect the success of the project. Explain some common risky scenarios, such as:

• Being unaware of deadlines is a blocker when it comes to test planning
• Misunderstanding the product can lead to potential escaped bugs
• A poor quality product will impact its success on the market in a negative way
• A product that doesn’t perform as it should will affect the revenue, the number of users will drop, and so forth.

Being faced with the risks might trigger a positive reaction from the client. But if this becomes too much of a challenge for you, it might be best to escalate this issue to your superiors. If nothing works, there could be bigger issues in regard to these particular clients and it might not be your place to fix them.

Practice, Grow, and Expect the Unexpected

There are many challenges a QA has to face and overcome, and the aforementioned are just a few. This is, of course, in addition to the main task, which is signing off on a high-level, quality product.

Whether the scenarios described are familiar to you or if you’re a beginner in the testing area, it’s always a good idea to expect the unexpected. Sure, being observant and thinking outside the box are two must-have qualities for a good QA, as they are crucial in finding issues of all kinds. However, a professional QA should always be open-minded in order to evaluate how to best respond to unpredictable situations.

Besides growing on the technical side, QAs should also expand and practice their soft skills. When you are working with various, diverse teams, soft skills become critical. Studying and practicing to improve the way you connect and interact with your colleagues will help you and the teams involved in the project deliver quality products that make the overall business successful.

So Much More Than Bug Hunting: How to Overcome Common QA Challenges was originally published in Cognizant Softvision Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Ionut Chichisan, .Net Enterprise Software Engineer, Cognizant Softvision

CLR, the .Net Runtime. Or ‘time to run,’ quickly if possible.

In the modern era, people want to have quick and responsive software. They want to spend the least amount of time in front of a computer and do their jobs in the most autonomous way possible. Usually, 10 seconds exceeds the limit users expect to wait for an operation. At the same time, application misbehaviors must be quickly solved by support teams, ensuring quick recovery when incidents arise.

In a developer’s world, there are general principles that should be followed as much as possible– guidelines that can increase application performance, reduce the risk of incidents/errors, and allow quick resolutions in case of failure. The following is a checklist of principles and recommendations for developers.

Assume not null

This is one of the most common exceptions/assumptions of all time, resulting in “Object reference not set for an instance of an object” or in the .Net world, NullReferenceException.

An object’s lifetime is dictated by multiple systems in software: the flow interaction (code), the garbage collector, the platform invoke, etc.

“throw ex”

This one results in no stack trace > no log specifics. Later debugging scenarios and incidents will be harder to accomplish.

“Swallow” exceptions

A try/catch without any error handling/logging on the catch block will lose the ability to identify problems later. There would be no logs, no error propagation, nothing to lead to the actual error identification. Too many logs on the other hand will result in spam. Every flow should output just the right amount of information, in order to quickly identify any error along with the most important parameter values.

Thread exceptions

You cannot catch exceptions outside the thread it was running on. Instead, you can use try/catch in threads or the ContinueWith method and check for errors. The ContinueWith method comes in multiple styles regarding its TaskContinuationOptions flags parameter. One of the parameter values specifies ‘OnlyOnFaulted’, which ensures the continuation is only being executed if the parent thread terminates in an unhandled exception.

Loops

Loops are the simplest way of losing execution performance of the code, especially if the input enumeration length cannot be managed. What if the enumeration has 1 million records?

The solution would be to use multithreading with chunks, by splitting the list into smaller chunks that can run in parallel or by making use of maximum degree of parallelism.

There is a catch. Database operations usually are not thread-safe. Entity Framework and other ORMs do not allow the use of their database context in a multithreaded manner. To bypass this, guide the execution flow to collect all the data in a multithread manner, then commit/save the data once, after all threads have completed.

Another thing about the maximum degree of parallelism is that for optimal performance, the number of threads must be correlated with the number of CPU cores on the server.

In case of really large enumerations that result in losing precious time. regardless of whether or not you’re using multithreading, publisher/subscriber systems can be considered in order to be able to use multiple servers processing power. Also consider making the loop asynchronous to the user, meaning that a user launches the operation and is being notified later of the status, without directly waiting for the process to complete.

Local datetime

Never assume the application is going to be used locally, especially client/server ones.

Use UTC datetime centrally (server side, SQL Server, etc.) — beware the caveats of UTC as well — and convert it to local datetime when displayed to the user (client side). Then it would be easier for debugging and new SQL scripts to accommodate any date/time in your application.

Because datetime values could be in many places in an application, the code must be consistent about the time zone the dates are using.

When dealing with web APIs, the API response must output the UTC date (and then converted to the right timezone in JavaScript), while for server-side rendering scenarios (cshtml), the dates must be converted in JavaScript (client side) to the right time zone, after the rendering result is sent to the browser.

The best way would be to have specific user settings to be able specify the local time zone, with automatic selection based on browser specific APIs. This way the user may work on the default timezone (the browser detected one) or a specific one, if the user is traveling and is being accustomed to a specific timezone (other than the one reported by the browser).

With the user-specific time zone known, things might be easier in case of working with text/csv files where dates are not automatically converted upon opening. During generation of the file content, the exact time zone may be used.

Local number formats

Like local date formats, local number formats may be different from user to user.

A dot instead of a comma might ruin the data integrity for a whole year’s budget for the client company, with unforeseen consequences.

Keep server side numbers in an invariant culture (with dot as number separator), while on the client side convert everything to local number format. Ensure the process is reversed while pushing the data back to the server.

Just like time zones, local number formats should be persisted in storage on user settings, in order to be able to generate text/csv files containing numbers.

Note: Some countries prefer to install their servers in a different locale that the default one, so be aware that server-side code could be in a specific locale as well.

Blocking code/threads

Never use Task.Run()/Task.Factory.StartNew() with a Wait() with no timeout.

A CancellationTokenSource can also be used with a timeout defined. That way its CancellationToken will automatically be set to canceled after the time has run out. You can also pass a cancellation token to the Wait() method.

Notify users too late or not at all

According to this article about time perception in human-computer interaction, we could approximate how to interact with the user from a web page or form. Here are some results:

0–2 Seconds = No Indication Needed (generally instantaneous to the user)

2–5 Seconds = Busy Animation, Spinner or Spinning Animation

5–10 Seconds = Progress Indication Needed, Progress Bar or Visual Indication of Start & Finish (Note: A textual indication of the time remaining is generally recommended in these scenarios.)

10+ Seconds = Progress Indication & Cancel Button, User Should Have Ability to Cancel the Process (Note: A textual indication of the time remaining is strongly recommended in these scenarios.)

Parallel.ForEach loops with async/await

The parallel loop doesn’t wait for an async/await code completion; it creates orphaned threads instead. There are also a lot of pitfalls described in this article.

I/O

Assume source availability

Whenever you read from storage, network or any other input devices, it might not always be available. Things like checking for folder existence or bytes received from the network should always be part of initial checking mechanisms before reading actual bytes.

Path/Url length

Never assume a path will fit an operating system max allowed path length, especially if the path is dynamic. Windows usually supports paths up to 260 characters, while Linux up to 4096.

Also avoid using special characters in paths.

Read past the end of a stream

Always check the stream length when peeking portions of a stream.

Always reset the stream back to 0 when done interacting with it.

In case the development is being done in the web environment, and if the request content needs to be gathered, remember to reset the stream back to 0 after reading it. That’s because subsequent readings might expect the stream position to be set at the beginning.

Read stream contents into memory

Never read an entire stream into memory. The most edifying example is trying to copy a large file to other destinations. An out of memory error will be thrown as soon as the memory is not able to handle such a large file.

A solution is to buffer only parts of the source data and send it to the destination.

The tricky part is to implement it in a web environment, for example uploading large files. There are countless client-side libraries that can upload a file using chunking, but the idea is not to store the whole file in memory (server side), but to redirect those file parts (bytes) to the destination storage.

Different speeds, chained read/writes

When you have some raw processing of stream bytes gathered from an arbitrary source, plan to use buffers to accommodate the difference in the reading/processing speeds.

Ignore logs

There is a fine line between an informative log and a spamming one. Too few messages become hard to follow, while too many messages could easily become spam.

Group messages by a common identifier, “Correlation Id,” that should indicate messages coming from the same processing flow, for a specific user.

Give log messages enough information like date/time occurred, process id, user id, thread id, exception details (message and stack trace) to ensure less problematic fixing of issues later on. Include any major parameters that could save you from losing hours of code digging.

Make clear differences about log levels in order to control how many messages should be in the logs. Log more frequently occurring messages as debug level and enable log debug levels only when strictly necessary.

Make threads cancelable

Threads could pile up very quickly and if left unchecked, could decrease performance considerably.

Define timeouts whenever possible and cancel any operation that is lasting more than expected.

.Net has also a possibility to combine timeouts (cancellation tokens) and continue with a new token that will timeout as soon as one of the combined tokens times out.

Beware of timeout ordering: a timeout for a database operation cannot be set longer than the web request timeout the database call is being used in, otherwise the database timeout won’t be effective.

Have a centralized location to define timeouts for every aspect of your application.

Retry specific operations

Some operations (like database read/writes, API requests) have transient errors due to unavoidable factors (ex: network failures). Always plan to retry these operations, before marking the operation as failed.

The default retry strategies could be linear or using exponential backoff. The idea is to retry at the time the operation will most probable succeed.

You can also customize the retry interval by providing specific checks, in order to determine the retry is still feasible for success.

In .Net there is a comprehensive library that can handle retry operations called Polly. It also provides other resiliencies like:

• Circuit breaker — ability to stop an operation if it can’t be handled by the system anymore; useful in preventing DDoS attacks as well as allowing the system to cool off
• Timeout — provide timeout where the existing code does not permit it
• Bulkhead Isolation — independent resiliency of different application elements
• Rate-limiting — slows down an operation so the system could cope
• Fallback — alternatives to the main flow in case it fails

Database queries

Retrieving data from a database is one of the most underestimated operations in an application when it comes to performance. Because it became fairly easy to work with databases, the questions about query performance, number of database round-trips as well as database indexes are often ignored.

When working with millions of records in different tables, make sure proper database design has been considered from the beginning (indexes, table partitioning, normalization/denormalization of data), even proper database server.

Redesigning a database from scratch after the application has gone live is a procedure that almost no one wants to happen.

Data maintenance is another aspect that is worth mentioning. As time goes on and the data is accumulating, different indexing strategies must be considered. Azure provides this as automated tuning, a service that does index management automatically based on query history.

Last but not least: Pyramidal thinking

Think of the project as a pyramid. The very base of the pyramid constitutes the environment, hardware and software the application is going to run on.

It could be the most genius application ever, but if the environment won’t support it, all bets are off.

You must ensure the optimal processing power: CPU, memory, network bandwidth, and disk speed are just some of the parameters you should ask about.

Then comes the database. Because the database usually constitutes the “Single Point Of Truth (SPOT)” when it comes to data, you must ensure the server can handle enough concurrent connections to satisfy the application needs.

Usually, database calls are expensive in terms of performance. To overcome that, you must introduce at least some level of caching to keep the data into memory instead of reading it from the database. However, in order to ensure you have the most recent data when working with cache, you should proceed with at least one of the following:

• Cache static tables data, that won’t get changed at all or at least not very often
• Have ORMs implement multiple levels of caching. This ensures caches are invalidated as soon as write operations are performed against the database.

Every piece of software out there was designed to perform a specific operation. People tire of waiting quickly, and the slow software application gets scrapped. With a few precautions, serious software incidents and data loss can be easily avoided.

References:

https://learn.microsoft.com/en-us/windows/win32/win7appqual/preventing-hangs-in-windows-applications

https://www.zdnet.com/article/the-escape-button-a-key-to-the-psychology-of-device-design/

https://blog.prototypr.io/guidelines-for-time-indication-and-progress-bars-in-user-interaction-design-4d5038084c84

https://learn.microsoft.com/en-us/dotnet/standard/parallel-programming/potential-pitfalls-in-data-and-task-parallelism

https://github.com/App-vNext/Polly

https://dotnettutorials.net/lesson/maximum-degree-of-parallelism-in-csharp/

https://learn.microsoft.com/en-us/azure/azure-sql/database/automatic-tuning-overview?view=azuresql

“Todo” or Not “Todo” — It’s All About Time was originally published in Cognizant Softvision Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.