Việc chọn một dịch vụ để lưu trữ dữ liệu có thể gây nhầm lẫn và quá sức cho một Front-End Developer.
Tất cả những từ viết tắt này là gì? Cách đặt tên dịch vụ của Amazon có mục đích không?.
Những câu hỏi này và nhiều câu hỏi khác đang chờ đợi cuộc hành trình của bạn vào thế giới Back-End.
Là một Front-End Developer chuyển sang full-stack, tôi đã dành nhiều thời gian hơn những gì tôi muốn thừa nhận để cố gắng tìm ra phần backend. Vì phần backend khó visualize hơn, nên tôi đã phải vật lộn để hiểu cách các phần này khớp với nhau. May mắn thay, tôi đã sớm biết tôi không đơn độc. Có một nhóm hỗ trợ khi các kỹ sư front-end bối rối gặp nhau được gọi là Twitter.
Hãy coi bài viết này là một tác phẩm "chọn cuộc phiêu lưu của riêng bạn". Tôi sẽ đặt câu hỏi về yêu cầu của bạn và sau đó trình bày một vài lựa chọn. Trước khi chúng ta có thể bắt đầu cuộc hành trình của mình, trước tiên tôi phải giải thích những điều cơ bản. Bạn có thể cũng có thể chuyển trực tiếp đến [danh sách các dịch vụ] (/ blog / backend # list-of-services).
Mục lục
- Kiến thức cơ bản về backend
- Bạn có cần cơ sở dữ liệu?
- Giải pháp Low Code
- Điều khoản cần hiểu
- Levels of Abstraction
- Danh sách dịch vụ
- Bạn có nên sử dụng CMS không?
- Bắt đầu từ đầu
- Kết luận/Tài nguyên
Backend Basics
Vậy thì tóm lại ** Back-End ** là gì mà nghe ghê gớm vậy? Bạn có thể hiểu nó như sau:
Là một kỹ sư front-end, chắc hẳn bạn đã từng làm việc với các API. Chúng cho phép bạn tìm nạp dữ liệu từ một số cơ sở dữ liệu, ở đâu đó. Trên một dòng thời gian đủ dài, cuối cùng bạn sẽ cần phải xây dựng API của riêng mình hoặc làm việc với một cơ sở mã hiện có có một back-end. Điều này đưa chúng tôi đến câu hỏi đầu tiên của chúng tôi.
Bạn có cần cơ sở dữ liệu không?
Bạn cần một nơi để lưu trữ dữ liệu, phải không? Dưới đây là một số câu hỏi cần xem xét:
- Dữ liệu có thể đi chung với code không?
- Dữ liệu có thể được theo dõi với source control không?
- Những người không rành về kỹ thuật có cần sửa đổi dữ liệu không?
- Bạn có cần các cấp độ truy cập khác nhau không?
Nếu bạn có thể lưu trữ dữ liệu bằng mã của mình trong source control, bạn có thể ổn khi sử dụng Markdown với git - Giống như blog này sử dụng. Cũng cần nhắc lại rằng bạn có thể sử dụng tệp JSON làm cơ sở dữ liệu giả nếu bạn thuộc loại này.
Tuy nhiên, bạn có thể đang đọc bài viết này vì ** bạn cần một database**. Trước khi chúng ta bắt đầu tìm hiểu về cách bạn có thể tạo chương trình backend của riêng bạn, bạn cũng có thể xem xét một giải pháp mã thấp.
Giải pháp Low Code
Vì bạn là Front-End Developer, bạn có thể sử dụng Giải pháp Low Code. Những công cụ Low Code này được cho là cách nhanh nhất để truy cập vào một số dữ liệu từ xa.
Các ví dụ phổ biến bao gồm Google Sheets hoặc Airtable như một cơ sở dữ liệu. Có các dịch vụ khác cung cấp phần tóm tắt API trên nhiều nguồn dữ liệu khác nhau.
Điều khoản cần hiểu
Được rồi, vì vậy bạn cần một cơ sở dữ liệu và nó sẽ yêu cầu code. Trước tiên, tôi cần giải thích một số thuật ngữ mà bạn có thể sẽ gặp phải.
SQL/NoSQL
Cơ sở dữ liệu SQL chứa dữ liệu quan hệ. Hãy xem xét một trang web truyền thông xã hội có bảng dành cho users và posts.
Mỗi người dùng đại diện cho một hàng trong bảng users.
Mỗi người dùng có thể có nhiều posts khác nhau. Có sự liên kết giữa một bài đăng và người dùng.
Các liên kết này giúp bạn dễ dàng tra cứu các phần dữ liệu khác nhau thông qua các truy vấn.
Cơ sở dữ liệu NoSQL (nói chung) là hướng tài liệu. Không giống như cơ sở dữ liệu SQL, không có bảng hoặc hàng. Thay vào đó, bạn lưu trữ dữ liệu trong các tài liệu, được sắp xếp thành các bộ sưu tập. Ví dụ: trong Firestore mỗi tài liệu chứa một tập hợp các cặp khóa-giá trị. Đây là một lựa chọn tuyệt vời cho các bộ sưu tập lớn các tài liệu nhỏ.
GraphQL/REST
API cho phép các chương trình nói chuyện với nhau. REST và GraphQL chỉ đơn giản là hai cách khác nhau để tìm nạp dữ liệu. Ví dụ, đây là một
Yêu cầu GET để lấy số lượt xem cho một bài đăng trên blog.
$ curl https://callmetony.com/api/page-views?id=databases
{"total": 1234}GraphQL là một mã nguồn mở đặc biệt cho cách truy vấn các API của bạn. Chuyển đổi ví dụ trước đó từ REST sang truy vấn GraphQL có thể trông như thế này.
{
post (id: "databases") {
views
}
}Nếu bạn muốn tìm hiểu thêm, đây là một tài nguyên tuyệt vời.
Authentication/Authorization
Authentication xác minh người dùng là ai, trong khi authorization xác minh những gì họ có quyền truy cập. Bạn sẽ thường thấy điều này được viết tắt là AuthN (Xác thực) và AuthZ (Ủy quyền).
Nếu bạn đang xây dựng bất kỳ ứng dụng nào có người dùng hoặc yêu cầu hạn chế quyền truy cập vào một số khu vực nhất định, bạn sẽ cần xem xét cả hai điều này.
Hosted/Self-Hosted
Cơ sở dữ liệu của bạn có thể được lưu trữ (Hosted, do người khác quản lý) hoặc tự lưu trữ (Self-Hosted). Khi các dịch vụ Backend là mã nguồn mở, điều đó thường có nghĩa là có một tùy chọn để tự lưu trữ.
Nếu bạn không muốn xử lý cơ sở hạ tầng, hãy sử dụng dịch vụ được lưu trữ.
Serverless
Serverless cho phép bạn viết và triển khai mã mà không phải lo lắng về cơ sở hạ tầng bên dưới. Bạn chỉ thanh toán khi mã của bạn chạy. Với một máy chủ truyền thống, nó luôn chạy. Nói chung, serverless nên bảo trì ít hơn. Tuy nhiên, có sự đánh đổi.
Điều đáng nói là cách bạn triển khai front-end có thể ảnh hưởng đến dịch vụ back-end nào mà bạn chọn. Ví dụ: nếu bạn sử dụng Next.js và kết xuất phía máy chủ, mỗi trang sẽ tạo ra một chức năng không có máy chủ. Ở quy mô đủ lớn, bạn sẽ gặp phải các vấn đề khi có quá nhiều kết nối mở đến cơ sở dữ liệu của bạn. Một giải pháp chung vì đây là kết nối tổng hợp. Để biết thêm thông tin, hãy xem tài liệu triển khai của Prisma.
Data Modeling
Khi tìm hiểu về cơ sở dữ liệu, bạn có thể nghe thấy các thuật ngữ như one-to-many và many-to-many. Đây là những cách mô hình hóa các mối quan hệ cơ sở dữ liệu của bạn. Chuẩn hóa cơ sở dữ liệu là cách bạn tổ chức cơ sở dữ liệu thành các bảng và cột.
Levels of Abstraction
Mỗi tình huống là duy nhất. Có _ nhiều_ công cụ tồn tại để giải quyết cùng một vấn đề. Bằng cách hiểu những gì bạn đang tìm kiếm, nó sẽ giúp bạn chọn giải pháp phù hợp. Trước tiên, hãy hiểu _ những gì_ bạn đang cố gắng xây dựng.
- Bạn đang xây dựng Backend này cho chính mình?
- Người khác có cần sử dụng/hỗ trợ nó không?
- Bạn đang cố gắng xây dựng Minimum Viable Product (MVP)?
Cá nhân tôi thích thử nghiệm các công nghệ mới khi tạo các dự án cá nhân. Nếu tôi là chọn một công cụ cho công việc hàng ngày của tôi, tôi có thể sẽ mặc định là một công cụ được chấp nhận tốt trong ngành và có hỗ trợ mạnh mẽ. Có nhiều quyền kiểm soát hơn khi chọn Backend khi bạn là người sáng lập một mình xây dựng toàn bộ công nghệ cao cho mình. Khi bạn giới thiệu các kỹ sư khác vào hỗn hợp, mọi thứ trở nên phức tạp hơn.
Nếu bạn cần một cái gì đó nhanh chóng, bạn sẽ muốn một cái gì đó trừu tượng ở cấp độ cao hơn. Các dịch vụ này thường cung cấp một ứng dụng khách hoặc API ra khỏi hộp giúp giảm số lượng mã soạn sẵn bạn cần viết. Điều này thường được gọi là tự động hóa phần CRUD (Create, read, update and delete) trong phần Backend của bạn.
Giả sử bạn muốn thứ gì đó cao cấp hơn, lý tưởng nhất là với một trang web hoặc giao diện để quản lý dữ liệu của bạn. Nếu bạn muốn kiểm soát hoàn toàn, bạn có thể cân nhắc [xây dựng của riêng bạn] (/ blog / backend # build-your-own-backend).
Danh sách Dịch vụ
Tôi đã lấy nguồn từ cộng đồng một danh sách các dịch vụ mà bạn có thể cân nhắc sử dụng. Dưới đây, tôi sẽ cung cấp thêm thông tin chi tiết về một số dịch vụ mà tôi biết rõ. Thực tế là mỗi dịch vụ được liệt kê ở đây đều có sự cân bằng của riêng nó. Hy vọng rằng điều này cung cấp cho bạn một cái nhìn tổng quan cấp cao để nghiên cứu thêm. Cũng cần nhắc lại rằng dịch vụ mà bạn đã biết rõ có thể là sự lựa chọn tốt nhất của bạn. Đây là một số câu hỏi cần xem xét.
- Phần Backend của bạn có cần được xây dựng trên công nghệ mã nguồn mở không?
- Bạn cảm thấy thoải mái với mức độ khóa nhà cung cấp nào?
- Có những cân nhắc về bảo mật mà công ty / khách hàng của bạn có không?
- Mức độ bạn muốn xây dựng bản thân so với dựa vào dịch vụ là bao nhiêu?
- Bạn có cần đăng nhập mạng xã hội không? (Đăng nhập bằng Google, Facebook, v.v.)
- Bạn có cơ sở dữ liệu hiện có mà bạn đang cố gắng cải thiện quyền truy cập vào không?
Backend (Dịch vụ)
Đây là các dịch vụ (thường) được quản lý tự động tạo mã dựa trên database schema của bạn. Bạn có thể xem những giải pháp này được gọi là giải pháp "trong hộp". Ví dụ: Hasura cung cấp API GraphQL trong một hộp như một phần của nền tảng.
- ✅ & nbsp; Có, hoặc được đưa trực tiếp vào nền tảng
- ⛔️ & nbsp; Không được hỗ trợ hoặc có sẵn
- 🚧 & nbsp; Yêu cầu một số công việc
| Tên | Loại | Mã nguồn mở | Tùy chọn tự lưu trữ | Đã bao gồm AuthN | GraphQL |
|---|---|---|---|---|---|
| Firebase | NoSQL | ⛔️ | ⛔️ | ✅ | ⛔️ |
| MongoDB | NoSQL | ✅ | ✅ | ✅ | ⛔️ |
| Fauna | NoSQL | ⛔️ | ⛔️ | ✅ | ✅ |
| Userbase | NoSQL | ✅ | ✅ | ✅ | ⛔️ |
| Hasura | Postgres | ✅ | ✅ | 🚧 | ✅ |
| Nhost | Postgres | ✅ | ✅ | ✅ | ✅ |
| Siêu dữ liệu | Postgres | ✅ | ✅ | ✅ | ⛔️ |
| Khuếch đại AWS | Cả hai | ✅ | ✅ | ✅ | ✅ |
Firebase
Firebase là một nền tảng được thiết lập tốt và đã được chứng minh. Nó có (được cho là) trải nghiệm nhà phát triển tốt nhất so với bất kỳ giải pháp nào khác được liệt kê.
Tài nguyên
- Bạn có thể giảm nhẹ một số cơn đau không liên quan đến chỉ mục tổng hợp.
- Dữ liệu quan hệ mô hình trong Firestore NoSQL
- Chuyển sang Serverless với Next.js và Firebase
Hasura
Hasura cho phép bạn tạo một API GraphQL tức thì dựa trên Postgres. Với Hasura Cloud, thật dễ dàng để đi từ một ý tưởng đến một API trực tiếp. Tôi thích rằng bạn có thể tạo các mô hình cơ sở dữ liệu của mình trực tiếp thông qua bảng điều khiển của chúng.
Nếu bạn chưa xem Hasura kể từ khi họ ra mắt dịch vụ được quản lý của mình, hãy nhìn lại nó. Một trong những các vấn đề tôi gặp phải trước khi Hasura Cloud là thử dùng [Heroku] (https://heroku.com/ ) bậc miễn phí. Hasura Cloud ngăn chặn điều này trong khi vẫn còn trên bậc miễn phí.
Mặc dù Hasura thường khuyến nghị sử dụng Auth0 để ủy quyền, nhưng bạn có thể tự triển khai. Nếu bạn muốn xác thực đi kèm với Hasura, hãy xem xét Nhost.
Xây dựng chương trình backend của riêng bạn
Đây là các thư viện và công cụ để xây dựng API và logic back-end của riêng bạn. Nói chung, tôi sẽ không giới thiệu những cho người mới bắt đầu tuyệt đối. Cá nhân tôi học tốt nhất bằng cách doing. Quá trình tham gia phát triển back-end của tôi đã thành công xây dựng các ứng dụng thực tế và thử các công nghệ khác nhau. Bạn muốn có một số chiến thắng nhanh chóng khi bắt đầu để bạn có thể cảm thấy như bạn đang tiến bộ.
Khi bạn mất một mức độ trừu tượng, có những phần khác bạn cần phải xem xét.
- Cơ sở người dùng của tôi được phân phối như thế nào?
- Cơ sở dữ liệu/chương trình backend của tôi cần phải đáng tin cậy như thế nào?
- Giải pháp cung cấp loại công cụ nào (ví dụ:di chuyển cơ sở dữ liệu)
Điều đáng nói là bạn có thể sử dụng AWS RDS để tự lưu trữ bất kỳ cơ sở dữ liệu dựa trên SQL nào. Đó là công nghệ đã được chứng minh thậm chí có tín dụng có sẵn dành cho người sáng lập / khởi nghiệp.
| Tên | Loại | Mã nguồn mở | Tự lưu trữ? | Đã bao gồm AuthN | GraphQL | | -------------------------------------------------- ---------- | --------- | ----------- | ------------- | -------------- | ------- | | AWS DynamoDB | NoSQL | ✅ | ✅ | ⛔️ | ⛔️ | | Prisma | Dựa trên SQL | ✅ | ✅ | ⛔️ | ⛔️ | | Prisma + Nexus | Dựa trên SQL | ✅ | ✅ | 🚧 | ✅ |
Honorable Mentions: Laravel, Rails. Tôi muốn tập trung vào JavaScript này.
Prisma
Prisma cung cấp trình tạo truy vấn được tạo tự động và an toàn về kiểu dựa trên lược đồ cơ sở dữ liệu của bạn. Nó hiện hỗ trợ cơ sở dữ liệu PostgreSQL, MySQL và SQLite.
Có các khung công tác như Redwood và Blitz được xây dựng dựa trên Prisma. Nếu bạn muốn xây dựng API GraphQL với Prisma, bạn có thể ghép nối nó với Nexus. Nexus có plug-in để xác thực / ủy quyền.
Các dịch vụ khác
Tôi chưa thử với các dịch vụ khác, nhưng đây là một số thông tin chung mà bạn có thể muốn biết:
- MongoDB có thể hỗ trợ GraphQL với Stitch
- Supabase vẫn đang trong giai đoạn alpha tại thời điểm viết bài này.
- Nếu quan tâm đến Fauna, bạn có thể muốn tìm hiểu ngôn ngữ truy vấn của họ FQL.
Bạn có nên sử dụng CMS không?
Hệ thống quản lý nội dung (CMS) cho phép bạn quản lý việc tạo và sửa đổi dữ liệu của mình, dữ liệu này thường bao gồm cơ sở dữ liệu. Ví dụ: WordPress có thể sử dụng cơ sở dữ liệu MySQL để lưu trữ nội dung. Bạn nên sử dụng CMS hay chỉ sử dụng cơ sở dữ liệu trực tiếp? Thêm vài câu hỏi
- Bạn đang muốn lưu trữ hình ảnh hoặc tài liệu?
- Có bất kỳ người dùng không chuyên về kỹ thuật nào cần quản lý dữ liệu không?
- Bạn có cần bản địa hóa dữ liệu không?
- Bạn có cần bản nháp/xem trước nội dung (như bài đăng trên blog) không?
Nếu bạn trả lời có cho bất kỳ câu hỏi nào trong số đó, bạn có thể muốn khám phá CMS.
Bắt đầu từ số 0
Một số nhà phát triển full-stack (thường có kinh nghiệm hơn) muốn toàn quyền kiểm soát cơ sở hạ tầng của họ và thích làm việc trực tiếp với cơ sở dữ liệu. Điều này thường đòi hỏi sự hiểu biết cơ bản hơn về back-end. Có toàn bộ sách về chủ đề này, bao gồm danh sách các từ thông dụng sau đây.
- Object-relational mappers (ORMs)
- Manually sharing/replicating
- Scaling instances
- Provisioning servers
- Transactions / ACID
- Containers
Đừng cảm thấy choáng ngợp. Là nhà phát triển front-end, chúng tôi biết rằng chúng tôi không cần biết everything. Cả front-end và back-end đều là những thứ phức tạp, dày đặc. Bắt đầu từ quy mô nhỏ, chăm chú học hỏi và bạn sẽ sớm tạo ra các APIs của riêng mình một cách dễ dàng.
Kết luận/Tài nguyên
Bạn có thay đổi bất cứ điều gì không? Bạn có tài nguyên nào để học back-end không? Nếu có, hãy để lại bình luận bên dưới và tôi sẽ cập nhật danh sách này.