Cara aqui vejo 2 erros GRAVÍSSIMOS

Erro da empresa

Por ter contratado um júnior para fazer um trabalho tão complexo.

Você é júnior cara, lembro quando eu tinha 1 ano de experiência e certamente não tinha capacidade para tomar 10% das decisões que estão sendo tomadas. Me preocupo de como vai ficar a qualidade final do projeto.

Erro seu

Por ter iniciado um projeto sem estar analisado.

Tudo estava correndo surpreendentemente bem, já desenvolvi várias telas, fazendo consultas no banco de dados e exibindo dados em tabelas gráficos, entretanto precisei começar a pensar em uma versão de produção para o app..

Um software web hoje, na minha opinião, deve estar na web no dia 1. Você instalou a biblioteca, fez o commit da primeira tela, ele já tem que estar em produção e acessível (CI/CD que fala)

Você gastou um tempo absurdo criando um projeto sem saber se ele vai funcionar? A comunicação com o banco de dados deveria ser a tua primeira preocupação!

Saiba o seu lugar

Quanto somos iniciantes temos muita sede e energia para querer mudar o mundo. Mas você deve saber o desafio que você pode e não pode resolver.

Não vejo você capacitado para resolver esse desafio.

E sinceramente se voê está perguntando essa dúvida aqui é porque sua empresa também não está preparada para esse desafio. Deve contratar gente especializada em infraestrutura, negócios e sobretudo gestão.

Aprenda a dizer não. não tem problema nenhum em dizer que Não sabe, que não tem capacidade pra resolver um desafio. Problema é você assumir uma responsabilidade e falhar com ela.

Enfrentando o problema.

Os erros foram cometidos, agora a questão é reparar.

Você aqui tem 2 opções:

1- Mover as bases de dados para a cloud.

Essa é a solução mais fácil para você. Porém mais difícil para o seu colega e possivelmente traumática para seus clientes.

Aqui deve-se contratar um servidor profissional em uma nuvem grande. Recomendo AWS, Azure, Google ou Oracle.

também implicaria em um custo adicional indesejado

Você está fazendo uma funcionalidade nova. O quanto isso vai gerar de lucro? Se não gerar lucro abandona o projeto e deixa do jeito que está.

Vantagens

• Solução mais rápida e confiável

Desvantagens

• Se todo o sistema em delphi não foi pensado para trabalhar com banco de dados remoto e faz muitas consultas subsequentes todo o sistema vai ficar mais lento por conta da latência.
• Os clientes vão ficar reféns da qualidade de conexão deles. perde toda a vantagem de ser um sistema local

2- A sua aplicação acessar o banco de dados.

Isso facilmente seria resolvido com uma VPN como o Tailscale. Instale a VPN em cada servidor, dê permissão apenas para o servidor web ver cada um deles. E use o MagicDNS para acessar cada banco de dados individualmente.

Vantagens

• Nenhum cliente vai precisar ser impactado por conta da nova funcionalidade. Tudo vai poder rodar na infra atual.

Desvantagens:

• O servidor web vai sofrer com latência alta, vai ter que ter suas querys muito bem oyimizadas para trafegar a menor quantidade de dados possíveis na menor quantidade de querys possíveis.
• O servidor web estará sujeito a disponibilidade da internet e banda de cada cliente. Se um cliente ficar sem internet o sistema inteiro fica fora do ar

Dor de cabeça

Sim, MUITA. O que você mais vai ter com esse projeto vai ser dor de cabeça. Sugiro atualizar seu currículo, aplicar pra, no mínimo, 100 vagas por dia e sair daí o mais rápido possível.

Uma empresa que trabalha há 20 anos vendendo um software e não dá valor ao core business só tem um caminho: a falência.

Uma dúvida pessoal: Se cada criente tem sua base local como são feitos os backups? o que acontece se aquele computador que fica lá no canto queimar do dia pra notie?

O que mais me impressiona é um júnior entrar numa empresa e em pouco tempo ter que tomar decisões de negócio, resolver B.O gigantes, ao invés de estar fazendo as issues do projeto. Não sei como ajudar, mas eu deixaria claro que isso não faz parte da minha função dentro do time, ta com cara de infra.

Sem delongas, vou falar o que eu fiz numa situação muito semelhante. Não encare como sugestão, apenas é algo que fiz e pode ser interessante como caso de estudo.

Meu cliente possui varias filiais onde cada uma tem uma copia do banco de dados. Aplicação desenvolvida em Delphi e banco de dados Firebird. Eu precisava sincronizar todos os bancos de todas as filiais para montar um estoque centralizado (virtualmente centralizado) pois eles precisam alem de vender nas lojas fisicas, agora vender em um site proprio e em marketplaces. Isso significa que eu tambem teria que dar baixa no estoque quando um produto fosse vendido online. Sendo assim eu precisaria de comunicacao entrando e saindo de todos os bancos o tempo todo.

