แหกกฎ: การใช้ SQLite เพื่อสาธิตเว็บแอป

ผู้ใช้ที่มีศักยภาพส่วนใหญ่จะต้องการทดลองใช้ซอฟต์แวร์หรือบริการก่อนที่จะยอมสละเวลาและเงินใดๆ ผลิตภัณฑ์บางอย่างใช้งานได้ดีโดยเพียงแค่ให้ผู้ใช้ทดลองใช้งานฟรี ในขณะที่แอปอื่นๆ จะมีประสบการณ์ที่ดีที่สุดกับข้อมูลตัวอย่างที่มีอยู่แล้ว บ่อยครั้งนี่คือจุดที่บัญชีทดลองเก่าเข้ามาเล่น

อย่างไรก็ตาม ใครก็ตามที่เคยใช้บัญชีทดลองสามารถยืนยันถึงปัญหาที่เกี่ยวข้องได้ คุณรู้ว่าสิ่งต่าง ๆ ทำงานบนอินเทอร์เน็ตอย่างไร: ทุกคนสามารถป้อนข้อมูล (ไม่ว่าจะสมเหตุสมผลหรือไม่ก็ตามสำหรับผลิตภัณฑ์) และมีโอกาสดีที่เนื้อหาที่เพิ่มโดยผู้ใช้ที่ไม่ระบุชื่อหรือบอทอาจเป็นที่น่ารังเกียจต่อผู้อื่น แน่นอน คุณสามารถรีเซ็ตฐานข้อมูลได้เสมอ แต่จะบ่อยแค่ไหนและเมื่อไหร่ และท้ายที่สุด มันช่วยแก้ปัญหาได้จริงหรือ? โซลูชันของฉันในการใช้ SQLite

ทำไมไม่ใช้ SQLite สำหรับเวอร์ชันที่ใช้งานจริง?

เป็นที่ทราบกันโดยทั่วไปว่า SQLite ไม่ได้จัดการหลายเธรด เนื่องจากฐานข้อมูลทั้งหมดถูกล็อกระหว่างคำสั่งเขียน ซึ่งเป็นหนึ่งในสาเหตุที่คุณไม่ควรใช้ในสภาพแวดล้อมที่ใช้งานจริงตามปกติ อย่างไรก็ตาม ในโซลูชันของฉัน ไฟล์ SQLite แยกต่างหากถูก ใช้สำหรับผู้ใช้แต่ละราย ที่สาธิตซอฟต์แวร์ ซึ่งหมายความว่าข้อจำกัดในการเขียนจำกัดเฉพาะผู้ใช้รายนั้น แต่ผู้ใช้หลายรายพร้อมกัน (แต่ละคนมีไฟล์ฐานข้อมูลของตนเอง) จะไม่พบข้อจำกัดนี้ ซึ่งช่วยให้ควบคุมประสบการณ์ในการทดสอบผู้ใช้ในการขับรถซอฟต์แวร์ และช่วยให้พวกเขาดูสิ่งที่ คุณ ต้องการให้พวกเขาเห็นได้อย่างแม่นยำ

บทช่วยสอนนี้อิงจากโซลูชันในโลกแห่งความเป็นจริงที่ฉันใช้งานสำหรับเว็บแอปสาธิต SaaS ได้สำเร็จมาตั้งแต่ปี 2015 บทช่วยสอนนี้เขียนขึ้นสำหรับ Ruby on Rails (กรอบงานที่ฉันเลือก) เวอร์ชัน 3 ขึ้นไป แต่แนวคิดพื้นฐานควรเป็น สามารถปรับให้เข้ากับภาษาหรือกรอบงานอื่น ๆ ได้ อันที่จริง เนื่องจาก Ruby on Rails ดำเนินตามกระบวนทัศน์ของซอฟต์แวร์ "การประชุมผ่านการกำหนดค่า" จึงอาจง่ายกว่าที่จะใช้ในเฟรมเวิร์กอื่น โดยเฉพาะอย่างยิ่งภาษาเปล่า (เช่น PHP แบบตรง) หรือเฟรมเวิร์กที่ไม่ได้ทำอะไรมากในแง่ของการจัดการการเชื่อมต่อฐานข้อมูล .

