Magento 2 como solución sin cabeza

48

Quiero saber si hay algunas mejores prácticas para usar Magento 2 como una solución de comercio electrónico sin cabeza .

Un comercio electrónico típico en 2017 es tener una solución omnicanal que incluya

  • Comercio electrónico
  • CMS
  • Multiplataforma
  • Integración del sistema de niveles (ERP, ...)

Quiero saber cómo involucrar a Magento 2 API con este tipo de solución.

Mi acercamiento:

  • Use un marco frontend diferente (como angular) para aplicaciones web de escritorio / móviles y aplicaciones móviles

  • Utilice solo la API de Magento 2 para recuperar o interactuar con datos / acciones de comercio electrónico

  • Solo use la API de CMS para recuperar datos de CMS.

Pro: solo API, omnicanal

Contras: Limitación de rendimiento / características / formato

Algunas preguntas para este enfoque:

  • Quién es responsable de formatear los datos, por ejemplo, los precios. ¿API de Magento y marco frontend?
  • ¿Quién es responsable de cambiar el tamaño de las imágenes del producto y almacenarlas en caché? Porque en la API nativa de Magento 2 no hay cambio de tamaño o sistema de caché.
  • ¿Necesito crear una nueva API aislada personalizada o ampliarla nativa para futuras actualizaciones?
  • ¿Recomiendas usar una capa adicional para combinar CMS y Magento API?

Le agradezco que comparta su retorno de experiencia.

Además, encontré este enfoque: http://fbrnc.net/blog/2015/10/super-scaling-magento

Enlaces útiles:

EDITAR:

Encontré un buen arranque para crear su propia lógica de caché para su API de Magento 2: https://github.com/magespecialist/m2-MSP_APIEnhancer

EDITAR: Un buen proyecto de código abierto para usar Magento 2 como un comercio electrónico sin cabeza con VueJS PWA: https://github.com/DivanteLtd/vue-storefront

EDITAR: Las herramientas oficiales de Magento 2 PWA basadas en React: https://github.com/magento-research/pwa-studio

magento2 api best-practice Franck Garnier
fuente
: / No estoy seguro de que me guste esta moda "sin cabeza", quiero decir que los desarrolladores inteligentes lo han estado haciendo durante años cuando es necesario, hacen una interfaz y solo usan consultas de la base de datos para manipular los datos, con almacenamiento en caché de consultas, estructuras de datos de memcaching y página completa almacenamiento en caché según sea necesario.
Wolfe
Sí, pero necesita una interfaz como la API de Magento 2.
Franck Garnier
En realidad no, todas las interfaces CRUD son capas innecesarias adicionales para consultas SQL, para las interfaces que hacen más, a menudo puede arrancar y simplemente hacer llamadas a funciones / métodos nativos para hacer lo que sea necesario. Todo lo que digo es que es solo un nuevo nombre para algo que existe desde hace mucho tiempo. Probablemente no lleguemos a un consenso y este probablemente no sea el lugar para hacerlo, así que buena suerte con su proyecto.
Wolfe
Nunca dije que este enfoque es nuevo. Pero incluso si puede hacerlo sin la capa API de Magento con consulta directa, pierde todos los beneficios de mantenimiento. Como la abstracción de la base de datos, la compatibilidad con versiones anteriores, etc. Puede evitar la API de Magento, pero necesita agregar su propia capa. Gracias.
Franck Garnier

Respuestas:

38

Respuestas a las preguntas.

Quién es responsable de formatear los datos, por ejemplo, los precios. ¿API de Magento y marco frontend?

La API de Magento proporciona acceso a los datos y la lógica empresarial . El formato de datos / precios es parte de la lógica de presentación , por lo que de esta manera, tiene más flexibilidad para presentar la información de la manera que desee (sin verse obligado a hacerlo en el modo Magento).

Por ejemplo, puede utilizar javascript para detectar la configuración regional y proporcionar datos apropiados. Verifique lo siguiente: navigator.language toLocaleString ()

O incluso puede optar por importar precios de Magento a un sistema de terceros, o una herramienta de análisis de datos, y tener los precios formateados de acuerdo con el formato de moneda solo interrumpiría el proceso de importación hasta que resuelva la "conversión de moneda".

¿Quién es responsable de cambiar el tamaño de las imágenes del producto y almacenarlas en caché? Porque en la API nativa de Magento 2 no hay cambio de tamaño o sistema de caché.

Exactamente. Como dije anteriormente, Magento proporciona acceso a los datos (sin lógica de presentación). Depende de usted cómo lo usará.

Por ejemplo, puede optar por cambiar el tamaño de la imagen adaptativa http://adaptive-images.com/details.htm , para que pueda usar fácilmente la imagen original y hacer lo que quiera.

