Respostas às perguntas
Quem é responsável pela formatação dos dados, por exemplo, preços. API Magento e estrutura de front-end?
A API Magento fornece acesso aos dados e à lógica de negócios . A formatação de dados / preços faz parte da lógica de apresentação , portanto, dessa forma, você tem mais flexibilidade para apresentar as informações da maneira que desejar (sem ser forçado a fazê-lo no Magento).
Por exemplo, você pode utilizar o javascript para detectar configurações de localidade e fornecer dados apropriados. Verifique o seguinte:
navigator.language
toLocaleString ()
Ou você pode optar por importar os preços do Magento para o sistema de terceiros ou a ferramenta de análise de dados, e ter preços formatados de acordo com o formato da moeda apenas interromperá o processo de importação até você resolver a "conversão de moeda".
Quem é responsável por redimensionar as imagens do produto e armazená-las em cache? Porque na API nativa do Magento 2 não há redimensionamento ou sistema de cache.
Exatamente. Como eu disse acima, o Magento fornece acesso aos dados (sem lógica de apresentação). Depende de você como o usará.
Por exemplo, você pode optar por redimensionar a imagem adaptável http://adaptive-images.com/details.htm , para poder usar facilmente a imagem original e fazer o que quiser.
Você pode escolher a maneira como armazenará as imagens em cache, deseja usar a compactação com ou sem perdas para reduzir imagens, etc.
Preciso criar uma nova API isolada personalizada ou estender o nativo para fins de atualização futura?
Eu recomendo que você faça sua API que será usada para a lógica de apresentação, e você terá 99,9% (meu palpite) de que não será afetado por uma futura atualização da API Magento2.
Você recomenda o uso de uma camada extra para combinar CMS e Magento API?
Altamente recomendado. Mas, a camada extra não precisa ser um aplicativo adicional; também pode ser um módulo Magento2. O bom disso é que você é livre para combiná-lo como quiser; você pode criar sua camada de proxy usando qualquer idioma / tecnologia que desejar.
Agradeço por compartilhar seu retorno em experiência.
Existem muitas abordagens que você pode usar aqui. Vou compartilhar minha opinião sobre isso.
Minha abordagem ao decapitado
Primeiro, eu o dividiria em duas camadas: camada proxy e camada de apresentação .
Camada de proxy
A primeira coisa que você deve considerar é sobre a criação da camada Proxy. Nos bastidores, você pode utilizar a API Magento, API CMS, API ERP, API x, o que quiser ...
Na camada de proxy, você pode usar e organizar os dados da maneira que desejar. Você pode implementar a camada de cache lá, bem como funcionalidades adicionais para formatação de dados, rastreamento de clientes, várias automatizações, etc. Em geral, tudo o que você precisa para fazer malabarismos fáceis na camada de apresentação.
A camada de proxy não precisa ser codificada em PHP; ele pode ser codificado em Java, NodeJS ou você pode utilizar o AWS API Gateway, o AWS SQS e o Lambda para fornecer uma camada proxy inteira ou apenas parte dela.
Uma das abordagens que você pode usar é descrita por Fabrizio Branca em http://fbrnc.net/blog/2015/10/super-scaling-magento
Camada de apresentação
A camada de apresentação depende da plataforma do cliente; se você for usá-lo no aplicativo móvel, as coisas ficam bem claras sobre como você deve utilizar a API proxy.
Para um aplicativo da web, existem muitas possibilidades. Você pode usar:
- Solução PHP padrão (desenvolvida por qualquer estrutura), na qual você pode utilizar qualquer um dos mecanismos de modelagem PHP (como Smarty, Twig, Dwoo ...) para fornecer saída HTML
- Java / NodeJS / qualquer idioma com o qual você se familiarize
- Solução puramente baseada em javascript, que renderizaria todo o HTML e chamaria APIs apropriadas por meio do ajax para preenchê-lo com dados
- Qualquer híbrido / combinação dessas abordagens acima
Isso não está na lista de livros , acabei de compartilhar algumas combinações. Na realidade, sua imaginação é o único limite.
Pensamentos finais
Use a solução baseada em javascript o máximo possível, pois pode proporcionar uma melhor experiência ao Cliente, menor carga útil para carregamentos de páginas, você pode até carregar dados especulativos se puder prever as próximas ações do cliente.
MAS, o problema com a solução puramente javascript é SEO. Se todos os seus dados forem carregados pelo Ajax, o Google provavelmente não poderá analisá-los.
A solução é criar um aplicativo híbrido que atenda a página HTML inteira no primeiro carregamento, por exemplo, quando você clica em / catalog / shoes. Para qualquer navegação adicional no site, você pode utilizar o ajax para buscar apenas os blocos necessários.
Uma das abordagens seria criar instantâneos da sua página, por exemplo, usando o PhantomJS . Também existem poucas soluções pagas para isso, como: