Tran Duc Thang

Mình thấy các trang web thương mại điện tử khi lưu địa chỉ thường sẽ tách nhỏ từng phần ra, tức cho chọn Tỉnh, chọn Quận, rồi sau đó mới cho người dùng gõ tên phố, tên đường cụ thể. Mình đoán là thiết kế cơ sở dữ liệu sẽ có trường Tỉnh Thành, và trường Quận Huyện riêng, sau đó sẽ dựa vào Tỉnh Thành và Quận Huyện để tính toán ra chi phí giao hàng (tức không cần quan tâm đến phố phường, thị xã ... Trong cùng một Quận Huyện thì phí sẽ như nhau).

Khi thiết lập bảng chi phí với cột Tỉnh Thành và cột Quận Huyện, bạn có thể có thêm cột trọng số để đánh mức độ tương quan giữa các tỉnh thành quận huyện với nhau, xem cái nào là rẻ hơn cái nào, cái nào là đắt hơn cái nào. Từ trọng số đó bạn dùng một công thức nào đó để tính ra chi phí Việc đánh trọng số chắc sẽ do người quản lý xây dựng từ đầu thôi

Ví dụ

Khi có được mã Tỉnh, mã Quận từ user, bạn tra trong bảng chi phí là sẽ tính ra được phí vận chuyển

• Làm chức năng thông báo realtime sử dụng nodejs (socketio) thì mình nghĩ là một sự lựa chọn hợp lý & phổ biến hiện nay rồi. Còn phần frontend bạn dùng React cũng tốt, cũng là một hot trend Khó thì không khó, bởi tài liệu liên quan đến kỹ thuật này có rất nhiều, kể cả trên Viblo, bạn có thể tìm hiểu thêm.
• Cấu hình máy chủ thì còn phụ thuộc vào nhiều vấn đề khác, như phần xử lý logic backend, cũng như lượng request được gửi tới đồng thời. Như ở ví dụ của bạn thì cùng lúc có 1000 người truy cập mình không rõ là cùng một lúc có 1000 requests gửi đến, và bạn yêu cầu phải xử lý được tầm 1000 requests / giây, hay là cùng một lúc có 1000 người đang mở trang web (không quan tâm họ gửi request lúc nào), và chỉ cần giữ 1000 kết nối socket thôi là được? Nếu là yêu cầu xử lý 1000 requests / giây thì câu trả lời là khó Và nó liên quan đến bài toán scale cho phần backend logic của bạn hơn là phần server socket. Còn nếu bài toán là giữ 1000 socket connection thì sẽ dễ dàng hơn, nhất là socket connection của bạn chỉ dùng đển bắn realtime notification, nên cũng không nặng nhọc như việc làm roomchat 1000 người (không, hoặc rất ít khi, phải broadcast message vào tất cả các connection, mỗi connection thỉnh thoảng mới nhận được 1 message ...). Nhưng ngẫm lại để có 1000 người cùng đang mở web, thì số lượng request đến đồng thời chắc cũng không phải là nhỏ, chắc bạn cũng phải xét đến vấn đề về scale phần backend của mình đấy

Web 3.0 was first mentioned by co-founder and former CTO of Ethereum, Gavin Wood. It was used to refer Decentralized Applications run on Ethereum Blockchain.

You can read the full original article ĐApps: What Web 3.0 Looks Like here

In short,

Web 3.0 = Ethereum (or other Smart Contract Blockchain) + Swarm/IPFS (peer-to-peer method of storing and sharing hypermedia in a distributed file system) + JS/CSS ...

You will not need a central server (backend server) to run a Web 3 Application (DApp/Decentralized Application), all assets and data are stored in a peer to peer network

Để giải thích được vấn đề ở trên, bạn cần tìm hiểu về khái niệm Scope ở trong Javascript.

Hiểu đơn giản thì Scope là phạm vi truy cập của một biến, nó sẽ quy định cách thức mà một biến được tạo ra, và phạm vi mà nó có thể được truy cập.

Trong các phiên bản Javascript cũ (trước ES6), thì Javascript chỉ có Function Scope, tức biến được tạo ra trong một function, và có thể dùng trong cả function, chứ không có Block Scope.

Và như bạn biết, thì từ khoá để khai báo biến vẫn được dùng trước đây, là var, chính là để khai báo Function Scope đó.

Như ở ví dụ đầu tiên của bạn:

for(var i = 0; i < 5; i++){
 setTimeout(function(){
  console.log(i); //scope là giống nhau nên giá trị của i là giá trị cuối cùng của nó
 });
}

thì chỉ có một biến i, hay nói cách khác, hàm console.log() gọi đến cùng một biến i. Hàm setTimeout sẽ làm cho callback ở trong đó không được chạy ngay, mà bị delay lại. Lúc callback này được gọi, nó sẽ dùng giá trị của i, lúc đó đã là 5. Thế nên bạn sẽ thấy tất cả sẽ in ra kết quả giống nhau.

Từ phiên bản ES6, Javascript giới thiệu một khái niệm mới là Block Scope, tức là bạn có thể tạo ra một biến với phạm vi sử dụng là một block (bằng cách sử dụng { }).

Và để sử dụng Block Scope, bạn cần dùng đến từ khoá let. Đây chính là sự khác biệt giữa var và let. var tạo ra Function Scope, còn let tạo ra Block Scope.

Ở ví dụ thứ 2 của bạn thì

for(let i = 0; i < 5; i++){
 setTimeout(function(){
  console.log(i); 
 });
}

ở đây do dùng let, nên bạn có thể hiểu đơn giản là ở mỗi một vòng for, nó sẽ tạo ra một biến i riêng, và biến i này chỉ có thể sử dụng trong vòng for đó, ra ngoài (hay chạy vòng for khác) là sẽ mất. Tức ở đây sẽ có 5 biến i khác nhau (mỗi biến tồn tại trong một scope khác nhau), và hàm console.log() sẽ gọi đến các biến i khác nhau ấy. Đó là lý do nó sẽ in ra các kết quả khác nhau

Bạn có thể tìm hiểu thêm về vấn đề này ở một số bài viết khác trên Viblo

• https://viblo.asia/p/javascript-under-the-hood-the-mysterious-parts-WApGx3P3M06y
• https://viblo.asia/p/tim-hieu-sau-hon-ve-scope-javascript-Qbq5QrRwKD8
• https://viblo.asia/p/tim-hieu-sau-hon-ve-scope-javascript-phan-2-Eb85oERkZ2G
• https://viblo.asia/p/scope-trong-javascript-RQqKLnW6l7z
• https://viblo.asia/p/scope-va-closures-trong-javascript-yMnKMqDQK7P
• https://viblo.asia/p/tim-hieu-variable-scope-va-hoisting-javascript-924lJMEWZPM

P/S: Vấn đề ở trên thì bên cạnh việc sử dụng let, bạn cũng có thể giải quyết bằng cách sử dụng IIFE (Immediately Invoked Function Expression) như sau

for(var i = 0; i < 5; i++){
  (function(i) { 
    setTimeout(function(){
      console.log(i);
     });
   })(i);
}

Bạn có thể tìm plugin về Email Verification trên trang của Wordpress.

Ví dụ như Email verification on signups, Woocommerce User Email Verification , khá đơn giản, hỗ trợ verify với email ở form sign up.

Hay Email Verification / SMS verification / Mobile Verification, hỗ trợ đủ các thể loại form của nhiều loại plugin khác nhau

Hàm $(element).each() với $.each() về cơ bản là giống nhau bạn ạ, chúng chỉ khác nhau cách viết (cách gọi hàm thôi)

Thực tế thì hàm $(element).each() sẽ gọi đến $.each() đấy

Bạn có thể check source code của nó trên repo Github tại đây

jQuery.fn = jQuery.prototype = {
    // Execute a callback for every element in the matched set.
    each: function( callback ) {
        return jQuery.each( this, callback );
    },
}

Còn hàm .forEach() thì là hàm vốn có của Javascript, không cần jQuery bạn cũng có thể sử dụng được, kết quả thì cũng giống 2 hàm trên thôi

Lỗi 502 thì có thể là do process php-fpm của bạn không chạy, hay do nginx không thể connect đến php-fpm.

Bạn thử làm một vài cách sau xem sao:

• Check xem php-fpm có chạy không bằng lệnh ps aux | grep php-fpm
• Check xem php-fpm có đúng là đang chạy ở port 9000 không, hay là đang chạy bằng unix socket. Bạn có thể dùng netstat để check: netstat -tapen | grep 9000. Nếu không thấy kết quả, thì có thể php-fpm đang lắng nghe bằng unix socket. Bạn check thư mục /var/run/ hoặc /var/run/php/ xem có file php7.0-fpm.sock không. Nếu có thì bạn cần sửa config fastcgi_pass từ 127.0.0.1:9000, sang địa chỉ file socket, ví dụ như /var/run/php/php7.0-fpm.sock
• Nếu vẫn không được, thì bạn có thể vào thư mục /var/log/nginx/, check nội dung file error.log rồi share lên đây được không. Nó sẽ giúp mọi người thấy rõ hơn về vấn đề mà nginx đang gặp phải

Để thực hiện được chức năng như ở trên, thì em cần làm cả ở 2 phía, Server và Client

• Server: Em cần thống kê được user đã viết những tags nào, mỗi tag có bao nhiêu bài ... Cách thực hiện đơn giản đó là thêm trường post_count vào trong bảng tags, mỗi lần có post mới sử dụng tag đó thì tăng post_count lên, và ngược lại, mỗi lần có post bị xoá đi (hoặc gỡ bỏ tag ra) thì giảm post_count xuống.
• Client: Em cần một thư viện javascript hỗ trợ vẽ biểu đồ, có thể kể ra như Chart.js, Highcharts JS, Google Chart ...

Em có thể tham khảo một vài bài hướng dẫn vẽ đồ thị trên Viblo như sau:

• https://viblo.asia/p/tao-bang-bieu-va-do-thi-voi-google-chart-7eEREJm6MgNj
• https://viblo.asia/p/huong-dan-cach-ve-do-thi-bang-html5-va-css3-7prv31l8MKod

Trang Techblog mà em đề cập đều lấy nội dung gốc ở Viblo về, em có thể tham khảo trực tiếp trên Viblo nhé

Cụ thể thì bài viết về Laravel Page View Counter em có thể xem ở đây: https://viblo.asia/p/laravel-page-view-counter-3Q75wg275Wb

Anh thấy bài đó cũng viết khá là chi tiết và rõ ràng rồi mà. Em cố gắng tìm hiểu và nắm vững kiến thức về Events trước, thì sẽ có thể hiểu được những gì tác giả muốn truyền đạt

Nhưng không biết những class, function trong bài viết được khai báo như thế nào ạ?

tác giả có viết namespace rất rõ ràng, em chỉ cần để ý namespace thì sẽ biết được file đó được đặt ở đâu.

ViewPostHandler.php được đặt ở đâu

như nội dung file VỉewPostHandler.php này ngay trên cùng có dòng namespace App\Demo\Events;, như vậy thì file sẽ nằm trong thư mục events.

Hy vọng câu trả lời có thể giúp ích được cho em. Nếu có vấn đề gì em có thể để lại commet ở đây, hoặc trao đổi trực tiếp với tác ở link bài viết ở phía trên nhé

Ngoài ra, em có thể tìm hiểu thêm về Laravel Events ở bài viết này https://viblo.asia/p/laravel-va-nhung-dieu-can-biet-phan-3-wgrKVxxaGVa#-event-1 . Bài viết giải thích khá chi tiết về cách thức hoạt động của Events cũng như cách sử dụng chúng.

Đúng như em nói, em có thể giải quyết bài toán trên bằng Task Scheduling của Laravel. Bản chất của nó là sử dụng cronjob của Linux/Unix để đặt lịch chạy cho một câu lệnh.

Nhìn chung là Laravel support đến tận răng rồi, mình chỉ việc viết logic gửi thông báo thôi

Ở bài toán của em thì em có thể setup schedule là chạy một task (console command) mỗi phút một lần, em chỉ cần một vài dòng config, việc còn lại Laravel sẽ thực hiện cho em.

Trong cái Console Command của em, em viết xử lý lấy trong Database ra, xem có user nào cần gửi thông báo vào thời điểm đó hay không. Nếu có user như thế thì gọi hàm gửi thông báo cho những users đó.

Chú ý là do cronjob chỉ có thể đặt lịch đến mốc thời gian là phút, nên em cũng chỉ có thể xử lý chính xác đến từng phút. Chẳng hạn nếu như trong Database có 2 users với thời gian là 00:00:01 và 00:00:50 thì cũng nên quy về là cùng một phút và đem ra xử lý cùng nhau

Một vài tài liệu em có thể tham khảo

