Hello. Appreciate your question. I think that this is a good use case for the Repository Pattern.

In your case, this might look something like this:

• TicketRepository, ScheduleRepository and TimerRepository interfaces which have their functions like create(), read(), update(), delete(), complexQueryByManyParams() etc. All your domain code should expect and operate on these interfaces.
• FirebaseTicketStore, FirebaseScheduleStore, FirebaseTimerStore classes which implement the respective interfaces. All your logic that relates to Firebase should be encapsulated here.
• You can later safely do things like swap out a FirebaseTicketStore with a MysqlTicketStore

You can consult the Design Patterns / Gang of Four book for more details

Off topic, but personally I don’t feel you should worry too much about having to change the database in the future. I have rarely seen it happen in my career.

I’ve heard of SQL Island and SQL Police Department which appear to be in the same vein, but I haven’t got any hands on experience with those two.

You must be a fan of the primeagen

This is really nice! You might also enjoy: Select Star SQL and SQL Murder Mystery

I came today from Reddit. Think i’m here for good. This feels magical.