อย่างที่กล่าวไปแล้ว เทคนิคนี้เหมาะอย่างยิ่งสำหรับ Ruby on Rails ทำไม? เพราะโดยส่วนใหญ่แล้วมันคือ "ฐานข้อมูลไม่เชื่อเรื่องพระเจ้า" หมายความว่าคุณควรจะสามารถเขียนโค้ด Ruby และสลับไปมาระหว่างฐานข้อมูลได้โดยไม่มีปัญหาใดๆ

ตัวอย่างของกระบวนการนี้ที่เสร็จสิ้นแล้วสามารถดาวน์โหลดได้จาก GitHub

ขั้นตอนแรก: สภาพแวดล้อมการปรับใช้

เราจะทำการปรับใช้ในภายหลัง แต่โดยค่าเริ่มต้น Ruby on Rails จะแบ่งออกเป็นสภาพแวดล้อมการพัฒนา การทดสอบ และการใช้งานจริง เราจะเพิ่มสภาพแวดล้อมการสาธิตใหม่สำหรับแอปของเราที่เกือบจะเหมือนกันกับสภาพแวดล้อมการใช้งานจริงในรายการนี้ แต่จะอนุญาตให้เราใช้การตั้งค่าฐานข้อมูลที่แตกต่างกัน

ใน Rails ให้สร้างสภาพแวดล้อมใหม่โดยทำซ้ำไฟล์ config/environments/production.rb และเปลี่ยนชื่อเป็น demo.rb เนื่องจากสภาพแวดล้อมสาธิตจะใช้ในการผลิตเช่นการตั้งค่า คุณอาจไม่จำเป็นต้องเปลี่ยนตัวเลือกการกำหนดค่ามากมายสำหรับสภาพแวดล้อมใหม่นี้ แม้ว่าฉันจะแนะนำให้เปลี่ยน config.assets.compile จาก false true ซึ่งจะทำให้ง่ายต่อการทดสอบในเครื่องโดยไม่ต้อง ต้องคอมไพล์ล่วงหน้า

หากคุณใช้งาน Rails 4 ขึ้นไป คุณจะต้องอัปเดต config/secrets.yml เพื่อเพิ่ม secret_key_base สำหรับสภาพแวดล้อมการสาธิต อย่าลืมทำให้คีย์ลับนี้แตกต่างจากการใช้งานจริง เพื่อให้แน่ใจว่าเซสชันจะไม่ซ้ำกันระหว่างแต่ละสภาพแวดล้อม ซึ่งช่วยให้แอปของคุณปลอดภัยยิ่งขึ้น

ถัดไป คุณต้องกำหนดคอนฟิกูเรชันฐานข้อมูลใน config/database.yml แม้ว่าสภาพแวดล้อมการสาธิตจะใช้ฐานข้อมูลที่ซ้ำกันเป็นหลักซึ่งเราจะกล่าวถึงในส่วนถัดไป เราต้องกำหนดไฟล์ฐานข้อมูลเริ่มต้นและการตั้งค่าที่จะใช้สำหรับการสาธิตของเรา เพิ่มสิ่งต่อไปนี้ใน config/database.yml :

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

ใน Rails คุณอาจต้องการตรวจสอบ Gemfile ของคุณเพื่อให้แน่ใจว่า SQLite3 พร้อมใช้งานในสภาพแวดล้อมการสาธิตใหม่ คุณสามารถตั้งค่านี้ได้หลายวิธี แต่อาจมีลักษณะดังนี้:

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

