Closed apocas closed 10 years ago
Já estou a usar express, num branch à parte (https://github.com/iptomar/letrinhas_si/tree/feature/node-andre), mas não tinha pensado nessa estrutura para os métodos. Parece-me ser interessante.
CORS será necessário se nós quisermos que browsers modernos acedam à API através de XMLHttpRequests. Se as tags de CORS não estiverem presentes na resposta do servidor, a request é descartada no browser.
Já agora, acho que autenticação/autorização deverá ser feita com recurso a Passport.JS (na realidade Passport só faz autenticação, mas extender não deve ser complicado)? As implementações que vi fazem recurso ao MongoDB, mas não deverá haver problemas em implementar aquilo com MySQL.
Já agora, nós estamos a usar JSON para fazer a troca de dados entre o servidor e a app. Isto é ideal se só for coisas básicas, mas continuo a achar que deve haver uma melhor forma de transportar dados binários que sejam igualmente simples de tratar na app. Base64 conversion tem overhead tanto de computação como de espaço (cerca de 30%). O overhead de espaço pode ser mitigado com recurso a compressão gzip, mas o computacional não.
Alternativamente, não se envia dados binários em JSON, mas sim referências, e a app transferia esses recursos diretamente. Eram mais passos, mas o servidor também podia (caso o conteúdo não esteja guardado numa BD) fazer caching dos conteúdos para devolvê-los mais rapidamente, e removia o overhead de computação, apesar de ter que responder a mais HttpRequests.
Correcto, mas pensei que iriam necessitar de fazer algum processamento do audio, etc no backend do backoffice e aí faria sentido o backend do backoffice fazer os pedidos e não o browser.
Sim passport funciona bem, não importa muito onde as credenciais estão guardadas. Agora para a versão inicial e se estiverem sem tempo, podem usar basicauth directamente no express.js e deixar esse tweak para depois. Simplificava o demo do lado do Android também provavelmente.
Pois JSON para os endpoints que necessitam de transportar dados binários também não me parece o ideal, mas aqui não há resposta certa ou errada, é um tradeoff.
Não estamos a pensar implementar autenticação para a versão 0.2. Vamos implementá-la para a versão 0.3, e neste momento, o grupo de SI ainda está a tratar de testar funcionalidades de conectividade na app para depois explicarmos ao grupo da App como tratar dos conteúdos que o servidor lhe envia.
Quanto ao resto, concordo consigo. Provavelmente, a não ser que se implemente coisas como autocomplete em pesquisas ou site do backoffice como uma Single Page App com coisas como AngularJS, CORS não será necessário, mas fica lá porque testar POSTs no browser é mais fácil do que estar à espera um bom bocado pelo emulador :-)
Já agora, obrigado.
Estive a falar com o André Marques (AS @andredcmarques) que esteve a vender-me a vossa possível ideia para arquitectura.
Olhei também para o vosso mockup em node. Alguma sugestões (podem segui-las ou não :) ): Criem um módulo separado para a API. Desta forma a APP Android e o vosso Backoffice eram os dois meros consumidores da vossa API. ( eliminavam a necessidade de cors, etc e separam o backoffice em um processo à parte)
A nível de código se quiserem manter-se com o node ( que eu acho muito bem :P ) usem express.js ou até hapi.js, senão vão perder o fio à meada. Se quiserem um bom exemplo para o vosso caso de uso, deixo-vos uma API Olá Mundo em express.js, não liguem aos endpoints que o trabalho deles era diferente: https://github.com/apocas/node-moss
A nível de análise de sistemas era importante definirem já as assinaturas para os vossos endpoints, pelo que falei com o André seria algo do género...:
//controlador professores GET /api/professores GET /api/professores/:id
//controlador escolas GET /api/escolas GET /api/escolas/:id GET /api/escolas/:id/testes GET /api/escolas/:id/alunos GET /api/escolas/:id/professores
//controlador alunos GET /api/alunos GET /api/alunos/:id POST /api/alunos/:id/submeter/:testeid
//controlador testes GET /api/testes GET /api/testes/:id