Hi everyone,
In a project involving Firebase and object types like Tickets, Schedules, and Timers, I want to structure my classes such that switching databases (potentially to MySQL) wouldn’t require a complete rewrite.
Approach 1:
- A DatabaseProxy interface with generic methods (e.g., createTicket, createTimer, etc.)
- A FirebaseProxy class implementing the interface, with methods for each object type (e.g., createTicket, createTimer, etc.)
- Manager classes for Tickets, Schedules, and Timers, that primarily use the FirebaseProxy for operations. This provides flexibility for processing input/output, but most of the time the manager classes will just be calling methods on the Proxy directly.
Approach 2:
- A DatabaseProxy interface with the most basic CRUD methods (create, read, update, delete).
- A FirebaseProxy class implementing the interface.
- Manager classes for Tickets, Schedules, and Timers, calling FirebaseProxy with parameters like update(collection, ticket) and implementing createTimer, createTicket, etc.
I like the second approach in theory, but what I’m worried about is whether the separation is too low level. What happens if the database I switch to changes schema such that taking in an object and a collection name isn’t good enough anymore? For example, will there be concerns if I switch between Vector, NoSQL, and SQL?
Any opinions are appreciated!
I would generally say to stick to approach 1, as much as that stinks. Your observation about approach 2 especially compounds once you start to look at more complex operations that need to be optimized based on how the underlying DB works. Care still needs to be taken in approach 1 to avoid non-optimal operations, but at least you have the freedom to rework individual methods on your DatabaseProxy instead of all FirebaseProxy methods using your underlying CRUD operations.
One of the fastest ways I get people thinking about this is asking
Generally that’s complex enough to bring out pain points.