간단히 말해서 Firebase는 외부 데이터베이스 서비스입니다. 그들은 자신을 다음과 같이 정의합니다.
자세한 내용은 "Google에서 제공하는 일련의 백엔드 클라우드 컴퓨팅 서비스 및 애플리케이션 개발 플랫폼"을 여기에서 확인하세요: https://firebase.google.com/
데이터베이스 서비스 외에도 다양한 애플리케이션에 대한 인증 및 통합 서비스도 제공합니다. 지원되는 애플리케이션 및 프로그래밍 언어는 Flutter, Dart, C++, Android, IOS, JavaScript , Unity 엔진 및 Java입니다.
이 모든 것이 왜 중요합니까? 우리는 애플리케이션 개발에 Firebase를 사용했기 때문입니다. 그뿐만 아니라 우리는 가장 인기 있는 서비스인 데이터베이스 서비스를 사용했습니다.
왜 Firebase를 사용하는 걸까요? Firebase는 쉽습니다 . 사용자 데이터를 일부 형식으로 저장해야 하는 모든 유형의 개발 프로젝트를 수행할 때 데이터베이스가 필요합니다. 이는 향후 분석, 데이터 수정, 데이터 보호, 데이터 복원 등을 위해 사용자 데이터를 저장하는 것일 수 있습니다. 이는 회사, 개인 및 조직, 심지어 더 많은 그룹에도 적용됩니다.
이제 데이터베이스를 사용하는 이유를 알았으니 다음 질문을 던져야 합니다. 어떤 데이터베이스 유형이 우리에게 더 적합합니까?
이러한 차이점을 살펴보겠습니다. 그렇게 하는 동안 Firebase가 어떤 데이터베이스 유형에 속하는지 추측해 보세요.
중앙 집중식 데이터베이스 : 애플리케이션에 사용되는 데이터베이스를 이를 사용하는 사람이 직접 물리적으로 접근할 수 있는 장소에 저장하는 경우입니다. 또한 원하는 방식으로 데이터베이스를 편집, 개선, 업데이트 및 재구성할 수 있습니다. 기본적으로 귀하는 물리적, 내부적, 디지털 인프라 측면에서 모든 면에서 데이터베이스에 대한 완전한 소유권과 편집 기능을 갖습니다.
분산형 데이터베이스 : 이는 중앙형 데이터베이스와 완전히 반대입니다. 그들은 web3 기반 데이터베이스입니다. 이는 저장 장치가 다양한 컴퓨팅 장치에 분산되어 있는 데이터베이스입니다. 특정 조직만이 데이터베이스 내부 기능을 사용자 정의하고 개선할 수 있습니다. 사용 사례는 제한되어 있습니다. 대부분 web3 앱, 토큰 및 기타 web3 제품 호스팅용으로 만들어졌습니다.
더 자세히 살펴보는 web3 데이터베이스에 대한 자세한 내용은 여기에서 확인하세요: https://www.makeuseof.com/what-is-web3-storage-how-does-it-work/
DBaaS : 이 데이터베이스 유형을 흔히 "서버리스"라고 합니다. 이는 중앙 집중식 데이터베이스와 유사한 이 데이터베이스 유형을 사용하면 데이터베이스를 가까운 곳에 로컬로 보관할 수 없기 때문입니다. 데이터베이스는 제3자 회사를 통해 호스팅되며 이를 통해 데이터베이스의 특정 디지털 인프라를 사용자 정의할 수 있지만 그 이상은 아닙니다. 이 데이터베이스의 주요 판매 포인트는 비용 효율성입니다. 자신의 중앙 집중식 데이터베이스를 만들기 위해 자금을 낭비하는 대신 노력을 아웃소싱하는 것을 선택합니다. 누군가가 지저분한 건설 작업을 수행하고 귀하는 그들로부터 임대하여 데이터베이스 서비스를 사용할 수 있습니다. 다양한 유료 계층 수준에 따라 다양한 기능을 사용할 수 있습니다.
저는 DBaaS를 사용하기로 결정했습니다. Firebase는 DBaaS입니다. 나는 이 데이터베이스 모델의 비용 효율적인 특성 때문에 이를 선택했습니다.
앱을 만들고 있어요. 앱의 기능 중 하나는 사용자 등록, 로그인 및 로그아웃 기능입니다. 위 사진에서 볼 수 있듯이 가입을 위한 테스트 사용자 이름과 테스트 비밀번호를 만들었습니다. "가입" 버튼을 누르면 앱이 관련 데이터베이스로 정보를 보냈습니다. Firebase에서 호스팅되는 데이터베이스입니다. 가입을 시도했지만 동일한 앱 페이지에 남아 있었고 아무것도 변경되지 않았습니다. 내 Firebase에서 사용자를 확인한 후 그 당시에는 새로운 사용자가 등록되지 않았습니다. 이는 내 사용자가 등록되지 않았음을 의미합니다.
새로운 사용자를 인식하려면 앱이 필요합니다. 이 단계에서 개발자는 자신의 코드를 살펴보고 Firebase용 API(애플리케이션 처리 인터페이스)와 이를 코드에서 호출한 방법을 살펴볼 수 있습니다. 또한 사용자를 정의하는 변수를 살펴보고 올바르게 정의되었는지, 기능이 양호한지 확인합니다. 또한 사용된 라이브러리나 Firebase API 링크 자체와 같이 데이터베이스 연결을 방해하거나 상호 작용하는 항목을 업데이트해야 하는지 확인할 수도 있습니다. 우리의 호출을 무시하고 데이터베이스에 대한 해결책을 찾기 위해 이 모든 단계 이상을 수행할 수도 있습니다. 한 가지 문제가 있습니다.
이 중 어느 것도 나에게 적용되지 않았습니다 . 왜 그럴까요?
이러한 표준 디버깅 방법을 수행할 필요가 없었던 이유는 이 새로운 시도가 있기 조금 전에 새 사용자를 데이터베이스에 등록할 수 있었기 때문입니다. 일주일도 안 되어 갑자기 멈췄습니다. 내 코드를 변경하지 않으면 이전에 작동했던 프로세스가 더 이상 작동하지 않습니다. 이로 인해 저는 큰 혼란을 겪었고 API 호출 링크를 반복적으로 교체하여 다른 영역에 배치했습니다. 나는 익숙한 내 라이브러리와 다른 파일 호출에 대한 참조 호출을 구성했습니다. 심지어 Firebase의 데이터베이스 서비스가 다운되었는지 문의하기 위해 온라인에 접속하기도 했습니다. 사실은 그렇지 않았습니다. 그때 저는 표준 디버깅 실습을 시작하려고 했습니다….. 그리고 마침내 해결책을 찾았습니다 ! 그건 내 이메일에 계속 있었어.
예, 제 이메일에는 항상 해결책이 있었습니다! 이 문제로 며칠 동안 정체된 후 이메일을 확인해보니 Firebase에서 보낸 알림 이메일을 발견했습니다. Firebase에서 내 데이터베이스 액세스가 차단되었다는 알림을 받았습니다. 이는 Firebase 데이터베이스 설정 중에 보안을 위해 특정 날짜에 데이터베이스 액세스가 차단되도록 설정했기 때문입니다. 나는 내가 스스로 추가한 이 규칙을 잊어버렸습니다. 내가 지정한 날짜를 잊어버렸어요. 결과적으로 저는 연락이 끊겼을 때 이메일을 확인할 때까지 그 사실을 알지 못했습니다. 아래에서는 2023년 3월 12일에 연락이 끊기도록 데이터베이스를 설정한 것을 볼 수 있습니다.
이 문제를 해결하려면 "마감" 날짜의 기간을 연장하기 위해 규칙을 업데이트해야 했습니다. 여기에서 볼 수 있듯이:
이 문제를 해결하기 위해 다음 기한을 6월 29일로 정했습니다. 이렇게 하면 마감일까지 다시는 어떤 방해도 받지 않을 것입니다.
누군가는 " 지금부터 몇 년 후로 설정하거나 지금부터 몇 달 후로 설정하여 신경쓰지 않는 것이 어떨까요?"라고 물을 수 있습니다. 좋은 질문. 나는 이 의존성을 나에게 상기시키기 위해 일년 내내 몇 가지 분기별 알림을 원하기 때문에 그렇게 하지 않을 것입니다. 장기 기한으로 정하고 또 잊어버리고 1년 뒤에도 같은 상황에 갇히고 싶지는 않다. 내 두뇌에서 반복적으로 의식한다는 것은 앱 개발에 영향을 미칠 수 있는 모든 요소를 지속적으로 생각한다는 것을 의미하며, 이는 개발 프로세스를 계속하는 데 도움이 될 것입니다. 이것을 학습 선호도라고 부를 수도 있습니다.
Firebase 인증 절차가 사용자 ID 토큰을 사용자 특수 식별자로 반환하는 것을 볼 수 있습니다. 이것이 바로 해당 토큰이 등록되었음을 확실히 알 수 있는 방법입니다.
개발은 재미있지만 항상 작은 것까지 의식해야 합니다. 대부분의 경우 응용 프로그램에 문제가 있는 경우 자체 코드 오류로 인한 것일 가능성이 높습니다. 그러나 때로는 문제가 코드에서 발생하지 않을 수도 있습니다. 필요한 업데이트처럼 간단할 수도 있고 이 경우에는 간단한 데이터베이스 규칙 검토일 수도 있습니다.