DEV Community: Mateus Malaquias

Quarkus Testing: @QuarkusTest vs @QuarkusIntegrationTest

Mateus Malaquias — Mon, 15 Dec 2025 12:56:27 +0000

TL;DR

Here is the cheat sheet:

Feature	@QuarkusTest	@QuarkusIntegrationTest
Process	Same process (Shared JVM)	External process (Separate JVM/Native)
@Inject Beans	✅ Yes (Full Access)	❌ No (Black Box)
Mocking	✅ Yes (`@InjectMock`)	❌ No (Network only)
Artifact	Run against compiled classes	Run against `.jar`, Docker or Native Binary
Speed	Faster (Dev Loop)	Slower (Builds artifact first)

Use @QuarkusTest for 90% of your tests (logic, service layer, mocking).
Use @QuarkusIntegrationTest to verify the final artifact (especially Native Image builds).

The Confusion

We have all been there. You write a beautiful test using @QuarkusTest. You inject your repository, maybe mock an external service, and assert that your Service returns the correct DTO. Green lights everywhere.

Then, you decide to be a "good citizen" and ensure your app works as a native binary. You copy-paste the test class, rename it to MyResourceIT, and swap the annotation to @QuarkusIntegrationTest.

Boom. Exception.

// This throws an error in @QuarkusIntegrationTest
@Inject
MyRepository repository;

Suddenly, your repository is null, or the test won't even start. You stare at the screen, wondering why Quarkus hates you.

The problem isn't Quarkus. The problem is that despite looking similar, these two annotations work in completely different dimensions.

Under the Hood: The Process Boundary

The main difference—and the only one you really need to care about—is the Process Boundary.

1. @QuarkusTest (White-Box)

When you run this, Quarkus boots up inside the same process as your test.

Think of it like being inside the house. You are in the living room (the Test), and the application is in the kitchen.

You can walk into the kitchen and change the ingredients (Mocking).
You can grab food directly from the fridge (@Inject Beans).
Even when you use RestAssured to call an endpoint, the application is technically making a request to itself. It sounds weird, but it's legal.

2. @QuarkusIntegrationTest (Black-Box)

This is where things change. This annotation tells Quarkus: "Build the artifact (Jar or Native), spin it up in a separate process, and let me talk to it.".

Now, you are locked out of the house. You are standing on the sidewalk.

You cannot walk into the kitchen to mock things.
You cannot reach into the fridge (@Inject is impossible because the beans are in a different JVM process!).
You can only shout through the window (HTTP Requests via RestAssured).

This runs against the packaged form of the app. If you are testing a Native Image, the test runner starts the binary executable. You can't inject a Java Bean into a compiled binary running in a separate shell context.

When to use which?

Prefer `@QuarkusTest` when:

You are doing TDD or the daily dev loop.
You need to mock external dependencies (like a Payment Gateway or specific DB state).
You need to verify internal logic that isn't exposed via the API.
You want speed.

Prefer `@QuarkusIntegrationTest` when:

You need to verify the final build artifact.
Native Mode: This is crucial. Reflection behaves differently in Native images. Things that work in JVM might crash in Native. This test catches those issues.
You want to test the application in a containerized environment (Docker/Podman).
You want a true "Black Box" test where you strictly test public API contracts.

Wrapping up

Don't try to force @Inject into your Integration Tests. It won't work. If you find yourself needing to inspect the database state during an Integration Test, you have two options:

