I decided to go with Firestore to our new project.

The goal is I don't want our server logics and database designs are locked-in by Cloud Function and Firestore, And also long-term maintainability.

While I know there will still have some degree of locked-in,

My idea is to write the logic in Cloud Functions separately as microservices and persist datasets in any other database. (This is the write model)

In the meanwhile, We will project those changes to update another bucket of Firestore which will optimize for the client app to read on it. (This is the read model)

Is this a good idea to achieve my goal?

  • The title of your question is very different from the question asked in the last sentence. Is the question if CQRS will prevent vendor lock-in?
    – Rik D
    Nov 13 '20 at 7:36
  • Hi, You're right, I've changed the title.
    – b.ben
    Nov 13 '20 at 7:55
  • Question: Are you really going to change the database independently of changing the cloud functions? If you are the solution would be the repository pattern so that you can substitute the data store backend. Whether they are micro services, CQRS, or other is irrelevant.
    – Kain0_0
    Nov 13 '20 at 8:12
  • I don't see how this is releasing you from Google Firebase. It's pretty much locked to Google. If any of the two (C.F or Firestore) changes or goes out of support or disappears, the whole app is doomed. The whole write logic will have to be rewritten from scratch somewhere else and you will have to look for a NoSQL data store that supports your documents' structures, queries, etc.
    – Laiv
    Aug 11 '21 at 8:44

Command Query Responsibility Segregation (CQRS) is a pattern that allows to differentiate read and write models.

Both models can work on a single database, or you store a write model in a separate database and use another mechanism to create views for the read model.

The CQRS pattern itself does nothing to prevent vendor lock-in. As with any software system, in order to minimize the dependency on a specific technology, you need to create an abstraction that allows you to swap the underlying implementation without affecting the rest of the application.

This is usually done by creating an additional layer between the two responsibilities. If we look at the database, a common way is to create repository classes that handle communication with the database. The application only knows the repository classes, so if you decide to use a different database technology, only the repository classes need to change.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.