DEV Community: Mateusz Gajda

Serverless application development in 5 minutes with Node.js

Mateusz Gajda — Mon, 27 Apr 2020 08:11:28 +0000

Serverless is one of those trends that excite both developers and business people, due to all the potential benefits it can provide. Want to quickly get up to speed with it? Let’s create a serverless application in a couple of minutes with Node.js! It’s a great opportunity to find out more about the strengths and weaknesses of serverless application development.

What if I told you that you can create your REST API, deploy it on a server, and connect it to the database in just 5 minutes? What’s more, it won’t drain your wallet. Sounds good? Let’s talk today about serverless.

Let’s establish an important fact. Unfortunately, serverless doesn’t mean that our code will magically run without a server 😢. What we get is a solution which allows us to deploy the code without having to manage the whole server infrastructure. Everything runs automatically. All we have to do is bring our code to one of the popular platforms and all of our worries about buying servers, monitoring, or scaling can be forgotten.

But it’s not all roses. An important aspect to consider is vendor lock-in. When our configuration is big, it can be hard to migrate from one vendor to another. Each one of them has specific services and different ways to configure them. Once we decide on one of them, it can be very difficult to change it.

With that said, let’s take a closer look on the bright side of serverless 😉

Benefits of serverless app development

I noticed that most developers don’t find it very hard to create custom software or design its architecture. This is our daily bread and we feel comfortable about it. The problem occurs when we need to deploy our application somewhere. I think that people are a little bit afraid of the server layer. Managing and deploying applications correctly might give you a headache.

What if we didn’t have to do it? That is one of the reasons why we should try this new fancy solution called serverless. It allows us to focus solely on writing an app, without having to care about infrastructure.

But what about the cost? Unlike with traditional servers, we only pay for the resources used or for the functions called out. But what does it mean?

Let’s say we have an application, which is used mostly during standard working hours (9-17). For the rest of the day, the application “sleeps”. With the traditional approach, we will pay for the whole day all the same, even if no one has used the application for almost 16 hours. In a case like this, we can save up a lot with serverless. Why? Because when our service is deployed as a function, we pay only for each execution or for the execution time. The cost is tied to actual usage.

What else can functions give us? For once, they are extremely scalable. Depending on the traffic, the functions scale up to a level that will allow for handling of all the requests. They are also highly available, so we don’t have to worry about service availability.

That’s the theory – what about practice? Let’s make a quick serverless for beginners project to really get you started!

Serverless application development frameworks

We’re going to use the Serverless Framework, one of the most popular tools for building serverless applications. It is an open source solution and you can find it on GitHub. This framework supports a lot of providers such as AWS, GCP, Azure, OpenWhisk and many others. It also supports different languages such as Node.js, C#, Java, Go, Python etc. With a large community around it as well as impressive popularity, it’s definitely worth a try.

Let’s create our REST API!

Below you will find a rest of an article! Have fun! :)
https://tsh.io/blog/serverless-application-development/

Do you know GRASP? Part 3 - Cohesion and Coupling

Mateusz Gajda — Wed, 08 Jan 2020 09:05:07 +0000

Cohesion and Coupling are very popular terms in Software Engineering. Also, GRASP tells something about it. Let's take a look at what these patterns tell us about these weirds words.

Coupling

What everybody knows about coupling is that good practice is to keep coupling low. It is because coupling means how one element relates to another. As coupling grows, the dependence of different modules on each other increases. So we can say that if the coupling is low, changing something in one class shouldn't affect another.
We can also notice another benefit of low coupling. If classes are independent or have a low number of dependencies, they are easy to reuse. They are also easy to test because we have fewer dependencies to manage :)

High coupling makes it very difficult to maintain or introduce any features into our codebase. From the client perspective, it is also very irritating, because the client needs to wait much more time for new features. So he need also to pay more for our work.

As we divided coupling for low and high, let's consider how to distinguish them? High coupling is when one class use or depends on the implementation details of another class. For example, we use some properties from another class directly. So we depend on implementation detail. In case when this property will be changed, we will be forced to change first class. Low coupling is when we depend on abstraction and encapsulation. It's when the second class exposes some public methods, which allows us to access important data. It's because when implementation details have been changed, our public contract will be the same. So we don't care what is going on inside the method, we just use it.

There are different types of couplings, below is a list ordered from least accepted to the most accepted:

