Forem: Antonio Basile

How I Rediscovered Enthusiasm in the World of Technology After the Rise of LLMs

Antonio Basile — Sun, 29 Mar 2026 07:47:48 +0000

When LLMs entered my daily life as a software engineer, my feeling was that you could talk about anything with them, and it seemed like there was a real human being on the other side.

Back in 2022, users would access ChatGPT to ask it anything — including software coding problems (sometimes it worked, sometimes it didn't, sometimes you had to tweak things a little). Now, in 2026, LLMs like Claude Opus 4.5 make you realize that the code they write is better than that of a senior software engineer.

There was a moment in my life when I said — and I think each of us has thought this at least once — "Will I be replaced by a machine?", "Will I stop writing code?", "Will I keep working in this field?". All these questions were keeping me up at night. I was struggling, and I wasn't even productive at work anymore.

Until I read a book by Bulgakov — The Master and Margarita. The story is about the Devil visiting Moscow in the 1920s under the Stalinist regime, causing all sorts of chaos and literally driving some prominent figures to the asylum. As you may have noticed, it has nothing to do with the world of technology. So why did it "save" me? Why did I feel the urge to say "thank you" to it?

It was Bulgakov's imagination and creativity — the way he uses them to describe a communist Moscow and criticize the representatives of the USSR — that made me realize that I too can use my creativity to do something, both at work and outside of it. That I am not a monkey writing the same function 100 times in different contexts. That I am a designer of scalable and maintainable software architectures. And that my value always comes from the knowledge I use to create working software.

What I can say to all my colleagues who have found themselves in the same situation is this: the world changes, so embrace change, and always let enthusiasm guide you in designing software — and try to see the glass as half full.

I wish everyone a positive 2026, under the sign of AI.

7 Tips for Better Relationships with Colleagues

Antonio Basile — Tue, 31 Dec 2024 07:35:37 +0000

Hi everybody 😄
I have read many books in these days, including a book about the personal growth. The book is called "How to win Friends & Influence people", written by Dale Carnegie in 1936. Dale explains how to build positive relationships with people. Every chapter is a principle with many examples about how to approach people that we know and don't know, including friends, parents and colleagues.
I think that some of these principles are useful, in our devs world, so I'll list some for you.

Don't criticize

Don't criticize anyone, as it hurts the people's pride and creates the resentment.
Criticism does not foster better relationships or healthy communication, instead, it provokes resentment.
Resentment discourages collegues without contributing in any way to improving the situation.

Offering sincere and honest compliments

Many people want to feel important. how can you make that happen? You have to offer sincere and honest compliments.
If we see a junior collegue works on important feature and doing an excellent job, that's great! We should make compliments him on the work he's done. (and why doesn't he pay a 🍺? 😄).
Be careful the compliments must to be sincere and we shouldn't fall into flattery.

Helping the colleague

Is our colleague in difficulty? Help him. A day he'll be the one to help us.

Smile!

Smile!!! The people like those who smile! You send the message "I like you, nice to see you".
Ps. If you smile, your mood improves.

Avoiding the discussions

Nine times out of ten, a debate ends with both sides convinced they are right. How can you always win a discussion? Avoid it

Avoid telling people 'you are wrong!' and admit your own mistakes

Telling someone 'you are wrong' is like saying, 'I am smarter than you!' How can you avoid this? Simple: start your sentence with phrases like, 'I see things differently, but I could be wrong,' or 'I might be wrong, perhaps...' or 'Maybe I’m mistaken, but...' By doing this, you acknowledge that your reasoning might be flawed, allowing the other person to admit that they, too, could be mistaken.

Correct your colleague's mistakes with tact

How many times have we encountered functions written by a junior colleague that are 100 lines long? Or cases where they didn’t perform all the necessary tests? What should you do in such situations?

Well, don’t say they didn’t do a good job—that won’t help the team’s wellbeing. Instead, acknowledge their effort and mention that, at their age, you made worse mistakes (nobody is born knowing everything). This approach will point out the error while encouraging your colleague to correct it in a more constructive way.

What do you think on these tips?
I hope this post has been helpful. If you have any other advice to share, please leave a comment, it could be useful 😄!

How to create Angular 17 project with Nx

Antonio Basile — Mon, 22 Jan 2024 09:31:39 +0000

Summary

Introduction
What is DDD?
What is NX?
A little bit of NX commands
- create project
- create library
- create component
Rick and morty project
- Structure Folder
- Solid Architecture
- App project
- Shell library
- Feature library
- Domain library
- Util library
Conclusion

Introduction

I've always wondered, after various Angular projects, how to create organized, maintainable, and testable projects. While Angular documentation provides guidelines on writing components, directives, and pipes, sometimes it's not enough. For enterprise-level Angular projects, it falls short. I started searching on GitHub for various projects and studying several articles on Angular until someone recommended reading articles from angular architects.

In particular, the book "Microfrontend and Moduliths with Angular" can be downloaded here. In one of these chapters, it explains how to structure Angular projects with Domain-Driven Design, supported by NX.

What is DDD?

Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. The name comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns.
One of the DDD disciplines I have utilized is strategic design. The goal of strategic design is to identify so-called sub-domains that don’t need to know much about each other.
Now, I won't delve further into the topic, but for those interested, I recommend reading the book Domain-Driven Design: Tackling Complexity in the Heart of Software.

What is NX?

NX is a tool that enables deploying, building, and testing scalable JavaScript applications. It can be used to create frontend/backend projects that communicate with each other, or to build microservices applications using Node.js, or a suite of frontend projects utilizing a library of components among themselves. It's a powerful tool with a wide range of capabilities! In this case, I used it to create Domain-Driven Design projects.

A little bit of NX commands

Here are some commands that I've used and that might be useful for you to create a monorepo project with NX.

Create project

npx create-nx-workspace@latest <monorepo-project> --preset=angular-monorepo

Create library

nx g @nx/angular:library <library-name> --tags=ui

Create component

nx g @nx/angular:component <component-name> --directory=path/to/library

Create an Angular component with the "directory" argument that allows specifying where to create the component.

Rick and morty project

Who likes Rick and Morty? Some love it, and some are not telling the truth 😄. I've created an Angular project with NX where you can see how I've structured the project. The application is not complete yet, but it demonstrates the structure an enterprise application should have. In this repository, you'll find the project. I used The Rick and Morty API to retrieve all the data about Rick and Morty characters.

Structure Folder

From the image below, you can see that there is a project named rick-and-morty-monorepo in the apps folder, and in the libs folder, I have divided them by subdomains, following the principles of Domain-Driven Design with strategic design.

the subdomains I identified are:

character
location
episode

In each subdomain, the following libraries have been created:

api: Provides functionalities exposed to other domains (service classes, store).
ui: Library where dumb components are located.
util: Utility library containing helper functions or models available to ui/util/features libraries.
domain: Implements the entire business logic, including HTTP services and data management. For data management, I used @ngrx/signals.
features: Implements use cases using smart components.
shell: Provides an entry point for the domain. It contains all the routes to be assigned to the rick-and-morty-monorepo application.

Each subdomain can utilize shared libraries, and for this reason, I have created three libraries that can be used by all the other libraries. These are:

shared-ui: Shareable components across all subdomains.
mock: Mock classes, objects that can be used in tests.
util: Helper functions.

Solid Architecture

This structuring of libraries allows for the separation of responsibilities between classes/components and brings a certain order and cleanliness to the project. To maintain this robust architecture, it is necessary to limit the interaction between libraries. Rules can be established through ESLint:

       "@nx/enforce-module-boundaries": [
          "error",
          {

            "allow": [],
            "depConstraints": [
              {
                "sourceTag": "scope:app",
                "onlyDependOnLibsWithTags": ["type:shell"]
              },
              {
                "sourceTag": "type:api",
                "onlyDependOnLibsWithTags": ["type:domain"]
              },
              {
                "sourceTag": "type:shell",
                "onlyDependOnLibsWithTags": ["type:feature", "type:util"]
              },
              {
                "sourceTag": "type:feature",
                "onlyDependOnLibsWithTags": ["type:domain", "type:util", "type:ui", "type:mock"]
              },
              {
                "sourceTag": "type:ui",
                "onlyDependOnLibsWithTags": ["type:util", "type:mock"]
              },
              {
                "sourceTag": "type:domain",
                "onlyDependOnLibsWithTags": ["type:util", "type:mock"]
              },
              {
                "sourceTag": "type:mock",
                "onlyDependOnLibsWithTags": ["type:util"]
              },
              {
                "sourceTag": "type:shared",
                "onlyDependOnLibsWithTags": []
              }
            ]
          }
        ],

These rules define the interaction scope between different libraries:

scope:app: Applications can only communicate with shell and shared-ui libraries.
type:domain: Domain libraries can use util and mock libraries for testing.
type:shell: Shell libraries can use features and util libraries.
type:feature: Feature libraries can use domain, util, ui, shared-ui, and mock libraries.
type:ui: UI libraries can use util and mock libraries.
type:domain: Domain libraries can use util and mock libraries.
type:mock: Mock libraries can use the util library.

App project

In the main App project, my focus was primarily on creating basic templates. In this instance, I had to develop only one base template, featuring a drawer and footer component with the overall management of HTTP API calls.

Within the main template, <router-outlet></router-outler> is present, enabling the insertion of content from the shells.

export const TEMPLATE_ROUTES: Routes = [
  {
    path: '',
    component: RickAndMortyTemplateComponent,
    children: [
      {
        path: '',
        loadChildren: () => import('@rick-and-morty-monorepo/characters/shell').then(m => m.routes)
      },
      {
        path: 'episodes',
        loadChildren: () => import('@rick-and-morty-monorepo/episodes-shell').then(m => m.EPISODES_ROUTES)
      },
      {
        path: 'locations',
        loadChildren: () => import('@rick-and-morty-monorepo/locations-shell').then(m => m.LOCATION_ROUTES)
      }
    ]
  }
]

As you can see, the template, based on the path, will accept three shell entry points: characters, episodes, and location.

The shell library

The shell library contains nothing but the routes to the features within that domain.

import { Routes } from '@angular/router';

export const routes: Routes = [
    {
        path: '',
        loadComponent: () =>
            import('./pages/characters-page/characters-page.component').then(
                (c) => c.CharactersPageComponent
            ),
    },
];

Of course, in this case, I only had one feature. However, in a shell, I can have many features.

Features Library

Here We find the pages

For these libraries, I've opted to use the container-presentational pattern. In this pattern, the container component is responsible for fetching information through the domain library and passing the result to the dumb component. The page components, on the other hand, handle the skeleton of the page.

//card-list-container.component.ts
@Component({
    selector: 'rick-and-morty-monorepo-card-list-container',
    standalone: true,
    imports: [CardListComponent, CommonModule],
    providers: [],
    templateUrl: './card-list-container.component.html',
    styleUrl: './card-list-container.component.scss',
    changeDetection: ChangeDetectionStrategy.OnPush,
})
export class CardListContainerComponent implements OnInit {
    readonly store = inject(CharacterStore);

    ngOnInit(): void {
        this.store.charactersRequest({});
    }

    changePage(page: number) {
        this.store.charactersRequest({ page: page });
    }
}

<!--card-list-container.component.html-->
<app-card-list
    [characters]="store.characters()"
    [totalPages]="store.pages()"
    (pageSelected)="changePage($event)"
></app-card-list>

<!--characters-page.component.html-->
<div class="p-3">
    <rick-and-morty-monorepo-card-list-container></rick-and-morty-monorepo-card-list-container>
</div>

Domain library

In the domain library, you can find services that make HTTP calls and a store for data management. I've delved into @ngrx/signals for data management, and I must say it's quite impressive!

Util library

In the Util libraries, there are models that can be utilized by both the domain and container/presentational components.

Conclusion

Strategic Design is a proven method for breaking down an application into autonomous domains. NX provides a structured way to implement these domains with different libraries grouped by domains. Restrictions enforced through the extension of eslint's enforce-module-boundaries help limit access to other domains and reduce dependencies.

These access restrictions contribute to ensuring easily maintainable systems with minimal impact on other parts of the system

NextAuth.js: create a custom OAuth provider

Antonio Basile — Fri, 18 Aug 2023 10:39:01 +0000

Hello World! In this post I going to explain how to create in NextAuth.js a Custom provider. Auth provider in NextAuth.js are OAuth definition that allow yours users to sign in with their favorite existing logins.

NextAuth.js contains several built-in providers where it just needs to have as parameter the client id and the client secret (Facebook, Google etc.)

Prerequisites

For those unfamiliar with the services, I reccomend reading the following links:

Let's start!

1. Create [...nextauth].ts

In pages at the path api/auth create the [...nextauth].tsx file

2. Create Authentication Provider

Here a custom provider has been created for authorization for ClickUp, a project management tool:



const clickUpProvider: OAuthConfig<any> = {
  id: 'clickup',
  name: 'clickUp Report',
  version: '2.0',
  type: 'oauth',
  authorization: 'https://app.clickup.com/api',
  token: 'https://api.clickup.com/api/v2/oauth/token'
  userinfo: 'https://api.clickup.com/api/v2/user',
  clientId: process.env.CLIENT_ID,
  clientSecret: process.env.CLIENT_SECRET,
  checks: ['state'],
  profile: (profile: any) => {
    console.log('profile', profile)
    return {
      id: profile.user.id.toString(),
      name: profile.user.username,
      email: profile.user.email
    }
  },
}

Now let's see the fields:

id: identication provider
name: project name
authorization: nextAuth.js will use it to redirect to the provider's login page
token: nextAuth.js will use it to get the token
userInfo: nextAuth.js will use it to get the user profile
clientId and clientSecret: keys generated from clickUp provider. I reccomend to insert them in .env files
callback: set the profile info (default values are id, name, email and picture)

3. Insert the custom provider in AuthOptions

After the provider object is created, you insert it into the "providers" array of authOptions.



export const authOptions: AuthOptions = {
  providers: [
    clickUpProvider,
  ],
...
}

export default NextAuth(authOptions)

I recommend to read the doc for more info: https://next-auth.js.org/configuration/providers/oauth#using-a-custom-provider