NoBackend y servicios móviles
•Transferir como PPTX, PDF•
1 gostou•1,948 visualizações
El documento presenta información sobre noBackend, incluyendo ejemplos de código para almacenar datos en servicios móviles como Mobile Services de Azure y Firebase sin necesidad de backend. También menciona brevemente el control de versiones y otros trabajos relacionados a la ingeniería de software.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (14)
Semelhante a NoBackend y servicios móviles
Semelhante a NoBackend y servicios móviles (20)
Último
Último (9)
NoBackend y servicios móviles
- 2. Cristian Moreno Zuluaga Globant – SharePoint Developer Líder de Avanet @khriztianmoreno | devkhriztian.wordpress.com
- 12. //Agregar una clase a un elemento //Iniciar session
- 17. ¿Si mi fuerte no es el backend, porque complicarme?
- 21. //Instanciar servicio de Mobile Service: //Almacenar datos en el servicio móvil: //Almacenar datos en el servicio móvil: var client = new WindowsAzure.MobileServiceClient('AppUrl', 'AppKey'); client.getTable('Tabla').insert(itemAGuardar); client.getTable('Tabla').del({id: idItem}); <script src='http://ajax.aspnetcdn.com/ajax/mobileservices/MobileServices.Web-1.1.2.min.js'></script>
- 22. //Instanciar servicio de Firebase: //Almacenar datos en el servicio móvil: //Almacenar datos en el servicio móvil: var myRootRef = new Firebase(https://my-firebase-name.firebaseIO-demo.com/'); myRootRef.child('user').set(itemAGuardar); myRootRef.child('user').child(id).remove(); <script src='https://cdn.firebase.com/js/client/1.0.15/firebase.js'></script>
- 32. Derechos de Autor: • Idea para la presentación es tomada de la ponencia de Alex Feyerke en JSConf 2013 Europa. • Look ma, no backend! Cristian Moreno Zuluaga @khriztianmoreno | http://devkhriztian.wordpress.com
Notas do Editor
- Estoy aquí para hablar de un nuevo paradigma en el desarrollo web frontend que algunos llaman "noBackend", y que puede incluir la idea de BaaS, Backend as a Service. Soy ante todo un desarrollador backend. Pero en la práctica, no lo soy. Soy un desarrollador tanto de backend como frontend. Muchos de nosotros probablemente lo son. No por elección, eso sí, sino porque no tengo ninguna alternativa. En algún momento, el 99% de mis proyectos requieren algún tipo de almacenamiento de datos o la autenticación de usuario.
- Me encanta que ya no vivamos en épocas del webmaster que hacía de todo (si, hasta el diseño y el soporte técnico), que exista diversificación de roles y en particular estuve analizando el caso de ciertos perfiles de programadores, donde algunos trabajan con el servidor y otros con el lado del cliente
- Los frontends tienden a ser programadores, pero hay diseñadores genios que también hacen frontend. Son los encargados de maquetar la estructura semántica del contenido (HTML), codificar el diseño en hojas de estilo (CSS) y agregar la interacción con el usuario (Javascript). En la época actual los frontends tienen HTML5 y CSS3. Con HTML5, desde el frontend, es posible hacer geolocalización, dibujo vectorial, guardar datos en el disco del usuario, insertar audio y video, entre otras cosas. Con CSS3, se pueden crear diseños altamente complejos sin la necesidad de imágenes cortadas, sólo usando código. Bordes redondeados, sombras, degradados, fondos múltiples, entre otros. Por último, Javascript y sus frameworks añaden el componente de interactividad y conexión al servidor. Es posible comunicarse con el backend y la base de datos sin recargar la página usando AJAX o WebSockets, recibir esos datos y cambiar el diseño entero del sitio. jQuery hace todo esto fácil pero no es el único framework de Javascript.
- Es la labor de ingeniería que compone el acceso a bases de datos y generación de plantillas del lado del servidor. En backend se encargan de implementar cosas como MySQL, Postgres, SQL Server o MongoDB. Luego, un lenguaje como ASP.NET, PHP o JSP, o frameworks como RoR, Django, se conectan a la base de datos. A través de estos lenguajes y frameworks se recibe, procesa y envía información al navegador del usuario. En código HTML (que crea el frontend) o enviando datos puros en XML, RSS o JSON, para ser procesados por Javascript. En Facebook, por ejemplo, PHP manda la estructura básica del sitio web, pero son múltiples programas y servidores hechos en C++ o Erlang que procesan la información en tiempo real (como chat, comentarios, notificaciones) y las envían y reciben a través de Javascript en el navegador.
- Si eres un desarrollador frontend probablemente te va tocar construir tambien tu backend, para poder almacenar tu informacion.
- La idea es que se puede construir una aplicación web con todas las funciones del lado del navegador y no preocuparse por lo que ocurre en el servidor. Ahora, yo no sé ustedes, pero para mí, esto suena muy deseable.
- Tanta cosa. Esto se trata de puestos de trabajo. Puestos de trabajo de otras personas. Ellos se ganan la vida con esto, y lo saben muy bien. Esto lo podría hacer un frontend Pero no sería muy bueno. Al frotend le tomaría mucho tiempo. Y lo más importante:
- Simplemente no lo quiere hacer. No es el trabajo el. No es su especialidad. No es lo que disfruta. Probablemente este desarrollador frontend encuentre mas de una manera de hacer errores terribles en la seguridad. Y realmente, ¿qué necesita?
- Sus requisitos, de hecho los requisitos de la mayoría de las personas no son extravagantes. Esto es algo muy básico. En realidad es poco espectacular.
- La gente ha estado haciendo estas cosas durante mucho tiempo. No es nuevo. No es interesante. No es exactamente la física de partículas. No debe ser difícil. De hecho hoy, sólo tardará unos minutos.
- ¿Por qué estas cosas del backend no pueden ser tan fáciles como cambiar un elemento DOM con jQuery ? ¿Por qué no puede hacerse desde el navegador?
- Ahí es donde la idea noBackend entra en juego y lo hace posible. noBackend es en esencia delegar responsabilidades. La cosa es que los bits difíciles y/o aburridos (para los frontens) sean manejados por otras personas que son mejores que ellos. Y esto tiene sentido, lo hacemos todo el tiempo, en todos los aspectos de la vida:
- El Backend es duro, esta formado por una gran cantidad de componentes diferentes que todos tienen que interactuar unos con otros, hay una variedad de lenguajes y la sintaxis, incluso en la configuración más simple, existen convenciones y capas sobre capas. Y eso es antes de empezar el escalamiento. PREGUNTA SLIDE Lo ideal seria eliminar estas complicaciones que no sabemos manejarlas y para eso llegan estas soluciones:
- Hay arquitecturas y servicios que le permiten más o menos olvidarse del backend, proporcionando una API simple desde frontend para tareas típicas de back-end, todo ello en JS. Algunos de ellos incluso tirar en datos en tiempo real, autenticación y la persistencia de datos / sincronización.
- noBackend es un enfoque para desacoplar las aplicaciones de backend, abstrayendo las tareas de back-end con el código de frontend (Dreamcode). Esto permite a los desarrolladores frontend centrarse en la experiencia del usuario y proporciona a los desarrolladores de back-end más flexibilidad en el lado de la aplicación. Nobackend no significa que no hay servicios de fondo, sino más bien la infraestructura de back-end está oculta para el desarrollador, toda la funcionalidad que suministra un marco, una biblioteca o un servicio. En resumen, la idea es simple, crear el frontend de la aplicación web agnóstica al backend (sin pensar en backend en absoluto). En primer lugar, voy a decir por qué esto es genial. Entonces voy a decir por qué es importante.
- · Ideal: Un solo lenguaje, un solo format de datos · Simple, Las soluciones NoBackend normalmente vienen como un servicio · Muy rápido para ponerse en marcha.
- · Ideal: Un solo lenguaje, un solo format de datos · Simple, Las soluciones NoBackend normalmente vienen como un servicio · Muy rápido para ponerse en marcha.
- - Muy poco de configuración, muy poco código repetitivo para escribir. Usted puede comenzar a hacer cosas importantes casi de inmediato, no hay nada que se interponga en el camino de sus ideas y los problemas interesantes de su aplicación, que es lo que hace el usuario con ella. Sincronización en vivo a través de dispositivos, datos en tiempo real de unión - Perfecto para pruebas extremadamente rápida de prototipos y el usuario con los datos reales y los comportamientos en los dispositivos reales
- Iniciar el desarrollo en el navegador, cerca del usuario, donde el único aspectos sea su aplicación. Construir las características de cara al usuario de forma rápida, validar, experimentar sin tener que preocuparse por la infraestructura o los esquemas de datos. Averiguar si la idea en realidad vale la pena como para gastar tiempo en ella.
- Dreamcode es esencialmente el diseño centrado en el usuario para una API.
- Todas estas cosas son cosas buenas. Es nuestro trabajo debemos hacer la web más accesible para las personas. Debemos ayudar a que la gente lo entiende, que se puede hacer en la web. Si optan por la web, sea el desarrollo o el diseño, preocúpense, por que la web se entienda.