Content Coupling - when one module talks directly with another module. It means that module X use implementation details from module Y.
Common Coupling - when two separated module depends on some shared state. It could be some variable for example. In this case, they don't talk directly to each other, but by some other value.
External Coupling - if two modules want to talk to each other, they use some external interface. When the interface has been changed, it can no longer communicate anymore.
Control Coupling - one module tells another module how to do his job. It can be done by passing a flag, which will manipulate another module by turning off/on some kind of business logic.
Stamp Coupling - we pass some data structure from one module to another, and this module use only part of the passed data to do their job. We depend on the whole data structure even if we need only some data from it.
Data Coupling - we pass from one module to another only data which are necessary by this module to do their job.

So for us, as a developer, important is to keep coupling low. Maybe not as low as possible, because sometimes it is useless, and increase the level of complexity, so we should be pragmatic.

Cohesion

When we talk about cohesion, we mean how focused the class is on their task. If the class has high cohesion we see that in the class are only methods related to the intention of the class. Thanks to that, when we have high cohesion, the modularity of our system is increasing. So if we keep things related to each other in one class or module, the bindings between other classes will be smaller. What will cause the changes will concern some small areas and not half of the system. If the class has low cohesion, we can notice inside the class some methods not related to it.

Like the coupling, cohesion has also some types. Below is a list ordered from least acceptable to the most:

Coincidental - two functions are in one module by accident and nothing connects them. Classes like utilities or shared are the best example of the coincidental cohesion.
Logical - when, at first glance, the two entities are connected, but after deeper consideration, they would turn out to be completely different. For example, two entities with similar names, but differentiated responsibility.
Temporal - two functions are in the same module because they must be executed at the same time.
Procedural - the procedure needs some operation to be executed. So we group all operations into one module
Communicational - there are functions in the module that use the same data
Sequential - there is a function, which returns data which the next function needs. So we create a pipeline of executions.
Functional - functions are in one module because together they create a whole feature.

Let's take a look at an example:

class Employee{
  id: string;
  name: string;
  address: Address;
  salaries: Salary[];

  getName(){}
  getAddress(){}
  getSalaryReport(){}
}

Here we have a class Employee with two methods, get name, and get a salary report. We can say that this is natural that employee has a salary, but are we really need this information in employee class? Should employee be responsible for creating a report? In my opinion not. What we should do? We should create a separated class focused on this functionality, like below:

class Employee{
  id: string;
  name: string;
  address: Address;

  getName(){}
  getAddress(){}
}

class EmployeeSalary{
  employeeId: string;
  salaries: Salary[]

  getSalaryReport(){}
}

Now, we have an independent class. When we want to generate the report for an employee we retrieve EmployeeSalary class from the database and execute method getSalaryReport(). Thanks to that Employee class don't know anything about the salary, because it is not important information for Employee.

Conclusion

In conclusion, cohesion means how related and focused the responsibilities of an software element are. Coupling refers to how strongly a software element is connected to other elements.
As we can see, taking care about low coupling and high cohesion helps us creating class with one specialization, without any additional dependency. It will help us in the future, when we will be forced to change an implementation. When we spend enought time thinking about, how to design our system and apply this patterns, we save time in the future. We will also make our client happy, what is very important, because we create software for the business.

In the next part, I write about last 3 patterns: Polymorphism, Protected variations and Pure fabrications.

Do you know GRASP? Part 2 - Indirection and Information expert

Mateusz Gajda — Sun, 05 Jan 2020 18:46:54 +0000

Welcome in Part 2 in series about GRASP. Today I would like to tell you more about Indirection and Information expert patterns. As a reminder, these patterns allow us to see how to allocate responsibility in our code.

Indirection

Problem: Where to assign a responsibility to avoid direct coupling between two or more things?

For better understanding where we can use this pattern, let's imagine the following situation. We have a system for booking people at an event. The client can choose from many employees due to their specialization and add them to their project. In this case, we need to set each employee as booked for the specified date, we must also inform the project that new people have been added to it, and finally update the fee the client will pay.

As you can see, in this case, the Employee component needs to call and know about the Project component so that it can update the information about booked employees. In addition, there would be another binding between the project and client charges. We want these three components to be independent, so this solution is not good for us.

So what we need? A new component that will be kind of orchestrator for others. It will determine the order of operations. We can use some of these design patterns to introduce it:

bridge
facade
adapter
mediator

Why? Because we need an object that will be responsible for communication between all modules. This way the components will know nothing about each other. In addition, there will be no problems to find out which component is looking at which one, because none is looking at any.

Here is a result of introducing mediator to our code:

Information expert

Problem: What is a basic principle by which to assign responsibilities to objects?

