Kuralları Yıkmak: Web Uygulamalarını Tanıtmak İçin SQLite Kullanmak

Yayınlanan: 2022-03-10
Kısa özet ↬ Bir sonraki harika web uygulamasını oluşturdunuz, ancak şimdi her yeni ürünün düşünmesi gereken soruyla karşı karşıyasınız, "Uygulamamın ne kadar harika olduğunu herkese nasıl gösterebilirim?"

Potansiyel kullanıcıların çoğu, herhangi bir zaman ve para taahhüdünde bulunmadan önce yazılımı veya hizmeti denemek isteyecektir. Bazı ürünler, kullanıcılara yalnızca ücretsiz deneme süresi vererek harika çalışır, diğer uygulamalar ise en iyi şekilde halihazırda mevcut olan örnek verilerle deneyimlenir. Genellikle bu, eski demo hesabının devreye girdiği yerdir.

Bununla birlikte, bir demo hesabı uygulayan herkes, ilgili sorunları doğrulayabilir. İnternette işlerin nasıl yürüdüğünü bilirsiniz: Herkes veri girebilir (ürün için anlamlı olsun ya da olmasın) ve anonim kullanıcılar veya botlar tarafından eklenen içeriğin başkaları için rahatsız edici olma olasılığı yüksektir. Elbette, veritabanını her zaman sıfırlayabilirsiniz, ancak ne sıklıkta ve ne zaman? Ve nihayetinde, bu gerçekten sorunu çözüyor mu? SQLite kullanma çözümüm .

Üretim Sürümü İçin Neden SQLite Kullanmıyorsunuz?

SQLite'ın, bir yazma komutu sırasında tüm veritabanı kilitlendiğinden, normal bir üretim ortamında kullanmamanızın nedenlerinden biri olan, birden çok iş parçacığını işlemediği yaygın olarak bilinir. Ancak benim çözümümde, yazılımın demosunu yapan her kullanıcı için ayrı bir SQLite dosyası kullanılıyor . Bu, yazma sınırlamasının yalnızca bir kullanıcıyla sınırlı olduğu, ancak aynı anda birden çok kullanıcının (her biri kendi veritabanı dosyasına sahip) bu sınırlamayla karşılaşmayacağı anlamına gelir. Bu, yazılımı kullanan kullanıcı testi için kontrollü bir deneyim sağlar ve onların tam olarak görmelerini istediğiniz şeyi görmelerini sağlar.

Atlamadan sonra daha fazlası! Aşağıdan okumaya devam edin ↓

Bu öğretici, 2015'ten beri bir SaaS demo web uygulaması için başarıyla çalıştırdığım gerçek dünya çözümüne dayanmaktadır. Öğretici, Ruby on Rails (tercih ettiğim çerçeve) sürüm 3 ve üstü için yazılmıştır, ancak temel kavramlar şu şekilde olmalıdır: başka herhangi bir dile veya çerçeveye uyarlanabilir. Aslında, Ruby on Rails "konfigürasyon üzerinden konvansiyon" yazılım paradigmasını takip ettiğinden, diğer çerçevelerde, özellikle çıplak dillerde (düz PHP gibi) veya veritabanı bağlantılarını yönetme açısından fazla bir şey yapmayan çerçevelerde uygulanması daha kolay olabilir. .

Bununla birlikte, bu teknik özellikle Ruby on Rails için çok uygundur. Niye ya? Çünkü çoğunlukla "veritabanı agnostiğidir". Bu, Ruby kodunuzu yazabilmeniz ve veritabanları arasında sorunsuz bir şekilde geçiş yapabilmeniz gerektiği anlamına gelir.

Bu işlemin bitmiş bir sürümünün bir örneği GitHub'dan indirilebilir.

İlk Adım: Dağıtım Ortamı

Dağıtıma daha sonra geçeceğiz, ancak Ruby on Rails varsayılan olarak geliştirme, test ve üretim ortamlarına bölünmüştür. Bu listeye, uygulamamız için üretim ortamıyla neredeyse aynı olacak ancak farklı veritabanı ayarları kullanmamıza izin verecek yeni bir demo ortamı ekleyeceğiz.