Use a separate library to connect to the DB directly (bypassing the app's internal beans).
Expose a specific "test-only" endpoint in your app to retrieve the data (but please, don't do this in production).

Resources

Quarkus Guides: Testing

[Quick Fix] Hibernate: object references an unsaved transient instance

Mateus Malaquias — Mon, 08 Dec 2025 17:00:35 +0000

TL;DR

You are likely trying to save an Entity that refers to another object that isn't saved in the database yet.

The Fix: just add cascade = CascadeType.ALL to the relationship annotation.

// In your Parent Entity (e.g. Order.java)
@OneToMany(mappedBy = "order", cascade = CascadeType.ALL) // <--- Add this
private List<OrderItem> items = new ArrayList<>();

The Scenario

Here is the thing. You have an Order and a list of OrderItems. Classic relationship.

You create the Order, create an OrderItem, add the item to the list, and try to save the Order parent:

Order order = new Order();
order.setCustomer("John Doe");

// Creating a new child entity
OrderItem item = new OrderItem();
item.setProduct("MacBook Pro");
item.setOrder(order);

order.getItems().add(item);

// Trying to save
orderRepository.save(order);

Boom. Exception.

The Error

The logs will scream this at you:

org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing

Why this happens

Basically, Hibernate is confused.

You have the OrderItem in memory (Java heap), but it doesn't exist in the DB yet (no ID). When you call .save(order), Hibernate looks at the child object and freaks out because it doesn't know if it should save that child automatically or not.

It stops the process to prevent data corruption. Ideally, it expects you to save the child manually first, but nobody wants to do that for every single item.

The Solution

We gotta tell JPA to just propagate the save operation.

Go to your Parent entity and force the cascade.

Before (The Error):

@Entity
public class Order {
    // ...
    @OneToMany(mappedBy = "order")
    private List<OrderItem> items = new ArrayList<>();
}

After (The Fix):

@Entity
public class Order {
    // ...
    // The Fix: Add CascadeType.ALL
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List<OrderItem> items = new ArrayList<>();
}

Why this works

Adding CascadeType.ALL tells Hibernate: "If i save the Parent, save the Children too. If i delete the Parent, delete the Children."

Simple as that. Now when you run repository.save(order), Hibernate handles the new OrderItem insert automatically.

Note: If you are on legacy XML configs (I hope not), use cascade="all".

How JWT, JWS, and JWE Secure Your Data?

Mateus Malaquias — Fri, 14 Feb 2025 14:18:38 +0000

TL;DR

JWT (JSON Web Token):

A compact format for securely transmitting information between parties.

JWS (JSON Web Signature):

A signed JWT ensures the authenticity and data integrity, however, the data is public and not have encryption. If you need to keep the data private, use JWE.

JWE (JSON Web Encryption):

It is an encrypted JWT, ensuring data confidentiality, however, does not ensure authenticity. Use when you need to keep the data private.

Key differences

Feature	JWT	JWS	JWE
Purpose	Authentication and information exchange	Signing data for integrity	Encrypting data for confidentiality
Payload	Contains claims	Signs an external payload	Encrypted payload
Structure	Header, Payload, Signature	Header, Signature	Header, Encrypted Key, IV, Ciphertext, Auth Tag
Visibility	Claims are visible	Payload is visible	Payload is encrypted

Are you covered?

Secure tokens are a fundamental component of modern application, playing an important role in both authentication and authorization operations. These tokens serve as digital passports, allowing users to access sensitive systems and data.

However, if they are mishandled because to incorrect storage, poor creation methods, or insufficient validation. They can lead to a slew of security vulnerabilities.

Attackers may exploit vulnerabilities like as Cross-Site Scripting (XSS) or Cross-Site Request Forgery (CSRF), which can result in data breaches, identity theft, and unauthorised access to your systems. In other words, the integrity and secrecy of these tokens have a direct impact on your overall security posture.

In this article, I will discuss the three important standards: JWT, JWS, and JWE. While they are connected, they serve distinct roles in safeguarding authentication and data transmission.

Understanding their differences can assist you in determining the best approach for your application's security requirements.

JWT (JSON Web Token)

A JWT is essentially a way to safely transmit information between parties as a JSON object. It is compact, URL-safe, and designed to be used in web contexts.

A typical JWT consists of three parts:

Header: Specifies the token type (JWT) and signing algorithm (e.g., HMAC SHA256).
Payload: Contains the claims (user data).
Signature: Ensures the token's integrity by verifying the header and payload against the secret key.

Common use cases

Authentication (e.g., OAuth 2.0, OpenID Connect)
API authorization
Information exchange between services

Why use JWT?

Stateless: The server does not need to store session information.
Portable: Easily passed around via URL, POST parameters, or HTTP headers.
Versatile: Can be used for authentication, information exchange, and more.

JWS (JSON Web Signature)

JWS is a specification for signing arbitrary data to ensure its integrity and authenticity. It is always signed but does not inherently carry a payload; rather, it signs a payload provided separately.

A JWS consists of:

Header – Includes the signing algorithm (e.g., RS256).
Payload – The actual data, readable by anyone.
Signature – Created using a private key to validate authenticity.

The JWS process involves:

Signing the Data: The header and payload are signed using a specified algorithm (e.g., HMAC, RSA, or ECDSA).
Verification: The recipient can verify the signature with the corresponding secret or public key.

Common use cases

Token integrity (e.g., in OAuth 2.0 and OpenID Connect) to ensure they haven’t been altered.
API authorization.
Inter-Service messaging
Document signing
Secure data exchange when combine with encryption (JWE)

When to use?

Data Integrity: That the token’s contents haven’t been modified.
Authenticity: That the token comes from a trusted source.

JWE

Takes things one step further by not only signing the token but also encrypting it. This means that even if someone intercepts the token, they won’t be able to read its contents without the proper decryption key.

A JWE consists of:

Header – Defines the encryption algorithm (e.g., RSA-OAEP, A128GCM).
Encrypted Key – Encrypts the symmetric key used for content encryption.
Initialization Vector – Ensures randomness in encryption.
Ciphertext – The encrypted payload.
Authentication Tag – Ensures data integrity.

Common use cases

Data confidentiality
Secure API communication
Nested token security use JWE alongside JWS for layered security (e.g., sign then encrypt a token)
Inter-Service data protection
Sensitive document protection

When to use?

Confidentiality is Required: You want to keep the token’s payload hidden from unauthorized parties.
Sensitive Data: The token contains sensitive user data or permissions that should not be exposed.

Benefits of combining JWS and JWE

Signing the data with JWS, can ensure that any modifications or tampering are immediately detectable, thereby verifying the authenticity and integrity of the information.

Following this, encrypting the signed payload with JWE protects the contents from unauthorized access, ensuring that sensitive information remains confidential even if intercepted.

This dual approach where the signature confirms the origin and integrity of the message and the encryption safeguards its privacy provides defense in depth, making it significantly more challenging for attackers to compromise the security of your data.

Best Practices

Validate Tokens Rigorously: Always check the token’s signature and expiration date before trusting its claims.
Use Strong Algorithms: Avoid deprecated algorithms. Stick to modern, secure options like RS256 for signing and AES for encryption.
Keep Secrets Safe: Securely store keys and secrets used in signing or encryption. Compromised keys can lead to security breaches.
Implement Token Revocation: Consider strategies for revoking tokens if a breach is detected.
Least Privilege Principle: Only include the necessary information in your token and limit permissions.
Regularly Update Dependencies: Keep libraries and dependencies up to date to mitigate vulnerabilities.

Resources

Tilde or Caret in package.json - Stop copying and start choosing

Mateus Malaquias — Mon, 26 Feb 2024 18:14:23 +0000

TL;DR

Syntax	Versions	Dependency	Impacts
tilde (~)	1.6.X	~1.6.7	only bug fix can be upgrade
caret(^)	1.X.X	^1.6.7	backwards compatible, deprecated and operational functionally, refactors, bug fix

Tilde (~): Use it for libraries where stability is crucial. Example: express framework.
Caret (^): Use it for libraries where you want to benefit from new features and bug fixes. Example: Jest, Prettier.

SEMVER

SemVer is a convention, not a law. What happens when each number changes:

Major: Something big has changed, and previous versions maybe will not work.
Minor: New features or improvements, things should still work mostly the same.
Patch: Solves small issues without changing the structure.

Tilde (~)

Only allows patch updates.
Useful for getting the latest bug fixes and security patches while maintaining stability.
Use it for libraries where stability is crucial. Example: express framework.

Caret (^)

Allow both minor and patch updates.
Useful for staying up-to-date with new features and improvements, however, we have a risk of potentially breaking changes.
Use it for libraries where you want to benefit from new features and bug fixes. Example: Jest, Prettier.

How to update my dependencies?

npm outdated

This command will scan your code for outdated packages compare with the latest version in the npm registry and no extra downloads needed because it is built into npm.

npm update

This command will update the dependencies in package.json and package-lock.json using the "wanted" version.

Resources

Semantic Versioning 2.0.0
Node.js - Peer Dependencies
Node.js - An introduction to the npm package manager
Thanks to masahiro miyagi @masamasa3 for making this photo available on Unsplash 🎁

How to solve error parsing HTTP request header in Spring Boot

Mateus Malaquias — Tue, 13 Feb 2024 11:44:02 +0000

TL;DR

Just add a line like below in your application.properties file:

server.max-http-header-size=64kb

This sets the limit header size to 64 kilobytes.

What are HTTP headers?

According to Mozilla an HTTP header is a field of an HTTP request or response that passes additional context and metadata about the request or response. For example, a request message can use headers to indicate its preferred media formats, while a response can use header to indicate the media format of the returned body.

Why Spring Boot limit the header size?

Well, large headers will consume more memory, they can slow down the request or worst crash our server. Limit them is a safety approach.

Under the hood Spring Boot is not a server, indeed Spring can embedded 3 distinct servers, Tomcat, Jetty or Undertow. However, the configuration for them will be the same.

The default header size are:

Tomcat = 8kb
Jetty = 8kb
Undertow = 1mb

To change the max size, follow the TL;DR example.

Be careful when increasing the size limit always analise your situation and try to understand why the header is too large (usually are auth token).

References

When I prefer use when then if-else in Kotlin

Mateus Malaquias — Mon, 05 Feb 2024 15:41:05 +0000

TL;DR

if-else for simple cases with only one conditions or to use early returns pattern.
when for more complex cases with multiple conditions and to have a cleaner code.

Ever feel lost in a maze of if-else statements, desperately trying to handle every input nuance? Fear not, fellow dev! Kotlin's when statement offers a sleek and powerful escape route.
Forget the Java switch cases or the endless else if that makes your code's readability horrible. when can simplify your logic, writing multiple conditions into a single and clear block.

Why `when` is better in my option?

Clean Code: allows you to write more concise and readable code, especially when you need to check multiple conditions.
Type Safe: runtime mistakes can be avoided by checking the expression against each case value.
Extensibility: can be easily extended to handle new cases.

Code example

fun renderRequests(userId: String) = renderComponent {
  val user = getUser(userId)
    when (user.role) {
      is ROLE.CHILD -> return
      is ROLE.UNCLE -> defaultRequestError()
      is ROLE.PARENT -> {
        buildRenderComponent(user)
      }
    }
}

Now compare with if-else:

fun renderRequests(userId: String) = renderComponent {
  val user = getUser(userId)
   if (user.role == ROLE.CHILD) {
    return
   } else if (user.role == ROLE.UNCLE) {
    defaultRequestError()
   } else if (user.role == ROLE.PARENT) {
    buildRenderComponent(user)
   }
}

When `if-else` is a better option?

When I want to use early returns pattern.

Writing functions or methods, early return means that the expected positive result is returned at the end of the function, and when conditions are not met, the rest of the code ends the execution by returning or throwing an exception.

Code example

fun sayMyName(name: String): String {
 if (!name || name.length < 0) {
    return;
  }
  return `Hello, ${name}`
}

References

Why I like to use Early Returns Pattern?

Mateus Malaquias — Fri, 07 Oct 2022 13:22:34 +0000

Thanks to Sarah Kilian @rojekilian for making this photo available freely on Unsplash 🎁

I want to start this article by saying that I didn't like to use early returns in the beginning, however, with time and paring with members of my team, I understood how this simple pattern is strong.

I learned bad habits in my first years as a programmer and, it's OK to develop new ones. Let's see an example from my daily life.

How fast a simple code can mess up everything?



async function getDeliveryType(prod: Product, user: Client) {
  if (prod.isValid()) {
    if (user.isValid()) {
      const address = await getClientAddress(user.id);
      if (address) {
        const fee = await calculateFee(user, address);
        if (fee > 0) {
          return 'delivery';
        } else {
          return 'online';
        }
      } else {
        throw new Error();
      }
    } else {
      throw new Error();
    }
  } else {
    throw new Error();
  }
}

The code above was a simple idea to get the delivery type, this is a perfect example to help us understand the power of applying early returns without messing up the code.

What can we observe in the code?

The code isn't linear, if we put more validations will be hard to understand all the conditions.
We need to navigate through the ifs to see the positive response.
It's confusing to read because of the struct created by if-else.
Besides, we get two anti-patterns: Else is considered smelly and Arrow anti-pattern.

What is an early return?

An approach to keep readability in functions and methods.

😂 Yeah, the answer is pretty simple.

When writing functions or methods, early return means that the expected positive result is returned at the end of the function, and when conditions are not met, the rest of the code ends the execution by returning or throwing an exception.



function sayMyName(name: string): string {

 if (!name || name.length < 0) {

    return;

  }

  return Hello, </span><span class="p">${</span><span class="nx">name</span><span class="p">}</span><span class="s2">

}

Refactoring the code to use the Early Returns Pattern

Like I said too many if-else can make it hard to follow the code. I like this approach because the indentation helps me to focus on understanding ”what this code does?” and not on “what's going on here?”

Let's refactor the example code.



async function getDeliveryType(prod: Product, user: Client) {

  if (!prod.isValid()) {

    throw new Error();

  }

if (!user.isValid()) {

    throw new Error();

  }

const address = await getClientAddress(user.id);

if (!address) {

    throw new Error();

  }

const fee = await calculateFee(user, address);

  if (fee > 0) {

    return "delivery";

  }

  return "online";

}

What can we observe now?

The code has one indentation level.
It’s easy and fast to read the code.
The positive result stays at the end of the function.
We can find our logic/business errors first, and in the log term will help us to avoid mistakes and bugs.
Now we have a fail-fast design pattern 🙂.
The function ends immediately on errors.
With this mindset, we implement a list of design patterns: Fail Fast, Guard Clause, Bouncer Pattern.

Conclusion

I recommend you to adopt as a style guideline, however, this is a subjective thing, so it's your decision whether to use it or not.

Lombok: Fixing SonarQube coverage problem

Mateus Malaquias — Wed, 13 Oct 2021 21:16:17 +0000

Photo by Scott Rodgerson on Unsplash

Here is a Portuguese version.

In my ongoing project, I have a CI/CD flow and one step is responsible to collect the code coverage and validate if I have the minimal value to proceed to another step.

However, even having 84% of code coverage, the SonarQube always returned 30% of the result in the step, because of that the deployment step was never executed.

I spent some time understanding that the problem was in the Lombok annotations, the SonarQube was computing the generated code.

The solution:

It's simple to resolve this issue. I created a file named lombok.config inside the folder java (/../src/main/java/lombok.config) with this:

config.stopBubbling = true
lombok.addLombokGeneratedAnnotation = true

What are these settings for?

The config.stopBubbling informs the Lombok that the folder where the file is the root and the Lombok don't need to search for more parent folders.

While lombok.addLombokGeneratedAnnotation put in every generated code by Lombok annotation, another one named @lombok.Generated. This annotation informs Jacoco to not collect coverage from those codes.

Done, problem solved!

Finishing...

If you liked this post, please be sure to like and share 😄

If you want to know what I'm doing out there or ask any questions, feel free to look for me on social networks like @malaquiasdev.

To read more of my posts, go to MalaquiasDEV | Life, the code and everything else.

Lombok: Corrigindo problema de cobertura de código no SonarQube

Mateus Malaquias — Wed, 06 Oct 2021 12:20:43 +0000

Photo by Scott Rodgerson on Unsplash

No meu projeto atual temos um fluxo de CI/CD automatizado e uma das responsabilidades desse fluxo é detectar se estamos cumprindo a taxa mínima de cobertura de código estabelecida pelo time.

Entretanto, mesmo possuindo uma cobertura de código com 84% o SonarQube estava sempre informando 30% como resultado, por causa dessa taxa tão baixa o processo de CI/CD parava e o deploy não acontecia.

Demorou um tempo para eu entender que o SonarQube também estava computando a parte do código criada pelas anotações do Lombok.

A solução para o problema:

A solução é muito simples. Precisei criar um arquivo chamado lombok.config na pasta java (/../src/main/java/lombok.config) com os valores abaixo:

config.stopBubbling = true
lombok.addLombokGeneratedAnnotation = true

Para que serve essas configurações?

O config.stopBubbling está informando que a pasta onde o arquivo se encontra é a raiz do projeto e o Lombok não deve procurar arquivos de configurações em outras pastas.

Enquanto lombok.addLombokGeneratedAnnotation está configurando o Lombok para adicionar uma anotação @lombok.Generated em todos os métodos criados por alguma anotação.

E é exatamente isso que queremos porque o plugin Jacoco responsável por coletar a cobertura de código do projeto e informa ao SonarQube vai passar a ignorar todos os métodos que tiverem essa anotação.

Pronto, problema resolvido. Depois que você aplicar essas configurações a cobertura de código do seu projeto deve voltar ao normal.

Finalizando...

Se você gostou desse post, por favor não deixe de dar um like e compartilhar 😄

Se quiser saber o que ando fazendo por aí ou tirar alguma dúvida fique a vontade para me procurar nas redes sociais como @ malaquiasdev .

Para ler mais post meus acesse MalaquiasDEV | A Vida, o código e tudo mais .

Weekly Edição 1

Mateus Malaquias — Sun, 28 Feb 2021 12:06:13 +0000

Weekly é uma sessão do blog onde guardo todos os links dos conteúdos que li, ouvi ou assistir durante uma semana.

📚 Textos:

Abba: Using PartiQL to query AWS DynamoDb in Javascript
Ali Abdaal: The Ultimate Guide to Studying
Flavio Copes: How to write a CSV file with Node.js
Ali Abdaal: Useful Apps To Improve Productivity and Study Effectively
Simon Holdorf: Why You Need Soft Skills as a Software Developer – And How to Improve Them
Natalie Pina: How Empathy Can Make You a Better Software Engineer
Tiago de Freitas Lima: Microserviços e REST (sério?)
Marvin Mouroum: iOS Dynamic Push Notifications with AWS Pinpoint

🎙 Podcasts:

Charles Duhigg: O Poder do Hábito
Tallis Gomes: Nada Easy
Sun Tzu: A Arte da Guerra
Hipsters: O Ecossistema Frontend da Gupy – Hipsters On The Road #52
Hipsters: Estado atual do DevOps – Hipsters Ponto Tech #240
Hipsters: Trello, Jira e Ferramentas de Produtividade – Hipsters Ponto Tech #239
Nath Finanças: Orçamento Sem Falhas

🗣 Tweets:

@rponte: " alguém tem algum artigo sobre boas práticas em design de APIs gRPC (ou mesmo RPC)?"

🖥️ Videos:

Beto Muniz: Desenvolvimento Web Além do HTML, CSS e JavaScript - YouTube
Rocketseat: Node.js: carreira, mercado e dicas na prática | #PR 27

Publicando pacotes privados do NPM no Nexus repository

Mateus Malaquias — Tue, 23 Jun 2020 17:58:43 +0000

Atualmente trabalho com JavaScript e Node.js em uma grande operadora daqui do Brasil e muitas de nossas soluções não podem estar públicas na internet por questões de segurança.

No projeto que trabalho temos o costume de compartilhar módulos JavaScript entre microserviços para aumentar nossa produtividade.

Isso no levou a desenvolver muitas libs internas, até então estávamos utilizando um gitlab interno como repositório de pacote para essas libs, mas o processo de governança e publicação não ficou muito bom.

Por isso migramos para o Nexus Repository Manager (também conhecido como Nexus), que é um gerenciador de repositório de código aberto fornecido pelo Sonatype.

A nossa intenção é continuar usando o NPM e tudo aquilo que a comunidade JavaScript pode nos oferecer de open-source. Combinando com nossas libs privadas do Nexus, além de conseguir utilizar de maneira decente um processo de controle de pacotes.

Neste artigo vamos ver um resumo de porque escolhemos o Nexus como repositório privado, como configura-ló para funcionar com o NPM e como conseguir consumir os pacotes guardados no Nexus.

Por que não estamos usando os produtos do NPM?

Bem, aqui a gente entra um pouco no processo de contratação de serviço da empresa, geralmente não se contrata ou compra serviços que vão atender a somente um time, como temos muitos projetos e muitos times trabalhando a empresa tenta contratar o serviço para o máximo de times possíveis.

No momento que estou escrevendo esse artigo o NPM a nível enterprise que possuí toda a estrutura de serviços que uma grande corporação precisa está custando ao mês 10 mil dólares.

Com 10 mil dólares nosso time de DevOps é capaz de subir toda infraestrutura necessária, configurar backups regulares, camadas de segurança e ainda vai sobrar bastante dinheiro porque o Nexus pode atender diversas plataformas de programação.

Se você só utiliza JavaScript em seus projetos e pode pagar pelos produtos oferecidos pelo NPM ou não possuiu um time que possa manter uma infraestrutura decente para você, recomendo optar pelo NPM.

O mínimo que você precisa saber para prosseguir

O Nexus vai expor para você um repositório “publico” chamado group que internamente é combinação do nosso repositório privado, ou seja, hosted e um proxy para o registro público do NPM.

O proxy é extremamente importante se seu projeto precisa utilizar libs open source que estão hospedadas no NPM ou em qualquer outro repositório que não seja o teu Nexus.

Por padrão sempre que a gente consumir um pacote publico o Nexus vai criar um cache para que a gente não precise acessar o NPM a todo momento por exemplo.

No final de nossa configuração teremos a seguinte somatória group = hosted + proxy e nosso fluxo de uso será sempre baixar os pacotes do group e fazer uploads para o hosted.

No fim, vamos arregaçar um pouco as mangas e entender.

Criando um repositório Host

Repositórios hospedados são os repositórios particulares que criamos para armazenar nossos pacotes particulares. O que torna esses repositórios privados é a incapacidade de ler o conteúdo desses repositórios sem um authToken. Veremos isso em um exemplo no final do artigo.

Para criar um repositório do tipo hosted vá em Settings => Repository => Repositories => Create Repository.

Depois de clicar em Create Repository o Nexus vai nos exibir uma quantidade enorme de plataformas que gerenciam dependências. Se for sua primeira vez usando Nexus, aproveite a oportunidade para da uma explorada no que a plataforma pode te oferecer.

Dessa lista vamos focar no npm, o primeiro repositório que vamos será npm(hosted).

Na tela de criação o Nexus vai nos solicitar um nome único e em storage vamos guardar os nossos artefatos.

E é isso, basta clicar no botão Create Repository para finalizar.

Criando um proxy e grupo do NPM

Volte novamente para Repository => Repositories => Create Repository, para criamos um novo repositório do tipo npm(proxy).

Na tela de configuração nos vamos especificar que queremos nos comunicar com o NPM no campo Proxy Location adicionando a URL https://registry.npmjs.org.

Com os repositórios npm(hosted) e npm(proxy) criados, podemos finalmente criar o npm(group).

O fluxo de configurações é igual aos anteriores, coloque um nome e informe o mesmo store utilizado em npm(hosted) e npm(proxy).

Além disso precisamos selecionar os usuários ou grupos que podem acessar o repositório npm(group).

Enviando pacotes para o Nexus

Agora que estamos prontos com os repositórios criados, podemos configurar nossos projetos.

Para publicar um artefato no Nexus, precisamos alterar o arquivo package.json adicionando um objeto chamado publishConfig que vai guardar a URL do nosso repositório privado.



{
  "name": "@ms-ott/tools",
  "version": "2.0.4",
  "description": "Common and helpers tools to create microservices APIs",
  "main": "src/index.js",
  "publishConfig": {
    "registry": "https://meu.dominio.com/repository/npm-private/"
  },
  "scripts": {
    "lint": "eslint \"{src,apps,libs,test}/**/*.js\" --fix",
    "test": "jest",
    "test:watch": "jest --watch",
    "test:cov": "jest --coverage"
  },
  "devDependencies": {
    "eslint": "^5.16.0",
   "eslint-plugin-import": "^2.16.0",
    "eslint-plugin-prettier": "^3.0.1",
    "jest": "^24.7.1",
    "prettier": "^1.16.4"
  },
  "dependencies": {
    "aws-sdk": "^2.263.1",
    "dotenv": "^5.0.1",
    "dynamoose": "^1.7.3",
    "joi": "^13.4.0",
    "jsonwebtoken": "^8.5.1",
    "node-cache": "^4.2.0",
    "restify-cors-middleware": "^1.1.1",
    "restify-errors": "^8.0.1",
    "uuid": "^3.3.3",
    "request": "^2.83.0",
    "request-ip": "^2.1.3",
    "winston": "^3.2.1"
  }
}

Com o package.json configurado, agora precisamos fazer um login no npm cli apontando o registry para o nosso domínio:

npm login —registry=https://meu.dominio.com/repository/npm-private/

Digite seu usuário e senha do nexus e pronto. 🧞

Agora basta executar o comando: npm publish .

Se tudo deu certo você vai conseguir verificar sua lib hospedado acessando o repositório privado.

Baixando seus pacotes do Nexus

Agora que publicamos nossa lib no Nexus, vamos consumi-la em outros projetos.

Precisamos adicionar um arquivo .npmrc no projeto, para evitar que toda pessoa desenvolvedora do time precise fazer um npm login apontando o registry para o Nexus.

O arquivo .npmrc vai guardar tanto a URL do Nexus como um authToken com permissão de acesso.

Como boa prática, recomendo que você possua configurado em seu Nexus um usuário com permissão de somente leitura que possa ser usado para um fluxo de CI/CD e que você possa deixar o arquivo .npmrc versionado.

Para gerar o authToken você pode usar o comando abaixo:

echo -n 'registryuser:registrypassword' | openssl base64

Com o authToken em mãos, basta criar o arquivo como no modelo abaixo:



registry=https://meu.dominio/repository/npm-group

always-auth=true

_auth=bWF0ZXVzLm1hbGFxdWlhczoxMjM0NTY=

Bônus: Usando Jenkins com Nexus

Se você assim como eu, possui um Jenkins privado e deseja que o teu fluxo de publicação seja automatizado. O código abaixo possui o mínimo necessário para publicar nossas libs usando o Jenkins.



pipeline {

    agent any

    tools{nodejs "node”}

environment {
    REGISTRY_URL = "http://localhost:8081/repository/malaquias-npm-private/“
    REGISTRY_USER_EMAIL = "malaquiasdev@gmail.com”
    NPM_TOKEN = "bnBtdXNlcjpWbnRlaG1fMDU=“
}

stages {
    stage('Git Checkout') {
        steps {
            git 'https://gitlab.com/malaquiasdev/nexus-study.git'
        }
    }

    stage('Publish to Nexus') {
        steps {
            sh ‘ls'
            sh 'echo -e "registry=${REGISTRY_URL}\nemail=${REGISTRY_USER_EMAIL}\nalways-auth=true\n_auth=${NPM_TOKEN}" &gt;&gt; .npmrc’
            sh 'npm publish'
        }
    }
}

Conclusão

Nesse artigo pincelei um fluxo básico de como publicar e consumir libs privadas usando o Nexus Repository.

Finalizando...

Se você gostou desse post, por favor não deixe de dar um like e compartilhar 😄

Se quiser saber o que ando fazendo por ai ou tirar alguma dúvida fique a vontade para me procurar nas redes sociais como @ malaquiasdev .

Para ler mais post meus acesse MalaquiasDEV | A Vida, o código e tudo mais .

O Guia dos Serverless das Galáxias #3 - Entendendo o ciclo de vida de uma função lambda

Mateus Malaquias — Tue, 05 May 2020 13:16:03 +0000

Quando a gente cria ou atualiza uma função, na maioria dos casos, esse processo é muito rápido e as nossas funções estão prontas para executar quase que imediatamente.

No entanto, existem situações em que esses processos podem levar mais tempo.

Neste post, vamos entender os estados de uma função, as condições de cada estado e como ocorre a transição entre eles.

Estados de uma função

Pendente

É o primeiro estado pelo qual todas as funções passam quando são criadas. A função se mantém nesse estado durante um processo de deploy ou durante a configuração de todos os recursos externos necessários.

Tenha sempre em mente que só é possível executar uma função quando o seu estado é Ativo, portanto, qualquer invocação nesse momento irá falhar.

Ativo

Alcançado após a conclusão de qualquer deploy com sucesso, configuração ou alocação de recursos durante a criação ou atualização de uma função.

É importante ter em mente que as funções só podem ser invocadas nesse estado. Por isso que durante uma atualização, o estado permanece como ativo.

Durante um processo de atualização todas as invocações irão ser executadas utilizando os códigos e as configurações anteriores até que o processo seja concluído com sucesso.

Falha

É o estado que representa algo que deu errado na configuração ou no provisionamento de recursos externos.

Inativo

Inativo, onde acontece o famoso "cold start" é o estado de uma função quando ela fica sem ser executada por um determinado período de tempo ou quando a função precisa escalar rapidamente para atender muitas chamadas concorrentes.

Esse estado existe para baratear os custos de infraestrutura do serviços, quando a função entra nesse estado todos os recursos externos que foram configurados para ela são removidos.

Estados de uma função durante uma atualização

Em progresso

Significa que uma atualização está acontecendo. Enquanto uma função está nesse sub estado, todas as invocação são realizadas nos códigos e configurações já existentes.

Bem sucedido

A atualização foi concluída.

Falhou

A atualização da função falhou, todas as alterações são abortadas. Tanto o código como a configuração anterior permanecem no estado ativo e disponíveis.

Outro ponto importante durante o processo é que as funções só podem ser atualizadas se estiverem no estado Ativo ou Inativo. Os comandos de atualização emitidos nas funções que não estão nesses estados falharão.

Ciclos de Vida dos Estados de uma função

Como não conseguimos mover manualmente uma função entre os seus estados, a transição entre os estados acaba dependendo das ações que executamos diretamente sobre as funções.

Para todas as funções, o ciclo de vida do estado primário se parece com o seguinte:

Ao criar uma função, ela começa no estado Pendente;
Após a configuração de todos os recursos necessários com sucesso, o estado passa a ser Ativo;
- Se a configuração de recurso ou função falhar por qualquer motivo, ela passará para o estado de Falha;
Se uma função não for executado durante um período de tempo, ela entrará no estado Inativo;
Na primeira chamada após ficar Inativo, uma função entra novamente no estado Pendente;
- Êxito define o estado como Ativo novamente;
- Falha define o estado de volta para Inativo;
Uma atualização com sucesso, também define o estado de volta para Ativo;

Ciclo de vida de uma função durante o processo de atualização

Para atualizar funções, o ciclo de vida é o seguinte:

Na atualização, o estado de atualização é definido como Em Progresso;
- Êxito define o estado como Bem Sucedido;
- Uma falha define como Falha mesmo;
Uma função inativa voltará ao estado ativo com uma atualização bem sucedida.

Conclusão

Na AWS (provedor de cloud que tenho mais contato) todas as funções mostrarão apenas um estado Ativo no painel web. Você não verá uma transição de estado para Pendente por exemplo. Mas dá para consultar o estado atual da função usando os SDKs da AWS e a CLI da AWS mais recentes (versão 1.16.291 ou superior).

Finalizando…

Se você gostou desse post não esquece de dar um like e compartilhar 😄

Se quiser saber o que ando fazendo por ai ou tirar alguma dúvida fique a vontade para me procurar nas redes sociais como @ malaquiasdev.

Para ler mais post meus acesse MalaquiasDEV | A Vida, o código e tudo mais.

DEV Community: Mateus Malaquias

Quarkus Testing: @QuarkusTest vs @QuarkusIntegrationTest

TL;DR

The Confusion

Under the Hood: The Process Boundary

1. @QuarkusTest (White-Box)

2. @QuarkusIntegrationTest (Black-Box)

When to use which?

Prefer @QuarkusTest when:

Prefer @QuarkusIntegrationTest when:

Wrapping up

Resources

[Quick Fix] Hibernate: object references an unsaved transient instance

TL;DR

The Scenario

The Error

Why this happens

The Solution

Why this works

How JWT, JWS, and JWE Secure Your Data?

TL;DR

Key differences

Are you covered?

JWT (JSON Web Token)

Common use cases

Why use JWT?

JWS (JSON Web Signature)

Common use cases

When to use?

JWE

Common use cases

When to use?

Benefits of combining JWS and JWE

Best Practices

Resources

Tilde or Caret in package.json - Stop copying and start choosing

TL;DR

SEMVER

Tilde (~)

Caret (^)

How to update my dependencies?

Resources

How to solve error parsing HTTP request header in Spring Boot

TL;DR

What are HTTP headers?

Why Spring Boot limit the header size?

References

When I prefer use when then if-else in Kotlin

TL;DR

Why when is better in my option?

Code example

When if-else is a better option?

Code example

References

Why I like to use Early Returns Pattern?

How fast a simple code can mess up everything?

What is an early return?

Refactoring the code to use the Early Returns Pattern

What can we observe now?

Conclusion

Lombok: Fixing SonarQube coverage problem

The solution:

What are these settings for?

Finishing...

Lombok: Corrigindo problema de cobertura de código no SonarQube

A solução para o problema:

Para que serve essas configurações?

Finalizando...

Weekly Edição 1

📚 Textos:

🎙 Podcasts:

🗣 Tweets:

🖥️ Videos:

Publicando pacotes privados do NPM no Nexus repository

Por que não estamos usando os produtos do NPM?

O mínimo que você precisa saber para prosseguir

Criando um repositório Host

Criando um proxy e grupo do NPM

Enviando pacotes para o Nexus

Baixando seus pacotes do Nexus

Prefer `@QuarkusTest` when:

Prefer `@QuarkusIntegrationTest` when:

Why `when` is better in my option?

When `if-else` is a better option?