Forem: Samuel Luiz

Como eu reduzi em até 99% o tempo de resposta da minha API

Samuel Luiz — Fri, 22 Nov 2024 23:23:59 +0000

ORM's são uma ferramenta poderosa, mas ao mesmo tempo que facilita nossa vida, também torna um pouco obscura a resolução de problemas se você não tiver experiência com os recursos que são oferecidos. Vou resumir como a funcionalidade de Lazy Loading do JPA + Hibernate e implementar HATEOAS reduziu em até 99% o tempo de resposta de um sistema em produção.

Inexperiência

Esse projeto foi feito no início da minha jornada com Java, onde pude aplicar o pouco conhecimento que eu havia adquirido em um projeto real, com pressão real e expectativas reais. Como era minha primeira experiência, fui aprendendo ao longo do projeto e em alguns momentos isso levava a algumas práticas questionáveis, incluindo duas mais impactantes.

Banco de dados

A API foi construída utilizando Java, PostgreSQL e JPA como ORM para facilitar a comunicação com o banco de dados.

Por padrão, o JPA utiliza Lazy Loading para buscar as informações relacionadas a uma entidade. Por exemplo: Se um Cliente possui várias compras associadas a ele, ao consultar um cliente na aplicação, o JPA entende que se eu não utilizei as compras de um cliente dentro de um contexto, ele não precisa consultar também todas as compras desnecessariamente. Esse era o padrão em minha aplicação inteira, exceto no contexto mais importante.

Quando me deparei com um erro na camada de autenticação, procurando soluções encontrei uma alternativa que funcionou: utilizar Eager Loading nos relacionamentos que eu estava manipulando naquela camada. Adicionei essa propriedade nas duas entidades da seguinte forma:

@ManyToMany(mappedBy = "profissionais", fetch = FetchType.EAGER)
private List<Cliente> clientes;

Nos primeiros meses após a implantação não aconteceu nenhum problema, mas assim que o sistema escalou para algumas centenas de usuário as reclamações começaram a surgir. E não foi a toa, as requisições estavam levando de 10 segundos a quase 1 minuto pra completar:

Nesse cenário assustador, com um pouco mais de experiência devido aos meses que se passaram e algumas pesquisas, cheguei à conclusão de que essa lentidão foi causada principalmente pelo alto volume de processamento de JSON em uma só requisição. Isso se deu pelo fato de haver muitos recursos aninhados, algo que vou explicar a seguir.

Design da API

Devido ao projeto ter um prazo de entrega curto e um MVP muito grande devido a falta de experiência na coleta de requisitos, fui obrigado a tomar algumas decisões de arquitetura que não eram muito escaláveis. A pior decisão foi utilizar o retorno de todos os objetos aninhados partindo do objeto pai. Isso significa que um recurso consultado possuía vários objetos aninhados, e esse objetos também possuíam vários objetos aninhados, até chegar no último objeto possível associado ao recurso. Isso causou um gargalo no processamento de respostas JSON em consultas e outras interações com retorno e, dentre várias outras otimizações, optei por solucionar esse problema aplicando (parcialmente) o princípio HATEOAS, substituindo os recursos aninhados por links relevantes para consultar esses recursos associados. Esse pequeno ajuste garantiu uma escalabilidade maior, já que agora os retornos da API não cresciam exponencialmente.

Solução definitiva

Após várias otimizações em consultas custosas ao banco de dados, redução de roundtrips da aplicação ao banco de dados utilizando operações em batch e criação de índices no banco de dados, chegou o dia da implantação dessa refatoração. Estava ansioso pra testar essas funcionalidades mas precisava de um teste confiável. Pra garantir isso repliquei o banco de dados de produção para o ambiente de stage, abri a aplicação, testei e...

Não evoluiu nada.

Após meses de aprendizado constante e muitas modificações no código, parecia que meu esforço havia sido em vão. As requisições continuavam levando a mesma quantidade de tempo, mas dessa vez a performance estava ainda pior pelo motivo do frontend estar fazendo mais requisições do que antes (já que agora não existiam mais recursos aninhados). Naquele momento senti um frio na barriga e pensei que teria que virar a madrugada pra solucionar um problema grave de performance que parecia não ter mais soluções.

Até que eu lembrei do trecho abaixo de código:

@ManyToMany(mappedBy = "profissionais", fetch = FetchType.EAGER)
private List<Cliente> clientes;

