[REPRODUCIENDO MÚSICA] WESLEY CHUN: Hola, y bienvenido a
"Estación de migración sin servidor". Soy Wesley de Google, acompañado
por mi colega, Martin, para ayudarlo a navegar el mundo
de la migración de un producto a otro, generalmente
en relación con una de nuestras
plataformas informáticas sin servidor. Hoy, Porter nos mostrará la
migración opcional de Cloud Datastore a Cloud Firestore. MARTIN OMANDER: Oh, ¿en serio? ¿Otra opción sobre la migración? ¿Qué les pasa a ustedes? WESLEY CHUN: [RISAS]
Lo sé, ¿verdad? Para ser justos, les
informamos a los desarrolladores en los
videos de los módulos 2 y 3 que los
desarrolladores de App Engine de Python 2 realmente solo necesitan pasar de
la biblioteca NDB original a Cloud NDB.
Al hacerlo, es más fácil
migrar aplicaciones a Python 3 y también obtenerlas
en Cloud Datastore, la
solución NoSQL independiente que surgió del
App Engine Datastore original. Dado que la biblioteca de cliente de Cloud NDB
funciona con Python 3 App Engine, los usuarios solo
migrarían a las bibliotecas de cliente de Cloud Datastore o Cloud Firestore
si tuvieran una
buena razón para hacerlo.
MARTIN OMANDER: Oh, sí. Creo recordar,
pero ¿puedes recordármelo? WESLEY CHUN: Claro, Martín. Las bibliotecas cliente de Cloud NDB y Cloud
Datastore acceden a Cloud Datastore,
la base de datos subyacente. Cloud NDB se creó
específicamente para los desarrolladores de Python 2 App Engine
como una herramienta de migración, mientras que los usuarios de Python 3 y los que
no son de App Engine son dirigidos a Cloud
Datastore de inmediato. Por lo tanto, los desarrolladores
solo deben migrar de Cloud NDB a la
biblioteca de cliente de Cloud Datastore si ya
tenían un código que la usa, lo que significa que es donde
desea consolidar para usar solo una
biblioteca de cliente para hablar con Datastore.
MARTIN OMANDER:
Ah, así es. Gracias por el recordatorio. Pero ahora, ¿qué pasa con la migración de hoy
a Cloud Firestore? WESLEY CHUN: Me alegra que
hayas preguntado, Martin. Bueno, hay buenas noticias
y luego hay malas noticias. MARTIN OMANDER: Oh, oh. Bueno, soy optimista. ¿Cuáles son las buenas noticias, Wes? WESLEY CHUN: Bueno,
Cloud Datastore se convirtió en su propio producto en 2013. Pero al
año siguiente, Google adquirió Firebase por su increíble
base de datos en tiempo real. Luego, ambos equipos trabajaron
juntos y lanzaron la
base de datos NoSQL escalable de próxima generación en 2017. Para demostrar que Datastore
unió fuerzas con Firebase, el producto se renombró
como Cloud Firestore. MARTIN OMANDER:
Oh, sí, y me dijiste que esperara hasta
este video para aprender más.
Aqui estamos. También mencionó
que Firestore es totalmente compatible
con Datastore y que todas las
bases de datos de Datastore se convertirán a Firestore de forma oculta. ¿Está bien? WESLEY CHUN: Sí, Martín. Una vez convertidos
, funcionarán en modo de compatibilidad de Datastore,
o Firestore en modo Datastore, para abreviar. Sin embargo, este modo
no le da acceso a las funciones nativas de Firestore
, solo a las de Datastore. Para acceder a
todo Firestore , debe estar ejecutando el
modo nativo de Firestore. De manera similar, cuando se le solicite
crear un nuevo almacén de datos NoSQL, puede elegir entre
Firestore en modo Datastore o Firestore en modo nativo. Consulte el gráfico
en los documentos para ver las diferencias entre ellos. MARTIN OMANDER: Oh, ya veo.
Entonces, todo lo que los usuarios deben hacer
es cambiar de Firestore en modo Datastore a modo Nativo
, y están bien, ¿verdad? Pero creo que mejor pregunto ahora. ¿Cuál es la mala
noticia que mencionaste? WESLEY CHUN: Sí. Creo que sabes lo
que voy a decir. No puede cambiar entre los modos
Datastore y Native Firestore . Una vez que se configura el modo y
se almacenan los datos, el modo se bloquea. Además, para complicar las cosas,
Datastore y Firestore se excluyen mutuamente
en los proyectos de GCP, lo que significa que una vez que
el modo está bloqueado, no solo no puede cambiarlo. Pero para
usar el otro modo , debe
crear un proyecto completamente nuevo. MARTIN OMANDER: Entonces,
lo que está diciendo es que si tengo
datos en Datastore, incluso si
migro a las bibliotecas cliente de Cloud NDB o Cloud Datastore , no puedo usar
Cloud Firestore en modo nativo a menos que cree una nueva
proyecto con una nueva aplicación, seleccionar Firestore en
modo nativo en ese nuevo proyecto, descargar los datos de Datastore
de mi proyecto actual y cargarlos en Firestore
en el nuevo proyecto? WESLEY CHUN: Sí, lo tienes.
Y ahora sabe por qué
esto es incluso más opcional que pasar de
Cloud NDB a Cloud Datastore. Al menos con esa
migración, no tienes que crear
un proyecto completamente nuevo. Pero este sí requiere eso. Y no importa si es la
aplicación App Engine, Cloud Run o incluso una aplicación que no es de la nube que
usa Datastore. Tienes que tener un nuevo proyecto. Entonces, una vez más, realmente
necesita tener una buena razón para realizar esta migración. Y si acceder a esas
funciones de Firebase es lo suficientemente convincente, tienes que hacer lo
que tienes que hacer, ¿verdad? MARTIN OMANDER:
Sí, así es.
Bueno, quiero
aprovechar las funciones nativas de Firestore y estoy
dispuesto a crear un nuevo proyecto para que esto suceda. ¿Cómo empiezo? WESLEY CHUN: Bueno,
lo primero es que debes reconocer que
hay dos piezas en este rompecabezas. Primero, sus datos
deben transferirse desde Datastore en
su proyecto actual a Firestore en el nuevo proyecto. Esa es la primera parte. En segundo lugar,
probablemente no hace falta decir que necesita una aplicación en ese nuevo
proyecto que use la biblioteca cliente de Firestore. MARTIN OMANDER: Está bien, lo tengo. Pero antes de hacer
eso, recuerdo del módulo 3 que la biblioteca
cliente de Cloud Datastore puede ser utilizada tanto por App
Engine como por aplicaciones que no son de App Engine. ¿Es eso cierto también para Cloud
Firestore? WESLEY CHUN: Sí,
definitivamente Martin. Si bien vamos a hacer una demostración de
cómo migrar una aplicación de App Engine a Cloud Firestore, en realidad
podría ser cualquier aplicación.
El único
requisito real es que tienes que tener un nuevo proyecto. Y como
mencionó el módulo 3, ahí es donde creamos
nuestra aplicación Cloud Datastore. Así que vamos a migrar
ese a Cloud Firestore. Específicamente, la
versión de Python 3, ya que es más probable que las aplicaciones de Python 2
usen Cloud NDB en su lugar. Entonces, si hizo el
laboratorio de código, use su código o tome el nuestro de
la carpeta del módulo 3b clonando el repositorio
o descargando el archivo zip. Haga una pausa aquí si es necesario. Pero una vez que esté listo,
vayamos a la computadora ahora. Bien, antes de comenzar,
necesitamos otro proyecto de Cloud para Firestore. Por lo tanto, cree uno nuevo
en Cloud Console o reutilice uno existente en el que
no se usen Datastore ni Firestore . Tome la identificación de ese proyecto, no el nombre del proyecto,
ni el número, la identificación. Luego habilite la
API de Cloud Firestore. Si prefiere la línea de comando,
use gcloud projects create, luego cambie a ese nuevo
proyecto con gcloud config set y, finalmente, active Firestore
con gcloud services enable.
Por supuesto, también se le pedirá
que habilite la facturación. Dado que siempre sugerimos que
comience con el código de trabajo, implemente la
aplicación Python 3 del módulo 3, ya sea que esté
usando la suya o la nuestra. Pero haz esto desde
tu antiguo proyecto, el que usa Datastore. Use la lista de configuración de gcloud para
ver su proyecto actual y use el conjunto de configuración de
gcloud, si es necesario. Una vez que esté en su
proyecto de Datastore, ejecute gcloud app deployment
y confirme que la aplicación funciona como antes. Ahora cambie a su nuevo proyecto
con gcloud config set project una vez más, ya que estaremos aquí
el resto de esta migración, comenzando con los
archivos de configuración.
La única configuración
que necesita cambiar es cambiar de Cloud
Datastore, o Cloud NDB si está usando eso,
a Cloud Firestore. Debe haber un
intercambio de una línea en requisitos.txt. Todos los demás cambios
están en main.py. Reemplace las
importaciones de la biblioteca del cliente de Cloud Datastore y la creación de instancias del cliente de API en
la parte superior con lo mismo para Cloud Firestore. Los grupos de
entidades similares en Datastore se identifican con
una clave principal común. Las entidades en Datastore
se conocen como documentos en Firestore. Las entidades son de cierto
tipo en Datastore, mientras que los documentos de Firestore
se agrupan como colecciones. Al almacenar una nueva
visita en Datastore, se crea una nueva entidad
con la clave principal de la visita.
Del mismo modo, en el
lado de Firestore, configuramos nuestra colección con el mismo
nombre que una clave principal de Datastore. La entidad de Datastore obtiene
sus pares clave-valor de datos de la misma manera que lo hace un
documento de Firestore, pero este último se
agrega a la colección de inmediato, mientras que la
entidad de Datastore debe escribirse explícitamente. A continuación, están las consultas del almacén de
datos en las que consulta los tipos de entidades de visita
, el orden deseado, luego busca y regresa. Para Firestore,
consulte la colección de visitas, especifique el orden,
obtenga y convierta a diccionarios compatibles con Python
, luego regrese como un
iterable compatible con la memoria. Lo crea o no,
eso incluye los cambios necesarios para cambiar de Cloud
Datastore a Cloud Firestore. El verdadero trabajo está en tener
que crear un nuevo proyecto. Entonces, ¿qué piensas de
esa migración, Martin? MARTIN OMANDER: Esa migración
no fue tan mala en absoluto. Pero antes dijiste que cualquier
aplicación puede usar Cloud Firestore.
Si estoy dispuesto a crear un nuevo
proyecto para acceder a Firestore y hacer el esfuerzo de
migrar mis datos, ¿significa esto que puedo reescribir
mi aplicación Python 2 Datastore como una aplicación Node.js Firestore? WESLEY CHUN: Absolutamente, Martín. Su aplicación Datastore podría
ser App Engine, Cloud Run o incluso no estar en la nube. No es como en los
viejos tiempos de App Engine, en los que, si usabas Datastore
, tenía que ser una aplicación de App Engine. Eso ciertamente ya no es
el caso.
Entonces, lo mismo se aplica
a su nuevo proyecto, lo que significa que puede
tener cualquier aplicación que use Firestore como su base de datos. Entonces, si su empresa está
trabajando más en Node.js hoy, no hay nada de malo en
reconstruir o refactorizar como una aplicación Node 16 Cloud Run para
su nuevo proyecto Firestore. Eso es lo que queremos decir con
App Engine, y realmente todo Google Cloud
en su conjunto, siendo más abierto que
nunca, tanto para sus datos como para sus aplicaciones. MARTÍN OMANDER: Hm. Bueno, eso es muy interesante. Estuve
pensando en hacer exactamente eso, ya que mi equipo está haciendo
más con Node.js en estos días. De todos modos, ahora que sé cómo
migrar mi aplicación a Firestore, ¿qué pasa con la migración de mis datos? WESLEY CHUN: Definitivamente, Martín. Vamos a abordar
eso en el módulo 10. Mientras espera la continuación de
la migración de datos, aquí hay algunos
recursos adicionales para considerar.
Anteriormente, lo vinculamos a un
gráfico que diferencia los modos Datastore y Firestore Native. Encima de ese gráfico se encuentra nuestra
guía sobre cuál de esos modos elegir para sus aplicaciones, así
que revise esa página en los documentos y simplemente revise todos
los documentos de Firestore, de todos modos, para familiarizarse con
su nueva base de datos NoSQL. Además, vea este otro
video de uno de nuestros colegas que profundiza en la
migración y las diferencias entre Datastore y Firestore. MARTIN OMANDER: Genial. Echaré un vistazo a esos. Ahora, ¿hay otras
migraciones que deba considerar para mi aplicación de App Engine? WESLEY CHUN: Bueno, en primer lugar
, puede ver en esta lista que ya hemos migrado
de nuestro antiguo App Engine Datastore y NDB a Cloud
NDB, Cloud Datastore y ahora Cloud Firestore.
Sin embargo, si está
en Cloud NDB, puede migrar directamente
a Cloud Firestore. No es necesario migrar
primero a Cloud Datastore y luego pasar de
Datastore a Firestore. simplemente combine el módulo
3 con este módulo 6. En lo que respecta a otras
migraciones, si está pensando en contener
sus aplicaciones de App Engine para que se ejecuten en Cloud Run
, consulte los módulos 4 y 5. Ayuda de los módulos 7, 8 y
9 aprenderá a migrar de
App Engine Task Queue a Cloud Tasks. Finalmente, si tiene una
aplicación pequeña que es solo una función, o una aplicación grande que
desea dividir en múltiples
microservicios, considere migrar a Cloud Functions. Lo encontrará en el módulo 11. MARTIN OMANDER: Ah. Gracias por los consejos. Hay tantas
maneras de actualizar. WESLEY CHUN: Bueno,
eso es definitivamente cierto.
Queremos dar a nuestros
usuarios muchas opciones. Y gracias,
espectadores, por acompañarnos en estos viajes para
modernizar sus aplicaciones sin servidor . Habla Wesley de Google Cloud
en nombre de Martin y Porter. Esperamos que pronto se una a nosotros en
la próxima "Estación de migración" o en una
"Expedición sin servidor" diferente. Dale me gusta y suscríbete para
ver más contenido como este. Y hasta la
próxima, feliz viaje. [REPRODUCIENDO MÚSICA].