เมื่อฐานข้อมูลได้รับการกำหนดค่าแล้ว คุณต้อง rake db:migrate RAILS_ENV=demo แล้วจึง seed ข้อมูลลงในฐานข้อมูลตามที่คุณต้องการ (ไม่ว่าจะมาจากไฟล์ seed การป้อนข้อมูลใหม่ด้วยตนเอง หรือแม้แต่การทำซ้ำไฟล์ development.sqlite3 ) ณ จุดนี้ คุณควรตรวจสอบเพื่อให้แน่ใจว่าทุกอย่างทำงานโดยเรียกใช้ rails server -e demo จากบรรทัดคำสั่ง ในขณะที่คุณใช้งานเซิร์ฟเวอร์ในสภาพแวดล้อมการสาธิตใหม่ คุณสามารถตรวจสอบให้แน่ใจว่าข้อมูลการทดสอบของคุณเป็นแบบที่คุณต้องการ แต่คุณสามารถกลับมาแก้ไขเนื้อหานั้นในภายหลังได้เสมอ เมื่อเพิ่มเนื้อหาของคุณลงในฐานข้อมูลสาธิต ฉันขอแนะนำให้สร้างชุดข้อมูลที่สะอาด เพื่อให้ไฟล์มีขนาดเล็กที่สุด อย่างไรก็ตาม หากคุณต้องการย้ายข้อมูลจากฐานข้อมูลอื่น ฉันขอแนะนำ YamlDb ซึ่งจะสร้างรูปแบบที่ไม่ขึ้นกับฐานข้อมูลสำหรับการดัมพ์และกู้คืนข้อมูล

หากแอปพลิเคชัน Rails ของคุณทำงานตามที่คาดไว้ คุณสามารถไปยังขั้นตอนถัดไปได้

ขั้นตอนที่สอง: การใช้ฐานข้อมูลสาธิต

ส่วนสำคัญของบทช่วยสอนนี้คือ การอนุญาตให้แต่ละเซสชันใช้ไฟล์ฐานข้อมูล SQLite ที่แตกต่างกัน โดยปกติ แอปพลิเคชันของคุณจะเชื่อมต่อกับฐานข้อมูลเดียวกันสำหรับผู้ใช้ทุกราย ดังนั้นจำเป็นต้องมีโค้ดเพิ่มเติมสำหรับงานนี้

ในการเริ่มต้นอนุญาตให้ Ruby on Rails เปลี่ยนฐานข้อมูล ก่อนอื่นเราต้องเพิ่มวิธีการส่วนตัวสี่วิธีต่อไปนี้ลงใน application_controller.rb คุณจะต้องกำหนด a before filter สำหรับเมธอด set_demo_database เพื่อที่ตรรกะที่อ้างอิงฐานข้อมูลการสาธิตที่ถูกต้องจะถูกเรียกในการโหลดหน้าเว็บทุกครั้ง

 # 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

เนื่องจากทุกเซสชันของเซิร์ฟเวอร์จะมีฐานข้อมูลที่แตกต่างกัน คุณจะต้องเก็บชื่อไฟล์ฐานข้อมูลไว้ในตัวแปรเซสชัน อย่างที่คุณเห็น เรากำลังใช้ session[:demo_db] เพื่อติดตามฐานข้อมูลเฉพาะสำหรับผู้ใช้ เมธอด set_demo_database ควบคุมฐานข้อมูลที่จะใช้โดยสร้างการเชื่อมต่อกับฐานข้อมูลที่ตั้งค่าในตัวแปรเซสชัน วิธี default_demo_database จะโหลดเส้นทางของฐานข้อมูลตามที่กำหนดไว้ในไฟล์กำหนดค่า database.yml

หากคุณกำลังใช้ภาษาเปล่า ณ จุดนี้คุณสามารถอัปเดตสคริปต์การเชื่อมต่อฐานข้อมูลของคุณให้ชี้ไปที่ฐานข้อมูลใหม่แล้วไปยังส่วนถัดไป ใน Rails สิ่งต่าง ๆ ต้องใช้ขั้นตอนเพิ่มเติมอีกสองสามขั้นตอนเพราะเป็นไปตามกระบวนทัศน์ของซอฟต์แวร์ "การประชุมผ่านการกำหนดค่า"

ขั้นตอนที่สาม: การทำซ้ำไฟล์ SQLite

