Firebase를 사용하는 경우 비즈니스 로직을 어디에 두어야합니까?

다중 사용자 문서화 시스템으로 단순화 된 단일 페이지 웹 응용 프로그램을 개발하려고합니다. 프론트 엔드는 아마도 Angular2를 사용할 것입니다.

프로젝트는 마감일이 짧기 때문에 "바로 가기"를 찾고있었습니다. 즉, 처음부터 모든 것을 구현하는 대신 다양한 기성 서비스를 사용했습니다.

애플리케이션 데이터를 저장하려면 일종의 백엔드가 필요합니다. 나는 주변을 둘러보고 Firebase를 찾았습니다 .Firebase는 프론트 엔드와 통신하기 위해 별도의 백엔드와 API를 만드는 작업 중 일부를 제거하는 것으로 보입니다.

그러나 그것은 또한 비즈니스 로직을 프론트 엔드, Angular2 웹 앱에 넣어야한다는 것을 의미합니다.

나중에 언젠가 모바일 앱 프런트 엔드를 만들고 싶다면 비즈니스 로직 코드를 복제해야합니까?

대안은 비즈니스 로직을 포함하고 데이터 저장소에 Firebase를 사용하는 백엔드를 만드는 것이지만, 조금 이상하게 보입니다 (ORM이나 직접 백엔드에서 무언가를 사용하여 동일한 결과를 얻지 못했을 수는 없습니다) 더 많은 일 이요?)

예를 들어 Firebase를 사용하려는 사람들은 일반적으로 이러한 종류의 앱을 어떻게 구성합니까?

Q : 그러나 그것은 또한 비즈니스 로직을 프론트 엔드, Angular2 웹앱에 두어야한다는 것을 의미합니다 .

예. 서버가 지원하지 않으면 비즈니스를 어딘가에 구현해야합니다.

Google을 인수 한 후 Firebase는 자체 백엔드를 배치 할 여유가없는 (또는 필요하지 않은) 모바일 앱 개발자를위한 플랫폼으로 발전했습니다. 스토리지, 로그인, 분석 및 메시지 서비스와 같은 대부분의 서비스는 상당히 번거롭지 만 일부 비즈니스 관련 규칙을 수행하는 데 사용할 수있는 클라우드 기능 (일부 람다) 도 제공합니다 . 그러나 엔터프라이즈 응용 프로그램이나 복잡한 도메인 및 비즈니스 논리를 가진 대규모 응용 프로그램의 경우 이러한 종류의 지원이 부족합니다.

따라서 추측 할 수 있듯이 Firebase는 백엔드가 비즈니스 전용 작업을 호스트하고 운영하는 데 전념하는 것을 면제하지 않습니다.

Q : 미래에 언젠가 모바일 앱 프런트 엔드를 만들고 싶다면 비즈니스 로직 코드를 복제해야합니까?

반드시 그런 것은 아닙니다. 웹 응용 프로그램이 Angular에 구축 된 경우 NativeScript 와 같은 크로스 플랫폼을 사용하면 웹 구성 요소, 라이브러리, 유틸리티, 모델 등을 재사용 할 수 있습니다. 주제에 대해 자세히 다루지 않았으므로 완전한 호환성을 보장 할 수 없습니다. 키는 TypeScript 에 있으며 Angular 및 NativeScript 모두 TS를 코딩해야합니다.

문제 는 배포 및 버전 관리를 위해 Javascript를 호스팅 할 위치 입니다. 단어 CDN .

Q : 대안은 비즈니스 로직을 포함하고 데이터 저장소에 Firebase를 사용하는 백엔드를 만드는 것이지만, 조금 이상하게 보입니다 (ORM 또는 직접 백엔드에서 무언가를 사용하여 동일한 결과를 얻을 수는 없습니다) 더 많은 작업없이 결과?)

몇 가지 고려 사항

한편으로 데이터베이스 호스팅, 롤아웃, 관리 및 유지 관리는 별거 아닙니다. 보안, 확장 성, 가용성 등을 다루는 것은 말할 것도 없습니다. 따라서 DB 공급자가 이러한 일을 돌보는 것이 흥미 롭습니다. 요즘 우리 데이터베이스를 클라우드에 배치하는 것은 미친 생각이 아닙니다. 물론, 우리가 은행을 위해 미들웨어와 백엔드를 구현하고 있다면 이것을 제안하지 않을 것입니다. 그러나 고객의 세션, 사용자 프로필, 환경 설정 및 일반적으로 고객 측에 존재하는 이러한 종류의 데이터 또는 우리가 신경 쓰지 않는 데이터에는 적합합니다.

반면에 백엔드를 갖는 것은 간단한 이유로 분리 할 수 있습니다.

고객을 관리 및 제어하지 않는 모든 종류의 서비스에 고객을 연결하는 대신, 고객이 서비스 종료 또는 중단과 같은 문제에 대해 걱정할 필요가 없도록 서버 측 애플리케이션을 배포합니다. 변화. 또한 백엔드는 외관처럼 작동하기 때문에 단순성을 얻습니다.

Q : 예를 들어 Firebase를 사용하려는 사람들은 일반적으로 이러한 종류의 앱을 어떻게 구성합니까?

프로젝트마다 다릅니다. 예를 들어 Firebase + 백엔드를 사용합니다.

• 중포 기지 DB 간 데이터를 공유하는 장치 - 계정 - 세션 . 또한 변경 로그로서 백엔드를 일시적으로 사용할 수없는 경우 클라이언트가 쓰기 작업을 로그에 전송하고 나중에 동기화됩니다.

• Firebase Cloud Messages 는 업스트림 / 다운 스트림 푸시 알림 및 주제를 제공합니다. 우리는 펍 / 서브 메시지 교환을 위해이 서비스를 사용합니다.

• Firebase 분석 주로 메트릭스에 사용됩니다.

• 비즈니스와 관련된 모든 것을위한 백엔드

짧은 대답 : 비즈니스 로직을 사용하지 마십시오.

긴 대답 : 별도의 비즈니스 논리를 갖지 않을 정도로 작게 보이는 응용 프로그램을 설명합니다. 처음에 그러한 비즈니스 로직이 있는지 평가하십시오. 많은 비즈니스 로직은 데이터 디자인과 프리젠 테이션 레이어에 의해 줄어들 수 있습니다. 많은 소규모 시스템은 대부분 CRUD이며 실제 비즈니스 로직은 없습니다. 여러 번 나는 미래에는 결코 도착하지 않을 공간을 남기는 객체를 통과하는 2 ~ 3 개의 클래스 계층을 보았습니다.

Firebase에서 직접 API로 시작한 후 나중에 서비스가 안정적인 서명을 유지할 수 있도록 계약을 충분히 설계 할 수 있다면 비즈니스 로직을위한 추가 계층을 도입 할 수 있습니다. 구현이 변경 될 수 있습니다.

참조 /programming/54994228/how-to-minimise-firebase-function-latency를

Cloud Firestore는 프런트 엔드와 백엔드 간의 기본 연결입니다. 물론 일부 로직은 프론트 엔드 내에있을 수 있지만 일반적으로 보안은 사용자의 이익을 위해서만 오프라인이 될 수 있습니다. 역할 또는 필요한 모든 것을 확보하여 Cloud Firestore 컬렉션 자체에 보안을 구현해야합니다.

그런 다음 Cloud Firestore 트리거에서 호출 된 Cloud Functions를 사용하십시오.

프론트 엔드 애플리케이션에서 클라우드 기능을 호출해서는 안됩니다.