Riesgo # 1: múltiples modelos
Eventualmente querrá consultar la base de datos desde otro lugar que no sea la aplicación que está creando o en un contexto que no sea el usuario final principal de la aplicación.
Recuerde que casi todas las aplicaciones tienen múltiples usuarios.
- ¿Es correcto cambiar de organización en 6 meses, considerando que los proyectos futuros en la organización serán proyectos de apoyo y no proyectos de desarrollo?
- ¿Explicar los diversos modos de software en la nube como un servicio (SaaS) entorno
- Cómo ganar dinero con SaaS
- ¿Cuál es la cuota de representantes en una empresa como HubSpot (producto MRR de $ 500)? ¿Cuántos usuarios de pago tienen que cerrar los representantes en un mes para una empresa con un producto MRR de $ 500?
- ¿Qué es Salesmate CRM?
- Si vende algo, la contabilidad necesitará acceso.
- Si ofrece soporte a los clientes, necesitará una visibilidad profunda de su cuenta.
- Si se comunica con ellos (correos electrónicos, notificaciones push), querrá almacenar datos sobre cosas como capacidad de entrega y clics. Datos que generalmente no están expuestos al usuario que paga.
- Si planea ejecutar pruebas A | B o algún tipo de proceso de mejora continua, deberá ocultar estos datos a los usuarios.
Uno de los riesgos clave aquí es cómo modelar y asegurar todo esto. Desea que Modelos en el lado del cliente les permita acceder a los datos a través de Angular, pero también necesita Modelos en el lado del servidor para administrar qué datos entran y salen del sistema. Todos sueñan con que estos sean los mismos Modelos, pero no lo son, exactamente por la razón que señalé anteriormente. Su equipo de soporte tiene una vista diferente del Modelo de usuario que el cliente.
Sueña con administrar solo los permisos de las operaciones CRUD, pero incluso Angular.js requiere al menos un controlador básico en el lado del servidor para entregar el HTML / CSS / JS para cargar el sitio. Por supuesto, debido a que tiene diferentes tipos de usuarios, necesitará múltiples de estos para poder enviar una IU al equipo de soporte que sea diferente de la aplicación principal.
El procesamiento fuera de línea ( como un correo electrónico diario ) complica aún más esto porque necesitará una API a la que pueda llamar algún servicio pero que sea inaccesible para la interfaz de usuario normal.
Riesgo # 2: seguridad
Entonces hay un patrón conocido para esto. Si puede implementar Oauth2 o usar un servicio existente para esto, generalmente puede hacer la parte de autenticación con bastante facilidad. Pero tienes que saltar a través de varios aros como manejar XSS.
El mayor desafío es la parte de autenticación . Debe ser muy consciente de quién llama al punto final REST dado junto con lo que se les permite ver / hacer. Su código tiene que estar muy atento al manejo de solicitudes entrantes incorrectas de los usuarios porque es trivial falsificarlas y buscar vulnerabilidades.
Por ejemplo, si un usuario malintencionado ve un campo en el objeto Usuario llamado “IsDeleted” junto con una ID y puede encontrar las ID de otros usuarios, entonces es bastante trivial comenzar a publicar actualizaciones que intentan eliminar varios usuarios. Si el código en el lado CRUD no está desinfectando las solicitudes y la comprobación de los permisos correctamente es muy posible que un usuario cause muchos daños muy fácilmente.
Del mismo modo, si está creando una aplicación SaaS, tendrá varios clientes con datos que no pueden interactuar. Deberá ser muy consciente de las “secuencias de comandos entre sitios” de sus propios clientes.
Resumen: es más complicado
He creado varias aplicaciones web a lo largo de los años. Actualmente estoy involucrado en la construcción de una aplicación SaaS empresarial que en realidad tiene una API de acceso público.
Creo que la premisa de que su API solo administrará “permisos de usuario de operaciones CRUD” es una simplificación dramática.
