Lançamos o Project IDX, nossa nova experiência de desenvolvimento experimental baseada em navegador, para simplificar o caos da criação de aplicativos de pilha completa e agilizar o processo de desenvolvimento de ponta a ponta (de back-end a front-end).
Em nossa experiência, a maioria dos aplicativos da Web é criada com, pelo menos, duas camadas diferentes: uma camada de front-end (IU) e uma camada de back-end. Quando você pensa no tipo de app que criaria em um espaço de trabalho de desenvolvedor baseado em navegador, talvez não considere imediatamente apps de pilha completa, com back-ends robustos e totalmente funcionais. O desenvolvimento de um back-end em um ambiente baseado na Web pode se tornar complicado e dispendioso muito rapidamente. Entre diferentes configurações de autenticação para ambientes de desenvolvimento e produção, comunicação segura entre back-end e front-end e a complexidade de configurar um ambiente de teste (hermético) totalmente autônomo, os custos e os inconvenientes podem aumentar.
Sabemos muitos de vocês estão ansiosos para experimentar o IDX, mas, por enquanto, gostaríamos de compartilhar esta postagem sobre o desenvolvimento de pilha completa do Project IDX. Desvendaremos algumas das situações complexas que você talvez enfrente como desenvolvedor ao criar suas camadas de front-end e back-end em um espaço de trabalho baseado na Web — autenticação do desenvolvedor, comunicação entre front-end e back-end e testes herméticos — e mostraremos como tentamos tornar tudo um pouco mais fácil. E, obviamente, queremos saber de vocês o que mais poderíamos criar para facilitar o desenvolvimento de pilha completa!
Em primeiro lugar, simplificamos o processo para permitir a comunicação de front-end dos aplicativos com os serviços de back-end na VM, facilitando a visualização de aplicativos de pilha completa no navegador.
Os espaços de trabalho do IDX são criados no Google Cloud Workstations e acessam com segurança os serviços conectados por meio de contas de serviço. A conta de serviço exclusiva de cada espaço de trabalho oferece suporte a ambientes de visualização contínuos e autenticados para o front-end dos aplicativos. Portanto, quando o Project IDX é usado, as visualizações dos aplicativos são criadas diretamente em seu espaço de trabalho, e você não precisa configurar um caminho de autenticação diferente para visualizar a IU. Atualmente, o IDX suporta apenas visualizações da Web, mas as visualizações de aplicativos para Android e iOS chegarão em breve aos espaços de trabalho do IDX perto de você.
Além disso, se uma configuração exigir a comunicação com a API de back-end em desenvolvimento no IDX fora da visualização do navegador, estabelecemos alguns mecanismos para fornecer acesso temporário às portas que hospedam esses back-ends de API.
Se você estiver usando um framework que atende às camadas de back-end e front-end da mesma porta, poderá transmitir a flag $PORT para usar uma variável de ambiente PORT personalizada no arquivo de configuração do espaço de trabalho (alimentado pelo Nix e armazenado diretamente no espaço de trabalho). Isso faz parte do fluxo básico de configuração no Project IDX, portanto não é necessário fazer nada particularmente especial (além de definir a variável no arquivo de configuração). Veja aqui um exemplo de arquivo de configuração baseado em Nix:
{ pkgs, ... }: {
# NOTE: This is an excerpt of a complete Nix configuration example.
# Enable previews and customize configuration
idx.previews = {
enable = true;
previews = [
{
command = [
"npm"
"run"
"start"
"--"
"--port"
"$PORT"
"--host"
"0.0.0.0"
"--disable-host-check"
];
manager = "web";
id = "web";
}
];
};
No entanto, se o servidor de back-end estiver sendo executado em uma porta diferente do servidor de IU, você precisará implementar uma estratégia diferente. Um método é fazer do front-end o proxy do back-end, assim como você faria com as opções de servidor personalizadas do Vite.
Outra maneira de estabelecer a comunicação entre as portas é configurar o código para que o JavaScript em execução na IU possa se comunicar com o servidor de back-end usando solicitações AJAX.
Vamos começar com um exemplo de código que inclui um back-end e um front-end. Este é um servidor de back-end escrito em Express.js:
import express from "express";
import cors from "cors";
const app= express();
app.use(cors());
app.get("/", (req, res) => {
res.send("Hello World");
});
app.listen(6000, () => {
console.log("Server is running on port 6000");
})
A linha em negrito no exemplo — app.use(cors()); — configura os cabeçalhos CORS. A configuração pode ser diferente com base na linguagem e no framework escolhidos, mas o back-end precisará retornar esses cabeçalhos se você estiver desenvolvendo localmente ou no IDX.
Quando você executa o servidor no terminal do IDX, as portas de back-end aparecem no painel IDX, e cada porta em que o servidor é executado é automaticamente mapeada para um URL que você pode chamar.
Agora, vamos escrever um código de cliente para fazer uma chamada AJAX para esse servidor.
// This URL is copied from the side panel showing the backend ports view
const WORKSPACE_URL = "https://6000-monospace-ksat-web-prod-79679-1677177068249.cluster-lknrrkkitbcdsvoir6wqg4mwt6.cloudworkstations.dev/";
async function get(url) {
const response = await fetch(url, {
credentials: 'include',
});
console.log(response.text());
}
// Call the backend
get(WORKSPACE_URL);
Também é preciso garantir que a chamada fetch() inclua credenciais. Os URLs do IDX são autenticados, por isso precisamos incluir credenciais. Dessa forma, a chamada AJAX inclui os cookies para autenticação em nossos servidores.
Se você estiver usando XMLHttpRequest em vez de fetch, poderá definir a propriedade "withCredentials" da seguinte maneira:
const xhr = new XMLHttpRequest();
xhr.open("GET", WORKSPACE_URL, true);
xhr.withCredentials = true;
xhr.send(null);
Seu código pode diferir de nossos exemplos com base na biblioteca de cliente que você usa para fazer as chamadas AJAX. Se isso acontecer, consulte a documentação de sua biblioteca de cliente específica para saber como fazer uma solicitação credenciada. Mas certifique-se de fazer uma solicitação credenciada.
Em alguns casos, talvez você queira acessar seu aplicativo no Project IDX sem fazer login em sua conta do Google ou em um ambiente em que não seja possível fazer esse login. Por exemplo, se você quiser acessar uma API que está desenvolvendo no IDX usando Postman ou cURL na linha de comando de um laptop. Para isso, basta usar um token de acesso temporário gerado pelo Project IDX.
Depois que o servidor estiver em execução no Project IDX, você poderá abrir o menu de comando para gerar um token de acesso, que é um token de curta duração que permite temporariamente acessar a estação de trabalho.
É extremamente importante observar que esse token fornece acesso a todo o espaço de trabalho do IDX, incluindo, entre outros, seu aplicativo na visualização. Portanto, você não deve compartilhá-lo com ninguém. Recomendamos que você o utilize apenas para testes.
Quando você executar esse comando no IDX, o token de acesso aparecerá em uma caixa de diálogo. Copie o token de acesso e use-o para fazer uma solicitação cURL para um serviço em execução na estação de trabalho, como esta:
$ export ACCESS_TOKEN=myaccesstoken
$ curl -H "Authorization: Bearer $ACCESS_TOKEN" https://6000-monospace-ksat-web-prod-79679-1677177068249.cluster-lknrrkkitbcdsvoir6wqg4mwt6.cloudworkstations.dev/
Hello world
Agora, você já pode executar testes a partir de um ambiente de servidor autenticado!
Como destacamos, você pode testar o front-end e o back-end do aplicativo em um ambiente totalmente autocontido, autenticado e seguro usando o IDX. Você também pode executar emuladores locais no ambiente de desenvolvimento baseado na Web para testar os serviços de back-end do aplicativo.
Por exemplo, você pode executar o Pacote de emuladores locais do Firebase diretamente no espaço de trabalho do IDX. Para instalar o pacote de emuladores, execute firebase init emulators na guia Terminal do IDX e siga os passos para configurar quais emuladores você deseja e em quais portas.
Após a instalação, você poderá configurá-los e usá-los da mesma forma que faria em um ambiente de desenvolvimento local no terminal do IDX.
Como você pode ver, o Project IDX pode atender a muitas de suas necessidades de desenvolvimento de pilha completa: do front-end ao back-end e a todos os emuladores intermediários.
Se você já usa o Project IDX, marque-nos nas redes sociais com #projectidx para que possamos saber como o Project IDX tem ajudado você no desenvolvimento de pilha completa. Para se inscrever na lista de espera, visite idx.dev.
Google I/O 2024: What’s new in Android Development Tools
How Firebase Genkit helped add AI to our Compass app
Everything you need to know about Google Wallet
Ajuste o Gemini Pro no Google AI Studio ou com a API Gemini
Série de vídeos Build with Google AI, 2ª temporada: mais padrões de IA
Welcome India to the Google Wallet API