Trần Xuân Thắng

Theo mình biết thì Rails mặc định không có kiểu cache chính xác như bạn nói. Tuy vậy Rails có low-level caching mà bạn có thể dùng để cache từng query mà bạn muốn trong khoảng thời gian bạn đặt.

Ví dụ:

class User < ApplicationRecord
  def User.all_cached
    Rails.cache.fetch('users/all', expires_in: 1.day) do
      User.all
    end
  end
end

Sau đó bất cứ chỗ nào bạn cần sử dụng User.all, bạn thay bằng gọi đến User.all_cached. Ngoài ra bất cứ khi nào có thay đổi gì ở bảng users, ví dụ như có người dùng mới đăng ký, người dùng sửa thông tin hay đổi password,... bạn cần phải tự tay invalidate cache ở trên với Rails.cache.delete để dữ liệu được đồng nhất.

Mình thấy đây là câu hỏi rất hay, nhưng tiếc là theo mình thấy thì không có nhiều cách để giải quyết vấn đề này từ phía bạn. Việc giảm thiểu tấn công bằng cách chặn chỉ qua địa chỉ IP vốn đã không phải là cách hay rồi. Cách tốt nhất là bạn nên liên hệ với website đó, nhờ họ unblock và whitelist dải IP của công ty bạn luôn.

Đây là câu hỏi về sử dụng COUNT() với GROUP BY khá đơn giản. Bạn thử tham khảo 2 truy vấn sau nhé:

SELECT table_b.*, COUNT(table_a.tb_id) AS total_id
FROM table_b LEFT JOIN table_a ON table_b.tb_id = table_a.tb_id
GROUP BY table_b.tb_id, table_b.av_name
ORDER BY table_b.tb_id;

SELECT DISTINCT(ka_status), COUNT(tb_id) AS count_status
FROM table_a
GROUP BY ka_status
ORDER BY ka_status;

Bạn xem ví dụ qua fiddle dưới đây nhé: http://sqlfiddle.com/#!17/8837d9/10

Wordpress từ đầu vốn đã không phải là mã nguồn hướng đến hiệu suất cao. Bạn có thể thử tìm những plugin giúp bổ sung khả năng cache như Total Cache, Super Cache,... để giúp cải thiện hiệu suất xem sao. Với trang web dần cồng kềnh và có nhiều lượt truy cập thì mình nghĩ đây là lúc để dần xây dựng mã nguồn Web riêng cho đúng với mục đích của bạn nhất và migrate sang, lúc này bạn sẽ có nhiều cơ hội để tối ưu hoá hơn và tuỳ ý sử dụng công nghệ mình muốn (như sử dụng Node.js, Go, Mongodb,...).

Bạn thử thay text thành html xem, nếu đoạn text đó là từ người dùng thì cẩn thận để khỏi bị XSS

swal({
        title: title,
        html: '<h1>This is text</h1>',
    });

https://sweetalert2.github.io/#examples

Bạn không nên đặt bundle install ngay vào trong câu lệnh RUN của Dockerfile. Thay vào đó, bạn nên chuyển bundle install vào trong file start.sh.

Ví dụ file start.sh:

#!/bin/sh
bundle
rm /api/tmp/pids/server.pid
bundle exec rails s -b 0.0.0.0

Sau đó ở file docker-compose.yml thì bổ sung volume:

  app:
    container_name: app
    build: .
    volumes:
      - ./app:/app
      - ./data/api/bundle:/usr/local/bundle
    ports:
      - 3000:3000
    environment:
      DATABASEHOST: mysql

Tìm hiểu thêm ở https://anonoz.github.io/tech/2019/03/10/rails-docker-compose-yml.html

Nếu chỉ là một lần lăn chuột cuộn được luôn một màn hình thì cái này có thể làm chỉ cần qua CSS với scroll-snapping:

Xem thêm ở https://css-tricks.com/practical-css-scroll-snapping/

Nếu bạn dùng chế độ thread, thì có thể làm đơn giản như sau:

count = [0, 0, 0, 0, 0]
Parallel.map(items, in_threads: 5) do |item|
  count[Parallel.worker_number] += 1
  sleep(100) if count[Parallel.worker_number] % 100 == 0
  # process(item)
end

Chỉ jRuby hay mấy bản phân phối Ruby không có GIL/GVL thì mới có multithread thực thụ nhé. Còn nếu dùng bản phân phối MRI (phổ biến nhất) thì nó sẽ mãi thực thi ở thread 0, trừ khi có tác vụ blocking (I/O hay ví dụ sleep như ở trên) thì các thread khác mới được sử dụng.

Bạn có thể thử truy vấn với WITH RECURSIVE (sử dụng CTE) để truy vấn mọi đại lý cấp dưới, và cấp dưới của cấp dưới,... của 1 user.