This pattern tells us that we should add new responsibility to the class that has the information needed to fulfill it. We do it to avoid implicitly connections between class. So this is very important to aggregate similar responsibilities in the same class.
Let take a look at the following example:

class ShoppingCart {
  orders: Order[];

  addOrder(order: Order) {
    this.orders = [order, ...this.orders];
  }

  getTotal() {
    return this.orders.reduce((total, order) => {
      return (total += order.cost);
    }, 0);
  }
}

So if we want to add a new feature, to count the total cost of our shipping card, we should add this function to the ShoppingCart class. Why? Because this class knows everything about orders, so this is the best place for this. Someone may be wondering if such an addition of methods will not make the class grow too much? It's possible. But is it really a problem for us if all functions are linked to the same data? I don't think so.

Conclusion

In the next part, I will talk more about cohesion and coupling. These are very interesting topics, so I will try to tell you a little more about them.

Do you know GRASP? Part 1 - Controller and Creator

Mateusz Gajda — Sat, 04 Jan 2020 20:56:40 +0000

Due to the fact that shorter posts are much better read, I decided to divide this topic into about 4 separate entries. Each concerning two or three patterns. Here is part one.

What is it?

GRASP - General Responsibility Assignment Software Patterns are 9 patterns, which will help you with adding a new responsibility to your current codebase. It could be very helpful because sometimes we don't know if this component is suitable for this functionality. Maybe we should create a new one? These 9 patterns can help us.

Controller

Problem: What the first object beyond the UI layer receives and coordinates “controls” a system operation?

In the software world, everything should have its responsibility. Models contain data, views present the data, repositories talk with databases, etc. Our systems are consistent with a lot of different objects and components. Very often they have to talk with each other, but we should take care who's talking to whom.
We do not want to let our objects talk directly to the database or other external services. We need something which takes this responsibility.

By simplifying our systems, we can say that they consist of many different use cases. Each use case needs to talk with a lot of different objects. We need to talk with the database, execute some operations on the domain object or retrieve some data from external API. We need also a layer that will be responsible for handling user input.

That is why we a controller. An object which will be an entry point for our use case or system. It will be the first object beyond the UI layer. Very often it will be an application service or command handler if we are talking in CQRS case. But, be careful! It isn't a controller such as in MVC. In MVC the controller is still part of a UI. In our case, it is the first object in the system. Let's take a look:

export class OrderService {
  private orderRepository: OrderRepository;
  private productRepository: ProductRepository;
  private constructor(
    orderRepository: OrderRepository, 
    productRepository: ProductRepository) {
    this.orderRepository = orderRepository;
    this.productRepository = productRepository;
  }
  async create(orderDetails: OrderDetailsDto) {
    const { quantity, productId } = orderDetails;

    const product = await this.productRepository.get(productId);
    const order = Order.create(quantity, product);

    await this.orderRepository.save(order);
  }
}

We have our application service called OrderService. Here we talk to our database through repositories. We retrieve a product which next is passed to our static factory method, which is part of our domain model Order. Next, we save a new order to the database. Thanks to that, the domain model doesn't know anything about the database. Additionally, the separation of the application code from the UI allows us to test our service more easily. In the case of the unit tests, we need only to mock our repositories.
Here is how it looks like in our router:

export const orderRouting = (orderService: OrderService) => {
  const router = express.Router();
  router.post("/order", (req: Request, res: Response, next: express.NextFunction) => {
    orderService
      .create({
        productId: req.body.productId,
        quantity: req.body.quantity,
      })
      .then(result => res.json(result))
      .catch(err => next(err));
  });

  return router;
};

Creator

Problem: Who creates object Y?

A common problem is definitely which object should be responsible for creating a class Y instance. Creating an object is an important process, so it is good to have defined rules that will make it easier to decide who should create a Y-instance. So let's take a look at these rules. Object X can create Y if the following conditions are true:

X aggregate/contains Y.
X has all the data required to create Y
X closely use Y

Thanks to these rules, it may turn out that we don't have to create a special factory to create the Y object. We can simply create it in object X. Why? Because X object needs Y object, it knows everything about how to create Y object so a new factory, in this case, will be useless.

Assume that we have a diary class that contains our notes. We can easily create our note inside the Diary, because it contains the list of Notes.

export class Diary {
  notes: Notes[];

  addNote(title: string, content: string){
    this.notes.push(Notes.create(title, content))
  }
}

Summary

That's only 2 out of 9 patterns. In the next few parts, I'll introduce you to the next ones. I hope you'll find them useful and use them. If you have some question, feel free to write a comment :)