Havia uma esperança que esse trecho simples do código fosse o responsável por pelo menos uma parte do gargalo do sistema. A única alteração que fiz (em 3 trechos parecidos do código) foi a seguinte:

@ManyToMany(mappedBy = "profissionais", fetch = FetchType.LAZY)
private List<Cliente> clientes;

Agora, sabendo o que essas estratégias de data fetching significam e seus prós e contras, estava confiante o suficiente para subir essa fix e testar novamente. Foi então que obtive os resultados abaixo:

Conclusão

ORM's são uma poderosa ferramenta, mas você precisa saber muito bem o que está fazendo. Mesmo após dezenas de otimizações, o gargalo em sua maioria estava em uma única propriedade do JPA. Eu obteria o mesmo resultado caso tivesse alterado isso e não realizasse nenhuma outra melhoria? Nunca saberemos.

Building an interpreter in Go: Lexical Analysis

Samuel Luiz — Sun, 25 Feb 2024 06:47:35 +0000

Every programmer will or has once thought about how languages are created. When I first started thinking about it, I got interested in everything that this world has to offer: compilers; interpreters; bootstraping; ast's; and so on.

But honestly, I didn't feel quite confident to create my own programming language. I've always felt like this was something made only by super genius or really experienced developers. But wait... I wanna become a super genius really experienced developer in the near future! So I decided to finally learn and build my own interpreted language.

Disclaimer: I will not go deeply through all the technical definitions of everything because ~~I still don't know exactly what I'm doing~~ it's not the purpose of this article. I'm doing this to mainly help me in my learning process because I feel like I reinforce what I learn by explaining step by step what I did. I will be using the book Writing an Interpreter in Go by Thorsten Ball as my guide.

Defining our steps

There are a lot of ways of creating an interpreter: you can build it from scratch and directly execute it; you can use parser generators to help in the parsing process; you can use an existing library in common languages like Python ast and Javascript eval; and a lot of other ways that I still don't know about. But in our case, we will build an interpreter using an Abstract Syntax Tree (ast) defined by ourselves from scratch.

When creating a language using this method we usually have these steps:

Lexical Analysis (Tokenization)
Parsing
Semantic Analysis
Execution

With our steps clearly defined, let's begin!

Creating our language syntax

Well, before we start programming our language (cool huh) we obviously need to have a language to begin with. I will start by writing a small code that contains all of the language tokens (basically symbols that will be read by our interpreter):

a = 2;
b = 3;
c = 4;

add f(x, y, z) -> x + y * z / 2 - 1;

add(a, b, c);

As you can tell, it's a dead simple language that for now has only variables, numbers, arithmetic operations, and functions. Later on, we will add conditional statements and precedence order as well, but that will be it. I will call this language "Ematics" because it's mathematics without the math.

Now that we have our language grammar defined, we can start coding it!

Defining our tokens

First off, we will create a token.go file to define all of our language tokens:

// token.go

package main

type TokenType string

type Token struct {
    Type TokenType
    Literal string
}

const (
    ILLEGAL = "ILLEGAL"
    EOF = "EOF"

    VARIABLE = "VARIABLE"
    NUMBER = "NUMBER"

    ASSIGN = "="
    PLUS = "+"
    SLASH = "/"
    STAR = "*"
    MINUS = "-"

    COMMA = ","
    SEMICOLON = ";"
    RETURN_ARROW = "->"

    FUNCTION = "FUNCTION"
)

var keywords = map[string]TokenType{
    "f": FUNCTION,
}

We're starting off simple here: We're defining a type TokenType which will be a string, and a struct containing the Type and the Literal (value) of the token. Web dev folks: think of that as when you start your web application by defining your data models! It's not the hardest part of the program, but it has to exist in order to continue.

Then we create a bunch of constants that organize which tokens our language will have. Note that ILLEGAL, EOF, and FUNCTION are not exactly token definitions. ILLEGAL is every token that our language doesn't recognize, EOF is the end of the file, and FUNCTION is just an identifier name that will be used in the keywords lookup table, the map that we defined below our constants. Basically, everytime our lexer reads the letter f, it expects a function definition, and that's because of that lookup table and another function that we will add later.

Defining our lexer:

Creating a lexer is not a super hard task. But it can be tricky because of the many repetitive operations and a slight addition to the language can break everything. So we will first define a test for the lexer so that test validates everything we do:

// lexer_test.go

package main

import (
    "testing"
)