ตอนนี้แอปได้รับการตั้งค่าให้ใช้ฐานข้อมูลใหม่แล้ว เราจำเป็นต้องมีทริกเกอร์สำหรับเซสชันสาธิตใหม่ เพื่อความเรียบง่าย ให้เริ่มต้นด้วยการใช้ปุ่ม "เริ่มการสาธิต" พื้นฐาน คุณยังสามารถสร้างแบบฟอร์มสำหรับรวบรวมชื่อและที่อยู่อีเมล (สำหรับการติดตามผลจากทีมขาย ฯลฯ) หรือสิ่งต่างๆ มากมาย

ผสานกับข้อตกลง Rails สร้างคอนโทรลเลอร์ 'Demo' ใหม่:

 rails generate controller demos new

ถัดไป คุณควรอัปเดตเส้นทางให้ชี้ไปที่การกระทำคอนโทรลเลอร์ใหม่ของคุณ ล้อมไว้ในเงื่อนไขเพื่อป้องกันไม่ให้ถูกเรียกในสภาพแวดล้อมที่ใช้งานจริง คุณสามารถตั้งชื่อเส้นทางได้ตามที่คุณต้องการหรือตั้งชื่อโดยใช้แบบแผน Rails มาตรฐาน:

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

ต่อไป ให้เพิ่มรูปแบบพื้นฐานมากใน views/demos/new.html.erb คุณอาจต้องการเพิ่มฟิลด์แบบฟอร์มเพิ่มเติมเพื่อจับภาพ:

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

ความมหัศจรรย์เกิดขึ้นในการดำเนินการ create เมื่อผู้ใช้ส่งไปยังเส้นทางนี้ การดำเนินการจะคัดลอกไฟล์ demo.sqlite3 ด้วยชื่อไฟล์ใหม่ที่ไม่ซ้ำ ตั้งค่าตัวแปรเซสชัน เข้าสู่ระบบผู้ใช้ (ถ้ามี) จากนั้นเปลี่ยนเส้นทางผู้ใช้ไปยังหน้าที่เหมาะสม (เราจะเรียกสิ่งนี้ว่า 'แผงควบคุม').

 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

ตอนนี้ คุณควรจะสามารถลองใช้โค้ดสาธิตในเครื่องได้โดยการเปิดเซิร์ฟเวอร์อีกครั้งโดยใช้ rails server -e demo

หากคุณมีเซิร์ฟเวอร์ที่ทำงานอยู่แล้ว คุณจะต้องรีสตาร์ทเซิร์ฟเวอร์สำหรับการเปลี่ยนแปลงใดๆ ที่คุณทำ เนื่องจากเซิร์ฟเวอร์ได้รับการกำหนดค่าให้แคชโค้ด เช่น เซิร์ฟเวอร์ที่ใช้งานจริง

เมื่อโค้ดทั้งหมดทำงานตามที่คาดไว้ ให้คอมมิตการเปลี่ยนแปลงในการควบคุมเวอร์ชันของคุณ และตรวจสอบให้แน่ใจว่าคุณคอมมิตไฟล์ demo.sqlite3 แต่ไม่ใช่ไฟล์ในไดเร็กทอรี db/demos หากคุณกำลังใช้ git คุณสามารถเพิ่มสิ่งต่อไปนี้ในไฟล์ .gitignore ของคุณ:

หากคุณต้องการรวบรวมข้อมูลเพิ่มเติมจากผู้ใช้สาธิต (เช่น ชื่อและ/หรืออีเมล) คุณอาจต้องการส่งข้อมูลนั้นผ่าน API ไปยังแอปพลิเคชันหลักของคุณหรือไปป์ไลน์การขายอื่น ๆ เนื่องจากฐานข้อมูลสาธิตของคุณจะไม่น่าเชื่อถือ (จะรีเซ็ตทุกครั้งที่คุณปรับใช้ใหม่)

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

ขั้นตอนสุดท้าย: การปรับใช้เซิร์ฟเวอร์สาธิตของคุณ

