Data Model - Trip

[sam-lowenkamp]

The following model will be expressed (roughly) via TypeScript types but could be easily translated to a relational DB:

Primary workflows:

• Create a trip from a city, country, or point of interest
• Add additional cities, countries, and/or points of interest to the trip

Eventual workflows:

• Include flight, train, car, bus, etc information for the traveler (even if imported from external source)

interface Trip {
    id: number;
    // For these, I think we care more about the ~day~ (Jun 12, 2018) 
    // than the full date (Jun 12, 2018 @ 11:30am EST)
    startDate: Date;  
    endDate: Date;
    stops: Stop[];
}

interface Stop {
    // Once we want to integrate travel info, we can change arrival
    // and departure to a more complex type with that info
    id: number;
    arrival: Date;
    departure: Date;
    city: SygicPlace,
    country: SygicPlace, // in a DB context, we would probably store a SygicPlace.id for these values
    // accomodations: ?[] // this would hold information about where they're staying
    activities:     
}

// Activity extends the SygicPlace model (specifically where the category is POI)
// to add additional metadata such as date/time, number of people, other booking info
interface Activity extends SygicPlace {
    id: number;
    date: Date;
    // Other metadata?
}

Suggested trip creation data flow:

1. User clicks "create trip" on a POI / city / country
2. Application makes POST request to API with all available data, API returns newly created Trip object with the relevant data pre-populated
3. Application walks user through workflow of adding additional data (start/end date, whatever else wasn't included in initial creation)

Suggested trip update flow:

1. Trip already exists
2. User clicks "add to trip" (or some other option in application)
3. Application sends POST request with Trip.id and the relevant info (separate endpoints for adding a stop vs adding an activity --- probably need to send Stop.id when updating a stop instead of Trip.id)

I intend this as a "first take," not final product. Very open to suggestions, edits, changes! I also worked under the assumption that we move to a relational db in the near-ish future. The data feels very relational so it seems appropriate. Also open to challenges to that point.

[sam-lowenkamp]

Looks like this is a well-regarded TS based ORM: http://typeorm.io/#/faq

I think we should use psql or mysql for this stuff. I've never used an ORM in JS/TS but feel like we should stay in the JS world so you don't have to learn another language and I don't become a blocker for your work.

[sam-lowenkamp]

If you're pro-relational db, I can work on getting us deployed on heroku or something like that with a relational database + wiring up a sample view. Otherwise, we can move forward in non-relational with more firebase stuff. As long as we use interfaces in the JS, it shouldn't be impossible to migrate to another system down the line.

[asqwrd]

im fine with moving out of the js world. I kno backend engineers hate it so by all means if you feel that something is better im fine with you going that route this is also a good opportunity to learn stuff so i dont mind picking up another language.