small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

#### What Tools Does a Senior Full Stack Developer Use?

Welcome to first episode of our **“Developer’s Tool Set”** series, where we dive into the technologies and workflows that power our engineering teams. Today, we’re focusing on the toolkit of a **Senior Full Stack Developer** - the key tools they rely on to build, maintain, and scale our applications efficiently.

This article takes the form of an interview with one of our senior developers, offering firsthand insights into their daily workflow. We’ll explore not only the technical stack - backend frameworks, frontend libraries, cloud infrastructure, and DevOps tools - but also some more casual topics. Expect answers to questions like: What’s your favorite mobile app? Which browser do you use? Do you prefer dark mode or light mode?

Whether you’re an aspiring full stack developer or just curious about our tech ecosystem, this guide will give you a behind-the-scenes look at how our team works.

Let’s dive in!

#### Łukasz Duraj, Senior Full-Stack Developer.

I have **13 years of experience.** I mainly program in **PHP** and **NodeJS.** Additionally, I have worked commercially with Java and Python on the backend, as well as with various frontend tools - from jQuery and Angular 1 to React, React Native for mobile, and React frameworks like Remix and Next. I also focus on application architecture on the backend and cloud infrastructure (AWS/GCP).

#### Essential Tools

I use the entire IntelliJ suite - **PHPStorm, WebStorm, IDEA,** and **PyCharm.** These tools provide a very rich feature set. The most important tool for me is always the **debugger,** whether it’s **XDebug integration in PHPStorm** or running applications with built-in framework tools. It’s crucial for me to be able to step through an application from checkpoint to checkpoint.

Additionally, integrations with **Docker, databases,** and **Git** (such as performing Code Reviews directly in the editor) are indispensable.

#### Languages & Frameworks

It depends on the project. **I prefer working without a framework or with micro-frameworks.** In PHP, these would be **Symfony-based micro-frameworks,** and in Python, Flask. However, I most often work with:
- **Nest.js** in NodeJS
- **Symfony/Laravel** in PHP
- **Django** in Python


#### Code Management & Collaboration

