Firebase vs Ruby: Lựa chọn cái nào để phát triển backend?
Bài đăng này đã không được cập nhật trong 3 năm
Lựa chọn cái gì để làm backend cho ứng dụng iOS hay android của bạn đôi lúc có thể trở nên rất khó khăn. Trong khuôn khổ bài viết nhận thấy Firebase và Ruby cũng có rất nhiều các lợi thế khác nhau nên chúng ta sẽ mang 2 thứ này ra cân đo đong đếm xem nên chọn cái nào để phát triển backend cho ứng dụng di động. Đâu là lý do để ta không dùng Firebase hay Ruby? Và có thể dùng firebase kết hợp với Ruby on Rail hay không? Hãy cùng nhau khám phá nhé.
Bạn có đồng ý với tôi rằng tiếp thị là 1 phần cực kỳ quan trọng để quảng bá sản phẩm của bạn khiến cho mọi người chú ý? Và bộ phận chịu trách nhiệm cho việc này chính là phòng marketing của công ty. Nó đã triển khai tới các ngõ ngách mà bạn có thể nghĩ rằng chúng ta không thể làm gì để có thể xúc tiến hay phát triển ở đó. Các nhà phát triển lựa chọn hướng đi cho sản dựa trên số lượt vote (số sao) của các thư viện tương tự có trên Github hay số lượng "tweets"của tài khoản để có thể dự đoán được công nghệ nào phát triển nhanh chóng và là xu hướng trong năm. Với môi trường kỹ thuật số này thì nó làm cho chúng ta có nguy cơ trở thành nạn nhân của sự cường điệu hoá, ở đó chúng ta có thể bị đánh lừa - chỉ cần rơi vào 1 công cụ được khuyến cáo, được tạo ra bởi các nhà tiếp thị độc ác.
Một trong các công cụ mà mọi người vừa bàn đến gần đây là Firebase và những APIs của nó, một nền tảng phát triển ứng dụng web và di động được phát triển bởi Firebase Inc trong nằm 2011, sau đó được google mua lại vào năm 2014 dưới dạng các trang Wikipedia. Trước khi Firebase được mua lại bởi google năm 2014 không có bằng chứng nào cho thấy sự tăng trưởng mạnh mẽ nhanh chóng của sản phẩm, một số cho rằng những bất lợi của Firebase đã hiện hữu. Mặc dù 1 số điều đã thay đổi từ thời điểm đó. Firebase đã được triển khai trong quá trình thực hiện các ứng dụng như: • Shazam • Alibaba order & delivery app • Todoist app organizer
Với 1 gã khổng lồ như Shazam rõ ràng sẽ không quá tốn kém trong việc chi tiêu, vì vậy đối với họ, Firebase là sự lựa chọn khá hợp lý, chúng tôi đã cố gắng để xem xét các ưu điểm và khuyết điểm trong quá trình triển khai firebase, cố gắng tìm ra những dự án mà khi áp dụng firebase sẽ là sự lựa chọn tối ưu.
Nhưng trước khi chúng ta đi sâu vào firebase thì hãy làm rõ 2 điểm quan trọng để tránh những hiểu lầm đáng tiếc có thể xảy ra:
Thế nào là cơ sở dữ liệu NoSQL?
NoSQL là một khái niệm chỉ về một lớp các hệ cơ sở dữ liệu không sử dụng mô hình quan hệ (RDBMS). RDBMS vốn tồn tại khá nhiều nhược điểm như có hiệu năng không tốt nếu kết nối dữ liệu nhiều bảng lại hay khi dữ liệu trong một bảng là rất lớn. NoSQL ra đời năm 1998 bởi Carlo Strozzi khi ông lập mới một hệ cơ sở dữ liệu quan hệ mã nguồn mở nhanh và nhẹ không liên quan đến SQL Vào năm 2009, Eric Evans, nhân viên của Rackspace giới thiệu lại thuật ngữ NoSQL khi Johan Oskarsson của Last.fm muốn tổ chức một hội thảo về cơ sở dữ liệu nguồn mở phân tán. Thuật ngữ NoSQL đánh dấu bước phát triển của thế hệ CSDL mới: phân tán (distributed) + không ràng buộc (non-relational). Nó có đặc điểm: - NoSQL lưu trữ dữ liệu của mình theo dạng cặp giá trị “key – value”. Sử dụng số lượng lớn các node để lưu trữ thông tin - Chấp nhận dữ liệu bị trùng lặp do một số node sẽ lưu cùng thông tin giống nhau - Phi quan hệ – không có ràng buộc nào cho việc nhất quán dữ liệu - Có hiệu suất cao (high performance) và tính sẵn sàng cao (high availability)
Ngược lại SQL là viết tắt của Structured Query Language, là ngôn ngữ truy vấn mang tính cấu trúc, Nó được thiết kế để quản lý dữ liệu trong một hệ thống quản lý cơ sở dữ liệu quan hệ (RDBMS), SQL là ngôn ngữ cơ sở dữ liệu, được sử dụng để tạo, xóa trong cơ sở dữ liệu, lấy các hàng và sửa đổi các hàng, … Tất cả DBMS như MySQL, Oracle, MS Access, Sybase, Informix, Postgres và SQL Server sử dụng SQL như là ngôn ngữ cơ sở dữ liệu chuẩn.
Ok vậy giờ hãy cùng nhau tìm hiểu 1 vài lợi thế của Firebase:
1. Realtime Database – Cơ sở dữ liệu thời gian thực Firebase lưu trữ dữ liệu database dưới dạng JSON và thực hiện đồng bộ database tới tất cả các client theo thời gian thực. Cụ thể hơn là bạn có thể xây dựng được client đa nền tảng (cross-platform client) và tất cả các client này sẽ cùng sử dụng chung 1 database đến từ Firebase và có thể tự động cập nhật mỗi khi dữ liệu trong database được thêm mới hoặc sửa đổi. Ngoài ra Firebase còn cho phép bạn phân quyền một các đơn giản bằng cú pháp tương tự như javascript. 2. Firebase Authentication – Hệ thống xác thực của Firebase Với Firebase bạn có thể dễ dàng tích hợp các công nghệ xác thực của Google, Facebook, Twitter, … hoặc một hệ thống xác thực mà bạn tự mình tạo ra vào trong ứng dụng của bạn ở bất kì nền tảng nào như Android, iOS hoặc Web. 3. Firebase Hosting Các bạn có thể triển khai một ứng dụng nền web chỉ với vài giây (chém gió tới từ firebase, chính mình cũng không tin lắm) với hệ thống Firebase, và các dữ liệu sẽ được lưu trữ đám mây đồng thời được bảo mật thông qua giao thức truy cập SSL. Các ứng dụng sẽ được cấp 1 tên miền dạng <name>.firebaseapp.com hoặc bạn có thể trả tiền để sử dụng tên miền của riêng mình.
4. Tốn cực ít thời gian để phát triển ứng dụng Với Firebase bạn có thể giảm bớt rất nhiều thời gian cho việc viết các dòng code để quản lý và đồng bộ cơ sở dữ liệu, mọi việc sẽ diễn ra hoàn toàn tự động với các API của Firebase. Không chỉ có vậy Firebase còn hỗ trợ đã nền tảng nên bạn sẽ càng đỡ mất thời gian rất nhiều khi ứng dụng bạn muốn xây dựng là ứng dụng đa nền tảng. Không chỉ nhanh chóng trong việc xây dựng database, Google Firebase còn giúp ta đơn giản hóa quá trình đăng kí và đăng nhập vào ứng dụng bằng các sử dụng hệ thống xác thực do chính Firebase cung cấp.
Hoa hồng dù rất đẹp nhưng cũng rõ là lắm gai Vì vậy nếu bạn tạo ra sản phẩm mà có tới hàng nghìn người sử dụng thì Firebase có thể là giải pháp vô giá trị
Một khi bạn chọn Firebase với vai trò làm backend chính, có một vài điểm bạn cần phải xem xét. Không phải là những bất lợi của việc sử dụng firebase. Với Firebase, bạn được tự do lựa chọn kế hoạch giá cả - nhưng một trong những phù hợp cho các ứng dụng thời gian thực là một "trả tiền khi bạn dùng" một. Với kế hoạch này, bạn chỉ trả tiền cho các tài nguyên mà bạn tiêu thụ, vì vậy nhiều người dùng ứng dụng của bạn chi phí sẽ càng cao hơn.
Nhiều người cho rằng điều này sẽ trở nên thú vị hơn - vì nhiều người sử dụng sản phẩm của bạn, thật tuyệt vời phải không? Tuy nhiên, ngay từ đầu nó khó kiếm tiền từ tất cả chúng - bạn cần làm cho mọi người yêu thích sản phẩm của bạn trước tiên. Và trong trường hợp với Firebase, bạn sẽ phải trả tiền cho tất cả người dùng miễn phí của mình. Vì vậy, nếu bạn có ý định rằng hàng ngàn người sẽ sử dụng sản phẩm của bạn - thì Firebase có thể là một giải pháp không có giá trị.
Tin đồn cho rằng Firebase cũng có chi phí ẩn, sau khi người sử dụng nhanh hoặc tăng trưởng sử dụng, bạn có thể bị buộc phải trả thêm tiền mà không có cảnh báo; vì vậy nếu bạn không phải lo lắng về việc bị tính phí âm thầm - thì cho nó lướt đi (không dùng nữa)
Đó là lý do tại sao tôi đề xuất 1 tuỳ chọn khác cho bạn đó là ứng dụng sử dụng Ruby backend + một máy chủ để có thể lưu trữ dữ liệu (đây là phương pháp chúng ta thuường tiếp cận khi làm việc với dự án của khách hàng) thêm vào đó Ruby on Rails backend và firebase cũng có những đặc điểm ít nhiều giống nhau, trường hợp của ruby thì đây là follow của nó:
1. Ruby on Rails là 1 ngôn ngữ đơn giản Có cả 1 danh sách các framework được implement trong Ruby on Rail, ngay cả khi so sánh với PHP và mã nguồn của nó thì nó vẫn rất là nhiều. Có nhiều các gems - một hệ thống hoàn chỉnh các thư viện đa năng cho Ruby, nó sử dụng mô hình kiến trúc MVC.
2. Cộng đồng Ruby rất lớn và có thời gian dài để kiểm định các thư viện
Không giống như cộng đồng nhà phát triển mới mẻ của Firebase, cộng đồng của Ruby rất lớn, nó có rất nhiều nguồn mở, cho phép lập trình nhanh chóng và phát triển các ứng dụng phức tạp. Thêm vào điều này, do "danh tiếng" của Ruby cũng rất lớn nên nhiều dịch vụ nổi tiếng (như Stripe) đã cung cấp các thư viện cho Ruby.
3. Bạn có thể test code của bạn trên Ruby
Ruby có một cơ sở hạ tầng phát triển tiên tiến cho phép tối đa hóa và viết các unit test trên toàn dự án để giảm lỗi trong các tính năng mới và hiện có. Điều này cũng sẽ cắt giảm chi phí của sự thay đổi trong tương lai giữa quá trình phát triển.
4. Không bị ràng buộc với bất kỳ 1 loại cơ sở dữ liệu cụ thể nào
Hoặc, chính xác hơn, đối với một loại cơ sở dữ liệu cụ thể. Ruby cho phép bạn sử dụng bất kỳ cơ sở dữ liệu quan hệ hoặc oriental databases, cũng như NoSQL và các công nghệ khác nhau - bao gồm Elasticsearch, Reddis và các công nghệ phổ biến khác.
5. Cú pháp đơn giản như ăn bánh
Với Ruby thì không có quy định kiểu dữ liệu, không cần phải xem liệu các loại dữ liệu được cấu trúc phù hợp. Hơn nữa, hệ thống composable Error(còn gọi là hệ thống khai thác gỗ) cũng có mặt; điều này làm cho việc debug lỗi trở nên dễ dàng hơn và sau đó cho phép sửa lỗi nhanh hơn.
Vậy Firebase với RoR, trong 2 cái đó khi nào thì dùng cái gì sao cho phù hợp?
Sau 1 hồi so sánh thì có thể kết luận là tuỳ mục đích của bạn mà lựa chọn Firebase hoặc Ruby on Rails
Bạn dùng firebase làm backend trong những trường hợp sau:
Những ứng dụng dạng real-time với những chức năng đơn giản Một ứng dụng đơn giản nơi bạn cần lưu trữ dữ liệu và download dữ liệu Ứng dụng dạng demo nhưng sau đó sẽ được làm mới hoàn toàn khi bạn phát triển mở rộng hơn.
Nếu bạn đang tìm kiếm 1 cách tiếp cận có thể xây dựng 1 ứng dụng di động phức tạp với các thuật toán và nhiều tính năng cho lượng lớn người dùng thì RoR là sự lựa chọn tuyệt vời, còn nếu là 1 ứng dụng không cần có cấu trúc rõ ràng, cơ sở dữ liệu không quan hệ, sử dụng cloud thì firebase rất tốt, nhưng với firebase cùng với lượng sử dụng của bạn tăng lên thì bạn có thể bị tính phí vào 1 ngày đẹp trời nào đó khi bạn tỉnh dậy và kiểm tra tài khoản. Nên nhớ rằng firebase trước khi được google mua lại thì cũng chẳng có gì nổi bật. Hy vọng với những thông tin trên sẽ giúp bạn có thể chọn được cách tiếp cận phù hợp, bạn có thể dùng firebase nếu nó phù hợp nhu cầu của bạn.
Trích dẫn nguồn: https://themindstudios.com/blog/firebase-vs-ruby-for-mobile-backend/ và 1 số tư liệu khác
All rights reserved