Puede elegir la forma en que almacenará en caché las imágenes, si desea utilizar la compresión con pérdida o sin pérdida para reducir las imágenes, etc.

¿Necesito crear una nueva API aislada personalizada o ampliarla nativa para futuras actualizaciones?

Le recomiendo que haga su API que se usará para la lógica de presentación, y estará 99.9% (supongo) seguro de que no se verá afectado por una futura actualización de la API de Magento2.

¿Recomiendas usar una capa adicional para combinar CMS y Magento API?

Muy recomendable. Pero, la capa adicional no tiene que ser una aplicación adicional; También puede ser un módulo Magento2. Lo bueno de esto es el hecho de que eres libre de combinarlo como quieras; puedes construir tu capa proxy usando cualquier idioma / tecnología que desees.

Le agradezco que comparta su retorno de experiencia.

Hay muchos enfoques que puede usar aquí. Compartiré mi opinión al respecto.

Mi acercamiento a los sin cabeza

Primero, lo dividiría en dos capas: capa proxy y capa de presentación .

Capa de proxy

Lo primero que tendrá que considerar es sobre la creación de la capa Proxy. Detrás de escena, puede utilizar Magento API, CMS API, ERP API, x API, lo que quiera ...

En la capa proxy, puede usar y organizar los datos de la manera que desee. Puede implementar la capa de almacenamiento en caché allí, así como funcionalidades adicionales para el formateo de datos, el seguimiento de clientes, varias automatizaciones, etc. En general, cualquier cosa que necesite para malabarizar fácilmente en la capa de presentación.

La capa proxy no tiene que estar codificada en PHP; puede codificarse en Java, NodeJS, o incluso puede utilizar AWS API Gateway, AWS SQS y Lambda para proporcionar una capa proxy completa o solo una parte de ella.

Fabrizio Branca describe uno de los enfoques que puede utilizar en http://fbrnc.net/blog/2015/10/super-scaling-magento

Capa de presentación

La capa de presentación depende de la plataforma del cliente; Si va a usarlo para la aplicación móvil, las cosas son bastante claras sobre la forma en que debe utilizar la API proxy.

Para una aplicación web, hay muchas posibilidades. Puedes usar:

  • Solución PHP estándar (con tecnología de cualquier marco) donde puede utilizar cualquiera de los motores de plantillas PHP (como Smarty, Twig, Dwoo ...) para proporcionar salida HTML
  • Java / NodeJS / cualquier idioma con el que se sienta familiarizado
  • Solución puramente basada en JavaScript, que representaría todo el HTML y llamaría a las API apropiadas a través de ajax para llenarlo con datos
  • Cualquier híbrido / combinación de esos enfoques desde arriba

Esto no está en la lista de libros , acabo de compartir algunas combinaciones. En realidad, tu imaginación es el único límite.

Pensamientos finales

Use la solución basada en JavaScript tanto como pueda, ya que puede proporcionar una mejor experiencia al Cliente, menor carga útil para las cargas de página, incluso puede hacer una carga de datos especulativa si puede predecir las próximas acciones del cliente.

PERO, el problema con la solución puramente javascript es SEO. Si todos sus datos se cargan a través de Ajax, es probable que Google no pueda analizarlos.

La solución es crear una aplicación híbrida que sirva toda la página HTML en la primera carga, por ejemplo, cuando presiona / catalog / shoes. Para cualquier navegación adicional por el sitio, puede utilizar ajax para obtener solo los bloques necesarios.

Uno de los enfoques sería crear instantáneas de su página, por ejemplo, utilizando PhantomJS . También hay pocas soluciones pagas para esto, como:

Sinisa Nedeljkovic
fuente
El inconveniente de usar solo la API nativa de Magento 2 es perder la función incorporada útil para la capa de presentación con duplicación de código. Para mi proyecto actual, utilicé API de Magento 2 personalizadas basadas en una nativa con capa de caché y formateo. Así que creo que sigo parcialmente tu enfoque.
Franck Garnier
Todo depende del caso de uso. En términos de tiempo de comercialización, probablemente sea más rápido integrar CMS de terceros y usar algún tipo de nube de integración para otros servicios, como Boomi ( boomi.com ).
Sinisa Nedeljkovic
1
Además, incluso Lizards and Pumpkins se pueden considerar como un buen ejemplo de la capa proxy, aunque no estoy seguro de si consume Rest API de forma predeterminada (pero se puede ampliar fácilmente).
Sinisa Nedeljkovic
10

Puedo compartir algunas ideas sobre el desarrollo de proyectos de magento sin cabeza ya que mi compañía ha creado 2 de ellos.

Hemos decidido utilizar reactjs como una aplicación frontend y conectarlo con backend alimentado por nodos. Las llamadas API a magento fueron realizadas por el nodo en el lado del servidor. Esto significaba que no se enviaban llamadas a magento desde el navegador.