I only use **[Git](https://git-scm.com),** as SVN is rarely used nowadays.
I’ve worked with **[GitHub](https://github.com), [GitLab](https://gitlab.com),** and **[Bitbucket](https://bitbucket.org),** and I don’t have a strong preference between them.
For team collaboration, it depends on the project. I mainly use **[Slack,](https://slack.com)** but I’ve also worked with **[Discord](https://discord.com)** and even [Gadu-Gadu](https://en.wikipedia.org/wiki/Gadu-Gadu) back in the day.

For project management, I’ve used many tools, including **[Jira](https://www.atlassian.com/software/jira), [Trello](https://trello.com), [Asana](https://asana.com), [Phabricator](https://phacility.com),** and **[YouTrack.](https://www.jetbrains.com/youtrack)** However, **[Linear](https://linear.app/) has recently won me over with its fantastic process automation features.**

#### DevOps & Deployment

**I work extensively with CI/CD** and have set up CI/CD pipelines from scratch using **GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, CircleCI,** and **Jenkins** - depending on project needs.

For monitoring and logging, I primarily use **[Sentry,](https://sentry.io/welcome/)** but I also rely on AWS **[CloudWatch](https://aws.amazon.com/cloudwatch/)** and **[GCP](https://cloud.google.com/)** logs. I’ve worked with **[Datadog](https://www.datadoghq.com/) and [Grafana](https://grafana.com/)** logs as well.

#### Debugging & Testing

**The IDE debugger** is my primary tool - I try to use it **always and everywhere.**

I test using libraries built into the respective environment, such as **[PHPUnit](https://phpunit.de/index.html)** for PHP and **[Jest](https://jestjs.io/)** for NodeJS.

#### Productivity & Workflow

I use **Google Keep** for quick notes and **Google Calendar** to manage everything I need to remember or schedule.
I’ve tried many productivity tools, but none worked for me in the long run.
At one point, I also used the **[Pomodoro technique](https://en.wikipedia.org/wiki/Pomodoro_Technique)** quite often.

#### Learning & Self-Development

Mainly conference talks. I also buy books on software architecture and take courses from **[DevStyle.](https://devstyle.pl/)**
I follow materials published by **[Bottega IT Minds.](https://bottega.com.pl/)**

#### All-Time Favorite Tool

**[Docker](https://www.docker.com/)** ❤.
That's my primary tool. Except the NVM for managing NodeJS versions, I don’t have any installed tools - I set up everything locally using Docker.
This allows me to virtualize any environment and tools I need. Most tools also have Docker images, so testing them is as easy as pulling the right image.

#### Quick Questions
- MacOS, Windows, or Linux? → **Linux**
- Light mode or dark mode? → **Dark mode**
- Which browser do you use? → **Chrome**
- Favorite browser extensions? → **[Grammarly](https://www.grammarly.com/), [Simple Translate](https://simple-translate.sienori.com/)**
- Your favorite mobile app? → Recently fell in love with **[BookBeat](https://www.bookbeat.com)**

thumbnail_ŁDblog_cover_high.jpg

ŁDblog_cover_high.jpg

Developer’s Tool Set part 1: Senior Full-Stack Developer

Frontend Engineering

UX/UI Design

Research & Discovery

AI For Your Business

Services

Case Studies

Career

About us

Blog

#### **Though, there was a problem...**
Some time ago, while working on one of the tasks in the project, I got to the stage where I had to write a test. I am aware that someone now could say that I should start with tests at the beginning. Why didn't I? Because some parts of the code already existed (and were not tested), and I wanted to be sure that my changes would not mess with what I found. This decision was ultimately aimed at overall improvement of the quality and testability of this part of the application.

The application remained uncooperative and did not want to perform, despite the fact that in my subjective opinion the quality of the found code was not so bad. Of course, I would find a few things that I would like to refactor, but despite the lack of testing, the code seemed *testable*. And I was not mistaken. After about 40 minutes I had a very decent *test suite* written, that covered a few existing and new cases. As an engineer, I was satisfied, but still something was bothering me. So I took two steps back and looked at my work again. I was troubled by a few questions. Why was the code so reluctant to be tested, despite its apparent testability? Did I spend enough time on these tests?  What's more, I started to wonder if what I tested actually gives me enough feedback in the case of subsequent changes to the system? It was definitely a topic worth exploring a bit more!


#### **Application Architecture On Her Testesty's (Secret) Service**
For the sake of simplicity, let's assume that the code architecture is primarily the way a code is organized. Of course, this does not only apply to the folders structure, but above all, what responsibilities are met by its individual parts. In the case with my project, we talk about striving to meet the demands of Clean Architecture, also known as Hexagonal, Ports and Adapters or even as Onion, although the latter name has not really caught on. Within this architecture, we distinguish three layers:

1. Infrastructure level - where we communicate with the outside world and use external dependencies (e.g. attached libraries and packages),

2. Application level - where the operational part of our application should be happening,

3. Domain level - where key decisions should be made, e.g. about changing the state of the application.


An interesting property that we should look for in such architecture is the range of visibility of each of these layers. The domain only sees itself and cannot access other layers. The application level has knowledge of the domain and itself. Infrastructure, in turn, sees everything - both from above and below. This mindset forces the developer to always include dependencies from the infrastructure layer to the application layer. We can say that we insert the dependencies from the bottom or, as in the case of the visualization characteristic of this architecture - from the outside to the inside.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_02_1r3nE0JHqmRUOI6znpMU7u.jpg)
##### Graph 1. Visualization of Clean Architecture, own diagram (Domain, App/application, Infrastructure)
We also aim for such architecture when we try to design our application according to DDD (Domain Driven Design) methodology. The system I was working with was definitely heading in DDD direction, although there were still a lot of things to do. That is why ideas derived from DDD appeared in the code, such as entities, value objects, or repositories. This blog-post is not intended to explain what DDD is and what concepts it consists of, but for a further understanding of the whole context, let's adopt such simplified definitions for a few of the terms that I used:

- Entity - it is an object with an identity that represents some model. For example, a user that we can uniquely identify. This model, however, unlike the typical approach containing mainly anemic entities, apart from data, also has methods that allow you to perform some action on this object.

- Value object  - this is an object that has no identity. A perfect example is the representation of money. However, unlike a simple data structure, it may also have some logic, e.g. related to validation, different representation or comparison.

- Repository - it is an object that allows us to perform database operations. However, it should provide a high-level API to not reveal implementation details.


It seems Uncle Bob would have accepted that. However, how could such architecture help us in any way in testing? What layer should we test the most? What should such tests look like? Unfortunately, it seems that the very concept of this architecture does not answer those questions. So let's try to ask a slightly different one. What makes a test easy to write, and what makes it difficult or even impossible?

#### **White or black?**
One popular pattern for writing unit tests is the 3xA rule:

- Arrange - prepare the application so that it can be tested,

- Act - perform an action,

- Assert - check and test if the result of the action is consistent with your predictions.


After analyzing the tests I wrote for the project I noticed that the Arrange stage, i.e. test preparation, was the most time consuming part. The very implementation of the action and test usually came down to one or two lines of code, but preparation took even a dozen or so. Besides, I had a strong feeling that I needed to go too deep into the implementation to know how to test a given piece of code.

Let's look at the following code snippet:

``Code 1: Implementation of the Calculator class``



Now let's try to test this code:

``Code 2: Tests for the Calculator class``



The code shows a very simple implementation of a calculator with two methods for dividing and adding. Very often, such samples are used to show an example of testing an application.



In each test case, I started with a comment of the part of the Arrange, Act and Assert sections. You will notice that these sections are very short and concise. Each test consists of 3 lines, one for each section. However, I would like to highlight one important thing that seems to be overlooked or not sufficiently resonant in such examples. These tests are very simple and quick to write. You could say that we are testing a very simple sample class, but actually such cases rarely occur in the real world. One could even say that these tests are detached from reality. But let's consider what, apart from this uncomplicated example, makes these tests so simple:

- explicitly defined contract in the form of the *CalculatorInterface* interface,

- the *Calculator* class has no dependencies,

- methods have all the information to be able to perform the requested action,

- there is a constant relationship between the input parameters and the return value.



It can be clearly stated that by looking at the methods of this class, we are able to say what their behavior is and what results we can expect. Thanks to this, knowledge of the internal implementation is not required and we could actually write tests based only on the methods specified in the *CalculatorInterface* interface. Tests with these properties are called *blackbox tests*. The black box test is the simplest type of test that makes it much easier to check your application. However, we rarely test simple calculators in our lives. So let's try to discuss a slightly more complex case.

``Code 3: Currency exchange service``



The purpose of this class is to convert the value of one currency to another. It has a dependency in the form of a repository returning the current exchange rate. The specific implementation of this repository, as part of our Clean Architecture, should be placed at the infrastructure level. In our case, this type of service belongs to the application layer. In the domain layer, in turn, there will be concepts presented as value objects, such as *Currency*, *Money* or *ExchangeRate*. Let's try to add tests for this class.



``Code 4: Tests for the CurrencyExchangeService class``



You can see at first sight that this test is much more complicated. What’s more, the number of lines of the test is bigger than the test code itself! This one test took me a lot more time than the 3 previous ones for the Calculator class combined. The test itself is not complicated, although some intellectual effort was required to have it prepared. It's worth noting that the *Arrange* section contains the most lines of code. As the *CurrencyExchangeService* class has an external dependency, it had to be replaced with an object of the class pretending to be a real repository. Such an object is called *Test Double* (the name refers to the term *Stunt Double*, i.e. a stuntman who replaces an actor in dangerous scenes of the movie). It is supposed to replace the original object on which it will be possible to call the necessary methods and return the previously prepared data. This is to ensure the repeatability of the test execution and to cut off the true dependencies in order to be able to test the code in isolation. In this particular case, I used a *Mock-type* test double, which allows you to verify whether a given method was used during the test. It also allows you to define what parameters the method should expect and the value to be returned.


In comparison to the previous example, in order to call and test the *exchange* method, I needed to know the internal implementation of the *CurrencyExchangeService* class. I needed to know that this method would call the *getExchangeRate* method inside and what value this method would give in return. Creating a test double complicated the process of writing the test. It is also not as transparent as the tests for the *Calculator* class. Tests where implementation knowledge is required are called *whitebox* tests. What is more interesting, almost all the tests I wrote and were dedicated to the problem described at the beginning of this article were *white box tests*. The tested classes had a large number of dependencies, so the *Arrange* stage first included the instance of many test doubles, which made the whole testing process difficult. I will also mention that the preparation of these test double files was extremely boring and required a thorough code review (as these tests were written in the form of TAD - *Test After Development*) in search of a specific use of them. It can be clearly stated that the white-box tests are much more difficult to write, although at the moment it seems that they are still much more “real life-like” than the black-box tests. Ideally, we should only be able to test the functionality with black-box testing. Then the question arises how to do it and how would our application architecture help us? Let's look at one more example and try to transform it to answer these questions.

#### **A classic. Testing the cart**
``Code 5: The CartService class``




In the presented section of the code, we have the part responsible for using the coupon with a percentage discount on the items added to the shopping cart. The *applyDiscountHandler* method takes a command (that is, an action request) and gets an instance of the current cart and finds the coupon in the database. Then it applies the coupon according to the business rules, saves the changed cart and blocks the coupon so that it cannot be used again. The code structure and dependencies are distributed within Clean Architecture.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_04_3CbAXJz8YLyGPyQgnyXlxZ.jpg)
##### 
Graph 2. Code structure of the Cart module
We can list the characteristic blocks from which we build the application using DDD design. Let us think about how we could test this method. The *CartService* class has 3 dependencies. Two for the repositories for the cart and coupons and one for the service for broadcasting events (event - something important happened in the system). This means that at first we would have to create mocks for these dependencies. Then we should check what methods are used (how many times, with what parameters and what they return) and set them accordingly. The key action we are trying to perform is actually changing the state of the *Cart* object. However, the *CartService* class does not return an instance of this class in any way. Verification of its condition would also have to be done with a *mock*. Definitely,  It would be a white box test. What's more, the code doesn't make it easy for us by returning nothing, which would require workarounds and tricks to make it work. This kind of test would be neither easy to write nor read (and we need to remember that tests are the best documentation!). At this point, we should have a feeling that something is wrong with our code. Let's try to refactor our code to make our tests a little easier to write and a little more readable.  So what is wrong with the code presented?

- The method definitely breaks the SRP (*Single Responsibility Principle*) principle and does too much - so it would be good to separate the operations on the coupon and the cart from each other.

- The business logic of the discount calculation rules leaked from the domain to the application site. The application layer is responsible for the operational part of the program. It should not make business decisions.

- Two different business logic are mixed up here. Logic of coupon management and blocking, and logic of the cart calculation.


First, let's deal with the separation of responsibilities. 

``Code 6: DiscountService class``



We have created a new class that deals only with the validation and coupon usage. On the found coupon, we call the *useDiscount* method, which returns the event informing about the change of the coupon state. Let's take a look at the *Discount* class.

``Code 7: Discount class``



*The Discount* class has no dependencies. All the information required to make the state change decision was provided in the initialization stage. So we have led to a situation where we can test our business logic with a ... black-box test!

``Code 8: Tests for class Discount``



Definitely, the test of our business logic looks much neater than the test of the currency conversion site and it took a lot less time to write it. Thanks to the returned events, we can examine the connections between the input parameters and the output parameters of the method. The use of the concept of events is also not accidental. By events, we mean a change of state that is significant for the system. This is also what happened in this case. Then, within *DiscountService*, we do two things with the event:

- We save the change - depending on the system architecture, we can save this event in our database. The sum of all events (i.e. changes in state) on an object will always give us its current state. On the other hand, in a system where these historical state changes are irrelevant, we can update the state of the object directly. In the latter case, however, it is good to transfer a new, consistent instance of the object being provided inside the event.

- We publish an event - thanks to this, other objects listening to specific events can take their own actions. This is how we make it possible to apply our coupon to the cart.


``Code 9: The CartService class``



The *DiscountCouponUsedEvent* event caused the *applyDiscountHandler* method to be called on a *CartService* object. This event brings the necessary information that we need to apply to our shopping cart. As you can see, there is no need to provide the entire discount object, only information about the discount type (*DiscountType*) and discount percentage (*DiscountPercentage*).

``Code 10: Cart Class`` 




Again, the *Cart* class has all the information required to apply the discount and returns an event as a result of calling the *applyDiscount* method. Then we persist in this event and publish it. This approach creates a cause and effect chain that is very easy to follow and understand. The *Cart* type tests will also be black box tests. However, the question arises, what about the *CartService* and *DiscountService* classes? Both have dependencies, so testing them forces us to do white-box testing. At this point, I would like to highlight the responsibilities of these services. Their task is to:

- preparation of our object (*Cart/Discount*),

- calling the appropriate method with appropriate parameters,

- calling actions aimed at preserving and publishing events.



Isn't that a bit like the *Arrange, Act, Assert* pattern? We have to answer the question, what would we really like to test in these classes? There seems to be no point in testing them, as the essence of their responsibility is actually triggering our business logic. So these would be the same tests we wrote for the *Discount* and *Cart* classes, but wrapped in a complicated structure of stubs and mocks. Therefore, integration tests, not unit tests, would make much more sense here.

#### **So where are these aggregates?**
The title of this article promised the aggregates, and I still haven't mentioned anything about them. This is a deliberate case, as it seems to me that this topic is not fully understood by many programmers. In the given example, all we did is refactor a little and reorganize our code. This allowed us to bring it to a stage where we were able to test it with a much simpler black-box testing method. As a result, our *Cart* and *Discount* classes have acquired some properties that they did not have before, namely:

___
**they have all the information required to make a business decision**

___
As a result, they can protect data with consistent rules and make state change decisions without having to ask other parts of the system for additional conditions. Let's add to this supplementary conditions that do not result directly from the code:

- *Cart* and *Discount* class objects should always be created in whole extend (all required data should be loaded),

- state changes should be persisted atomically (i.e. always all together),

- only the *Cart* and *Discount* classes can modify their state - no other part of the system can do so.



By adding these few additional conditions, it turns out that our *Cart* and *Discount* classes are technically... aggregates in the sense of the DDD. More precisely, the roots of their aggregates. To illustrate this better, take a look at how I reorganized the directory structure of our component.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_05_5EIfawNNSZ2LZx9zqPsdHr.jpg)
##### Graph 3. Cart module structure containing aggregates
The Domain class contains 3 catalogs: *Commons*, which contains common concepts, and *Cart* and *Discount*, where our aggregates are located. I highlighted their roots in blue, i.e. classes that constitute a public interface for interacting with the aggregate. It seems to me that such a presentation of this concept can be much more accessible, because it not only shows us the benefits of a much better testability of our code, but also one of the ways in which we are able to extract aggregates from our system. Of course, there are much better and more appropriate tools for this (e.g. process and tactical sessions in Event Storming), but even if we do not know these concepts, we can improve our applications in the way presented. 

#### **Who is your boss?**
In conclusion, I would like to present a certain analogy that comes to my mind when I think about the responsibilities of clean architecture. This analogy can be helpful when we are forced to decide how we should organize our application code.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_03_2lCBUwq9BZwf1P03b5469X.jpg)
##### Graph 4. Analogy of Clean Architecture to Organization, own diagram

Imagine your company has three levels:

1. The boss - the decision-maker

2. Middle-level manager

3. Employees


The responsibility of a middle-level manager is to execute the plan provided by the decision-making person. He does not do it by himself, but delegates work to employees. Employees do it physically. Moreover, the manager is responsible for providing the data the boss needs to make specific decisions. The preparation of these data is also delegated to employees, but the manager may also format or organize them differently before handing them over to the boss. In a large organization, the boss very often does not even know his employees. The data is provided to him by the manager, so there is no need to ask and search for data from the lowest-level employees. He is also not interested in the way the assigned tasks are performed.

Our application structure works similarly. The application layer orders the physical download and preparation of data for specific instances in the infrastructure layer, which retrieve it from the database and return our aggregate root. Then the parameters are called and passed to the aggregate method, which makes the decision about the state change already in the domain layer. This decision is returned by event to the application layer, which is then delegated back to the infrastructure layer for persistence and publication.

#### **Try it yourself!**
As part of this article, I also created an implementation of this solution. As you may have noticed, not everything I wrote about has been tested. What's more, the infrastructure layer has not been presented here in any way, which in our case can be completely replaced by tests. If you would like to practice, fork the codebase repository and try to extend the existing tests, modify the *CurrencyExchangeService* class the same way I did with the *CartService* class. Suggest your own solutions and share your implementation with everyone in the comments. I am curious about your opinion on how you understand the presented topic and ideas for implementation.

The blog post was created as a translation of a "Testowanie agregatów, czyli architektura wspierająca testowanie" entry on [**devkick.pl**](http://devkick.pl/testowanie-agregatow-czyli-architektura-wspierajaca-testowanie/)
, written by Łukasz Duraj. 

GitHub - [**lukasz-devkick**](https://github.com/lukasz-devkick)
**/**[**aggregates.testing**](https://github.com/lukasz-devkick/aggregates.testing)




small_Blog_artykul_TestingAggregates_LukaszD_cover_high.png

thumbnail_Blog_artykul_TestingAggregates_LukaszD_cover_high.png

Blog_artykul_TestingAggregates_LukaszD_cover_high.png

Testing Aggregates

#### Everywhere You look, there's TypeScript!

In JetBrains' "State of Developer Ecosystem 2022" report, TypeScript is recognized as the fastest-growing language in recent years. Undoubtedly, when working with technologies related to JavaScript, it's impossible not to notice that TypeScript is becoming increasingly prevalent and dominating tech stacks. TypeScript can be found in the development process of frontend applications in modern frameworks and libraries like React.js, Vue.js, and Angular. It's also present in backend projects using Node.js and its frameworks, mobile solutions like React Native, and can even be used in older solutions like jQuery. In other words, anywhere JavaScript is used, TypeScript can follow suit. But why do we need TypeScript in the first place? What is it used for?

#### What's wrong with JavaScript?

It's worth noting that TypeScript emerged as an extension of the JavaScript language. This means that any valid program implemented in JavaScript is also a valid TypeScript program. Furthermore, code implemented in TypeScript is transpiled into JavaScript. In other words, what's implemented in one programming language (TypeScript) is expressed in another language, JavaScript in this case. Ultimately, the program that is executed is always implemented in JavaScript.

One might wonder what's wrong with JavaScript that led people to decide to improve it. Moreover, why didn't they create TypeScript as an independent language, given that so many people see value in it and invest their time and quite often money to learn and implement it in commercial projects? In my opinion, the answer to this question is both the greatest advantage and disadvantage of the JavaScript language:


>JavaScript is a popular, simple language that offers tremendous flexibility in implementing solutions.

In the aforementioned survey, JavaScript has been the most widely used programming language for web and mobile applications for several years. Interestingly, the same report lists JavaScript as the least liked language among developers. This creates an intriguing dissonance that speaks volumes about the language itself.

So, why didn't the creators of TypeScript decide to release it as an independent language? If Microsoft, the company that developed TypeScript, had done so, it's likely that few people would be using the language today. This move reflects the lessons Microsoft learned from its past. Remember that in the early days of the internet, Microsoft proposed its own technology, ActiveX, to compete with JavaScript, but today it's virtually unheard of.


#### JavaScript is everywhere!

One of the key reasons for JavaScript's popularity is its cross-platform nature. JavaScript began as a scripting language meant to enhance interactivity on websites. Over time, it expanded its use beyond websites to server-side and native device applications, including mobile apps and desktop applications. Learning one programming language, with relatively low effort, enables developers to implement programs for various devices. Such a developer is more flexible in the job market and is not limited to a specific type of application. There's a slim chance that TypeScript could surpass the popularity of JavaScript. Despite being considered a separate language, TypeScript is closely tied to JavaScript.

#### JavaScript is simple!

JavaScript is simple, but some context is necessary. It's simple compared to other programming languages like C/C++, Java, C#, and even Python or PHP. If you look at the history of programming languages, you'll notice a trend. Later languages have simpler syntax, automate many operations, or encapsulate them in ready-made functions that you can use. Initially, we had only bitwise operations on processors. Assembly language was introduced as a way to operate on memory more easily. Assembly, however, is still a low-level language. Later, languages like C provided a friendlier environment for developers. Despite this, they still required direct memory management, including memory allocation and deallocation. Programs had to be compiled separately for different hardware architectures. To solve this problem, more layers of abstraction were introduced, such as virtual machines for Java or C#, and script interpreters for Perl, PHP, or Python.

As the internet and websites grew in complexity, there was a need for greater interactivity. Websites are applications that run within a runtime environment – the browser. The browser, in turn, is a program executed natively by the operating system. Originally, JavaScript was confined within a limited environment and lacked the capability to interact with the operating system or file system. In this context, a complicated language wasn't necessary. To simplify things, JavaScript introduced dynamic typing. Unlike "classical" programming languages, where you had to specify whether a variable would hold text, numbers, or boolean values, JavaScript can infer this based on the value's type. Its straightforward syntax, limited capabilities, dynamic typing, and the reduction of everything to basic types (text, numbers, boolean values) and data structures (arrays and objects) make JavaScript easier for beginners compared to other programming languages.

#### JavaScript is flexible!

JavaScript's flexibility is both its greatest advantage and disadvantage. JavaScript allows you to write code in the way you find most convenient. If a programmer thinks it's most convenient to change the behavior of a function that works in a specific way, there's nothing stopping them. JavaScript is a prototype-based scripting language. When we refer to an "object," we mean a combination of data and behaviors within a shared context, representing what we can do with that data. In traditional object-oriented programming, objects are created based on "classes" that describe the behaviors and data within an object. However, JavaScript doesn't have typical "classes"; instead, it employs the concept of objects that share data and behaviors via prototypes. A prototype is an object that serves as a base from which other objects can inherit. All objects ultimately inherit from the "object" prototype.



**“object” ←”Person” ←”Employee”**

In the example above, "Employee" is also a "Person," and "Person" is also an "object". This means that both "Employee" and "Person" can use the same behaviors as "object," and additionally, "Employee" can use behaviors available for "Person."

The problem arises when we overwrite the behavior of an object in the prototype chain while the program is running. This change affects all objects that inherit from it. Other object-oriented languages, due to the way classes are structured, don't have this issue. Even if you change the behavior of the code in the base class, it won't affect existing objects. Furthermore, the possibility to change the behavior of prototypes extends to built-in JavaScript objects as well.

#### Things can get very messy…

Imagine a scenario where you use a library created by someone else for a particular purpose. However, you're unaware that the library's creator has changed the behavior of base prototypes. In such a situation, your program might start behaving in ways you can't understand. It's extremely challenging to identify and eliminate these types of errors.

There's a popular joke that in languages like C/C++, C#, or Java, errors are mostly reported by the compiler during software development, while in JavaScript, errors are reported by the client. Unfortunately, this joke has a basis in reality. JavaScript makes it easy to write unreadable code. As a result, it's challenging to predict the consequences of even the simplest changes in the future. In compiled languages, the static determination of expected types offers a significant advantage because the compiler can quickly identify potential errors. In JavaScript, dynamic typing is performed during program execution. During code execution, in a specific use case, only one code path is executed. If the use case relies on input data, testing it becomes even more complicated, and a single execution may not suffice. As a result, such testing is often omitted or limited to critical paths.


#### We need to take a step back!

In my opinion, TypeScript represents a step backwards in the context of the evolution of programming languages. However, it's a step in the right direction. JavaScript has proven that too much freedom and simplicity in a programming language place too much responsibility on humans, in this case, on the programmer and the tester. When implementing software, we need quick feedback on whether what we've created works or not. We can distinguish two types of feedback here:

1. Technical feedback, which is about whether our program executes correctly.
2.  Business feedback, which pertains to whether the program delivers the expected added value and meets functional requirements.

TypeScript can help us to some extent with both of these aspects.

#### Business feedback

Although not directly, TypeScript can also help us when delivering software that needs to meet specific functional requirements. One of the fundamental principles of object-oriented programming is modelling the real world. When building software, we attempt to reflect real-world concepts in our code, while keeping it to a necessary minimum. For example, in an employee management system, we need information about employees, but only the data required for managing them within the organization, while other data can be omitted.

As I mentioned at the beginning, JavaScript, besides simple types, provides an "object" type, allowing us to create arbitrary data structures and behaviors. However, it doesn't enable the creation of new types describing other objects based on it; it's quite generic. Although newer versions of JavaScript introduced the concept of "classes," it's essentially syntactic sugar for "objects." In TypeScript, we can speak of classes that create new complex types. This allows us to create a type like "Employee," which enforces specific data and enables specific behaviors, such as "change hourly rate" or "set vacation days." Furthermore, just like with simple types, the correctness of using these classes is controlled by the language itself.

So, we gain a powerful mechanism for control, fast feedback, and data modelling, making the code more readable and understandable. This not only reduces technical errors but also functional errors, which often result from a lack of understanding of a given solution within the team.

#### A Solution to All Evils?

TypeScript solves many of the problems that JavaScript developers face on a daily basis. However, it can't solve them all. JavaScript is everywhere, especially on almost every website. It's difficult to introduce new versions that break away from the old ones due to the multitude of browsers and the millions of places where it's used, requiring backward compatibility. Therefore, it's easier to improve the software development process itself and then transpile nice and modern code into JavaScript that's backwards compatible. In the resulting code, we don't need to worry too much about errors related to incorrect data types because they have been verified in an earlier stage.

#### Help for the Programmer or Art for Art's Sake?
When trying to answer the question posed in the title of this article, we need to consider our motivations for using such solutions. TypeScript restricts the programmer and controls the code, making it harder to make simple mistakes. At the same time, one can go to extremes. For example, imagine building a front-end application that uses a technique to control CSS styles (which describe how a webpage should look) on the JavaScript side (typically these are two separate technologies). With a very rigid approach, a programmer might conclude that they need to describe, using types in TypeScript, the capabilities for managing CSS styles. Anyone who has ever implemented CSS styles knows that it would be cumbersome, time-consuming, and ultimately unnecessary. In this case, it could become art for art's sake.

It's essential to remember that TypeScript isn't a language used during program execution. It was created to enhance the work of developers during the software development process and to shorten the feedback loop. With this approach, a programmer can create more robust, maintainable, less error-prone, and ultimately more cost-effective code in the long term.

Furthermore, TypeScript helps us describe code, providing priceless context. This context is invaluable when using supporting tools such as Github Copilot. With this context, the tool can offer code suggestions that are more precise, speeding up work.

In my opinion, with the right approach, TypeScript is a wonderful aid for developers that eliminates many of the problems we face daily in pure JavaScript. However, it's also essential to recognize that it's not always worth using it in every possible aspect and to apply appropriate compromises in cases where its use would be too time-consuming, and potential benefits would be minimal.

Do you think TypeScript is a step forward or backwards in the development of programming languages? What are your personal experiences with TypeScript? 

Leave your opinion on our social media!


Sources:
JetBrains, [The State of Developer Ecosystem 2022](https://www.jetbrains.com/lp/devecosystem-2022/ )
JavaScript, [Prototypal Inheritance](https://ii.uni.wroc.pl/~wzychla/ra2I2J/weppo/WEPPO_05.pdf)
[JavaScript](https://en.wikipedia.org/wiki/JavaScript)
[TypeScript](https://www.typescriptlang.org/)

large_blog-TS_LukaszD_cover_high.png

medium_blog-TS_LukaszD_cover_high.png

small_blog-TS_LukaszD_cover_high.png

thumbnail_blog-TS_LukaszD_cover_high.png

blog-TS_LukaszD_cover_high.png

TypeScript - A Boon for Developers or an Art for Art's Sake?

#### The Story Repeats Itself

When I started my programming journey, I was simply a Web Developer. I was responsible for both frontend and backend parts, communication between them, and often for deployment and maintenance as well. Over time, however, these roles began to specialize, and people started focusing only on certain parts of the development process. This specialization was necessary since the complexity of systems has been growing, making it harder to understand, develop, and maintain the entire software stack. This complexity stems from more than just business logic but also from the myriad of technologies, tools, libraries, and frameworks. However, it turns out that having many specialized professionals is sometimes not cost-effective for projects of a certain scale. This gap has been filled by frameworks like Remix and Next.js, which are full-stack frameworks offering both frontend and backend programming capabilities.

#### However, Here Lies the Problem…

The cycle has yet to come full circle. The emphasis has shifted. In the past, frontend applications were secondary to backend applications. The backend would generate HTML for the frontend, and over time, with the advent of browser scripts, this trend started to reverse. In many contemporary applications, the focus is now on the frontend. This shift depends on the type of project and the complexity of its components. Sometimes, we deal with a simple interface and a complex API, while other times, both are equally complex or simple. However, the problem that frameworks like Next.js solve is when we have a complex interface and a simple API, which can be compared to a data repository. These frameworks allow us to quickly program a complex frontend application and the necessary backend application. In such cases, it's advantageous to have a developer who can handle both sides, saving a lot of time and money by avoiding the need to create a separate API. In this scenario, a frontend developer is the obvious choice. However, with specialization towards the frontend, backend skills are often neglected, resulting in a backend that becomes unmanageable, with complexity growing and resembling spaghetti code, while the frontend code remains clean and consistent.

#### Why Does This Happen?

Frontend applications have a different nature compared to backend applications. The architecture is inherited from available frameworks and libraries, implicitly guiding the developer. Although this approach can backfire in the long run and become unmanageable, it's better than having no architecture at all, especially when we are unsure how to design one sensibly. This is the situation we face on the backend side with Next.js or Remix. These frameworks offer us an entry point to the backend, automating communication via AJAX so we don't have to manually integrate it. However, they don't provide us with a structure within which we can operate.

#### Let's Introduce Some Architecture!

Since the framework doesn't enforce it, we should ensure we have an architecture that structures our code. Our basis for consideration will be GRASP, or General Responsibility Assignment Software Patterns. It contains a set of 9 basic principles and responsibilities that we should apply in our code. For our purposes, let's select 4 responsibilities:

- **Information Expert** - the object with all the information needed to perform a certain task.
- **Controller** - the object that controls the flow of work.
- **Pure Fabrication** - the object that performs tasks that are not part of the domain.
- **Creator** - the object that creates other objects.

These 4 types of objects outline an obvious division that we can try to implement in our application:

- **Domain part**, which will represent the concepts of our client's business. We can also think of it as concepts that could exist without the IT system, e.g., instead of a product catalog, we have a flyer sent by mail to the customer's mailbox.
- **Technical part**, which is required to handle the domain part and exists solely for the IT system's needs.


First, we should identify the responsibilities above in our code and check if they are mixed together. This way, we will separate the technical part from the business logic, laying the foundation for further dividing our architecture into layers.


#### What Can Be Done?

The lack of enforced architecture often leads to a haphazard structure, resulting in code that is hard to maintain, untested, and challenging to develop. In the following article, we will look at what to pay attention to when creating an architecture: not to invent our own architectures from known templates, but to adapt them to our real needs and make the first architectural decisions.

large_blog_cover_high.jpg

medium_blog_cover_high.jpg

small_blog_cover_high.jpg

thumbnail_blog_cover_high.jpg

blog_cover_high.jpg

Backend Architecture on Frontend Part 1

In the previous article, we outlined the problem of lacking enforced architecture in frontend frameworks that also allow frontend developers to write backend code. In this article, we will look at what to pay attention to in order to start structuring your code at a low cost. However, before we delve into application architecture, it's worth making a few architectural decisions to shape our application.

#### Separating Queries from Commands

A common issue that causes code clutter and reduces maintainability is overly large objects. By "overly large," I mean objects that hold too much information simultaneously. The reason objects hold too much data is often due to read operations. Some data is needed to make decisions, while the rest is just to display to the user. It's beneficial to separate these two situations. Even if we store the data in a single database table, we should create two independent models: one for reading and another one for making decisions and updating.

To achieve this, we can apply the CQS (Command Query Separation) or CQRS (Command Query Responsibility Segregation) patterns in our code. They both assume the separation of reading (Query) from writing (Command). Queries never modify data, and Commands do not return data. The difference lies in implementation: in CQS, we might have a single service with Command and Query methods, while in CQRS, we have entirely separate services or even microservices for both types.

In the provided example, it might seem that not separating queries from commands generates less code. However, this is a very superficial conclusion. By using CQS/CQRS, we slim down our write models and can create more flexible queries for our read models. Adding additional read data does not affect our commands and tests, making them more resilient to changes. We also avoid multiple places for reading or writing the same model, making the code more reusable.
![blog-code 1.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_code_1_a4980c7691.jpg)

_Code: Examples of CQS and CQRS. The repositories used are examples of Pure Fabrication from GRASP. They can also call Creator underneath, which instantiates returned objects._


#### Rich vs. Anemic Entities

Another important aspect is the approach to our data entities. Typically, there are two types:
- **Rich Entities** - contain both data and behaviors operating on that data. They do not have getters and setters. Behavior methods change the object's state and enforce business rules in one place. Rich entities are an excellent example of Information Expert.
- **Anemic Entities** - contain only data, along with getters and setters. Business logic is implemented in separate services that operate on these entities, change their state, and enforce business rules.

Existing backend frameworks often suggest the second approach, but using rich entities is a much better solution. Key behaviors, rules, and data are represented in one place, preventing entity bloat. In both cases, however, we should remember that entities should be as small as possible, containing only the data needed for specific decisions. A much better place for using anemic entities is DTOs (Data Transfer Objects), used for data transport between layers and modules, or objects for creating views (e.g., response from a Controller).

![blog-code 2.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_code_2_2fea35e4d6.jpg)

_Code: Example of an anemic entity with a service handling it._

![blog-code 3.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_code_3_e81ee58004.jpg)
_Code: Example of a rich entity with its use in a specific use case. AddOrderItemUseCase is an example of a Controller from GRASP._

#### Modules vs. Layers

Two techniques that help us divide our code into more manageable parts are modularization and layer division. An application module is more extensive and can be treated as a separate subprogram with its own application architecture (i.e., one that divides responsibilities according to layers) and its own API. Modularization is an individual, more significant topic, so we'll focus only on application architecture in this article. The following article will consider the two most popular application architectures: three-layer architecture and clean architecture. Regardless of the architecture type, it's important to remember that layers always have a unidirectional relationship, meaning the lower layer knows about the higher layer, but the higher does not know about the lower. This is crucial to avoid creating spaghetti code. Remember, the difference between a mere directory structure and layers primarily lies in respecting their relationship boundaries.

#### Did I Define the Layer Boundaries Correctly?

A good question is whether the boundaries I defined between layers are indeed boundaries. To this end, it's worth conducting a thought experiment. If I remove the lower layer and instead insert tests that call my layer, will the code of my layer still perform its tasks? If not, and there are missing dependencies to the lower layer, it means the boundary between layers is not respected, and our code will slowly degrade. Another more technical method is to use a simple architectural test that checks if there are imports to the lower layer's directory within the files of a given directory.

#### Application Architecture

Identifying and assigning responsibilities to objects in our code and determining the approach to our read and write entities is the basis for adequately dividing it into layers. In the next part, we will present the types of application architecture and how they interact with the concepts presented in this article. We will also identify the essential responsibilities of GRASP within the individual layers of known architectures.


large_blog-duraj part 2_cover_high.jpg

medium_blog-duraj part 2_cover_high.jpg

small_blog-duraj part 2_cover_high.jpg

thumbnail_blog-duraj part 2_cover_high.jpg

blog-duraj part 2_cover_high.jpg

Backend Architecture on Frontend Part 2

In the previous article, we encouraged making certain architectural decisions that can influence the final shape of application architecture. In this article, we will look at popular application architectures and how to create your own solution based on them. We will also identify the GRASP responsibilities presented in the first article within the layers of well-known application architectures.

#### Multilayer Architecture

The most popular multilayer architecture is the three-layer architecture, and its most notable representative is the MVC architecture or Model-View-Controller. MVC divides our application into three layers according to three responsibilities. Let's map them to responsibilities according to GRASP.
![blog-grafika 2.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_2_ead357b314.jpg)

- **Controller**: Responsible for coordinating workflow, serving as the Controller in GRASP. It may also be responsible for creating instances of Model objects, thus fulfilling the Creator function, and communicating with the database, which will be realized as Pure Fabrication. In MVC, the Controller is the entry point to the application.
- **Model**: This layer contains data and behaviors that can represent business logic, making it an Information Expert equivalent. The Model can be either a rich or anemic entity. Often, database communication is handled within this layer (instead of at the Controller level). However, it may be a good idea to separate persistence from logic, even if our Model also serves as a database model.
- **View**: Maps data from the model to views returned to the user, performed by Pure Fabrication services. Such a view can be a simple JSON object or a rich HTML view.

A simple multilayer architecture is beneficial in simple APIs where the backend application primarily serves to store and read data. In most cases, we will deal with such applications in simple API implementations within frontend frameworks.

Within the multilayer architecture, we have the flexibility to choose layers. We can often limit ourselves to just two layers, for example, a coordination layer and a business logic layer, where the view is part of the Controller's response. This especially makes sense if we use the previously mentioned CQRS or CQS. The Controller calls operations on the model, which returns nothing, and then queries the repository responsible solely for reading in the View layer.


#### Clean Architecture

Clean architecture is much more complex than multilayer architecture. It also has layers, although they are directed inward, unlike the layers in MVC. The workflow is from the outer layer to the inner and then from the inside out. At the same time, the direction of dependencies remains unidirectional inward through the proper use of programming interfaces (those interested should read about the "dependency inversion principle").

![blog-grafika 1.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_1_350cca9c14.jpg)

Clean architecture has three layers:
- **Infrastructure Layer**: Often divided into two layers - ports and adapters, where ports are objects allowing entry into the application (e.g., HTTP controller), and adapters are entries to other devices (e.g., databases or other external services). The infrastructure layer is the outer layer, the only one interacting with the outside world, including dependent libraries or frameworks. This layer handles data reading (Query from CQS/CQRS) and writing. Objects in this layer fulfill Pure Fabrication and Creator responsibilities from GRASP.
- **Application Layer**: A higher layer independent of the infrastructure layer. Its task is to coordinate specific use cases. It is independent of the framework and external libraries. Use cases (represented as services performing one specific task) fulfil the Controller's responsibility from GRASP. Typically, their role is to delegate tasks, fetch and save data to the lower layer and execute business logic code to the higher layer.
- **Domain Layer**: This layer contains domain services and entities (usually rich) that perform operations on data and change the application's state. This layer is independent of persistence, which is delegated by the application layer to the infrastructure. Domain layer objects fulfil the Information Expert role from GRASP.

Clean architecture can effectively separate client business-related aspects from technical details. However, it is quite complex, making it worth using for more complex systems where we will benefit from it.

As can be seen, this architecture involves two models - a domain entity in the domain layer and a database entity in the infrastructure layer. Therefore, layers must map their models when transitioning to a higher layer or receiving data in the lower layer, increasing implementation overhead. This problem does not occur in multilayer architecture, where models are defined in the higher layer to which the lower layer has access.


**What to Choose?**

The appropriate architecture choice depends on the project's complexity and business requirements. Multilayer architecture is simpler to implement, while clean architecture provides better separation of responsibilities and is more scalable. Remember, architecture is like clothing - each project needs an individual approach to feel comfortable and work effectively.

Depending on our project's needs and complexity, we can adapt it. Clean architecture and multilayer (and others not mentioned here) are known ways to handle common issues such as maintainability, testability, and scalability. There is nothing to prevent us from modifying existing solutions and adapting them to our needs. A good idea is to identify the responsibilities defined by GRASP in our code and architecture. This way, deciding how to structure the code will be easier. Additionally, it is worth familiarizing yourself with other GRASP principles that can help us make decisions in grouping and separating responsibilities or prepare us for change.

Developer’s Tool Set part 1: Senior Full-Stack Developer

Łukasz

Testing Aggregates

Łukasz

TypeScript - A Boon for Developers or an Art for Art's Sake?

Łukasz

Backend Architecture on Frontend Part 1

Łukasz

Backend Architecture on Frontend Part 2

Łukasz

Backend Architecture on Frontend Part 3

Łukasz

GET IN TOUCH