Como eu resolvi?

Simples. Desenvolvi duas aplicacoes uma client (que eu instalo na maquina que está o banco de dados da loja) e outra aplicação que eu hospedo num servidor que vai centralizar e orquestrar toda essa bagunça.

Por questões de segurança eu jamais coloco um computador exposto na internet. No lugar, eu faço o app client se comunicar com o banco de dados e sincronizar com o app servidor. É app falando com app.

O client coleta os dados locais e envia para o server na nuvem. O server processa isso de todos os canais (client, site e marketlaces).

Depois de processado, o server deixa uma resposta em fila para entregar ao client na proxima vez que ele conectar ao server para enviar as ultimas atualizações locais. Nesse momento, o server aproveita a conexão do client e devolve para ele os novos valores de estoque.

O server nunca fica com os dados armazenados nele. A informação é usada apenas até que o sincronismo esteja finalizado. Assim que todos os registros foram devidamente teansferidos para todos os clients, a info do server é apagada. Isso garante a segurança dos dados e permite que o server seja um terminal volatil que pode ser apagado, reiniciado, desligado que a informacao do server é apenas o resultado da coleta do que os clients enviam para ele. Por isso, se o server morrer e eu precisar reinstalar na nuvem novamente, eu nao preciso nem me preocupar com backup, pois na hora que ele iniciar a primeira vez após a manutencão, ele vai aguardar os dados que os clients vão enviar pra ele e tudo volta ao normal.

Como disse, solução simples, segura e barata.

pessoas são avessas a mudanças, bruscas ou não, independente da idade. é da natureza humana.

como funciona esse lance do acesso via VPN? vc conecta na vpn, o cliente tb e ai vc acessa pelo IP da rede local?

algumas perguntas para expandir o contexto aqui: -qual a razão por trás de ter um "datacenter on premise" basicamente? conexão de internet instável? -alem do banco rodando local, o que mais vc tem nessas localidades? -essas localidades tem internet sempre ou alguem precisa tambem conectar a internet (que seja trocando um cabo de porta no roteador ou equivalente) -que tipos de serviço já usam hoje? para não sugerir algo completamente fora da realidade

se bem entendi a sua necessidade é conseguir se conectar no DB sem precisar ligar pro João e pedir pra ele entrar na VPN, é isso mesmo?

A solução que vejo, é você montar um DCL na empresa e hospedar o banco de dados lá! É um custo adicional, mas um custo único. 40k em um data center local que não vai precisar de upgrade por alguns anos. Afirmo isso porque pelo seu relato, a empresa não deve ter um fluxo tão alto de clientes, então ter um cluster na sua empresa com os custos de banda, domínio e o básico para infra, como firewall, link secundário e etc. Essa é a melhor solução viável que vejo pra sua situação. Não necessariamente você precisa gastar uma grana que provavelmente a empresa não tem, pode ser um DCL simoles com custo de implantação na faixa dos 15k.

Outra solução não muito viável, é você arriscar usar um banco de dados online gratuito, mas isso vai causar um atraso na escalabilidade do seu sistema, tento inclusive um possível gargalo quando o banco tiver peso.

Está aí os meus 10 centavos de contribuição, também sou Jr. Na verdade, menos que Jr, estudo desenvolvimento Full Stack a 2 anos e isso é o que me veio na cabeça com sua explicação e a leitura da interação dos outros membros.

Minha stack é Angular + Nestjs + Java + OCI, estamos quase no mesmo barco. Boa sorte, sucesso pra você.

Rapaz, que situação complicada. Não sei se entendi completamente o problema, e peço desculpas se estiver falando besteira.

Eu proporia um plano de migração da seguinte forma:

• Modelo legados: continuarão como estão, mas explicaría que novas funcionalidades estarão disponíveis na versão web do produto.
• Modelo misto: para esses clientes, eu criaria um contêiner Docker para sua aplicação web e o instalaria na mesma máquina local que o FirebirdSQL. Os clientes poderiam continuar usando o Delphi, mas também teriam acesso à aplicação web na mesma rede. Isso permitiria que os usuários experimentassem a nova aplicação e se familiarizassem com a versão web.
• Modelo web: neste modelo, os usuários não teriam mais o Delphi local e acessariam tudo pela web. O banco de dados ficaria aonde voce quiser (acredito que em nuvem).

Na disciplina de economia comportamental, é dito que: "As pessoas mudam seu comportamento através de incentivos."

Crie um marketing persuasivo, explicando as vantagens do modelo web (mais barato, maior conveniência, melhor suporte, novas funcionalidades, etc.). Se os incentivos forem suficientemente atrativos, as pessoas mudarão.

Nota: O modelo misto que mencionei é bem arriscado; é arriscado ter duas applicacoes rodando em paralelo. Contudo, se o sistema atual é realmente legado e nao tem muitas atualizacoes; talvez este modelo misto funcione. Apenas voce pode avaliar isso.

agora há somente um desenvolvedor que está há mais de 20 anos aqui e que faz as manutenções e implementações de novas funções sozinho.

Ja perguntou para este desenvolverdor mais experiente? O que ele acha?

Se quer algo mais moderno que Delphi, só usar Java e JPA, é justamente para isso, a única coisa que tem que fazer na aplicação é instalar um driver para cada tipo de banco de dados. Se não dão acesso a internet o jeito é carga fria, cliente salva os dados em um .csv, compacta e envia por e-mail, pendrive e motoboy, conexão discada, o jeito que der. Vai ter problemas de dados desatualizados, vai, mas a empresa e cliente não querem investir nada não tem jeito. Lembrei de um diretor me botando pressão, falando que o "software estava lento", só falei assim, olha os dados aumentaram 20x, vai ter que investir em hardware agora. O cara de pau ainda mandava as funcionárias falar comigo, eu só dizia, o problema é hardware, conversa com o diretor. Um bocó de outra área, querendo agradar o diretor, usou cache indiscriminadamente, fez um monte de gambiarras, só para melhorar pouca coisa, mas no geral continuou lento e pior todo dia era a mesma coisa, pessoal falando que os dados estavam diferentes, ele falando para limpar cache.

Não falo mais que o Pilati falou. Mas uma coisa boa é que você vai aprender muito no meio desse caos e vai poder ir pra uma empresa melhor ou mais organizada. :)

O pingo de esperança para o seu problema

Cara uma solução que me veio a cabeça é aproveitar do aplicativo dentro do pc local e fazer uma conexção reversa com o back-end.

Um exemplo disso seria.

O ARQUIVO.EXE > NO PC COM ACESSO AO BANCO LOCAL > ENVIA UM REQUEST PARA O BACK-END CRIANDO UMA SESSÃO WEBSOCKET > AI O BACK-END FICA COM ACESSO "AO PC" PODENDO FAZER AS CONSULTAS POR LÁ ENVIANDO AS QUERYS SQL.

Bem eu não vejo "falha" nessa solução apartir das seguintes afirmações.

• O Pc da empresa precisa estar ligado (em resumo a empresa precisa estar com ernegia e aberta para o sistema web funcionar)
• A empresa tem que ter acesso a internet
• O usuario do sistema web teria o acesso enquanto a empresa estivesse funcionando (06:00 as 17:00)

Então a partir do momento que vc tem acesso a essa confirmações dos clientes do serviço essa solução é totalmente valida ao meu ver.

(estou aberto a perguntas e apontamento de erros é claro com respeito por favor).

Qual o tamanho do banco de dados destas empresas que são clientes do teu sistema?

Amigo, bom dia. Gostaria de fazer alguns comentários, mas não ficou claro pra mim, se:

• Você precisa ter acesso ao ambiente do cliente para dar suporte
  • Se o acesso basta ser apenas ao banco de dados ou se precisa acessar demais arquivos, como a propria aplicação
  • Se existe a necessidade efetual de ações de updates pontuais, ou se é um acesso para leitura apenas, para diagnosticar problemas e depois sim, fazer uma ação mais efetiva
• Você precisa ler as informações de tempos em tempos, mesmo sem a necessidade de suporte, pra acompanhar algo na operação do cliente.

Sobre o banco de dados. Não sei se é viável. Todas soluções requerem análise prévia. De custos e tempo de implementação. Você poderia adquirir pra desenvolvimento e teste uma instância de um banco RDS na AWS e incluir um novo database para cada cliente se não forem muitos. Ou alterar o banco pra funcionar com multi-tenant (um único banco com vários clientes plugados e acesso as tabelas vinculado por id de cliente, resumo tosco... na prática a treta é maior). Tu consegue uma instancia de banco rodando free por um ano. Veja nos demais provedores qual é mais vantajoso. No fim a ideia seria repassar os custos da instancia para os clientes ou incorporar como custos da empresa.

Já lidei com um problema parecido. Trabalhei em um ecommerce para farmácias e algumas delas usavam erp para controlar o estoque porém era interno/local. Tínhamos um serviço que rodava local que enviava pra uma fila os estoques 2 vezes ao dia para sincronizarmos com o ecommerce.

Não sei se é viável sincronizar o banco todo. Mas espero poder contribuir aí com a solução do seu problema.

Procure implicações da lgpd sobre uso do banco de dados. Se for utilizar banco na nuvem procure orientações sobre boas práticas de uso pois as implicações de vazamentos podem ser catastróficas. Lembre também que os custos recaem sobre a infra do banco (tamanho/potencia da máquina que implica na velocidade e capacidade de cache do banco), armazenamento (quantidade de memória em disco) e backup (tamanho e quantidade de vezes)