formulário para preencher o `data.json`

[jfoclpf]

Bom projeto, parabéns

Como é que estás a pensar alimentar o data.json? Com commits? Esquece, quase ninguém o fará. Falo por experiência própria.

Pensa em desenvolver um user-interface, tipo formulário, para qualquer um preencher o data.json, pois daqui a 3 meses já não vais ter paciência para seres tu a fazê-lo.

Não vai ser possível apenas com uma página github, terás que ter algo server-side, digo eu.

[portulemicas]

Antes de tudo, peço desculpa pela demora na resposta.

Obrigado.

Segui o conselho e atualizei a interface integrada com uma api de forma a que qualquer pessoa possa adicionar dados preenchendo um simples formulário. Este update deverá estar live agora.

[jfoclpf]

Fixe, qual o URL?

Altera também o readme.md desta repo adicionando os URLs onde está o site alojado. Por exemplo agora estou a usar apenas a GitHub app e estou perdido, não faço ideia qual o URL principal

Nas definições do GitHub do repo há também um campo para o website, edita em conformidade.

Bom trabalho

[portulemicas]

O url é portulemicas.com, no entanto, estou com alguns problemas com o servidor da api relativamente a disponibilidade.

Sim, tenho de editar o readme ainda para incluir mais info

[jfoclpf]

Qual é o problema que tens com o servidor? Eu tenho um bom servidor, queres que eu aloje a API? Corre em quê?

[portulemicas]

dei host à api no render.com , o problema é que às vezes não obtenho resposta aos pedidos. Não tendo resposta, não dá para sincronizar os dados, o que faz do site um pouco menos útil.

A api foi escrita em nodejs/express

[jfoclpf]

Será problema do render.com ?

Em que é que corres o backend? Quanto pagas no render.com?

Não queres pôr isso numa VPS? Por exemplo esta:

https://contabo.com/en/vps/vps-s-ssd/?image=ubuntu.267&qty=1&contract=1&storage-type=vps-s-200-gb-ssd

Têm taxas de acessibilidade de 99%

Eu posso doar te os primeiros 3 meses

[bentodaniel]

contactei a malta do render, eles também não sabem explicar.

uma vez que se trata de um side-project, estou a usar o web-service free, sendo que o downside deveria ser que, às vezes, o tempo de load se poderia aproximar dos 30 segundos, o que nem acho muito problemático.

Tbh, nunca dei host a uma api, pelo que ando meio a apalpar, nem nunca usei também uma vps (nem cheguei a considerar)

[jfoclpf]

Mas que tipo de API estamos a falar, ainda não percebi? O que é que faz exatamente a tua API? Desenvolveste a API em quê? Python?

As polémicas são guardadas numa BD ou vão para aquele ficheiro data.json aqui no repo?

Uma VPS faz milagres, na prática é um servidor Linux para tu brincares sempre ligado à net.

A página demorar 30 segundos a carregar parece-me claramente exagerado para uma página web.

[bentodaniel]

a api serve apenas para conectar ao firebase, que é onde os dados são guardados. Assim, qualquer utilizador consegue também adicionar novos dados. Está feita em nodejs/express.

Neste momento, idealmente vao para a bd no firebase e, ao carregar a página, são obtidos do firebase. Se em 30 segundos não houver resposta da api, são carregados do data.json.

Os 30 segundos são (em principio) o máximo que os web-services poderão demorar a voltar a ligar quando se desligam por inatividade. E, sim, pode ser um pouco mais do que devia, mas é o drawback de ter a api up free.

[jfoclpf]

epah, node/express é a minha praia, configurar uma VPS com node/express posso até alojar isso no meu servidor, caso queiras pois já lá tenho uma data de serviços desses a correr, envia-me apenas o código, ou melhor ainda, faz desta github repo uma monorepo e coloca aqui também o código backend node/express. Node/express com NGINX e fica operacional, se quiseres faço isso.

Mas conseguiste identificar a que se deve o tempo de espera? Do render.com ou do firebase?

Em vez de estares dependente do Firebase, podias simplesmente no mesmo servidor ter uma BD MySql (free and open source)

[bentodaniel]

Agraceço, mas também não queria ficar sem controlo do servidor que alojasse api, compreendes?