Rails'de, config/environments/production.rb dosyasını çoğaltarak yeni bir ortam oluşturun ve onu demo.rb olarak yeniden adlandırın. Demo ortamı, üretim benzeri bir ayarda kullanılacağından, bu yeni ortam için birçok yapılandırma seçeneğini değiştirmeniz gerekmeyebilir, ancak config.assets.compile false true , bu da yerel olarak test etmeyi kolaylaştıracaktır. önceden derlemek zorunda.

Rails 4 veya üstünü çalıştırıyorsanız, demo ortamı için bir secret_key_base eklemek için config/secrets.yml secrets.yml dosyasını da güncellemeniz gerekir. Oturumların her ortam arasında benzersiz olduğundan emin olmak ve uygulamanızın güvenliğini daha da artırmak için bu gizli anahtarı üretimden farklı yaptığınızdan emin olun.

Ardından, config/database.yml içinde veritabanı yapılandırmasını tanımlamanız gerekir. Demo ortamı öncelikle bir sonraki bölümde ele alacağımız çoğaltılmış veritabanını kullanacak olsa da, demomuz için kullanılacak varsayılan veritabanı dosyasını ve ayarlarını tanımlamalıyız. Aşağıdakileri config/database.yml ekleyin:

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

Rails'de, SQLite3'ün yeni demo ortamında kullanılabilir olduğundan emin olmak için Gemfile de kontrol etmek isteyebilirsiniz. Bunu herhangi bir sayıda şekilde ayarlayabilirsiniz, ancak şöyle görünebilir:

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

Veritabanı yapılandırıldıktan sonra, rake db:migrate RAILS_ENV=demo ve ardından verileri veritabanına istediğiniz şekilde tohumlamanız gerekir (ister bir tohum dosyasından, ister manuel olarak yeni veriler girerek veya hatta development.sqlite3 dosyasını kopyalayarak). Bu noktada, komut satırından rails server -e demo çalıştırarak her şeyin çalışıp çalışmadığını kontrol etmelisiniz. Sunucuyu yeni demo ortamında çalıştırırken, test verilerinizin istediğiniz gibi olduğundan emin olabilirsiniz, ancak daha sonra istediğiniz zaman geri gelip o içeriği düzenleyebilirsiniz. İçeriğinizi demo veritabanına eklerken, dosyanın mümkün olduğunca küçük olması için temiz bir veri seti oluşturmanızı tavsiye ederim. Ancak, başka bir veritabanından veri taşımanız gerekiyorsa, verileri boşaltmak ve geri yüklemek için veritabanından bağımsız bir biçim oluşturan YamlDb'yi öneririm.

Rails uygulamanız beklendiği gibi çalışıyorsa bir sonraki adıma geçebilirsiniz.

İkinci Adım: Demo Veritabanını Kullanma

Bu öğreticinin temel kısmı, her oturumun farklı bir SQLite veritabanı dosyası kullanmasına izin vermektir. Normalde uygulamanız her kullanıcı için aynı veritabanına bağlanacaktır, böylece bu görev için ek kod gerekecektir.

Ruby on Rails'in veritabanlarını değiştirmesine izin vermeye başlamak için, önce aşağıdaki dört özel yöntemi application_controller.rb içine eklememiz gerekir. Ayrıca, her sayfa yüklemesinde doğru demo veritabanına başvuran mantığın çağrılabilmesi için set_demo_database yöntemi için bir Before filtresi tanımlamanız gerekecektir.

 # app/controllers/application_controller.rb # use `before_filter` for Rails 3 before_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

Her sunucu oturumu farklı bir veritabanına sahip olacağından, veritabanı dosya adını bir oturum değişkeninde saklarsınız. Gördüğünüz gibi, kullanıcıya özel veritabanını izlemek için session[:demo_db] kullanıyoruz. set_demo_database yöntemi, oturum değişkenindeki veritabanı kümesine bağlantı kurarak hangi veritabanının kullanılacağını kontrol ediyor. default_demo_database yöntemi, database.yml yapılandırma dosyasında tanımlandığı gibi veritabanının yolunu basitçe yükler.

Çıplak bir dil kullanıyorsanız, bu noktada muhtemelen veritabanı bağlantı komut dosyanızı yeni veritabanına işaret edecek şekilde güncelleyebilir ve ardından bir sonraki bölüme geçebilirsiniz. Rails'de, "yapılandırma konvansiyonu" yazılım paradigmasını takip ettiği için işler birkaç adım daha gerektirir.

