Các nền tảng thời gian chạy bắt đầu cạnh tranh để có được mục nhập chuỗi công cụ toàn ngăn xếp

Ngay khi một dự án bắt đầu chạm vào SSR, tác vụ nền, lưu trữ đối tượng và triển khai bản xem trước cùng lúc, công cụ xây dựng sẽ sớm bộc lộ ranh giới ban đầu của nó. vite dev chịu trách nhiệm chạy trang, trả lại quyền quản lý khung kiểm tra, triển khai CLI để trực tuyến và thêm một lớp keo vào lớp thích ứng thời gian chạy. Lúc đầu, những điều này có thể chấp nhận được, nhưng khi dự án tách riêng thời gian gỡ lỗi cục bộ và thời gian chạy sản xuất, các vấn đề bắt đầu nảy sinh: nó có thể chạy cục bộ, nhưng bản xem trước không thành công; khi phiên bản bộ điều hợp được nâng cấp, các liên kết hàng đợi và lưu trữ không còn tương thích; các lệnh vẫn giống nhau và tôi đã biết rằng mỗi lớp có thể gặp sự cố một cách độc lập.

Thay đổi rõ ràng nhất trong chuỗi công cụ trong hai năm qua là nền tảng không còn hài lòng với “bước triển khai cuối cùng”. Họ bắt đầu tiến về phía trước, đưa các lệnh phát triển cục bộ, mô phỏng thời gian chạy, phản hồi thử nghiệm và phát hành vào cùng một liên kết. Với việc sáp nhập VoidZero vào Cloudflare gần đây, điều thực sự đáng xem không phải là tin tức mua lại mà là một tín hiệu rõ ràng hơn: các nền tảng thời gian chạy đang bắt đầu cạnh tranh trực tiếp để giành quyền vào chuỗi công cụ full-stack.

Khi công cụ xây dựng đạt đến thời gian chạy, ranh giới nền tảng sẽ di chuyển về phía trước

Theo nghĩa truyền thống, trách nhiệm của một công cụ xây dựng rất rõ ràng: đọc mã nguồn, tạo gói và chuyển nó cho hệ thống tiếp theo để xử lý. Sự phân công lao động này không còn đủ nữa. Miễn là ứng dụng có định tuyến phía máy chủ, cơ sở dữ liệu, hàng đợi, lưu trữ đối tượng và các chức năng biên thì việc hoàn thành xây dựng không có nghĩa là hoàn thành việc phân phối. Vẫn còn cả một phần ngữ nghĩa thời gian chạy cần căn chỉnh.

Nơi dễ gặp khó khăn nhất đối với loại dự án này không phải là liệu trình đóng gói có đủ nhanh hay không mà là liệu những gì đang chạy cục bộ lần này có phải là cùng một thời gian chạy được đặt trực tuyến hay không. Chỉ cần câu trả lời là không, vòng lặp phát triển sẽ ngày càng nặng nề hơn. Để lấp đầy khoảng trống này, nền tảng này chắc chắn sẽ tìm cách kéo máy chủ dev vào thời gian chạy của riêng nó và đưa “viết mã cục bộ” và “chạy trực tuyến” vào cùng một mô hình.

Vì vậy, những thay đổi mà chúng ta thấy bây giờ không còn chỉ là việc nền tảng cung cấp bộ điều hợp cho một khung nhất định mà đến lượt CLI, phần bổ trợ thời gian chạy và môi trường cục bộ của nền tảng được chủ động tạo thành hình dạng chuỗi công cụ mà các nhà phát triển đã quen thuộc. Bằng cách này, lối vào thay đổi. Nền tảng không còn chờ bước deploy xuất hiện nữa. Nó đã có mặt trên thị trường bắt đầu từ dev, build, test và thậm chí cả định dạng nhắc lỗi.

Đặc vụ đã phóng đại mọi xích mích nhỏ trong chuỗi công cụ có thể chịu đựng được.

Khi vấn đề này được đặt vào giai đoạn phát triển thuần túy thủ công thì nhịp độ không còn quá gấp gáp. Mọi người sẽ nhớ những lệnh nào cần được chạy nhiều lần, lỗi nào chỉ là vấn đề về môi trường và bộ điều hợp nào đôi khi bị co giật. Sau khi Đại lý xuất hiện, những sự mơ hồ này về cơ bản sẽ trở thành chi phí.

Tác nhân sẽ liên tục kéo máy chủ nhà phát triển lên, chạy lại kiểm tra, đọc lỗi, thay đổi mã và xác minh lại. Các lệnh không nhất quán, nhật ký không đều và hành vi thời gian chạy không nhất quán. Những trục trặc nhỏ đã được giải quyết trước đó bằng kinh nghiệm sẽ trực tiếp trở thành một vòng lặp vô hạn trong vòng thực thi. Tất nhiên, tốc độ xây dựng, tốc độ kiểm tra và tốc độ tìm lỗi mã nguồn cũng rất quan trọng, nhưng điều có giá trị hơn là liệu toàn bộ liên kết có các ràng buộc thống nhất hay không: cùng một bộ CLI, cùng một bộ mô hình cấu hình, cùng loại đầu ra lỗi và cùng mối quan hệ ánh xạ cục bộ và sản xuất.

Đây là lý do tại sao trạng thái của các công cụ như Vite đang thay đổi. Ban đầu chúng chỉ là thiết bị hữu ích nhất trong lớp xây dựng giao diện người dùng, nhưng giờ đây chúng đã dần trở thành cơ sở mặc định cho Đặc vụ dễ điều khiển ổn định nhất. Nhanh chóng, đơn giản và tương thích rộng rãi. Những lợi thế này trước đây chủ yếu phục vụ trải nghiệm phát triển, nhưng giờ đây chúng phục vụ trực tiếp cho độ tin cậy thực thi. Miễn là nền tảng gắn các khả năng thời gian chạy của nó với vòng lặp mặc định này, nó sẽ không chỉ đạt được mục tiêu triển khai mà còn cả tập hợp các thói quen xác minh và tạo ứng dụng.

Điều thực sự có giá trị không phải là sự liên kết của khung mà là ai sẽ loại bỏ quy trình làm việc mặc định.

Chỉ cần nhìn vào các tiêu đề tin tức, có thể dễ dàng hiểu những hành động đó là đầu tư sinh thái hoặc là một nền tảng muốn chuyển hướng lưu lượng truy cập sang các dịch vụ lưu trữ của riêng mình. Những thay đổi nhạy cảm hơn trong kỹ thuật thực sự ở một cấp độ khác: một khi giàn giáo dự án mặc định, thời gian chạy cục bộ mặc định, vòng kiểm tra mặc định và các lệnh phát hành mặc định đều nằm trên cùng một chuỗi công cụ, đơn vị cạnh tranh nền tảng sẽ thay đổi từ “máy của ai rẻ hơn” thành “ai là người đầu tiên xác định cách tạo ra ứng dụng”.

Sự khác biệt này không hề nhỏ. Giá có thể được so sánh theo chiều ngang. Một khi quy trình làm việc đã được ghi vào kho, tập lệnh, CI và thói quen của nhóm thì hiếm khi dễ dàng thay đổi. Nếu nền tảng chỉ có thể đảm nhận bước triển khai cuối cùng thì ngưỡng di chuyển không cao; nếu nền tảng đã chiếm toàn bộ đường dẫn từ dev đến deploy thì việc di chuyển sẽ ảnh hưởng đến môi trường cục bộ, thói quen ra lệnh, liên kết xem trước, phương pháp gỡ lỗi và tập lệnh thực thi Tác nhân. Thông thường lớp này thực sự tạo thành độ dính.

Làn sóng chuyển động gần đây này còn dẫn đến một điều khác: chuỗi công cụ full-stack đang định nghĩa lại tính “trung lập”. Trước đây, tính trung lập có nghĩa là nó độc lập với khung và chạy trên các gói khác nhau. Ngày nay, các yêu cầu về tính trung lập ngày càng khắt khe hơn. Các khả năng của nền tảng phải được đưa vào, nhưng bản thân chuỗi công cụ không thể được biến thành giao thức riêng của nền tảng. Bất kỳ ai có thể giữ lớp trừu tượng không xác định của nhà cung cấp trong khi tự triển khai trải nghiệm mặc định sẽ có nhiều khả năng nhận được vòng thưởng đầu vào tiếp theo hơn.

Con đường này chỉ phù hợp với những đội bị cản trở bởi sự phức tạp của việc phân phối

Không phải tất cả các dự án đều cần quan tâm đến kiểu cạnh tranh đầu vào này. Đối với các trang web tĩnh, phần phụ trợ nhỏ hoặc các dịch vụ có một hình thức triển khai duy nhất, việc tiếp tục tách riêng việc xây dựng, thử nghiệm và triển khai có thể không gây hại gì. Khi quy mô dự án lớn, các loại vấn đề này sẽ phát sinh nhanh chóng:

• Sự khác biệt giữa phát triển cục bộ và thời gian chạy trực tuyến đã bắt đầu tiêu tốn nhiều thời gian khắc phục sự cố
• SSR, hàng đợi tác vụ, lưu trữ đối tượng và liên kết cơ sở dữ liệu đều xuất hiện trong cùng một kho
• Các nhóm đã dựa vào môi trường xem trước, lệnh giàn giáo và mẫu CI để phân phối hợp tác
• Các đại lý tham gia mã hóa, sửa lỗi và kiểm tra, tính ổn định của chuỗi công cụ bắt đầu ảnh hưởng trực tiếp đến đầu ra.

Ở giai đoạn này, sẽ hơi muộn nếu coi công cụ xây dựng như một thành phần lớp giao diện người dùng thuần túy. Nó đã trở thành một phần của điểm vào ứng dụng, được kết nối với thời gian chạy, phía triển khai và phía thực thi. Việc sáp nhập VoidZero và Cloudflare chỉ làm cho vấn đề này trở nên rõ ràng hơn: vòng cạnh tranh nền tảng tiếp theo sẽ ngày càng giống như cạnh tranh về quy trình làm việc mặc định. Bất cứ ai đóng chuỗi này một cách suôn sẻ nhất sẽ có cơ hội tốt hơn trong việc quyết định ứng dụng sẽ phát triển trên nền tảng nào trước tiên.