1) Trong 4-5 năm qua, tôi đã thử nghiệm với rất nhiều kiến trúc ứng dụng Solana, và tôi nhận ra đã đến lúc tôi viết ra những phát hiện này. Bắt đầu với những điều đơn giản nhất và dần dần thêm vào những yếu tố phức tạp hơn. Vậy thì bắt đầu nhé: Kiến trúc ứng dụng Solana, một chuỗi thảo luận.

2) Hãy bắt đầu với chế độ dễ. Đây có lẽ là hình dạng của ứng dụng Solana đầu tiên của bạn. Một giao diện frontend react đơn giản, thiết lập kết nối với một RPC. Không cần một máy chủ api. RPC chính là máy chủ của bạn. Trong những ngày đầu, những điều này thường bị rải rác với getAccountInfos, logic xây dựng tx tùy chỉnh, v.v. Sau đó, khi hiệu suất bị ảnh hưởng, bạn thêm các lớp caching và batching. Nhập getMultipleAccounts. Có thể bạn cũng thêm các đăng ký websocket + polling để cập nhật trực tiếp UI. Kiến trúc này tạo ra việc prototyping cực kỳ nhanh chóng. Hầu như không có devops. Chi phí máy chủ không đáng kể (chỉ cần triển khai trên vercel, v.v). Tuy nhiên, nó có một vài khuyết điểm lớn.

3) Vấn đề đầu tiên bạn gặp phải là các truy vấn phức tạp. Trong kiến trúc này, tất cả những gì bạn có là Solana RPC cơ bản. Điều đó có nghĩa là bạn cần đối xử với Solana như cách mà một RPC phơi bày nó -- như một cơ sở dữ liệu NoSQL với một vấn đề về thái độ. Các truy vấn điểm không phải là vấn đề. Bạn thậm chí có thể sáng tạo rất nhiều với PDAs để duyệt dữ liệu chương trình của bạn như thể đó là một cơ sở dữ liệu đồ thị. Nhưng ngay khi bạn cần thực hiện gPA đầu tiên, bạn sẽ gặp phải đau đớn tối đa. Giao diện không hề thân thiện. Nếu bạn có bất kỳ loại dữ liệu có độ dài động nào, nó không thể được sử dụng chút nào. Tùy thuộc vào nhà cung cấp RPC của bạn, nó có thể chậm đến mức không thể tin được. Ngay cả khi không có gPAs, cách tiếp cận này thường chậm hơn rất nhiều so với ứng dụng web2 điển hình với việc render phía máy chủ và một cơ sở dữ liệu bình thường.

4) Vấn đề thứ hai bạn gặp phải là khả năng di động của logic xây dựng giao dịch. Với thiết lập này, tất cả logic để xây dựng giao dịch đều nằm trong (a) mã frontend của bạn hoặc (b) trong các thư viện mà mã của bạn nhập vào. Trong trường hợp (a), bất kỳ ai muốn xây dựng giao dịch bên ngoài frontend của bạn sẽ gặp rất nhiều khó khăn (điều này bao gồm cả bạn, khi bạn không thể tránh khỏi việc cần thêm ứng dụng). Trong trường hợp (b), bất kỳ thay đổi nào đối với logic xây dựng giao dịch đều yêu cầu phát hành thư viện, mọi người cập nhật gói của họ, và sau đó là cập nhật giao diện người dùng. Dựa nhiều vào công cụ Anchor như giải quyết tài khoản có thể giảm thiểu lượng logic cần được di chuyển -- nhưng vấn đề vẫn còn đó. Điều này lấy đi sự linh hoạt của bạn, và khiến việc thay đổi các điểm cuối hợp đồng thông minh trở nên khó khăn trong khi đảm bảo tất cả các phiên bản logic xây dựng TX của bạn vẫn tiếp tục hoạt động.

5) Vấn đề thứ ba bạn gặp phải là thực tế rằng các giao diện người dùng thường không tốt trong việc gửi giao dịch, đặc biệt là với logic thử lại. Một người dùng có thể rời khỏi trang, TX ngừng thử lại. Các giao dịch lớn thường gặp khó khăn trong việc hoàn tất. Thật khó để gỡ lỗi từ xa lý do tại sao mọi thứ không hoàn tất.

6) Vấn đề cuối cùng ở đây là bạn không phải là người duy nhất có kiến trúc này. Một RPC là rất giá trị, và bạn về cơ bản phải công khai URL RPC của mình trong frontend. Bây giờ, bạn sẽ rơi vào một trò chơi mèo vờn chuột để đảm bảo không ai đánh cắp RPC của bạn và làm tăng chi phí của bạn.

7) Vậy tiếp theo là gì? Thông thường, ngay cả khi bạn không giải quyết tính di động của giao dịch, bạn vẫn cần phải giải quyết các truy vấn danh sách. gPA thật tệ, và chúng ta đều biết điều đó. Vì vậy, bạn có thể xây dựng một kiến trúc lai. Trong kiến trúc này, bạn giữ khả năng tạo mẫu nhanh chóng, nhưng đẩy những truy vấn khó khăn và xấu xí vào một API. Một ví dụ cụ thể tốt về điều này là quản trị -- bạn có các đề xuất được tạo ra có một tập hợp các thẻ trên đó ("Kinh tế", "Kỹ thuật", v.v). gPA không thể lọc theo thẻ.

8) Kiến trúc này vẫn chưa giải quyết được tính di động của các giao dịch, hay việc mọi người rút RPC của bạn. Nhưng khi mở rộng quy mô, ít nhất bạn có thể giải quyết vấn đề gPAs chậm hoặc không thể thực hiện. Nó cũng tạo ra một vấn đề mới - các chỉ mục. Sẽ có thêm thông tin về điều này sau.