Desde el punto de vista de la API, es bueno, pero hay algunos problemas que hemos encontrado durante el desarrollo. Los puntos finales de Magento2 a veces son muy limitados. De forma predeterminada, el controlador de punto final no permite inyectar datos adicionales a la respuesta, ya que no se proporcionan extension_attributesa cada uno. Con frontend escrito por separado, no es una buena noticia. Muchas veces nos enfrentamos a la necesidad de agregar algunos datos y no pudimos hacer esto para el punto final nativo de magento debido a la falta de extension_attributes. Esas instancias requeridas para anular el punto final de magento y proporcionar nuestra propia interfaz con campos adicionales o crear nuestro punto final personalizado extendiendo el punto de magento y cambiando lo que necesitamos.

Por ejemplo, teníamos que anular, /rest/V1/categoriesya que magento por defecto no agregaba la ruta URL al árbol de categorías. /rest/V1/productslo que debería obtener datos del producto también era demasiado limitado para nosotros, ya que necesitábamos usarlo para la vista de categoría y queríamos recibir los filtros disponibles en esa respuesta.

Otro problema eran los puntos finales faltantes. Tuvimos que crear unos para enviar correos electrónicos de contacto, migas de pan para la categoría, obtener datos de cotización de quoteId y algunos adicionales para tratar con elementos específicos del proyecto. En términos generales, donde en el frente normal de Magento2 crearía un bloque para obtener una colección personalizada para tratar, es posible que deba agregar su punto final de API.

La parte más difícil fue el pago. Aunque está preparado para el modo sin cabeza, todavía hay algunas partes que requieren un ajuste específico. Si está utilizando PayPal, normalmente será redirigido al sitio de PayPal para el pago con algún tokent. Para nosotros, este token debe buscarse por separado, ya que no seguimos la forma de redireccionamiento estándar. Un caso similar fue con la conexión de Adyen, que requirió redireccionamiento después de realizar el pedido. El punto final estándar de magento solo devuelve la identificación del pedido en caso de éxito y no permite inyectar la URL de redireccionamiento. También tuvimos algunos problemas con la implementación de 3dSecure.

Una cosa importante a tener en cuenta y dejar en claro para el cliente antes de quedarse sin cabeza es que todas las partes relacionadas con la interfaz de los módulos externos deberán reescribirse para su implementación específica. Como actualmente no hay forma de que un módulo agregue sus propios datos a ninguna parte sin cabeza. Lo único que puede hacer el módulo es proporcionar puntos finales API.

En definitiva, el magento sin cabeza es definitivamente posible. Terminamos teniendo un módulo personalizado para esos ajustes y nuevos puntos finales que podrían usarse con otros proyectos.

React front funciona muy bien, ya que react front puede almacenar muchas cosas y el backend de nodo es extremadamente rápido. Estamos eliminando el tiempo necesario para ver parte de la solicitud estándar de magento de esta manera.

Si desea comprobar cómo se comporta, aquí hay enlaces a los proyectos:

https://therake.com/

https://www.emperia.ch/

Si alguien habla holandés puede consultar también este artículo sobre therake: http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[ACTUALIZAR]

Actualización sobre la pregunta de flujo de pago. Como escribí, el pago fue complicado. Las pasarelas de pago en los niveles de API son básicamente inexistentes. Por ejemplo, en el proceso de pago regular, la mayoría de las pasarelas de pago lo redirige a un sitio diferente para finalizar el pago. Algunos de esos módulos están creando pedidos en magento en estado pendiente, algunos (paypal express) se redirigen antes de crear el pedido. Esos redireccionamientos a menudo dependen de su sesión para obtener detalles después del regreso. Esto fue un problema ya que el punto final de la orden placeOrder solo devuelve la identificación del pedido recién creado y no la información de una redirección. Dado que también estábamos atacando no directamente a Mgento, sino al backend de nodo, la sesión debe restaurarse correctamente al regresar de la puerta de enlace. Nuestros proyectos actuales tienen pasarelas paypal y Adyen integradas y nos llevó más de 150h.

Zefiryn
fuente
Gran explicación, me encuentro con problemas similares. ¿Puede explicar más la parte de pago, por ejemplo, Paypal en un Magento sin cabeza? ¿Puedes compartir el flujo?
Franck Garnier
5

Aquí está el proyecto de código abierto https://github.com/ishakhsuvarov/going-headless

Este repositorio se crea por discusión "Going Headless", que fue parte de las sesiones de Imagine 2017 DevExchange, para recopilar y discutir ideas sobre el uso de la API web de Magento con una interfaz personalizada. El objetivo principal de este proyecto es recopilar los puntos más críticos y dolorosos en los flujos de API web y el desarrollo de una solución que satisfaga la mayoría de los casos de uso.

FireBear
fuente