JokersPistol

joined 1 year ago
 

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!

[–] JokersPistol@programming.dev 12 points 1 year ago

Yes and no. If your goal is to learn how to code manually, then you are "cheating" in that you may not learn as much.

If your goal is to learn how to utilize AI to assist you in daily tasks, I would say you're not.

If your goal is to provide value for others through how much you can produce in a given amount of time, then you're definitely not.

 

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!

[–] JokersPistol@programming.dev 2 points 1 year ago* (last edited 1 year ago) (1 children)

The only thing I can think of is when the user edits meetings en masse -- say they're rescheduling their whole day and are simultaneously creating and updating the timing of blocks. That probably will be functionality I'll want to implement (allowing users to enter "edit mode" for their schedule).

That's a good question though, other than that case it wouldn't be relevant. Plus, I probably would implement a createOrUpdateMeetings() API rather than createOrUpdateMeeting should that occur. Since Create and Update are both relatively simple APIs to implement, I think I'll stick with those for now and possibly shift over to createOrUpdate if the need comes up. Thanks for the insight!

Edit: After thinking about it and tinkering a bit more, I ended up going with the createOrUpdateMeetings() approach. At least on the surface, it seems simpler and cleaner for my use case -- there will be times where my client will have a list of both existing and new meetings to send over. Still open to suggestions from everyone though, people have made good points.

 

Which one is easier to develop and work with (which saves the most time)? Which one would you go for? The name of the API represents its true purpose in this case by the way, createOrUpdate creates or updates the passed in meeting and create just creates the meeting. I will be the only one working on this project for now, although obviously, I would like others to work on it with me eventually.