Um aplicativo Web típico é praticamente sem estado , devido à sua natureza de solicitação / resposta . O protocolo HTTP é o melhor exemplo de protocolo sem estado . Mas como a maioria dos aplicativos da web precisa de estado , para manter o estado , entre servidor e cliente, os cookies são usados para que o servidor possa enviar todas as respostas de volta ao cliente. Isso significa que a próxima solicitação feita do cliente incluirá esse cookie e será reconhecida pelo servidor. Dessa forma, o servidor pode manter uma sessão com o cliente sem estado , sabendo principalmente tudo sobre o estado do aplicativo , mas armazenado no servidor. Nesse cenário, em nenhum momento o cliente mantémestado , que não é como o Ember.js funciona.
No Ember.js, as coisas são diferentes. O Ember.js facilita o trabalho do programador, pois detém de fato o estado para você, no cliente, sabendo a cada momento sobre seu estado sem precisar fazer uma solicitação ao servidor solicitando dados de estado .
No entanto, manter o estado no cliente também pode às vezes apresentar problemas de simultaneidade que simplesmente não estão presentes em situações sem estado . No entanto, o Ember.js também lida com esses problemas, especificamente dados do brasa são criados com isso em mente. Em conclusão, o Ember.js é uma estrutura projetada para clientes com estado .
O Ember.js não funciona como um aplicativo Web sem estado típico, em que a sessão , o estado e os cookies correspondentes são tratados quase completamente pelo servidor. O Ember.js mantém seu estado completamente em javascript (na memória do cliente e não no DOM como em outras estruturas) e não precisa do servidor para gerenciar a sessão. Isso resulta em Ember.js sendo mais versátil em muitas situações, por exemplo, quando seu aplicativo está no modo offline.
Obviamente, por razões de segurança, é necessário enviar algum tipo de token ou chave exclusiva ao servidor sempre que uma solicitação é feita para ser autenticada , dessa forma o servidor pode procurar o token de envio (que foi inicialmente emitido pelo servidor) e verifique se é válido antes de enviar uma resposta de volta ao cliente.
Na minha opinião, a principal razão pela qual usar um token de autenticação em vez de cookies, conforme indicado nas Perguntas frequentes sobre autenticação de Ember, é principalmente devido à natureza da estrutura Ember.js e também porque se encaixa mais no paradigma de aplicativo da Web com estado . Portanto, o mecanismo de cookie não é a melhor abordagem ao criar um aplicativo Ember.js.
Espero que minha resposta dê mais significado à sua pergunta.