Üçüncü Adım: SQLite Dosyasını Çoğaltmak

Artık uygulama yeni veritabanını kullanacak şekilde ayarlandığına göre, yeni demo oturumu için bir tetikleyiciye ihtiyacımız var. Basitlik adına, basit bir "Demoyu Başlat" düğmesini kullanarak başlayın. Ayrıca, bir ad ve e-posta adresi (satış ekibinden bir takip vb. için) veya herhangi bir sayıda şey topladığınız bir form da yapabilirsiniz.

Rails kurallarına bağlı kalarak yeni bir 'Demo' denetleyicisi oluşturun:

 rails generate controller demos new

Ardından, üretim ortamında çağrılmasını önlemek için yolları yeni denetleyici eylemlerinize işaret edecek şekilde güncellemelisiniz. Rotaları istediğiniz gibi adlandırabilir veya standart Rails kurallarını kullanarak adlandırabilirsiniz:

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

Sonra, views/demos/new.html.erb çok basit bir form ekleyelim. Yakalamak için ek form alanları eklemek isteyebilirsiniz:

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

Sihir create eyleminde gerçekleşir. Kullanıcı bu rotayı gönderdiğinde, eylem, demo.sqlite3 dosyasını yeni bir benzersiz dosya adıyla kopyalayacak, oturum değişkenlerini ayarlayacak, kullanıcıyı oturum açacaktır (varsa) ve ardından kullanıcıyı uygun sayfaya yönlendirecektir (buna 'Gösterge Paneli').

 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 end end

Şimdi, çalışan rails server -e demo kullanarak sunucuyu bir kez daha başlatarak demo kodunu yerel olarak deneyebilmelisiniz.

Sunucu zaten çalışıyorsa, kodu üretim sunucusu gibi önbelleğe alacak şekilde yapılandırıldığından, yaptığınız tüm değişiklikler için onu yeniden başlatmanız gerekir.

Tüm kod beklendiği gibi çalıştığında, değişikliklerinizi sürüm kontrolünüzde gerçekleştirin ve db/demos dizinindeki dosyaları değil, demo.sqlite3 dosyasını taahhüt ettiğinizden emin olun. Git kullanıyorsanız, aşağıdakileri .gitignore dosyanıza eklemeniz yeterlidir:

Demo kullanıcısından ek bilgiler (ad ve/veya e-posta gibi) toplamak istiyorsanız, demo veritabanınız güvenilir olmayacağından bu bilgileri bir API aracılığıyla ana uygulamanıza veya başka bir satış hattına göndermek isteyeceksiniz. (her yeniden konuşlandırmanızda sıfırlanır).

 !/db/demo.sqlite3 db/demos/*

Son Adım: Demo Sunucunuzu Dağıtma

Artık yerel olarak çalışan demo kurulumunuz olduğuna göre, herkesin kullanabilmesi için onu dağıtmak isteyeceksiniz. Her uygulama farklı olsa da, demo uygulamasının ayrı bir sunucuda yaşamasını ve bu nedenle üretim uygulamanız olarak etki alanını (demo.myapp.com gibi) öneririm. Bu, iki ortamı izole tutmanızı sağlayacaktır. Ek olarak, SQLite dosyası sunucuda depolandığından, dosya sistemine erişim sağlamadığından Heroku gibi hizmetler çalışmayacaktır. Bununla birlikte, pratik olarak herhangi bir VPS sağlayıcısını (AWS EC2, Microsoft Azure, vb.) kullanmaya devam edebilirsiniz. Otomatikleştirilmiş rahatlığı seviyorsanız, VPS ile çalışmanıza izin veren başka Hizmet Olarak Platformlar seçenekleri de vardır.

Dağıtım sürecinizden bağımsız olarak, uygulamanın, demo SQLite dosyalarını depoladığınız dizininiz için uygun okuma/yazma izinlerine sahip olup olmadığını da kontrol etmeniz gerekebilir. Bu, manuel olarak veya bir dağıtım kancasıyla ele alınabilir.

SQLite Benim İçin Çalışmayacak. Peki Diğer Veritabanı Sistemleri?

Hiçbir iki uygulama aynı şekilde oluşturulmaz ve bunların veritabanı gereksinimleri de yoktur. SQLite kullanarak, veritabanını hızlı bir şekilde çoğaltabilme ve aynı zamanda dosyayı sürüm kontrolünde depolayabilme avantajına sahipsiniz. SQLite'ın çoğu durumda (özellikle Rails ile) çalışacağına inansam da, SQLite'ın uygulamanızın ihtiyaçları için uygun olmayabileceği durumlar var. Neyse ki, yukarıdaki aynı kavramları diğer veritabanı sistemleriyle kullanmak hala mümkündür. Bir veritabanını çoğaltma işlemi her sistem için biraz farklı olacaktır, ancak MySQL için bir çözüm sunacağım ve PostgreSQL ve diğerlerinde benzer bir süreç var.

Yukarıda kapsanan yöntemlerin çoğu, herhangi bir ek değişiklik yapılmadan çalışır. Ancak, sürüm kontrolünüzde bir SQLite dosyası depolamak yerine, demo deneyiminiz için kullanmak istediğiniz içeriğe sahip herhangi bir veritabanının SQL dosyasını dışa aktarmak için mysqldump (veya PostgreSQL için pg_dump ) kullanmalısınız. Bu dosya ayrıca sürüm kontrolünüzde saklanmalıdır.

Önceki kodda yapılan tek değişiklik demos#create eyleminde bulunacaktır. SQLite3 dosyasını kopyalamak yerine, denetleyici eylemi yeni bir veritabanı oluşturacak, sql dosyasını bu veritabanına yükleyecek ve gerekirse veritabanı kullanıcısı için izinler verecektir. Erişim vermenin üçüncü adımı, yalnızca veritabanı yöneticisi kullanıcınız, uygulamanın bağlanmak için kullandığı kullanıcıdan farklıysa gereklidir. Aşağıdaki kod, bu adımları işlemek için standart MySQL komutlarını kullanır:

 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_path end

Ruby, PHP dahil diğer birçok dilde olduğu gibi, kodunuzdan bir kabuk komutunu (yani, `ls -a` ) yürütmek için geri tepmeleri kullanmanıza izin verir. Ancak, bunu dikkatli bir şekilde kullanmalı ve sunucunuzu kötü amaçla enjekte edilen koddan korumak için komuta kullanıcıya yönelik hiçbir parametre veya değişken eklenemeyeceğinden emin olmalısınız. Bu örnekte, yeni bir veritabanı oluşturmanın tek yolu olan MySQL komut satırı araçlarıyla açıkça etkileşime giriyoruz. Bu, Ruby on Rails çerçevesinin yeni bir veritabanı oluşturmasıyla aynı şekildedir. ENV['DB_ADMIN'] ve ENV['DB_ADMIN_PASSWORD'] kendi ortam değişkeninizle veya veritabanı kullanıcı adını ayarlamanın başka bir yolu ile değiştirdiğinizden emin olun. Yönetici kullanıcınız uygulamanızın kullanıcısından farklıysa, ENV['DB_USERNAME'] için de aynısını yapmanız gerekecektir.

MySQL'e geçmek için gereken tek şey bu! Bu çözümün en belirgin avantajı, veritabanı sistemleri arasındaki farklı sözdizimlerinden ortaya çıkabilecek olası sorunlar hakkında endişelenmenize gerek kalmamasıdır.

Sonunda, kolaylık ve hız yerine beklenen kalite ve hizmete dayalı olarak nihai bir karar verilir ve bu yalnızca fiyat noktasından etkilenmez.

Son düşünceler

Bu, yeni demo sunucunuzla yapabilecekleriniz için sadece bir başlangıç ​​noktasıdır. Örneğin, pazarlama web sitenizde "XYZ özelliğini deneyin" bağlantısı olabilir. Bir ada veya e-postaya ihtiyacınız yoksa, demos#create yöntemini /demos/?feature=xyz gibi bir bağlantıyla bağlayabilirsiniz ve eylem, içindeki gösterge tablosu yerine istediğiniz özelliğe ve/veya sayfaya yönlendirilecektir. yukarıdaki örnek.

Ayrıca, geliştirme ve demo ortamları için SQLite kullanıyorsanız, bu örnek veritabanının her zaman sürüm kontrolünde olması, tüm geliştiricilerinize yerel geliştirme, test ortamları veya kalite güvence testlerinde kullanım için temiz bir veritabanına erişim sağlar. İmkanlar sonsuzdur.

Tamamlanmış bir demoyu GitHub'dan indirebilirsiniz.