func TestLexer(t *testing.T) {
    input := `
    a = 2;
    b = 3;
    c = 4;

    add f(x, y, z) -> x + y * z / 2 - 1;

    add(a, b, c);
`

    tests := []struct {
        expectedType    TokenType
        expectedLiteral string
}{
        {VARIABLE, "a"},
        {ASSIGN, "="},
        {NUMBER, "2"},
        {SEMICOLON, ";"},
        {VARIABLE, "b"},
        {ASSIGN, "="},
        {NUMBER, "3"},
        {SEMICOLON, ";"},
        {VARIABLE, "c"},
        {ASSIGN, "="},
        {NUMBER, "4"},
        {SEMICOLON, ";"},
        {VARIABLE, "add"},
        {FUNCTION, "f"},
        {LPAREN, "("},
        {VARIABLE, "x"},
        {COMMA, ","},
        {VARIABLE, "y"},
        {COMMA, ","},
        {VARIABLE, "z"},
        {RPAREN, ")"},
        {RETURN_ARROW, "->"},
        {VARIABLE, "x"},
        {PLUS, "+"},
        {VARIABLE, "y"},
        {STAR, "*"},
        {VARIABLE, "z"},
        {SLASH, "/"},
        {NUMBER, "2"},
        {MINUS, "-"},
        {NUMBER, "1"},
        {SEMICOLON, ";"},
        {VARIABLE, "add"},
        {LPAREN, "("},
        {VARIABLE, "a"},
        {COMMA, ","},
        {VARIABLE, "b"},
        {COMMA, ","},
        {VARIABLE, "c"},
        {RPAREN, ")"},
        {SEMICOLON, ";"},
        {EOF, ""},
    }
}

Don't worry about those errors. Now that we defined the skeleton of our test, let's start coding our lexer:

// lexer.go

package main

type Lexer struct {
    input        string
    position     int
    nextPosition int
    char             byte
}

func New(input string) *Lexer {
    l := &Lexer{input: input}
    l.nextCharacter()
    return l
}

// this function basically moves to the next character and stops if the next character is the end of the input
func (l *Lexer) nextCharacter() {
    if l.nextPosition >= len(l.input) {
        l.char = 0
    } else {
        l.char = l.input[l.nextPosition]
    }
    l.position = l.nextPosition
    l.nextPosition += 1
}

// this function returns what the next char will be
// but don't increment the read position
func (l *Lexer) peekNextChar() byte {
    if l.nextPosition >= len(l.input) {
        return 0
    } else {
        return l.input[l.nextPosition]
    }
}

// this function, well, skips whitespaces
func (l *Lexer) skipWhitespace() {
    for l.char == ' ' || l.char == '\t' || l.char == '\n' || l.char == '\r' {
        l.nextCharacter()
    }
}

// this function returns a token with the type and the literal
func newToken(tokenType TokenType, ch byte) Token {
    return Token{Type: tokenType, Literal: string(ch)}
}

// what the lexer will identify as letter. this allows variable names
// like 'foo_bar'
func isLetter(ch byte) bool {
    return 'a' <= ch && ch <= 'z' || 'A' <= ch && ch <= 'Z' || ch == '_'
}

// what the lexer will identify as a digit
func isDigit(ch byte) bool {
    return '0' <= ch && ch <= '9'
}

// this function reads the identifier name and returns the token
func (l *Lexer) readIdentifier() string {
    position := l.position
    for isLetter(l.char) {
        l.nextCharacter()
    }
    return l.input[position:l.position]
}

// this function reads the identifier name and returns the token
func (l *Lexer) readNumber() string {
    position := l.position
    for isDigit(l.char) {
        l.nextCharacter()
    }
    return l.input[position:l.position]
}

// this function reads the next token
// this function will be called in a loop until the end of the input
func (l *Lexer) ReadNextToken() Token {
    var token Token

    l.skipWhitespace()

    switch l.char {
    case '=':
        token = newToken(ASSIGN, l.char)
    case ';':
        token = newToken(SEMICOLON, l.char)
    case '(':
        token = newToken(LPAREN, l.char)
    case ')':
        token = newToken(RPAREN, l.char)
    case ',':
        token = newToken(COMMA, l.char)
    case '+':
        token = newToken(PLUS, l.char)
    case '-':
        if l.peekNextChar() == '>' {
            l.nextCharacter()
            token = Token{Type: RETURN_ARROW, Literal: "->"}
        } else {
        token = newToken(MINUS, l.char)
        }
    case '*':
        token = newToken(STAR, l.char)
    case '/':
        token = newToken(SLASH, l.char)
    case 0:
        token.Literal = ""
        token.Type = EOF
    default:
        if isLetter(l.char) {
            token.Literal = l.readIdentifier()
            token.Type = LookupIdent(token.Literal)
            return token
        } else if isDigit(l.char) {
            token.Type = NUMBER
            token.Literal = l.readNumber()
            return token
        } else {
            token = newToken(ILLEGAL, l.char)
        }
    }

    l.nextCharacter()
    return token
}