ตอนนี้คุณมีการตั้งค่าการสาธิตที่ทำงานในเครื่องแล้ว เห็นได้ชัดว่าคุณต้องการปรับใช้เพื่อให้ทุกคนสามารถใช้งานได้ แม้ว่าทุกแอปจะแตกต่างกัน ฉันขอแนะนำให้แอปสาธิตอยู่บนเซิร์ฟเวอร์ที่แยกจากกัน ดังนั้นโดเมนจึงเป็นแอปที่ใช้งานจริงของคุณ (เช่น demo.myapp.com) ซึ่งจะทำให้แน่ใจได้ว่าคุณเก็บสภาพแวดล้อมทั้งสองไว้แยกกัน นอกจากนี้ เนื่องจากไฟล์ SQLite ถูกเก็บไว้บนเซิร์ฟเวอร์ บริการต่างๆ เช่น Heroku จะไม่ทำงาน เนื่องจากไม่มีการเข้าถึงระบบไฟล์ อย่างไรก็ตาม คุณยังสามารถใช้ผู้ให้บริการ VPS ใดก็ได้ (เช่น AWS EC2, Microsoft Azure เป็นต้น) หากคุณชอบความสะดวกสบายแบบอัตโนมัติ มีตัวเลือก Platform as Service อื่นๆ ที่ให้คุณทำงานกับ VPS ได้

คุณอาจต้องตรวจสอบว่าแอปมีสิทธิ์อ่าน/เขียนที่เหมาะสมสำหรับไดเร็กทอรีของคุณที่คุณเก็บไฟล์สาธิต SQLite โดยไม่คำนึงถึงกระบวนการปรับใช้ของคุณ สามารถจัดการได้ด้วยตนเองหรือด้วยเบ็ดการปรับใช้

SQLite จะไม่ทำงานให้ฉัน แล้วระบบฐานข้อมูลอื่นล่ะ?

ไม่มีการสร้างแอพสองแอพที่เหมือนกันและไม่มีข้อกำหนดฐานข้อมูลของแอพทั้งสอง เมื่อใช้ SQLite คุณจะมีข้อได้เปรียบในการคัดลอกฐานข้อมูลได้อย่างรวดเร็ว ตลอดจนสามารถจัดเก็บไฟล์ในการควบคุมเวอร์ชันได้ แม้ว่าฉันเชื่อว่า SQLite จะทำงานในสถานการณ์ส่วนใหญ่ (โดยเฉพาะกับ Rails) แต่ก็มีบางสถานการณ์ที่ SQLite อาจไม่เหมาะกับความต้องการของแอปพลิเคชันของคุณ โชคดีที่ยังคงใช้แนวคิดเดียวกันข้างต้นกับระบบฐานข้อมูลอื่นๆ ได้ กระบวนการทำซ้ำฐานข้อมูลจะแตกต่างกันเล็กน้อยสำหรับแต่ละระบบ แต่ฉันจะร่างโซลูชันสำหรับ MySQL และมีกระบวนการที่คล้ายคลึงกันกับ PostgreSQL และอื่นๆ

วิธีการส่วนใหญ่ที่กล่าวถึงข้างต้นทำงานโดยไม่มีการแก้ไขเพิ่มเติม อย่างไรก็ตาม แทนที่จะจัดเก็บไฟล์ SQLite ในการควบคุมเวอร์ชันของคุณ คุณควรใช้ mysqldump (หรือ pg_dump สำหรับ PostgreSQL) เพื่อส่งออกไฟล์ SQL ของฐานข้อมูลใดก็ตามที่มีเนื้อหาที่คุณต้องการใช้สำหรับประสบการณ์การสาธิตของคุณ ไฟล์นี้ควรเก็บไว้ในการควบคุมเวอร์ชันของคุณด้วย