• Các bài viết trên Viblo:
  • https://viblo.asia/p/lap-lich-tasks-tren-linux-su-dung-crontab-6J3Zg28MKmB
  • https://viblo.asia/p/laravel-deep-dive-task-scheduling-YWOZreVvKQ0
  • https://viblo.asia/p/task-scheduling-trong-laravel-157G5oA8RAje
  • https://viblo.asia/p/laravel-task-scheduling-924lJOnb5PM
  • https://viblo.asia/p/cronjob-don-gian-trong-laravel-54-gGJ59XrJlX2
• Scheduling Document: https://laravel.com/docs/master/scheduling
• Console Command Document: https://laravel.com/docs/master/artisan#writing-commands

Câu hỏi của em chung chung quá, không biết phải trả lời ra sao nữa

Em có thể tham khảo các bài viết trên Viblo về multithreading nhé

https://viblo.asia/search?q=multithreading

• Java:
  • https://viblo.asia/p/multithreading-cac-cach-khoi-tao-va-su-dung-java-thread-5y8Rr7n0Mob3
  • https://viblo.asia/p/multithreading-race-conditions-critical-sections-va-thread-safety-OEqGj6LlG9bL
  • https://viblo.asia/p/multithreading-java-memory-model-l0rvmm4QvyqA
  • https://viblo.asia/p/multithreading-java-synchronized-blocks-lA7GKwnYGKZQ
• Multithreading trong Ruby: https://viblo.asia/p/ruby-multithreading-PjxMeV5bG4YL
• Multithreading trong C++: https://viblo.asia/p/lam-quen-voi-multithreading-trong-c-qm6RWQYXGeJE và https://viblo.asia/p/lam-quen-voi-multithreading-p2-AQ3vVka1RbOr
• Multithreading trong PHP: https://viblo.asia/p/php-multithreading-aKYMNBXbM83E
• Process vs Thread: https://viblo.asia/p/processes-vs-threads-naQZR7Xvlvx

Cụ thể thì em muốn tăng lượt view như thế nào, và như thế nào là an toàn

Về logic tăng lượt view thì có vài cái em có thể tham khảo:

• Mỗi lần access vào bài viết là 1 lần tăng: cách này đơn giản nhất, chỉ cần set tăng view ở Controller là được. Tuy nhiên dẫn dễ by pass bằng F5 (như em có đề cập), bằng câu lệnh curl, hay những đoạn script đơn giản
• Mỗi lần access vào bài viết là 1 lần tăng count, đồng thời lưu lại post_id cùng timestamp vào session của user. Nếu user reload lại trình duyệt thì check trong session ra kiểm tra xem có post_id không, và timestamp có gần đây không. Nếu hợp lệ thì mới tăng view. Cách này, như em nói, nếu user xoá cookie để update session (hoặc dùng Private Tab, Incognito Mode trên Chrome, Firefox ...) thì sẽ by pass được, ngoài ra, nó cũng không chống được curl thần thánh
• Mỗi lần access vào bài viết, thì chưa tăng view vội, chỉ add post_id cùng timestamp vào session của user thôi. Sau đó ở phía client (javascript) sẽ gọi lên API tăng view riêng, ở API này sẽ check xem user đã từng vào post đó chưa (có session với post_id trong đó không), nếu có thì mới tăng view. Cách này có thể hạn chế được curl, nhưng vẫn không qua nổi trò dùng incognito mode, xoá session :v Có thể hạn chế thêm bằng việc check timestamp sao cho phải cách thời điểm tăng view > 10 giây thì mới cho tăng chẳng hạn, hoặc thay vì lưu trong session thì lưu trong DB và buộc user phải submit chính xác một cái random string lên thì mới cho tăng view.

Nhìn chung thì cái nào cũng có cái hay, cái dở, và có lý do của nó. Nếu em muốn làm thật chặt thì đi theo hướng cuối cùng, verify request của users thật chặt vào.

P/S: Kiểu gì vẫn có thể by pass được thôi, nếu người dùng đã có chủ ý muốn gian lận, và họ có đủ kiến thức IT

P/S 2: Khi đặt câu hỏi em nên thể hiện rõ nội dung mình muốn hỏi ở tiêu đề, để người khác khi nhìn vào có thể biết được em muốn hỏi về vấn đề gì

Chứ để là Một vấn đề cần sự giúp đỡ của mọi người thì đúng là không ai có thể đoán ra được nội dung cả Những tiêu đề kiểu như "Logic xét tăng lượt view cho bài viết" có vẻ sẽ hay hơn