Now that's a little bit of code, right? Don't worry, it's not as difficult as it looks if it's your first time doing this.

First I defined the Lexer struct which will help us traverse through the characters of the input.

I've tried to make the function names and the comments as self-explaining as possible, but it's ok if you don't understand. For now, let's focus on exactly what the ReadNextToken() function does:

It defines a token that will be returned at the end.
It calls l.skipWhitespace because our interpreter doesn't care about whitespaces.
It enters inside a switch statement that compares the current character with the language symbols and keywords. That will tell the lexer whether it's an identifier or an operator, delimiter, and which one is it.
When it matches the current character, it assigns the token variable with the newToken() function, which will return the token given a token type and a character.
If it doesn't match any 'simple' token type such as operators or delimiters, it will check if it's a letter and if it is, it will assume it's an identifier (variable name or function definition), and will read it and assign to the token. If it's not a letter, it will assume it's a number and assign it to the token. If it's none of those, then the user screwed up and we return an ILLEGAL token.
After that it sets the current input position to the next position.
Return the token.

If you're really paying attention you must have noticed that there's an unknown function being called there. The tok.Type = token.LookupIdent(tok.Literal) line is being called but I didn't introduce this function yet. So, here it is:

// token.go

var keywords = map[string]TokenType{
    "f": FUNCTION,
}

func LookupIdent(ident string) TokenType {
    if token, ok := keywords[ident]; ok {
        return token
    }
    return IDENTIFIER
}

This function basically looks at our lookup table where we've defined the keywords of our language and returns the token type associated with it. If it can't be found, it returns the IDENTIFIER type, which is basically a variable or function name in our language.

Now that we finished our lexer, it's time to update our lexer test:

// lexer_test.go

package main

import (
    "testing"
)

func TestLexer(t *testing.T) {
    input := `
    a = 2;
    b = 3;
    c = 4;

    add f(x, y, z) -> x + y * z / 2 - 1;

    add(a, b, c);
`

    tests := []struct {
        expectedType    TokenType
        expectedLiteral string
}{
        {IDENTIFIER, "a"},
        {ASSIGN, "="},
        {NUMBER, "2"},
        {SEMICOLON, ";"},
        {IDENTIFIER, "b"},
        {ASSIGN, "="},
        {NUMBER, "3"},
        {SEMICOLON, ";"},
        {IDENTIFIER, "c"},
        {ASSIGN, "="},
        {NUMBER, "4"},
        {SEMICOLON, ";"},
        {IDENTIFIER, "add"},
        {FUNCTION, "f"},
        {LPAREN, "("},
        {IDENTIFIER, "x"},
        {COMMA, ","},
        {IDENTIFIER, "y"},
        {COMMA, ","},
        {IDENTIFIER, "z"},
        {RPAREN, ")"},
        {RETURN_ARROW, "->"},
        {IDENTIFIER, "x"},
        {PLUS, "+"},
        {IDENTIFIER, "y"},
        {STAR, "*"},
        {IDENTIFIER, "z"},
        {SLASH, "/"},
        {NUMBER, "2"},
        {MINUS, "-"},
        {NUMBER, "1"},
        {SEMICOLON, ";"},
        {IDENTIFIER, "add"},
        {LPAREN, "("},
        {IDENTIFIER, "a"},
        {COMMA, ","},
        {IDENTIFIER, "b"},
        {COMMA, ","},
        {IDENTIFIER, "c"},
        {RPAREN, ")"},
        {SEMICOLON, ";"},
        {EOF, ""},
    }

    lexer := New(input)

    for i, tt := range tests {
        token := lexer.ReadNextToken()

        if (token.Type != tt.expectedType) {
            t.Fatalf("tests[%d] - wrong token type. expected=%q, actual=%q", i, tt.expectedType, token.Type)
        }

        if (token.Literal != tt.expectedLiteral) {
            t.Fatalf("tests[%d] - wrong token literal. expected=%q, actual=%q", i, tt.expectedLiteral, token.Literal)
        }
    }
}