การเปลี่ยนแปลงเฉพาะในโค้ดก่อนหน้าจะพบได้ในการดำเนินการ demos#create แทนที่จะคัดลอกไฟล์ SQLite3 การดำเนินการควบคุมจะสร้างฐานข้อมูลใหม่ โหลดไฟล์ sql ลงในฐานข้อมูลนั้น และให้สิทธิ์แก่ผู้ใช้ฐานข้อมูลหากจำเป็น ขั้นตอนที่สามของการให้สิทธิ์การเข้าถึงจำเป็นต่อเมื่อผู้ดูแลระบบฐานข้อมูลของคุณแตกต่างจากผู้ใช้ที่แอปใช้ในการเชื่อมต่อ รหัสต่อไปนี้ใช้คำสั่ง MySQL มาตรฐานในการจัดการขั้นตอนเหล่านี้:

 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 ที่ให้คุณใช้ backticks เพื่อรันคำสั่งเชลล์ (เช่น `ls -a` ) จากภายในโค้ดของคุณ อย่างไรก็ตาม คุณต้องใช้สิ่งนี้ด้วยความระมัดระวัง และตรวจสอบให้แน่ใจว่าไม่มีพารามิเตอร์หรือตัวแปรที่ผู้ใช้เผชิญอยู่ในคำสั่ง เพื่อป้องกันเซิร์ฟเวอร์ของคุณจากการแทรกโค้ดที่เป็นอันตราย ในตัวอย่างนี้ เรากำลังโต้ตอบกับเครื่องมือบรรทัดคำสั่ง MySQL อย่างชัดเจน ซึ่งเป็นวิธีเดียวในการสร้างฐานข้อมูลใหม่ นี่เป็นวิธีเดียวกับที่เฟรมเวิร์ก Ruby on Rails สร้างฐานข้อมูลใหม่ อย่าลืมแทนที่ ENV['DB_ADMIN'] และ ENV['DB_ADMIN_PASSWORD'] ด้วยตัวแปรสภาพแวดล้อมของคุณเองหรือวิธีอื่นใดในการตั้งชื่อผู้ใช้ฐานข้อมูล คุณจะต้องทำเช่นเดียวกันกับ ENV['DB_USERNAME'] หากผู้ดูแลระบบของคุณแตกต่างจากผู้ใช้สำหรับแอปของคุณ

นั่นคือทั้งหมดที่ใช้ในการเปลี่ยนมาใช้ MySQL! ข้อได้เปรียบที่ชัดเจนที่สุดของโซลูชันนี้คือ คุณไม่ต้องกังวลกับปัญหาที่อาจเกิดขึ้นซึ่งอาจปรากฏขึ้นจากรูปแบบต่างๆ ระหว่างระบบฐานข้อมูล

ในที่สุด การตัดสินใจขั้นสุดท้ายจะขึ้นอยู่กับคุณภาพและบริการที่คาดหวัง มากกว่าความสะดวกและความเร็ว และไม่จำเป็นต้องได้รับอิทธิพลจากราคาเพียงอย่างเดียว

ความคิดสุดท้าย

นี่เป็นเพียงจุดเริ่มต้นสำหรับสิ่งที่คุณสามารถทำได้กับเซิร์ฟเวอร์สาธิตใหม่ของคุณ ตัวอย่างเช่น เว็บไซต์การตลาดของคุณอาจมีลิงก์ไปที่ "ลองใช้ฟีเจอร์ XYZ" หากคุณไม่ต้องการชื่อหรืออีเมล คุณสามารถเชื่อมโยงวิธีการ demos#create ด้วยลิงก์เช่น /demos/?feature=xyz และการดำเนินการจะเปลี่ยนเส้นทางไปยังคุณลักษณะและ/หรือหน้าที่ต้องการ แทนที่จะเป็นแดชบอร์ดใน ตัวอย่างข้างต้น

นอกจากนี้ หากคุณใช้ SQLite สำหรับการพัฒนาและสภาพแวดล้อมการสาธิต การมีฐานข้อมูลตัวอย่างนี้ในการควบคุมเวอร์ชันอยู่เสมอจะทำให้นักพัฒนาของคุณสามารถเข้าถึงฐานข้อมูลที่สะอาดเพื่อใช้ในการพัฒนาในพื้นที่ สภาพแวดล้อมการทดสอบ หรือการทดสอบการประกันคุณภาพ ความเป็นไปได้ไม่มีที่สิ้นสุด

คุณสามารถดาวน์โหลดตัวอย่างที่เสร็จสมบูรณ์ได้จาก GitHub