9) Cuối cùng, bạn có những gì tôi sẽ gọi là "kiến trúc doanh nghiệp" của Solana. Bạn không còn coi Solana như một cơ sở dữ liệu NoSQL nữa. Thay vào đó, bạn đang coi nó như một bus sự kiện. Giao diện người dùng không biết gì về mô hình dữ liệu của Solana. Máy chủ xây dựng các giao dịch và chuyển chúng đến giao diện người dùng để ký, sau đó gửi chúng đến chính Solana. Nó coi đây là một sự kiện và chờ đợi nó lan truyền trở lại các chỉ mục sẽ thay đổi dữ liệu cơ bản. Cấu hình này có tính di động giao dịch tuyệt vời - bất kỳ ai cũng có thể truy cập API của bạn với các tham số sạch và nhận lại giao dịch/hướng dẫn. Nó tạo ra một giao diện người dùng cực kỳ nhanh nhạy - về phần giao diện người dùng, đây về cơ bản là web2. Bạn có thể tận dụng tối đa SSR. RPC được trừu tượng hóa - không ai có thể đánh cắp tín dụng của bạn. Nhưng cấu hình này cũng có những vấn đề của nó.

10) Vấn đề đầu tiên bạn sẽ gặp phải là nỗi đau của indexer. Mặc dù điều này đã được giảm bớt trong vài năm qua (nhờ vào các đội ngũ Triton, Helius và StreamingFast), nhưng tôi vẫn thường xuyên phải đánh bại indexer của chúng tôi bằng một cái cờ lê. Bạn sẽ bỏ lỡ tin nhắn. Khi bạn bỏ lỡ một tin nhắn, giao diện người dùng của bạn sẽ rơi vào trạng thái kỳ lạ (ví dụ: tôi đã gửi cho bạn một NFT, trên chuỗi bạn đã nhận được nó, nhưng cơ sở dữ liệu của tôi lại nói rằng tôi vẫn sở hữu nó). Những loại vấn đề này thật khó chịu để gỡ lỗi. Có phải lỗi của bạn không? Có phải lỗi của nhà cung cấp dữ liệu của bạn không? Ai biết được! Thế là buổi chiều của bạn đã trôi qua.

11) Vấn đề tiếp theo bạn sẽ gặp phải là thời gian. Khi bạn trực tiếp sử dụng RPC cho mọi thứ, họ cho phép bạn truyền các cam kết và xử lý dữ liệu mới nhất. Với một indexer, tất cả đều là thủ công. Điều này có nghĩa là khi bạn đang xây dựng các giao dịch, bạn có thể đang xây dựng chúng dựa trên dữ liệu đã lỗi thời. Bạn trả về một giao dịch có nguy cơ thất bại. Bạn có thể giải quyết vấn đề dữ liệu lỗi thời bằng cách sử dụng các nhà cung cấp dữ liệu cung cấp cho bạn dữ liệu cực kỳ nhanh (ví dụ Helius laser stream). Nhưng sau đó bạn cần phải xử lý thủ công các reorg. Tức là, dữ liệu bạn đã lập chỉ mục cần phải được gỡ bỏ chỉ mục nếu giao dịch đó thực sự không được thực hiện. Đây là một cơn ác mộng.

12) Bạn có thể "hack" xung quanh các vấn đề về thời gian bằng cách chỉ xây dựng giao dịch sử dụng dữ liệu từ RPC, và chỉ sử dụng dữ liệu đã được lập chỉ mục của bạn để cung cấp cho giao diện người dùng. Nhưng sau đó, người dùng vẫn sẽ gặp vấn đề với những bất nhất tiềm ẩn giữa giao diện người dùng và chuỗi. Nghĩa là giao diện phía trước nói rằng tôi sở hữu NFT này và có thể chuyển nhượng nó, sau đó backend lại la mắng tôi và nói rằng tôi không thể.

13) Vấn đề cuối cùng bạn gặp phải với thiết lập này là chi phí, và nếu chúng ta nói một cách bi kịch "cái chết của sự phi tập trung." Giấc mơ của web3 là không phải triển khai hàng tấn máy chủ tập trung. Bây giờ bạn đã triển khai đủ hạ tầng để có được một công việc kiến trúc sư chính tại một công ty web2. Nó tốn tiền. Nó tốn thời gian. Và tất cả đều rất tập trung. Giao thức của bạn phi tập trung đến mức nào nếu cách tốt nhất để tương tác với nó là thông qua một API web2? Và có khoảng 72 lập trình viên trên solana biết cách tương tác với nó mà không cần API đó.

14) Cuối cùng, tôi sẽ không chết vì bất kỳ lý do nào liên quan đến phi tập trung. Điều tốt nhất cho người dùng thường là lựa chọn tốt nhất. Cấu trúc "doanh nghiệp" dẫn đến các ứng dụng web hiện đại, nhanh chóng và một sự phân tách rõ ràng về các vấn đề. Mặt trái là, nó làm tăng chi phí devops và khiến bạn kém linh hoạt hơn. Tôi khuyên hầu hết các startup nên bắt đầu với phương pháp trực tiếp đến rpc trừ khi bạn đang xây dựng một cái gì đó cần phải nhanh hoặc có ngữ nghĩa truy vấn phức tạp. Thời gian ra thị trường là chìa khóa. Bạn luôn có thể thuê một kỹ sư cấp trung sau và ném họ vào ngục tối lập chỉ mục.

15) Tài chính. Nếu ai trong số các bạn đã tìm thấy một thiết lập tốt hơn, hãy cho tôi biết. Đây là tất cả những thứ tôi đã thử. Gần đây tôi khá thích việc thử nghiệm với thiết lập doanh nghiệp.