Now if we run go test, our test will pass. Great! We've just finished our lexer. If you're doubting it, then modify something in the input variable or comment on some line in the tests struct and rerun the test. Crazy, right? This test is our reliable source of truth that will tell if we screwed anything up when we add some new features to our language. But we will have to manually add these new features to our test, so be cautious.

Bonus: Creating a REPL

Now that we've finished our lexer we can already insert some interactivity to our language! We can build a REPL (Read-Eval-Print-Loop). What the hell is that?

Well, if you install Python, open your terminal, and type python, you'll notice that you'll enter a different console where you can type Python commands and it will print the execution of these commands. It will first read, then evaluate, then print, and do it again. Read, Eval, Print, Loop!

Our REPL will not execute commands at this point. Instead, it will print the token definition. For example: if we type x = 5, it will print something like:

{Type:IDENTIFIER Literal:x}
{Type:= Literal:=}
{Type:INT Literal:5}
{Type:; Literal:;}

Every programmer has already made a simple CLI program before. A calculator, an even or odd algorithm, or anything that asks the user for input and prints an output.

A REPL is basically that! We prompt the user and after we receive an input we print out the output, which will be the token objects. And we'll do it inside a loop:

// repl.go

package main

import (
    "bufio"
    "fmt"
    "io"
)

const PROMPT = "> "

func Start(in io.Reader, out io.Writer) {
    scanner := bufio.NewScanner(in)

    exit := false

    for !exit {
        fmt.Print(PROMPT)
        scanned := scanner.Scan()
        if !scanned {
            return
        }

        line := scanner.Text()
        if line == "exit" {
            exit = true
            continue
        }
        lexer := New(line)

        for token := lexer.ReadNextToken(); token.Type != EOF; token = lexer.ReadNextToken() {
            fmt.Printf("%+v\n", token)
        }
    }
}

The code is pretty simple. We instantiate a scanner (like the good old java Scanner scanner = new Scanner(System.in);), then we loop until the user types exit in the prompt. We instantiate our lexer with the user prompt as the input and then we check if the token received is not an EOF. If it isn't, we print the token object.

Now we just have to call this inside our main function:


// main.go

package main

import (
    "fmt"
    "os"
)

func main() {
    fmt.Printf("Welcome to Ematics!\n")
    fmt.Printf("Feel free to type in commands\n")
    Start(os.Stdin, os.Stdout)
}

And now if we run the program with go run ., we'll see this amazing interactive console:

Welcome to Ematics!
Feel free to type in commands
>

And this is everything for now. In the next section, we'll be (hopefully) building our parser. Thanks for reading!

JPA Cheatsheet: visualizando relacionamentos

Samuel Luiz — Fri, 25 Aug 2023 14:59:41 +0000

Modelar e descrever relações entre entidades pode ser uma dificuldade para desenvolvedores iniciantes, mas no caso do JPA pode virar uma completa bagunça se não prestar a devida atenção. Quando aprendi esta tecnologia criei um pequeno guia pra me ajudar e me baseio nele até hoje quando estou com alguma dúvida.

OneToMany ou ManyToOne relationship

Regra: geralmente, o lado “many” é o dono da relação.

Exemplo: Cliente e Pedido.

Perguntas a se fazer:

Um cliente pode ter quantos pedidos?
Um pedido pode pertencer a quantos clientes?
Eu preciso saber quais os pedidos do cliente?
Eu preciso saber qual o cliente de cada pedido?
Quem é o dono do relacionamento?

Respostas:

[x] Um cliente pode ter vários pedidos. (OneToMany)
[x] Um pedido pode pertencer a apenas um cliente. (ManyToOne)
[x] Eu não preciso saber os pedidos de cada cliente, mas preciso saber o cliente de cada pedido. (Unidirecional)
[x] O pedido é o dono do relacionamento.

Portanto, chegamos a conclusão de que um cliente pode ter vários pedidos, mas um pedido pertence a apenas um cliente.

Na classe pedido, nós declaramos o atributo cliente com as anotações:

@ManyToOne (pois vários pedidos (Many) podem ter apenas um cliente (ToOne)
@JoinColumn(name = “cliente_id”) para criar uma coluna no banco de dados com o id do cliente

Classe Pedido:

@ManyToOne
@JoinColumn(name = “cliente_id”)
private Cliente cliente;

Na classe cliente, nós declaramos e INSTANCIAMOS uma coleção de pedidos com as anotações:

@JsonIgnore (para a resposta em json da requisição HTTP ignorar esta lista e não criar um loop de pedidos com cliente e cliente com pedidos, gerando stack overflow, afinal nós não precisamos saber os itens). Uma alternativa ao JsonIgnore pode ser usar DTO’s.
@OneToMany(mappedBy = “cliente”) pois um cliente (One) pode ter vários pedidos (ToMany), o parâmetro mappedBy serve para mapear o atributo da classe Pedido (deve ser exatamente igual ao atributo declarado na classe)

Classe Cliente:

@OneToMany(mappedBy = “cliente”)
private List<Pedido> pedidos;

ManyToMany relationship

Exemplo: Um produto pode pertencer a várias categorias, e uma categoria possui vários produtos.

Perguntas a se fazer:

Um produto pode pertencer a quantas categorias?
Uma categoria pode possuir quantos produtos?
Eu preciso saber quais produtos uma categoria possui?
Eu preciso saber a quais categorias um produto pertence?
Quem é o dono do relacionamento?

Respostas:

[x] Um produto pode pertencer a varias categorias. (ManyToMany)
[x] Uma categoria pode possuir vários produtos. (ManyToMany)
[x] Eu preciso saber quais produtos uma categoria possui, e também saber a quais categorias um produto pertence. (Bidirecional)
[x] O produto é o dono do relacionamento.

Portanto, chegamos a conclusão de que um produto pode pertencer a várias categorias, e uma categoria pode possuir vários produtos. Nesse caso, devemos criar uma tabela de associação usando o @JoinTable. Como o Produto possui essa anotação, é implícito que o Produto é o dono da relação.

Na classe produto, declaramos e INSTANCIAMOS uma coleção de categorias com as anotações:

@ManyToMany (pois vários produtos (Many) podem ser de várias categorias (ToMany)
@JoinTable (para criar uma nova tabela)
@JoinColumn (dentro do @JoinTable para criar as colunas)

Classe Produto:

@ManyToMany
@JoinTable(name = "tb_product_category",
joinColumns = @JoinColumn(name = "product_id"),
inverseJoinColumns = @JoinColumn(name = "category_id"))
private Set<Category> categories = new HashSet<>();

Na classe category, declaramos e INSTANCIAMOS uma coleção de produtos com as anotações:

@ManyToMany(mappedBy = “categories”) para mapear a coleção de categorias da classe Produto e indicar que o dono do relacionamento é o Produto.

Classe Categoria:

@ManyToMany(mappedBy = "categories")
private Set<Product> products = new HashSet<>();

OneToOne relationship

Exemplo: Um usuário pode ter um perfil associado, e um perfil pertence a apenas um usuário.

Perguntas a se fazer:

Um usuário pode ter quantos perfis?
Um perfil pode pertencer a quantos usuários?
Eu preciso saber o perfil de cada usuário?
Eu preciso saber o usuário associado a cada perfil?
Quem é o dono do relacionamento?

Respostas:

[x] Um usuário pode ter apenas um perfil. (OneToOne)
[x] Um perfil pode pertencer a apenas um usuário. (OneToOne)
[x] Eu preciso saber o perfil de cada usuário, e também o usuário associado a cada perfil. (Bidirecional)
[x] O usuário é o dono do relacionamento.

Portanto, concluímos que um usuário pode ter apenas um perfil, e um perfil pertence a apenas um usuário. Nesse caso, o usuário será o dono do relacionamento.

Na classe Usuario, declaramos o atributo perfil com as anotações:

@OneToOne(mappedBy = "usuario")
private Perfil perfil;

Na classe Perfil, declaramos o atributo usuario com as anotações:

@OneToOne
@JoinColumn(name = "usuario_id")
private Usuario usuario;

Observe que a anotação @OneToOne é utilizada em ambas as classes para indicar a relação One-To-One. A classe Perfil possui a anotação @JoinColumn para criar uma coluna no banco de dados com o id do usuário, que será usado para mapear o relacionamento. A classe Usuario utiliza a anotação mappedBy no atributo perfil para indicar que o relacionamento é mapeado pelo atributo usuario na classe Perfil.

Dessa forma, temos uma relação One-To-One entre Usuario e Perfil, em que um usuário pode ter apenas um perfil e um perfil pertence a apenas um usuário.