WITH RECURSIVE a AS (
  SELECT *, 0 AS level, CAST(affID AS VARCHAR) AS path
  FROM daily 
  WHERE nguoigt = 0
  
  UNION ALL
  
  SELECT b.*, a.level + 1 AS level, CAST(CONCAT(a.path, '/', b.affID) AS VARCHAR) AS path
  FROM a 
  INNER JOIN daily b
  ON a.affID = b.nguoigt
)
SELECT * FROM a ORDER BY path;

Đây là dữ liệu giả + ví dụ: http://sqlfiddle.com/#!17/e8210f/4

CTE hỗ trợ cho mariaDB từ bản 10.2.2 trở lên nên bạn cần phải update phiên bản mariaDB mới có thể gọi câu query trên.

Thay vì cho chạy cron job 1 phút/lần, một cách tốt hơn là thêm một trường tên expires_at (bằng now() + 5 phút) cho bảng table_otp của bạn và check cái trường này lúc xác nhận otp xem đã bị vượt quá chưa.

Sau đó bạn vẫn cần cron job để dọn dẹp, nhưng chỉ cần chạy nó 1 tuần/lần thôi thay vì mỗi phút, hiệu năng sẽ ổn hơn nhiều.

Qua comment của bạn trả lời thì mình nghĩ là có thể dùng truy vấn UNION trong sql như dưới đây (ví dụ có 2 bảng).

(SELECT *,
        'a' AS source
 FROM   a_table
 ORDER  BY date DESC
 LIMIT  1)
UNION
(SELECT *,
        'b' AS source
 FROM   b_table
 ORDER  BY date DESC
 LIMIT  1);

Câu này sẽ giúp lấy 1 record mới nhất của mỗi bảng a_table và b_table và bạn cũng sẽ biết được source nó thuộc từ bảng nào. Bạn thử kiểm tra xem được không nhé.

Nếu ý bạn đang nói là trình soạn thảo hỗ trợ cú pháp Markdown như Viblo đang dùng thì bạn có thể chọn thư viện:

• SimpleMDE (https://github.com/sparksuite/simplemde-markdown-editor) - là thư viện lâu đời, tuy nhiên gần đây không thấy được bảo trì nữa (commit mới nhất là năm 2016).
• EasyMDE (https://github.com/Ionaru/easy-markdown-editor) - nên dùng hơn, là một fork của SimpleMDE, mới hơn và vẫn được bảo trì thường xuyên.

Trường khóa chính trong bảng là một trường không NULL, được đánh index, được đảm bảo unique và giúp các bản ghi của bảng khác có thể tham chiếu đến qua khóa ngoại.

Nếu bảng không có trường nào là khóa chính, không những bạn bỏ lỡ khả năng truy vấn nhanh hơn nhờ index, mà cũng có nghĩa khả năng cao trong cơ sở dữ liệu của bạn không có ràng buộc quan hệ nào. Vì vậy, cơ sở dữ liệu của bạn có cơ hội xảy ra dị thường.

Ví dụ, bạn có một bảng users liên kết 1-nhiều bảng khác là articles. Khi bạn xóa đi một người dùng trong users, nhưng các articles của người dùng đó vẫn không bị xóa, mà lại tham chiếu đến một cái id người dùng không hề tồn tại (?!)

Vì vậy, bạn LUÔN LUÔN NÊN tạo khóa chính (thường tên là id) cho mọi bảng.

Mình không có nhiều hiểu biết về mạng lắm, nhưng cũng xin thử trả lời câu hỏi của bạn:

Trước hết thì ngày nay nhờ https nên hầu hết các lượt truy cập mạng đều đã được tự động mã hóa. Khi bạn truy cập https://google.com, ISP có thể biết được bạn đang kết nối đến 172.217.31.238 (địa chỉ IP của google), và tên miền google.com (nếu bạn không dùng DoH hay DoT), nhưng không thể biết được bạn đang tìm kiếm cái gì. => vốn internet ngày nay đã an toàn hơn xưa rất nhiều rồi. ISP vẫn đóng vai trò gửi thông tin đến đích nên vẫn cần phải biết địa chỉ IP đích của bạn, do đó ISP vẫn có thể chặn request mạng dựa trên IP được.

Còn VPN thì thật ra hoạt động tương đối đơn giản. Nó đóng vai trò trung gian kết nối giữa bạn và server đích. Quá trình kết nối giữa bạn <=> VPN cũng được mã hóa sẵn, nên nếu bạn sử dụng VPN và kết nối vào google.cọm, ISP sẽ không hề hay biết và chỉ nhìn thấy được rằng bạn đang truy cập tới IP của VPN. Cái header bạn đang nói, hay dù cái gì truyền giữa bạn với VPN đi nữa, cũng đều được mã hóa và chỉ có bạn & chủ sở hữu VPN biết. Còn sâu xa hơn thì mình không rõ đâu nhé )

Một ứng dụng Electron bản chất chỉ là trình duyệt Chromium headless, nén sẵn cùng với tài nguyên html, css, js,... như một trang web thông thường. Vậy việc giữ bảo mật cho đống asset kia cũng như cách bạn bảo vệ các asset html, css, js trên trang web của bạn không cho người khác đọc.

Nói cách khác là điều đấy là rất khó, bởi những thứ này vốn đã ở sẵn trong máy của người dùng rồi. Bạn không thể đưa cho người ta cả cái két sắt + chìa khóa nhưng lại muốn ngăn họ đừng mở cái két đó ra được. Bạn có thể minify và obfuscate mã nguồn, nhưng một ngươi đủ giỏi vẫn có thể deobfuscate nó như thường. Điều này cũng đúng không chỉ với nodejs hay javascript, mà những file apk của android, hay app binary hoàn toàn cũng có thể dịch ngược được thôi.

Cách tốt nhất là luôn cho rằng mã nguồn ứng dụng của bạn cho người dùng sử dụng trong máy hoàn toàn mở và bất cứ ai cũng đọc được. Từ đó, bạn đưa các logic hay những dữ liệu nhạy cảm cho phía backend quản lý và trả về ứng dụng.

Có một số cách để encrypt file ASAR hay các dữ liệu quan trọng cho Electron, nhưng mình nghĩ nó cũng không thể bảo vệ 100%, vì như mình nói ở trên, cái chìa khóa (key để giải mã) vẫn là do người dùng giữ và ở trên máy của người dùng.

Mình thấy thì cách bạn query không có vấn đề gì.

Mình có thể gợi ý một hướng để bạn gỡ lỗi: thử xem đoạn code trên trả về SQL thế nào:

$query = Street::where('name', 'LIKE', "%{$name}%");
$query->toSql(); // lấy câu lệnh sql
$query->getBindings(); // lấy các param

Sau đó nếu thấy câu query bằng SQL vẫn chính xác, hãy thử execute trực tiếp câu query SQL đó (bằng CLI của mysql hay psql) và kiểm tra kết quả trả về.

Để chuyển đổi ký hiệu xuống dòng (\n hoặc \r\n) mà người dùng nhập vào thành xuống dòng thực sự khi hiển thị ra giao diện thì có một số hướng sau đây nhá:

Sử dụng CSS white-space: pre-line

<span style="white-space: pre-line">Cộng hòa xã hội chủ nghĩa Việt Nam
Độc lập tự do hạnh phúc</span>

Xem ví dụ tại JSFiddle này: https://jsfiddle.net/0mcpahrj/

Chuyển đổi ký hiệu xuống dòng sang thẻ <br>

Cách này thì bạn chỉ cần thay thế mọi ký tự \n sang thẻ <br> là được. Đối với Javascript/Nodejs thì bạn có thể dùng cách thế này hoặc tương tự:

str.replace(new RegExp('\n', 'g'), '<br>')

Sau mỗi lần xuống dòng (hoặc 2 dấu xuống dòng) thì gói từng đoạn riêng lẻ vào thẻ đoạn văn <p>:

str
  .replace(new RegExp('\r\n', 'g'), '\n')
  .split('\n\n')
  .map(p => `<p>${p}</p>`)
  .join('')

Xem ví dụ ở đây: https://jsfiddle.net/r9f17uej/

Dùng luôn một thư viện parse markdown cho xịn sò ở frontend

Một số thư viện như markdown-it chẳng hạn. Vấn đề hiển thị xuống dòng của bạn sẽ tự được thư viện đó giải quyết, và còn được thêm cú pháp markdown nữa :v

Nhớ rằng cách giải quyết đẹp nhất luôn là xử lý dữ liệu (thêm xuống dòng, format văn bản) khi chuẩn bị đưa dữ liệu ra view, hoặc ở phía frontend.Nên tránh biến đổi trước khi đưa dữ liệu vào CSDL nhé.

• Bạn nên để các video cho các dịch vụ cloud storage quản lý như s3, google cloud storage,... Làm vậy sẽ giúp giảm tải server chính của bạn Nếu muốn dùng hàng VN thì hiện tại mình thấy có storage.com.vn nhé
• Mấy cái S3, GCS ở trên tuy lưu trữ hàng TB vẫn rẻ, nhưng phí băng thông thì trên trời, nên bạn nên dùng kết hợp với CDN nhé. CDN rất nhanh và giá băng thông thì lại cực rẻ. Nhất là khi trang web của bạn có người nước ngoài dùng nữa thì càng được hưởng lợi từ việc dùng CDN.
• Bạn nên encode video ra nhiều định dạng nhất có thể, từ 360p đến 1080p, 2 định dạng là mp4 và webm. Cho client dùng webm nếu có thể vì web cho dung lượng/chất lượng rất ổn (cẩn thận là Safari không hỗ trợ webm nhé).