Para responder a la pregunta de la cara, no es imposible, pero es difícil, y la magnitud de esa dificultad implica mucho más conocimiento de su aplicación que nosotros.
Para ir un poco más profundo, básicamente tienes dos estrategias que puedes probar. Ambos implican una cantidad de esfuerzo no trivial como base:
Yendo 100% nativo
- Cómo construir una aplicación web específica en Rails
- ¿Qué marco JS recomendaría para crear una aplicación web como YouTube?
- ¿Cuáles son los beneficios de usar Angular (2) o ReactJs en aplicaciones web empresariales?
- ¿Qué sucede dentro de un servidor web cuando comienzas y presionas la URL?
- ¿Es posible iniciar sesión en un sitio a través de una aplicación web, incluso si ese sitio no tiene una API?
Tienes una aplicación Rails increíble y quieres que esté disponible para las masas en un formato nativo. ¡Eso es genial! Para proporcionar la mejor experiencia posible, ha decidido centrar sus esfuerzos en convertir su aplicación en una experiencia 100% nativa sin dependencias externas de tiempo de ejecución. Aquí hay algunas cosas en las que deberá pensar si toma esta ruta:
- ¿A qué plataformas quiero apuntar? Es decir, cuando hablamos de “nativo” aquí, ¿estamos hablando de plataformas móviles, o también estamos apuntando a las plataformas de escritorio?
- ¿Necesito cambiar de idioma? Quizás no del todo, pero es mejor que lo hagas. Es decir, es probable que pueda reescribir la mayor parte de su lógica de negocios en ruby compatible con mruby y empujar casi todo a esa lógica, pero es probable que aún deba producir la mayoría del código front-end en un idioma nativo adecuado. Dicho esto, mruby es bastante limitado por derecho propio, y tampoco es lo más productivo de la historia, por lo que hacer esto podría anular el propósito del esfuerzo de conversión nativo.
- ¿Todos mis flujos de trabajo tienen sentido desde la perspectiva del usuario? Piense en sus flujos de trabajo en términos de descripciones simples en lenguaje natural. ¿Giran en torno a la frase “el usuario hace la cosa” o están más centrados en la idea “el sistema hace la cosa”? Si este último es el caso, es posible que sus flujos de trabajo sean bastante difíciles de asignar a la idea de una aplicación nativa completa.
- ¿Mi aplicación depende de algún dato que no pueda almacenarse localmente? Es decir, ¿sus usuarios interactúan a través del sistema (compartiendo contenido generado por el usuario)? ¿Un usuario individual necesita poder acceder a su propio contenido en diferentes dispositivos de manera transparente? Si es así, es muy probable que no pueda * realmente * volverse 100% nativo y aún necesitará al menos una API ascendente mínima.
- ¿Tengo suficientes recursos de tiempo / dinero para lograr esto? Hacer una reescritura completa de cualquier aplicación es generalmente un esfuerzo significativo, y aún más si necesita cambiar de idioma y considerar las idiosincrasias de sus plataformas de destino. Si el idioma / kit de herramientas que elige ya es compatible con todas sus plataformas de destino, puede aliviar al menos algo de ese dolor, pero todavía hay mucho dolor por encontrar. La realidad de la situación es que en realidad no valdría la pena las calorías (y el tiempo … y el dinero) que tendrá que quemar para que esto sea una realidad. Eso no quiere decir que no debas intentarlo, pero debes ser muy consciente de tus posibles puntos de pivote.
Interfaz nativa con una interfaz Rails
Tienes una aplicación Rails increíble y quieres que esté disponible para las masas en un formato nativo. ¡Eso es genial! Para no reinventar totalmente la rueda, por así decirlo, ha decidido que su aplicación nativa será una buena interfaz que se conecta a su aplicación Rails a través de una API. Aquí hay algunas cosas en las que deberá pensar si toma esta ruta:
- ¿Mi aplicación realmente necesita un servicio ascendente? Es decir, ¿su aplicación implica que los usuarios vean datos compartidos / seleccionados / creados / verbos en pasado por otros usuarios? ¿El usuario necesita poder acceder a su propio contenido desde múltiples dispositivos sin problemas? De lo contrario, es posible que desee considerar hacer una conversión nativa completa en lugar de esta estrategia dividida.
- ¿Qué pasa en el front-end y qué pasa en el back-end? Solo implemente cosas en el front-end que tengan sentido para un usuario. Es decir, el punto en un flujo de trabajo dado en el que “el usuario hace la cosa” pasa a “el sistema hace la cosa”, tiene una buena oportunidad para sacar la lógica empresarial y el esfuerzo del flujo de trabajo de los hombros del usuario y llevarlo a su API .
- ¿Qué marco de front-end usarás? Elija un buen sistema front-end. Algunas personas ya han sugerido React Native, y por lo que entiendo, es una buena opción. Dicho esto, realmente me gusta cómo se está formando la API de Flutter, y aunque es bastante verde, podría valer la pena echarle un vistazo.
- ¿Qué puedo hacer para garantizar una experiencia de usuario razonable? Esto es un poco abierto en sí mismo, pero seguiré y arrojaré el consejo que mejor se adapte a mi timonera. Haga que su API responda lo más rápido posible a las solicitudes. Esto podría significar arrojar solo una tonelada de hardware al problema, pero también podría significar configurar sus flujos de trabajo en torno a los procesos que puede ejecutar un trabajador en segundo plano como Sidekiq o Resque, y luego enviar los resultados al usuario cuando estén listos.
- ¿Cuánto debe cambiar mi aplicación Rails? Si sigues el Rails Way (TM), diría que puede que tenga que cambiar mucho, pero probablemente sea un puñado de cambios relativamente indoloros. Si es posible, probablemente sería mejor rediseñar la versión web de su aplicación para que sea simplemente otra aplicación de rieles solo API con un ingenioso front-end si esa no es la forma en que está configurada. Si hace esto, es posible que pueda usar las mismas herramientas de front-end tanto para su aplicación web como para su compilación nativa.
Independientemente de la estrategia que elija, que tenga la mejor de las suertes.