serverest / serverest Goto Github PK
View Code? Open in Web Editor NEWAPIs REST simulando loja virtual para servir de estudo de testes de API de forma manual ou automatizada
Home Page: https://serverest.dev
APIs REST simulando loja virtual para servir de estudo de testes de API de forma manual ou automatizada
Home Page: https://serverest.dev
Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Não!
Descreva a solução que você deseja
Seria legal a inicialização do projeto via docker, ja com uma imagem docker do docker hub, evitando conflitos de versionamento do computadores locais.
Descreva a solução que você deseja
Ter entrega contínua.
Ao realizar push para a master
deve realizar todas as etapas necessárias e publicar no NPM.
Descreva as alternativas que você considerou
standard-version
.Material de apoio:
Etapas do semantic-release:
Step | Description |
---|---|
Verify Conditions | Verify all the conditions to proceed with the release. |
Get last release | Obtain the commit corresponding to the last release by analyzing Git tags. |
Analyze commits | Determine the type of release based on the commits added since the last release. |
Verify release | Verify the release conformity. |
Generate notes | Generate release notes for the commits added since the last release. |
Create Git tag | Create a Git tag corresponding to the new release version. |
Prepare | Prepare the release. |
Publish | Publish the release. |
Notify | Notify of new releases or errors. |
Somente implementar entrega contínua com os testes de API finalizados. Está sendo tratado na issue #1.
Procurar o máximo de detalhamento possível para o projeto poder ser 100% independente.
Agora ao invés de rodar teste de mutação para todos os arquivos, o que demora aproximadamente 19 minutos, irá rodar apenas nos arquivos JS em /src que foram alterados na branch do PR. Com isso a execução será muito mais rápida e vai possibilitar que faça parte da pipeline de entrega contínua.
Essa issue já está em andamento no PR #172
Será utilizada a lib stryker-diff-runner.
Descreva o bug
Ao realizar a seguinte request:
curl --request POST --header "Content-Type: application/json" --data "{'nome':'Lucas Amaral', 'email':'[email protected]', 'password':'123457', 'administrador':'false'}" http://localhost:3500/usuarios
É retornado o seguinte erro:
{"error":{"expose":true,"statusCode":400,"status":400,"body":"{'nome':'Lucas Amaral', 'email':'[email protected]', 'password':'123457', 'administrador':'false'}","type":"entity.parse.failed"}}
Comportamento esperado
O POST seja feito corretamente ou a mensagem auxilie na solução do problema.
Esas issue é basicamente para utilizar o bot do all-contributors e reconhecer todos que colaboraram com o ServeRest.
Opção de debug para que o usuário consiga visualizar os dados da request que chegaram no ServeRest, como header, e body.
Esses dados serão impressos no console.
Para utilizar basta passar -D
ou --debug
.
Descreva o bug
No monitoramento do moesif surgiu erro 500 na rota de /produtos. E pelos detalhes da request o usuário utilizou a nova propriedade /imagem (incluído no PR #134) da rota POST /produtos com o Postman.
Reproduzir
Acessar o Postman v7.26.5 e realizar POST em /produtos com o seguinte body:
{
"preco": "18",
"imagem": "nada",
"nome": "Produto Novo 2",
"quantidade": "1",
"descricao": "descrição produto novo"
}
É preciso autenticar em /login
Response:
{
"message": "Abra uma issue informando essa resposta. https://github.com/PauloGoncalvesBH/ServeRest/issues",
"error": {}
}
Comportamento esperado
O cadastro deveria ter retorno 400 ou 201.
Capturas de tela
Print do moesif com os detalhes da request:
Detalhe do user agent:
Contexto:
npx serverest
, e não docker.Inserir no README.md informação sobre badge do ServeRest, contendo sugestão para as pessoas incluírem em seus projetos.
Acredito que o melhor local é antes da seção 'Empresas que utilizam o ServeRest', mas fica a seu critério essa implementação.(Podemos discutir sobre na PR)
O texto deve estar em português e deve ter o a badge em si e o código da badge em markdown para o usuário copiar. (é assim nos 2 exemplos abaixo)
Projetos que pode usar de inspiração:
Sugestão de página para gerar a badge:
img.shields
Alterar timeout de token de 1 segundo para 10 min.
Não há ganhos em timeout tão baixo. Isso acaba dificultando iniciantes em testes de API.
Os testes das pipelines de entrega contínua e integração contínua são executadas apenas na última versão do Node disponibilizada pela action setup-node.
Para garantir que o ServeRest suporta todas as versões LTS do Node, é preciso que ele execute nas versões 10, 12 e 14.
Isso é possível utilizando matrix.
Material de apoio:
Arquivos que serão alterados:
Ao gerar um token de autenticação com duração longa (5 minutos) e reiniciar o ServeRest, o token permanece sendo utilizável.
Que o token seja válido apenas para a sessão existente. Ao reiniciar o ServeRest ele deve ser considerado inváido.
A chave utilizada para gerar o token de autenticação está fixo.
https://github.com/PauloGoncalvesBH/ServeRest/blob/90dfff4458af725aa0bf582ee1846ad119c310bc/src/services/auth-service.js#L7
Substituir essa chave pelo v4 fornecido pelo uuid. Dessa forma será randômico, por sessão.
** Descreva o bug **
Código de retorno errado quando o método não é suportado pelo recurso. O código está 404, quando deveria ser 405 - Method not Allowed
referencias:
https://tools.ietf.org/html/rfc7231#section-6.5.5
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status/405
Reproduzir
Etapas para reproduzir o comportamento:
Comportamento esperado
deve retornar 405
** Capturas de tela **
Se aplicável, adicione capturas de tela para ajudar a explicar seu problema.
** Contexto (preencha as seguintes informações): **
** Contexto adicional **
Estando no docker hub será possível que usuários tenham 2 formas de utilizar o serverest, sem serem obrigados instalarem node.
Documentação:
Need analysis where to post.
GitHub Page? Heroku?
Attention; Deploy need to be a step on CI. #2
Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Nâo considero um problema.
Acredito que seja apenas uma futura feature para melhorar ainda mais o serverest.
Hoje, através de uma possível lib, temos a resposta default do tipo:
{
"error": {
"name": "ValidationError",
"message": "Validation Failed",
"statusCode": 400,
"error": "Bad Request",
"details": [
{
"email": "\"email\" is not allowed to be empty",
"password": "\"password\" is not allowed to be empty"
}
]
}
}
Descreva a solução que você deseja
A solução seria padronizar as mensagens de erro.
Como podemos ver, as mensagens de erro aparecem no padrão em EN. Seria interessante além de personalizar as mensagens para PT-BR, elas fossem mais claras para os usuários, por exemplo:
{
"email": "Email é obrigatório",
"password": "Password é obrigatório"
}
Contexto adicional
Segue response de /login sem enviarmos um email e um password:
Descreva a solução que você deseja
Os testes de API são executados apenas na integração e entrega contínua nas Actions do GitHub.
Para garantir qualidade e velocidade é interessante que os testes sejam executados no pré-push, abortando o commit caso os testes e a cobertura de código (executado automaticamente após os testes de API) falhem.
Descreva as alternativas que você considerou
No arquivo package.json
, dentro de husky (linha 34), incluir a hooks pre-push
com o comando npm test
.
Para saber mais do husky, acesse a página do projeto.
Contexto adicional
Além de adicionar o pre-push no hooks do husky, é importante:
Validação realizada localmente
Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Descreva a solução que você deseja
Refazer toda a documentação utilizando swagger UI
Internationalization will make it possible to increase the number of contributors and users.
Being in Portuguese it is already having 200 daily downloads, with the internationalization the number of downloads should increase considerably.
Besides, there is no project in English that provides REST server in an easy way as the serverest containing the main verbs and settings.
It is necessary to translate all tests, routes, schemas, functions, variables, documentation, help and response of the routes.
Descreva o bug
A mensagem de erro de que propriedade deve ser objeto não está traduzido igual as outras mensagens.
Reproduzir
Enviar POST em /carrinhos com o seguinte corpo:
[
null
]
O retorno será o seguinte:
{
"value": "\"value\" must be of type object"
}
Comportamento esperado
A mensagem deve ser traduzida para algo como X deve ser objeto
.
Contexto:
Versão do ServeRest: 2.9.2
Descrição técnica
Ajuste deve ser feito no arquivo montarMensagemDeErroDeSchema.js e novo teste de API deve ser criado para garantir cobertura.
** Falta aspas no json de autenticacao **
Na documentação do projeto, o json de autenticação esta faltando aspas na cabeçalho do atributo.
Reproduzir
Etapas para reproduzir o comportamento:
pois esta:
{
email: "[email protected]",
password: "paulo"
}
para funcionar no meu foi necessário por aspas. conforme abaixo:
{
"email": "[email protected]",
"password": "paulo"
}
Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
O ServeRest não está adequado à LGPD, embora não use os dados coletados para fins de ganhos financeiros.
Descreva a solução que você deseja
Precisamos informar aos usuários logo após a execução do ServeRest de que coletamos o nome de usuário da máquina da pessoa para entendermos o uso que ela faz e fazer os ajustes necessários (correção de bug e criação de novas features).
Precisamos informar que:
Print mostrando os dados de usuários coletados:
Código do ServeRest que coleta o nome de usuário da máquina:
https://github.com/PauloGoncalvesBH/ServeRest/blob/6d040e6fa0dcb876a8d3b440122d128b79f48805/src/monitor.js#L19
Descreva as alternativas que você considerou
npx serverest -h
) Para essa implementação será preciso verificar se está sendo utilizado docker ou npm para rodar.Contexto adicional
npx
. Ao utilizar com docker os dados são enviados de forma anônima.Incluir métricas de cobertura de código.
Ainda necessita de estudos e encontrar ferramenta que sirva a esse propósito.
Implementar monitoramento para entender o comportamento dos usuários.
Exemplo: saber quais rotas os usuários mais consomem, status Code que mais ocorre, ferramenta mais utilizada para chamar o ServeRest (a partir da info no header).
Descreva o bug
A mensagem de erro de campo vazio não está traduzido igual as outras mensagens.
Reproduzir
Enviar POST em /login com o seguinte corpo:
{
password: "senha"
email: ""
}
O retorno será o seguinte:
{
email:""email" is not allowed to be empty"
}
Comportamento esperado
A mensagem deve ser traduzida para algo como email não pode estar em branco
.
Contexto:
Versão do ServeRest: 2.9.0
Descrição técnica
Ajuste deve ser feito no arquivo montarMensagemDeErroDeSchema.js e novo teste de API deve ser criado para garantir cobertura.
Uso da lib https://www.npmjs.com/package/express-async-errors
Está sendo implementado pelo @gabriel-pinheiro
Refatoração total seguindo os seguintes itens:
Essas alterações vão:
Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Uma descrição clara e concisa de qual é o problema. Ex. Fico sempre frustrado quando [...]
Descreva a solução que você deseja
Uma descrição clara e concisa do que você deseja que aconteça.
Descreva as alternativas que você considerou
Uma descrição clara e concisa de qualquer solução ou recurso alternativo que você tenha considerado.
Contexto adicional
Adicione qualquer outro contexto ou captura de tela sobre a solicitação de recurso aqui.
O Max apresentou o ServeRest na sua talk sobre testes de API com Cypress.
Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Quando criei uma aplicação react e axios, E quando tento me conectar com a sua api acontece o erro de cors, devido não estar liberado, assim não é possível se comunicar localmente pela url http://localhost:3000/qualquer_rota.
Descreva a solução que você deseja
Apenas instalar o pacote "cors": "^2.8.5"
e adicionar o seguinte comando no arquivo app.js
const cors = require('cors');
app.use(cors());
Assim quem tem um client consegue se comunicar com a sua api.
Após o deploy em serverest.dev e da publicação de novas versões no NPM e Docker (seja @beta ou @latest), é preciso executar os testes de regressão pra validar se o comportamento do ServeRest está como esperado.
release
. https://github.com/PauloGoncalvesBH/ServeRest/blob/3559189167669da148e9de396834515407df1168/.github/workflows/continuous_delivery.yml#L58release-on-serverest-dev
. https://github.com/PauloGoncalvesBH/ServeRest/blob/3559189167669da148e9de396834515407df1168/.github/workflows/continuous_delivery.yml#L80Docker publica as versões da branch beta e trunk sempre como tag @latest. Isso é uma limitação do semantic-release de docker.
@PauloGoncalvesBH what about moving the
CHANGELOG.md
,CODE_OF_CONDUCT.md
andCONTRIBUTING.md
to the.github
folder since it's related to the project documentation or setting the visibility of Wiki page?
Originally posted by @leandromuto in #54 (comment)
Achei muito boa a sugestão do @leandromuto sobre mover arquivos relacionados à documentado para o diretírio .github
ou para a Wiki (que está desabilitada).
Porém não sei qual seria a melhor opção, e com isso gostaria de iniciar aqui uma discussão.
O único ponto que penso é que deixando no repositório, dentro de .github
, ao invés de mover para a wiki, mantém tudo versionado.
Solicitação de recurso.
Comecei a fazer um front para a pi e senti falta de foto dos produtos ao criar a lista de produtos.
Solução
Seria legal adicionar o parâmetro de foto do produto, quem usar isso pra front fica melhor visualmente.
Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Nâo considero um problema.
Acredito que seja apenas uma futura feature para melhorar ainda mais o serverest.
Hoje, com o comando npx serverest
, nosso terminal acaba por se "ocupar" até que o servidor seja parado, então, acaba por ser necessário a abertura de outro terminal e/ou aba. Para uma maior facilidade e até rapidez, subir o servidor em background via terminal seria uma ótima solução.
Descreva a solução que você deseja
A solução seria criarmos um argumento que fizesse o servidor subir em background via terminal.
Descreva as alternativas que você considerou
O webdriver-manager possui exatamente essa funcionalidade que pode ser vista AQUI
Podemos observar a opção: webdriver-manager start --detach
Contexto adicional
Acredito que poderiamos criar essa opção para os usuários e não mais travarmos o terminal ao subirmos o server.
O template de Pull Request servirá de apoio para novos colaboradores conseguirem entregar código de qualidade e adequado para o projeto.
Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Um usuário abriu determinado pull request e apenas o workflow continuous_integration.yml foi executado, enquanto os outros, de teste de mutação, check-links e codeql, não foram executados.
Com isso a qualidade do PR não está sendo garantida.
Descreva a solução que você deseja
Alterar os seguintes workflows para rodarem em pull_request
:
Descreva as alternativas que você considerou
Na seção on:
desses arquivos inserir a tag pull_request:
. Dessa forma esses workflows rodarão em PR.
Utilize a linha 4 do workflow de integração contínua como inspiração caso esteja com dúvidas: https://github.com/PauloGoncalvesBH/ServeRest/blob/trunk/.github/workflows/continuous_integration.yml
Muitos testes podem ter trechos substituídos por stubs, reduzindo a quantidade de requests e dependências.
Implementação está sendo feita na branch stub-test.
Necessita de refinamento.
@all-contributors please add @brunobatista25 for ideas
Adicionar na seção de empresas que utilizam o ServeRest, no README, a logo das empresas:
Estou testando o ServeRest com Docker, e ao acessar http://localhost:3000/
no navegador, recebo a seguinte mensagem:
{
"message": "Abra uma issue informando essa resposta. https://github.com/PauloGoncalvesBH/ServeRest/issues",
"error": {
"errno": -2,
"code": "ENOENT",
"syscall": "stat",
"path": "/usr/src/app/docs/localhost.html",
"expose": false,
"statusCode": 404,
"status": 404
}
}
Log da lib Morgan.
Utilizar variável de ambiente para saber se está em produção ou testes.
Isso vai tornar o resultado dos testes mais limpo.
Dica de uso: stryke mutation
Será criado nova rota utilizando GraphQL.
Assim que possuir mais detalhes serão inseridos aqui.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.