구글 앱 엔진 vs 파이어베이스
저는 어떤 옵션으로 할지 결정하려고 합니다.(또는 더 나은 경우 다른 것)이것은 알림 및 데이터베이스 쓰기의 양이 많은 메시징 유형 앱을 위한 것입니다.
옵션 1 - 클라우드 끝점 및 클라우드 데이터스토어를 사용하는 Google App Engine
의견:
- 원하는 방식으로 API를 구축할 수 있습니다.
- 확장 가능
단점:
- 알림 시스템 구현 작업이 더 많습니다.(Firebase Cloud Messaging이 될 것입니다.
옵션 2 - Firebase
의견:
- Firebase 데이터베이스, Firebase 사용자 인증, Firebase 클라우드 메시징(알림) 사용 가능
- 기기에 입니다.
단점:
- API 없음
옵션 3 - Google Cloud Endpoints와 Firebase를 결합할 수 있습니까?
먼저 Google 문서에서 제공하는 다양한 모바일 앱 백엔드 서비스를 비교 및 대조하기 위해 차트를 살펴봅니다.차트는 다음과 같습니다(참고: 차트는 해당 링크의 사이트에 더 이상 표시되지 않습니다).
개인적인 의견은 다음과 같습니다(업데이트).
옵션 1 - 클라우드 끝점 및 클라우드 데이터스토어를 사용하는 Google App Engine
의견:
- 당신은 당신만의 API를 작성하는 편안한 패턴에 대해 더 많은 것을 배울 것입니다.또한 iOS 또는 Android를 사용하여 편안한 api 통화를 하는 방법을 배워야 할 것이며, 이는 업계에서 매우 가치 있는 기술입니다.파이어베이스는 여러분을 위해 모든 것을 해주고 여러분은 이런 것을 결코 배우지 못할 것입니다.
- 직접 작성해야 하지만 API 메소드와 Google Cloud Messaging, 그리고 작성한 메소드 유형을 사용하여 정말 창의적으로 작업할 수 있습니다.모든 작업을 수행하고 모든 데이터베이스(예: MySQL, SQL 서버, 데이터스토어)에 연결할 수 있습니다.Firebase에서는 json 기반 데이터베이스를 사용해야 합니다.앱에 SQL 데이터베이스를 사용하는 것은 권장하지 않지만 사람마다 필요한 것이 다릅니다.
단점:
- 더 많은 작업이 필요하고 데이터스토어에 머리를 감는 것은 처음에는 어려울 수 있습니다.SQL과 같은 관계형 데이터베이스와는 다릅니다.
- 또한 매우 비효율적이고 실행 시간이 오래 걸리는 메소드와 쿼리를 생성하여 "자신의 발을 쏘는" 몇 가지 영역이 있다고 생각합니다.
- 새로운 앱들에게 짜증나는 한 가지는 GAE의 자동 스케일링입니다.간단히 말해서, 약 15분 동안 아무도 당신의 API를 치지 않으면 모든 인스턴스가 종료됩니다.새 호출이 발생하면 인스턴스 백업을 실행하고 API 메서드를 실행하는 데 상당한 시간이 걸립니다.새로운 사용자가 앱에 문제가 있다고 생각하여 사용을 중지할 수 있기 때문에 새 앱에는 성가신 일이 될 수 있습니다.수동 스케일링을 수행할 수 있지만 항상 인스턴스를 설치하는 데 비용이 듭니다(청구된 앱에서 월 27달러 정도를 기록하는 기준).이 문제에 대한 자세한 내용과 제가 생각해 낸 해결책은 여기에 있는 제 게시물을 참조하십시오.
옵션 2 - Firebase
의견:
- 초보자도 쉽게 사용할 수 있도록 제작되었으며, 푸시 알림 전송 및 동기화 데이터와 같은 인기 있는 작업을 수행할 수 있는 충분한 자습서/과정이 Firebase에 있습니다.
- GAE와 달리, 그것은 개봉이 빠릅니다.시동 인스턴스가 없습니다.따라서 빠른 데이터 가져오기로 사용자에게 깊은 인상을 주고자 하는 새로운 앱에 적합합니다.
- 어댑터(Android) 및 네트워킹(모바일 앱)과 같은 복잡한 것들을 쉽게 배울 수 있으며 Firebase 클래스에 의존할 수 있습니다.아마도 그것은 조금 더 noob friendly인가요?다시 말하지만, 문서는 훌륭하고 즉시 사용할 수 없는 것입니다. 비효율적인 질문을 작성함으로써 자신의 입장을 비난할 기회가 적다고 생각합니다.
단점:
- Firebase가 클라이언트 코드에서 무겁습니다.만약 당신이 안드로이드와 iOS 앱을 원한다면 당신은 둘 다를 위해 많은 클라이언트 코드를 작성해야 합니다.GAE에서는 이러한 논리의 많은 부분이 GAE 앱에서 추상화됩니다.그러나 앱에 데이터베이스 관리자를 원하지 않고 Firebase를 알고 있는 iOS 및 Android 개발자만 있다면 이점이 될 수 있습니다.하지만 저에게 이것은 큰 문제였습니다.
- 파이어베이스가 Parse.com 의 방식대로 간다면요?Facebook이 더 이상 지원하지 않을 것이라고 발표한 곳.그건 정말 최악일 거예요!당신은 Firebase에 갇혔을 것이고 편안한 API를 만드는 방법에 대한 어떠한 프로그래밍 지식도 개발하지 못했을 것입니다.그러나 Google이 Firebase에 많은 투자를 하고 GCM을 Firebase Cloud Messaging으로 업그레이드함에 따라 Firebase에 대한 큰 계획을 세웠으며 아무 일도 일어나지 않고 있습니다.그래서 나는 이것이 "사기"로 간주되지 않는다고 생각하지만 명심해야 합니까?
링크에서 이들을 결합하는 방법을 자세히 알아보십시오.
EDIT 2022:
Firebase를 고려하는 사람은 누구나 새롭고 개선된 Firestore를 고려해야 합니다.위의 모든 것은 Firestore에서도 여전히 유효합니다.
원래 답변에서 저는 파이어베이스가 파스처럼 사라질 수도 있다고 말했습니다.비록 그런 일은 일어나지 않았지만, Firestore가 확실히 대체품입니다.제 생각에는 구글이 파이어스토어를 먼저 지었어야 했습니다.이미 데이터스토어를 보유하고 있었는데, 이를 기반으로 구축하지 않은 것이 놀랍습니다.하지만 말하기는 쉽지만 행동하기는 쉽지 않을 것입니다.
Firebase에 대한 많은 논의(위의 질문과 답변 포함)가 저에게 매우 중요한 차이인 가격에 대해 언급하지 못하는 것에 대해 당혹스럽습니다.
여기 파이어베이스 가격표가 있습니다.
이것들을 비교하는 것은 까다로울 수 있지만, 제 해석은 파이어베이스가 매우 비싸다는 것입니다.
그리고 이것은 놀랄 일이 아닙니다.GAE와 데이터스토어는 아마존, 마이크로소프트 등의 유사 서비스와 경쟁해야 하며 경쟁이 치열합니다.예, 물론 이러한 서비스는 인프라 및 SQL만큼 일반적이지는 않지만 가격이 경쟁력을 유지할 정도로 근접한 것으로 보입니다.
반면 파이어베이스는 Parse와 같은 다른 백엔드 서비스와 경쟁하는 프리미엄 서비스로 일단 사용하기로 결정하면 전환이 매우 어려울 것으로 생각됩니다.구글이 파이어베이스를 그렇게 강하게 밀어붙이는 것은 놀랄 일이 아닙니다. 그들은 파이어베이스를 그렇게 비싼 가격에 팔 수 있기 때문에 아마도 엄청난 돈을 벌 것입니다.
제 생각에 이 결과는 Firebase가 소량 및 고수익 서비스에 적합한 선택이라는 것입니다. 하지만 많은 양을 사용하여 수익을 창출할 수 있는 일반적인 소비자 지향적이고 지원되는 서비스를 만들 계획이라면 Firebase의 비용이 수익을 떨어뜨릴 수 있습니다.
2017-10 추가:
최근 출시된 Firestore를 통해 Firebase를 다시 살펴봤습니다.
안드로이드 앱에 Firestore를 사용하는 것은 Google Play Services에 크게 의존하는 Firebase 클라이언트 라이브러리를 사용하는 것을 의미하며, 이는 아마존 Fire 태블릿과 전체 중국 시장을 포함한 비구글 기기에 배포할 수 없다는 것을 의미합니다.
해결책을 찾기 위해 고군분투하면서 최근에 알게 된 한 가지 사실은 Firebase는 서버에서 장치로 푸시 알림을 제공하고 설정이 매우 쉽다는 것입니다.하지만 전자의 기능 부족은 매우 중요하며 다른 구글 제품도 사용하도록 강요하기 때문이라는 음모론이 있습니다.
아니면 처음에는 개발되지 않았기 때문에 그대로 유지했을 수도 있습니다.저는 앱 엔진이 이러한 목적을 위해 파이어베이스와 장치를 연결하는 방법이라고 생각했기 때문에 이 경우 앱 엔진에서 파이어베이스와 다른 구글 제품을 결합하는 쪽으로 기울었습니다.이미지 처리 등과 같은 백엔드 처리를 더 많이 할 계획이라면 Firebase와 통합할 수 있는 앱 엔진과 컴퓨팅 엔진을 확실하게 검토하여 가상의 강력한 백엔드 솔루션을 구축할 수 있습니다.
언급URL : https://stackoverflow.com/questions/37471546/google-app-engine-vs-firebase
'programing' 카테고리의 다른 글
ORA-01779: 키가 보존되지 않은 테이블에 매핑되는 열을 수정할 수 없습니다. (0) | 2023.07.14 |
---|---|
읽기 전용 맵 유형 사용 (0) | 2023.07.14 |
전체 MySQL 데이터베이스 복제?아이디어? 사람들은 무엇을 합니까? (0) | 2023.07.14 |
합계가 있는 요약 행 추가 (0) | 2023.07.14 |
angular7에서 항목 목록을 표시할 때 매트 선택의 높이를 변경하려면 어떻게 해야 합니까? (0) | 2023.07.14 |