O que vem num projeto backend gerado pelo Studio — stack, estrutura de pastas, o que é gerado e o que é teu, configuração por variáveis de ambiente e como o correr.
Um projeto backend criado no Studio é uma API Spring Boot 3.5 já ligada à plataforma: autenticação JWT, permissões do Access Management, PostgreSQL, OpenAPI e descoberta de serviços. Esta página descreve o projeto; para o criar, ver Primeiro projeto, e para o modelar, Studio · Backend.
Stack
| Spring Boot 3.5 + Java 26 | Web, Data JPA, Data REST, Validation, GraphQL |
| Framework iGRP | cv.igrp.framework:core e os módulos de autenticação (@IgrpController, @igrpAuthorization) — ver Backend |
| Segurança | Spring Security — OAuth2 resource server (JWT do Keycloak) e client M2M para o Access Management |
| Dados | PostgreSQL (H2 nos testes), Hibernate |
| Plataforma | Eureka / Kubernetes discovery, Caffeine, springdoc-openapi (Swagger UI) |
| Build | Maven, Lombok |
O projeto compila com Java 26
O pom.xml gerado fixa java.version em 26 — o artefacto de autenticação do iGRP é bytecode Java 26. Para compilar fora do Docker precisas do JDK 26. A imagem Docker do projeto já usa um JRE recente.
Estrutura
O exemplo é o projeto servico-demo, com o estilo Technical (o predefinido no assistente) e o módulo pedidos:
O que é do Studio e o que é teu
| Pasta / ficheiro | Quem escreve | Para quê |
|---|---|---|
.igrpstudio/ | Studio | Módulos, esquemas, contracts e endpoints em JSON — a fonte do designer de APIs |
models/<entidade>/ | Studio | Entidade JPA e repositório Spring Data, por esquema. Com Gerar APIs CRUD, o repositório é exposto em REST (@RepositoryRestResource) |
dto/ | Studio | Os contracts (PedidoRequestDTO), com as validações |
controllers/<endpoint>/ | Studio | O controlador (@IgrpController, @PreAuthorize com as permissões do separador Security) e a interface do serviço (IPedidosService) |
services/ | Tu | A implementação do serviço (PedidosService) — é aqui que escreves a lógica de cada ação |
config/, security/, exceptions/ | Template | Auditoria, Swagger, segurança, sincronização do perfil do utilizador, tratamento de erros |
models/iamuserprofileentity/ | Template | Perfil do utilizador sincronizado a partir do token |
src/test/ | Template | Testes de configuração, controladores, repositórios e segurança |
O Studio regenera o que gera
Entidades, repositórios, DTOs e controladores são reescritos quando gravas no Studio — altera-os no designer de APIs, não no código. A lógica de negócio vai na implementação do serviço.
Estilo Domain-Driven Design
No assistente, Structure Style → Domain-Driven Design gera uma organização por domínio em vez de por camada técnica. Esta página descreve o estilo Technical.
Configuração
O application.properties lê tudo de variáveis de ambiente, documentadas no .env.example. Os perfis development, staging e production (SPRING_PROFILES_ACTIVE) acrescentam o que muda entre ambientes. As principais:
| Variável | Por defeito | |
|---|---|---|
SERVICE_PORT | 8080 | Porta da API |
POSTGRES_HOST, POSTGRES_PORT, POSTGRES_DATABASE, POSTGRES_USER, POSTGRES_PASSWORD | Base de dados | |
HIBERNATE_DDL | update | Gestão do esquema da base de dados |
SECURITY_ENABLED | false | Ativa a validação do JWT e as permissões |
AUTH_JWT_ISSUER | Issuer do Keycloak (realm) | |
IGRP_ACCESS_API_BASE_URL | API do Access Management | |
EUREKA_CLIENT_ENABLED | false | Registo no Eureka |
ENABLE_SWAGGER | true | Swagger UI |
No workspace, o Studio trata disto
Num projeto criado dentro do workspace, o Studio regista o cliente OAuth, cria a base de dados (db/init-database.sh) e injeta estas variáveis ao fazer Deploy Docker — ver Projetos.
Segurança, filtro JWT e permissões estão em Permissões no backend e Segurança & configuração.
Correr
No cartão do projeto, ⋮ → Deploy Docker: a API fica em http://<slug>:<porta>/gateway-api/<projeto>, ligada à plataforma local.
Com ENABLE_SWAGGER=true, a documentação OpenAPI fica em /swagger-ui.html. Para testar a API no Studio, ver Run Preview.
Última atualização: