En el momento en que un sitio necesita recordar algo — una reserva, una postulación, un socio — deja de ser una página y pasa a ser software. Ahí es donde los proyectos se frenan: ahora necesitás base de datos, una API, permisos y una pantalla para leer lo que entró. Describir qué junta el sitio debería alcanzar, y acá alcanza.
| Hacerlo vos | 54 | |
|---|---|---|
| Crear los datos | Diseñar tablas, escribir el esquema | Describir qué junta el sitio |
| Permisos | Escribir políticas de row level security | El dueño lee el admin, el público solo escribe por el formulario |
| El formulario | Construirlo y conectarlo a la API | Se crea junto con la colección |
| Leer lo que llegó | Construir una pantalla de admin | Ya está |
| Cuentas de usuario | Elegir un proveedor e integrarlo | Login por código al mail, incluido |
Escrito a partir de la documentación pública de cada producto. Los productos cambian: verificá el de ellos antes de decidir. Por eso mismo acá no hay precios de la competencia.
No. Nunca lo ves. Ese es el intercambio: tampoco tenés el poder crudo del SQL, y si lo necesitás querés un proveedor de Postgres de verdad.
En las colecciones propias de tu sitio, alcanzables solo por vos desde el admin y por tus páginas a través del formulario.
Sí, cuando quieras.
La persona pone su mail, recibe un código y entra. Nada que recordar, y ninguna base de contraseñas que vos tengas que proteger.
Sí: páginas que muestran su contenido solamente a alguien logueado.
Sí, desde el admin: leer, editar, marcar como revisada, borrar.
Los datos de cada sitio están aislados y el admin exige ser el dueño. La configuración pública va en las variables del sitio; los secretos no van en una página, en ninguna plataforma.
Los límites dependen del plan y el panel muestra cuánto estás usando. El número se ve antes de chocarlo, no después.
Tus páginas pueden llamar a cualquier API HTTP que ya tengas.
Describilo. El admin es parte del sitio, así que se puede cambiar como todo lo demás.