Bài toán này thực tế nếu em xử lý không khéo thì sẽ còn gặp khá nhiều vấn đề khác như:

Ví dụ bài viết của e có 3 tag(s) thì e hiện thì 3 bài, mỗi bài 1 tag của bài viết hiện đang xem

Nếu 1 trong 3 tags đó chỉ có duy nhất 1 bài (là bài em đang viết) thì sẽ ra sao, hay có những bài thuộc về 2 (hay cả 3) tag đó được select ra thì tính vào cho tag nào?

Ngược lại, nếu 2 tag(s) thì e lấy tag đầu tiên 2 bài, tag cuối 1 bài. Còn nếu 1 tag thì e lấy tag đó 3 bài...

Nếu tag đầu tiên không có đủ 2 bài để em select ra thì sao ...

Nếu như em giới hạn số tag là 4 (như ở phần comment em có đề cập ở trên), thì anh nghĩ có thể thực hiện theo cách chạy vòng for với từng tag, để lấy ra 3 bài viết (em có thể sắp xếp theo thời gian tạo bài viết khi thực hiện phép select này nếu muốn) đối với từng tag đó. Sau đó em chạy thêm vòng for để duyệt qua các kết quả trả về, mỗi lần lấy từ mảng ra 1 phần tử để đưa vào danh sách bài viết related mà em mong muốn, break vòng lặp khi em đã có đủ số bài mong muốn (3 chẳng hạn)

Hoặc em có thể đi theo một hướng giải quyết khác là làm đơn giản yêu cầu đi, để có được giải pháp đơn giản hơn Chỉ cần bỏ cái yêu cầu mỗi tag lấy một bài đi là mọi thứ dễ dàng hơn rất nhiều, chỉ cần select top 3 bài mà có tag_id nằm trong tập các tag_id của bài viết hiện tại là được.

Để bảo mật cho API của server thì bạn có thể sử dụng OAuth 2. Nó là một authorization framework, tức là một tiêu chuẩn chung được định nghĩa cho cả client và server để xác thực quyền của một request.

Phía server của bạn thực hiện việc xác thực request theo chuẩn OAuth 2, thì phía client người ta cũng viết theo chuẩn OAuth 2 là cả 2 bên có thể hoạt động được với nhau, mà bạn không cần phải chia sẻ quá nhiều thông tin liên quan đến server của bạn cho họ. Các công việc liên quan đến generate client credentials thì cũng có chuẩn luôn, dùng sẵn một package OAuth 2 đã được cộng đồng viết thì hầu như bạn chả phải làm gì mấy

• Bạn có thể tìm hiểu thêm về OAuth 2 tại:
  • https://viblo.asia/p/introduction-to-oauth2-3OEqGjDpR9bL
  • https://viblo.asia/p/oauth-2-authentication-oOVlYObzK8W
• Package OAuth 2 cho nodejs:
  • https://github.com/oauthjs/node-oauth2-server
  • https://github.com/lelylan/simple-oauth2

Anh có vài gợi ý cho em như sau:

• Em có một bảng posts với khoá chính là id
• Bảng comments sẽ có khoá ngoại là post_id, trường này để xác định xem comment đó thuộc vào post nào. Như vậy posts vàcomments sẽ có quan hệ 1-n.
• Bảng comments có trường parent_id, khoá này trỏ đến chính id của bảng comments, để xác định xem một comment sẽ có cha là comment nào (tức một comment là trả lời của một comment nào). Như vậy 1 comment có thể có nhiều comment con, và có không quá 1 comment cha.

Khi hiển thị comment trong một post thì em cứ select hết comments ra, rồi xử lý để sắp xết comment tầng tầng lớp lớp thôi, mặc dù hơi vất vả một chút

Đấy là trong trường hợp chỉ có post là có comment. Còn như Viblo thì có comment cho post, cho question, cho series nữa nên mọi thứ sẽ phức tạp hơn một chút Khi đó thay vì có post_id trong bảng comments, ta sẽ có commentable_type để lưu xem comment là cho đối tượng gì: Post, Question hay Series, và sau đó là commentable_id để lưu id của đối tượng được comment. Kiểu implement đó gọi là Polymorphic Relation, nhưng chắc trong trường hợp của em ở trên thì chưa cần đến mức như vậy đâu.

Còn tuỳ thuộc vào tính chất của chức năng của em như thế nào, và em mong muốn dịch vụ thể hiện ra sao khi em xoá category nữa

Như em miêu tả thì quan hệ giữa category và post là quan hệ 1-n, và nếu 1 post luôn luôn phải thuộc về 1 và chỉ 1 category, thì có vẻ sự tồn tại của post đó sẽ không có ý nghĩa, nếu như mà category bị xoá, nên khi xoá category thì có thể xoá hết cả post đi!

Tuy nhiên cách làm này đôi khi khá nguy hiểm khi người quản trị có thể vô tình xoá bài viết ngoài ý muốn. Để giải quyết thì em có thể thêm ràng buộc là chỉ cho phép xoá category khi không có post nào thuộc về category ấy. Điều này sẽ buộc người quản trị phải di chuyển các post trong một category sang category khác, hay xoá post đi (một cách thủ công), trước khi xoá category đấy. Cách này có thể sẽ đem lại sự an toàn hơn cho dữ liệu, tuy nhiên đôi lúc sẽ khiến người quản trị cảm thấy phiền toái

Ngoài ra khi xoá, em có thể cân nhắc lựa chọn soft delete (xoá logic, vẫn còn trong DB, nhưng không được select và hiển thị ra) và hard delete (xoá hoẳn khỏi DB).

Anh nghĩ có thể tổng kết như sau:

• Nếu bắt buộc một 1 post luôn luôn phải thuộc về 1 và chỉ 1 category => khi xoá category cần xoá cả post, hoặc chuyển post sang category khác
• Nếu 1 post có thể không thuộc về category nào, hoặc thuộc về nhiều category (cái này thì lại là quan hệ n-n, chắc không giống với câu hỏi của em nhưng thôi cứ liệt kê ra vậy ) thì có thể chỉ cần xoá category, bởi post vẫn có thể được hiển thị mà không gặp vấn đề gì.

Nhìn chung mỗi cách đều có một ưu và nhược điểm khác nhau, cũng tuỳ từng ngữ cảnh mà sử dụng cách thích hợp. Như anh thì luôn đặt sự toàn vẹn dữ liệu lên hàng đầu, nên anh sẽ ưu tiên chọn cách không cho phép xoá category khi mà nó không rỗng, mà khi xoá thì cũng chỉ soft delete thôi

Theo mình biết thì việc Autoplay trên trình duyệt, đặc biệt là với trình duyệt mobile thì nó phụ thuộc vào Policy của trình duyệt rồi, chắc là khó để can thiệp bạn ạ

Bạn có thể tham khảo thêm ở đây https://developers.google.com/web/updates/2016/07/autoplay https://bitmovin.com/play-not-play-new-autoplay-policies-safari-11-chrome-64/

Nhìn chung là Chrome với Safari họ đều không cho phép autoplay với âm thanh, để đảm bảo chúng không làm ảnh hưởng đến người dùng.

Bạn có thể dùng Docker để giải quyết vấn đề trên. Cách thực hiện có thể tóm tắt đơn giản như sau:

• Chuẩn bị môi trường server có cài đặt Docker
• Chuẩn bị các Docker Image với đầy đủ các môi trường có thể chạy được code C, PHP, Ruby, Java, Python ...
• Khi user viết code trên web và yêu cầu chạy code, bạn lưu code đó vào DB, tạo một file chứa nội dung code đó, và dựng một container với môi trường tương ứng với ngôn ngữ lập trình mà user sử dụng. Bạn có thể tìm và sử dụng Docker Client cho ngôn ngữ server của mình, ví dụ như docker-php, ruby docker-api, docker-py
• Đưa file chứa code của user vào trong container, và tiến hành chạy code bên trong container. Nhận kết trả ra từ trong container, tiến hành lưu lại vào DB và hiển thị lên trang web
• Tắt container, kết thúc quá trình chạy code

Có phải ý bạn là lúc scroll down thì chỉ scroll phần nội dung của bảng di duyển, thì phần header đứng yên đúng không nhỉ? Theo mình nghĩ thì bạn có thể set height cho thẻ tbody của bảng, rồi dùng thuộc tính overflow-y: scroll; với thẻ tbody đó

Để chạy HTTPS thì bạn cần có SSL Certificate, bạn đã tạo nó và config đầy đủ các thiết lập về SSL chưa?

Docker image của bạn dùng web server là gì, apache hay nginx? và bạn đã config web server như thế nào?

Mong bạn có thể gửi thêm thông tin để mọi người giúp đỡ