O tempo de espera é só devido ao render. Como estou na tier free, o serviço desliga-se após algum tempo de inatividade e pode levar 30 segundos a re-ativar. A questão de o servidor às vezes não responder, de todo, também é do render, mas ninguém sabe o porquê de estar a acontecer.

[joao]

@bentodaniel Experimenta o fly.io, que tem um tier gratuito de 3x instancias de 256MB e não pagas mais se não excederes adicionalmente $5 mensais. Não tem o sleep que o Render ou Heroku tem.

Tens aqui a referência para correr Node:
https://fly.io/docs/languages-and-frameworks/node/

[jfoclpf]

Agraceço, mas também não queria ficar sem controlo do servidor que alojasse api, compreendes?

Claro que sim, nesse caso, contrata os serviços de uma VPS, tens VPS muito baratinhas no mercado

Ou então segue a dica do @joao

confesso que não estou mesmo a par desta nova tech de colocar APPs diretamente "ready to run" na nuvem, estou mais habituado a configurar tudo de raiz com VPS num servidor Linux/Ubuntu.

@joao como é que carregas o código Node? Ftp? Copy-paste diretamente no browser? Aquilo depois fornece um subdomínio, é isso?

[joao]

@jfoclpf O método de deployment, após instalar a ferramenta CLI deles, é escrever no terminal fly deploy. Isto após correr outro comando para criar um ficheiro de configuração e até um dockerfile.

Num repositório GitHub também se pode configurar uma Action que corre o comando acima e faz deployment a cada commit. Mas não se coloca isso directamente num repositório GitHub público, porque tem um token que dá acesso à tua conta, então deve-se colocar um private token nas settings do repositório.

É fornecido um sub-domínio, já com SSL activado, para o qual podemos apontar domínios/sub-domínios nossos.

Tutorial básico aqui: https://fly.io/docs/getting-started/launch-app/

[jfoclpf]

muito interessante, desconhecia, obrigado @joao

[bentodaniel]

obrigado @joao, não conhecia o fly.io, vou dar uma vista de olhos.

Terei de ver as alternativas que tenho, no entanto, @jfoclpf sem duvida que já me puseste o bichinho da vps na cabeça. O meu maior problema com a vps é que parece overkill para ter apenas uma api a correr

[jfoclpf]

@bentodaniel depende do tráfego da API

Eu não sei qual o plano gratuito desses serviços tipo fly.io mas diria que sai sempre mais barato uma VPS no longo prazo com algum tráfego. Além disso podes ter lá outras apps ou serviços ou websites que venhas a criar no futuro sem qualquer custo adicional.

Numa VPS pagas apenas uma mensalidade fixa. Tens VPS muito baratas, tipo 5€ por mês.

https://themeisle.com/blog/cheap-vps-hosting/

Se avançares recomendo instalares Ubuntu ou Debian based. O APT dá muito jeito. Completamente gratuito, naturalmente.

Para node/express recomendo vivamente nginx para servidor http e MySql para base de dados, pois são gratuitos e Open source e de longe os que têm mais info na net para ajuda.

[joao]

@bentodaniel se quiseres explorar uma abordagem serverless, experimenta Vercel, com este tutorial: https://vercel.com/guides/using-express-with-vercel

Pegando no que o @jfoclpf aconselhou, se quiseres experimentar MySQL, sem te preocupares com configurações, tens um novo serviço chamado PlanetScale, com um bom plano gratuito. Desenvolvido por antigos programadores do GitHub e mesma tecnologia.

Para servidor web, o Caddy também uma é boa escolha e bastante developer friendly.

[bentodaniel]

@jfoclpf sim, acredito que se o tráfego começar a ser muito, uma vps seja de facto a melhor opção, mas é a tal cena, sendo, neste momento, um side-project, não sei até que ponto compensará. Vou ver as alternativas também, e claro, se avançar com a vps, será sempre ubuntu (ou debian). Nginx nunca usei, mas certamente não é um bicho de 7 cabeças.

@joao vercel por acaso já conhecia, mas não cheguei a experimentar. Já o PlanetScale e o Caddy, nem por isso.

Neste momento acho que vou manter a api no render.com, ver se o serviço estabiliza ou se terei mesmo de procurar alternativas.