Rompiendo las reglas: uso de SQLite para demostrar aplicaciones web

 

 

 

  • ¡Registro!
  • Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX

  • Índice
    1. ¿Por qué no utilizar SQLite para la versión de producción?
    2. El primer paso: entorno de implementación
    3. El segundo paso: usar la base de datos de demostración
    4. El tercer paso: duplicar el archivo SQLite
    5. Paso final: implementar su servidor de demostración
    6. SQLite no funcionará para mí. ¿Qué pasa con otros sistemas de bases de datos?
    7. Pensamientos finales
      1. Otras lecturas

    La mayoría de los usuarios potenciales querrán probar el software o servicio antes de comprometer tiempo y dinero. A menudo, aquí es donde entra en juego la antigua cuenta de demostración. Sin embargo, cualquiera que haya implementado alguna vez una cuenta demo puede dar fe de los problemas asociados. En este artículo, James Pierce le ofrece una solución: SQLite. Es comúnmente sabido que SQLite no maneja múltiples subprocesos ya que toda la base de datos está bloqueada durante un comando de escritura, lo cual es una de las razones por las que no debes usarlo en un entorno de producción normal. Sin embargo, en su solución, se utiliza un archivo SQLite separado para cada usuario que realiza una demostración del software.

     

    Entonces, ha creado la próxima aplicación web excelente, pero ahora se le presenta la pregunta que todo producto nuevo debe considerar: "¿Cómo puedo mostrarles a todos lo excelente que es mi aplicación?"

    La mayoría de los usuarios potenciales querrán probar el software o servicio antes de comprometer tiempo y dinero. Algunos productos funcionan muy bien con solo ofrecer a los usuarios una prueba gratuita, mientras que otras aplicaciones se experimentan mejor con datos de muestra ya implementados. A menudo, aquí es donde entra en juego la antigua cuenta de demostración.

    Sin embargo, cualquiera que haya implementado alguna vez una cuenta demo puede dar fe de los problemas asociados. Ya sabes cómo funcionan las cosas en Internet: cualquiera puede ingresar datos (ya sea que tengan sentido o no para el producto) y existe una buena posibilidad de que el contenido agregado por usuarios anónimos o bots pueda resultar ofensivo para otros. Claro, siempre puedes restablecer la base de datos, pero ¿con qué frecuencia y cuándo? Y, en última instancia, ¿eso realmente resuelve el problema? Mi solución para usar SQLite .

     

    ¿Por qué no utilizar SQLite para la versión de producción?

    Es comúnmente sabido que SQLite no maneja múltiples subprocesos ya que toda la base de datos está bloqueada durante un comando de escritura, lo cual es una de las razones por las que no debes usarlo en un entorno de producción normal. Sin embargo, en mi solución, se utiliza un archivo SQLite separado para cada usuario que realiza una demostración del software. Esto significa que la limitación de escritura solo se limita a ese usuario, pero varios usuarios simultáneos (cada uno con su propio archivo de base de datos) no experimentarán esta limitación. Esto permite una experiencia controlada para el usuario que prueba el software y le permite ver exactamente lo que usted quiere que vea.

    Este tutorial se basa en una solución del mundo real que he estado ejecutando con éxito para una aplicación web de demostración SaaS desde 2015. El tutorial está escrito para Ruby on Rails (mi marco de trabajo preferido) versión 3 y posteriores, pero los conceptos básicos deben ser capaz de adaptarse a cualquier otro lenguaje o marco. De hecho, dado que Ruby on Rails sigue el paradigma de software "convención sobre configuración", puede incluso ser más fácil de implementar en otros marcos, especialmente en lenguajes simples (como PHP) o marcos que no hacen mucho en términos de administración de conexiones de bases de datos. .

    Dicho esto, esta técnica es particularmente adecuada para Ruby on Rails. ¿Por qué? Porque, en su mayor parte, es "independiente de la base de datos". Lo que significa que debería poder escribir su código Ruby y cambiar entre bases de datos sin ningún problema.

    Se puede descargar una muestra de una versión finalizada de este proceso desde GitHub .

    El primer paso: entorno de implementación

    Llegaremos a la implementación más adelante, pero Ruby on Rails está dividido de forma predeterminada en entornos de desarrollo, prueba y producción. Vamos a agregar a esta lista un nuevo entorno de demostración para nuestra aplicación que será casi idéntico al entorno de producción pero nos permitirá usar diferentes configuraciones de base de datos.

    En Rails, cree un nuevo entorno duplicando el config/environments/production.rbarchivo y cámbiele el nombre demo.rb. Dado que el entorno de demostración se utilizará en una configuración similar a la de producción, es posible que no necesite cambiar muchas opciones de configuración para este nuevo entorno, aunque sugeriría cambiar config.assets.compilede falsea true, lo que facilitará la prueba local sin tener que precompilar.

     

    Si está ejecutando Rails 4 o superior, también deberá actualizar config/secrets.ymlpara agregar un secret_key_baseentorno de demostración. Asegúrese de que esta clave secreta sea diferente a la de producción para garantizar que las sesiones sean únicas entre cada entorno, lo que protegerá aún más su aplicación.

    A continuación debe definir la configuración de la base de datos en config/database.yml. Si bien el entorno de demostración utilizará principalmente la base de datos duplicada que cubriremos en la siguiente sección, debemos definir el archivo de base de datos predeterminado y la configuración que se utilizará para nuestra demostración. Agregue lo siguiente a config/database.yml:

    demo: adapter: sqlite3 pool: 5 timeout: 5000 database: db/demo.sqlite3

    En Rails, es posible que también desee verificar Gemfilepara asegurarse de que SQLite3 esté disponible en el nuevo entorno de demostración. Puedes configurar esto de varias maneras, pero puede verse así:

    group :development, :test, :demo do gem 'sqlite3'end

    Una vez que la base de datos está configurada, debe rake db:migrate RAILS_ENV=demoinicializar los datos en la base de datos como desee (ya sea desde un archivo inicial, ingresando manualmente nuevos datos o incluso duplicando el development.sqlite3archivo). En este punto, debe verificar para asegurarse de que todo esté funcionando ejecutándolo rails server -e demodesde la línea de comando. Mientras ejecuta el servidor en el nuevo entorno de demostración, puede asegurarse de que los datos de prueba sean como los desea, pero siempre puede volver y editar ese contenido más tarde. Al agregar su contenido a la base de datos de demostración, recomendaría crear un conjunto de datos limpio para que el archivo sea lo más pequeño posible. Sin embargo, si necesita migrar datos desde otra base de datos, le recomiendo YamlDb , que crea un formato independiente de la base de datos para volcar y restaurar datos.

    Si su aplicación Rails se ejecuta como se esperaba, puede continuar con el siguiente paso.

    El segundo paso: usar la base de datos de demostración

    La parte esencial de este tutorial es poder permitir que cada sesión utilice un archivo de base de datos SQLite diferente. Normalmente su aplicación se conectará a la misma base de datos para cada usuario, por lo que será necesario código adicional para esta tarea.

    Para comenzar a permitir que Ruby on Rails cambie de base de datos, primero debemos agregar los siguientes cuatro métodos privados a application_controller.rb. También deberá definir un filtro anterior para el método set_demo_databasede modo que se llame a la lógica que hace referencia a la base de datos de demostración correcta en cada carga de página.

    # app/controllers/application_controller.rb# use `before_filter` for Rails 3before_action :set_demo_database, if: - { Rails.env == 'demo' }private # sets the database for the demo environment def set_demo_database if session[:demo_db] # Use database set by demos_controller db_name = session[:demo_db] else # Use default 'demo' database db_name = default_demo_database end ActiveRecord::Base.establish_connection(demo_connection(db_name)) end # Returns the current database configuration hash def default_connection_config @default_config ||= ActiveRecord::Base.connection.instance_variable_get("@config").dup end # Returns the connection hash but with database name changed # The argument should be a path def demo_connection(db_path) default_connection_config.dup.update(database: db_path) end # Returns the default demo database path defined in config/database.yml def default_demo_database return YAML.load_file("#{Rails.root.to_s}/config/database.yml")['demo']['database'] end

    Dado que cada sesión del servidor tendrá una base de datos diferente, almacenará el nombre del archivo de la base de datos en una variable de sesión. Como puede ver, estamos utilizando session[:demo_db]para rastrear la base de datos específica del usuario. El set_demo_databasemétodo consiste en controlar qué base de datos utilizar estableciendo la conexión a la base de datos establecida en la variable de sesión. El default_demo_databasemétodo simplemente carga la ruta de la base de datos tal como se define en el database.ymlarchivo de configuración. Blog sobre salud

     

    Si está utilizando un lenguaje básico, en este punto probablemente pueda simplemente actualizar el script de conexión de su base de datos para que apunte a la nueva base de datos y luego pasar a la siguiente sección. En Rails, las cosas requieren algunos pasos más porque sigue el paradigma de software de "convención sobre configuración".

    El tercer paso: duplicar el archivo SQLite

    Ahora que la aplicación está configurada para usar la nueva base de datos, necesitamos un activador para la nueva sesión de demostración. En aras de la simplicidad, comience simplemente usando el botón básico "Iniciar demostración". También puede convertirlo en un formulario en el que recopile un nombre y una dirección de correo electrónico (para un seguimiento del equipo de ventas, etc.) o cualquier cantidad de cosas.

    Siguiendo las convenciones de Rails, cree un nuevo controlador 'Demo':

    rails generate controller demos new

    A continuación, debe actualizar las rutas para que apunten a las acciones de su nuevo controlador, envolviéndolas en un condicional para evitar que se llame en el entorno de producción. Puedes nombrar las rutas como quieras o nombrarlas usando las convenciones estándar de Rails:

    if Rails.env == 'demo' get 'demos/new', as: 'new_demo' post 'demos' = 'demos#create', as: 'demos'end

    A continuación, agreguemos un formulario muy básico al archivo views/demos/new.html.erb. Es posible que desee agregar campos de formulario adicionales para capturar:

    h1Start a Demo/h1%= form_tag demos_path, method: :post do % %= submit_tag 'Start Demo' %% end %

    La magia ocurre en la createacción. Cuando el usuario se envía a esta ruta, la acción copiará el demo.sqlite3archivo con un nuevo nombre de archivo único, establecerá variables de sesión, iniciará sesión con el usuario (si corresponde) y luego redirigirá al usuario a la página apropiada (a esto lo llamaremos "panel de control"). ).

    class DemosController ApplicationController def new # Optional: setting session[:demo_db] to nil will reset the demo session[:demo_db] = nil end def create # make db/demos dir if doesn't exist unless File.directory?('db/demos/') FileUtils.mkdir('db/demos/') end # copy master 'demo' database master_db = default_demo_database demo_db = "db/demos/demo-#{Time.now.to_i}.sqlite3" FileUtils::cp master_db, demo_db # set session for new db session[:demo_db] = demo_db # Optional: login code (if applicable) # add your own login code or method here login(User.first) # Redirect to wherever you want to send the user next redirect_to dashboard_path endend

    Ahora debería poder probar el código de demostración localmente iniciando una vez más el servidor ejecutando rails server -e demo.

     

    Si ya tenía el servidor ejecutándose, deberá reiniciarlo para cualquier cambio que realice, ya que está configurado para almacenar en caché el código como el servidor de producción.

    Una vez que todo el código funcione como se esperaba, confirme los cambios en su control de versiones y asegúrese de confirmar el demo.sqlite3archivo, pero no los archivos del db/demosdirectorio. Si estás usando git, simplemente puedes agregar lo siguiente a tu .gitignorearchivo:

    Si desea recopilar información adicional del usuario de la demostración (como nombre y/o correo electrónico), probablemente desee enviar esa información a través de una API a su aplicación principal o a algún otro canal de ventas, ya que su base de datos de demostración no será confiable. (se reinicia cada vez que se vuelve a implementar).

    !/db/demo.sqlite3db/demos/*

    Paso final: implementar su servidor de demostración

    Ahora que tiene su configuración de demostración funcionando localmente, obviamente querrá implementarla para que todos puedan usarla. Si bien cada aplicación es diferente, recomendaría que la aplicación de demostración viva en un servidor separado y, por lo tanto, tenga el mismo dominio que su aplicación de producción (como demo.myapp.com). Esto asegurará que mantenga los dos entornos aislados. Además, dado que el archivo SQLite se almacena en el servidor, servicios como Heroku no funcionarán ya que no brindan acceso al sistema de archivos. Sin embargo, aún puedes utilizar prácticamente cualquier proveedor de VPS (como AWS EC2, Microsoft Azure, etc.). Si le gusta la comodidad automatizada, existen otras opciones de Plataformas como Servicio que le permiten trabajar con VPS.

    Independientemente de su proceso de implementación, es posible que también deba verificar que la aplicación tenga los permisos de lectura/escritura adecuados para su directorio donde almacena los archivos SQLite de demostración. Esto podría manejarse manualmente o con un gancho de implementación.

    SQLite no funcionará para mí. ¿Qué pasa con otros sistemas de bases de datos?

    No se crean dos aplicaciones iguales ni tampoco sus requisitos de base de datos. Al utilizar SQLite, tiene la ventaja de poder duplicar rápidamente la base de datos, además de poder almacenar el archivo en control de versiones. Si bien creo que SQLite funcionará en la mayoría de las situaciones (especialmente con Rails), hay situaciones en las que SQLite podría no ser adecuado para las necesidades de su aplicación. Afortunadamente, todavía es posible utilizar los mismos conceptos anteriores con otros sistemas de bases de datos. El proceso de duplicar una base de datos será ligeramente diferente para cada sistema, pero describiré una solución para MySQL y existe un proceso similar con PostgreSQL y otros.

     

    La mayoría de los métodos cubiertos anteriormente funcionan sin modificaciones adicionales. Sin embargo, en lugar de almacenar un archivo SQLite en su control de versiones, debe usar mysqldump(o pg_dumppara PostgreSQL) para exportar un archivo SQL de cualquier base de datos que tenga el contenido que le gustaría usar para su experiencia de demostración. Este archivo también debe almacenarse en su control de versiones.

    Los únicos cambios al código anterior se encontrarán en la demos#createacción. En lugar de copiar el archivo SQLite3, la acción del controlador creará una nueva base de datos, cargará el archivo SQL en esa base de datos y otorgará permisos al usuario de la base de datos si es necesario. El tercer paso de otorgar acceso solo es necesario si el usuario administrador de su base de datos es diferente del usuario que utiliza la aplicación para conectarse. El siguiente código utiliza comandos MySQL estándar para realizar estos pasos:

    def create # database names template_demo_db = default_demo_database new_demo_db = "demo_database_#{Time.now.to_i}" # Create database using admin credentials # In this example the database is on the same server so passing a host argument is not require `mysqladmin -u#{ ENV['DB_ADMIN'] } -p#{ ENV['DB_ADMIN_PASSWORD'] } create #{new_demo_db}` # Load template sql into new database # Update the path if it differs from where you saved the demo_template.sql file `mysql -u#{ ENV['DB_ADMIN'] } -p#{ ENV['DB_ADMIN_PASSWORD'] } #{new_demo_db} db/demo_template.sql` # Grant access to App user (if applicable) `mysql -u#{ ENV['DB_ADMIN'] } -p#{ ENV['DB_ADMIN_PASSWORD'] } -e "GRANT ALL on #{new_demo_db}.* TO '#{ ENV['DB_USERNAME'] }'@'%';"` # set session for new db session[:demo_db] = new_demo_db # Optional: login code (if applicable) # add your own login code or method here login(User.first) redirect_to dashboard_pathend

    Ruby, como muchos otros lenguajes, incluido PHP, le permite usar comillas invertidas para ejecutar un comando de shell (es decir, `ls -a`) desde su código. Sin embargo, debe usar esto con precaución y asegurarse de que no se puedan insertar parámetros o variables de cara al usuario en el comando para proteger su servidor contra código inyectado maliciosamente . En este ejemplo, estamos interactuando explícitamente con las herramientas de línea de comandos de MySQL, que es la única forma de crear una nueva base de datos. Esta es la misma forma en que el marco Ruby on Rails crea una nueva base de datos. Asegúrese de reemplazar ENV['DB_ADMIN']y ENV['DB_ADMIN_PASSWORD']con su propia variable de entorno o cualquier otra forma de configurar el nombre de usuario de la base de datos. Deberá hacer lo mismo si ENV['DB_USERNAME']su usuario administrador es diferente del usuario de su aplicación.

    ¡Eso es todo lo que se necesita para cambiar a MySQL! La ventaja más obvia de esta solución es que no tiene que preocuparse por posibles problemas que puedan surgir debido a la diferente sintaxis entre los sistemas de bases de datos.

    Al final, se toma una decisión final basada en la calidad y el servicio esperados, más que en la conveniencia y la velocidad, y no está necesariamente influenciada únicamente por el precio.

    Pensamientos finales

    Este es sólo un punto de partida de lo que puede hacer con su nuevo servidor de demostración. Por ejemplo, su sitio web de marketing podría tener un enlace a "Pruebe la función XYZ". Si no necesita un nombre o correo electrónico, puede vincular demos#createel método con un enlace como /demos/?feature=xyzy la acción simplemente redirigiría a la función y/o página deseada, en lugar del panel del ejemplo anterior.

    Además, si utiliza SQLite para los entornos de desarrollo y demostración, tener siempre esta base de datos de muestra en el control de versiones les daría a todos sus desarrolladores acceso a una base de datos limpia para usar en desarrollo local, entornos de prueba o pruebas de control de calidad. Las posibilidades son infinitas.

    Puede descargar una demostración completa desde GitHub .

    Otras lecturas

    • Una descripción general de alto nivel de conceptos, casos de uso y herramientas de modelos de lenguaje grandes
    • Cómo desarrollar WordPress localmente con MAMP
    • Comprensión de RPC frente a REST para API HTTP
    • El desarrollo web se está volviendo demasiado complejo y puede ser culpa nuestra

    (rb, ra, il, mrn)Explora más en

    • Aplicaciones
    • SQL
    • Ruby on Rails
    • javascript





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Rompiendo las reglas: uso de SQLite para demostrar aplicaciones web

    Rompiendo las reglas: uso de SQLite para demostrar aplicaciones web

    ¡Registro! Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX Índice ¿Por qu

    programar

    es

    https://aprendeprogramando.es/static/images/programar-rompiendo-las-reglas-uso-de-sqlite-para-demostrar-aplicaciones-web-931-0.jpg

    2024-05-20

     

    Rompiendo las reglas: uso de SQLite para demostrar aplicaciones web
    Rompiendo las reglas: uso de SQLite para demostrar aplicaciones web

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20