Backend Folder Structure

[one2code]

@0916dhkim @DaleOrders @anjolaoluwaakindipe @1234tgk

Since we are in the early days of the project, I think it's important to hash out a backend folder structure before we get too deep into the weeds. Based on the natural flow thus far, I think the folder structure here + a folder for the serializer's /serial could work. Or we continue with the module split's for each api, but the drawback to this is repetition in file creation.

[1234tgk]

@one2code My modules folder was never meant to be a split for each API as you mentioned. Each module folder is designed to take care of individual table on our database and/or other resources we pull from third-party. I checked your early draft regarding event type API, and I feel like you have a misunderstanding on how I intended to design the project.

This is our database schema:

model User {
  id String @id @default(uuid())

  firstName                  String?
  lastName                   String?
  email                      String           @unique
  phone                      String?
  role                       Role             @default(USER)
  eventRegistrationCompleted Boolean          @default(false)
  communityEvents            CommunityEvent[]
}

model EventType {
  id          String           @id @default(uuid())
  type        String
  description String?
  active      Boolean          @default(false)
  events      CommunityEvent[]
}

// Full template timezone > DateTime implementation
model CommunityEvent {
  eventType             EventType @relation(fields: [typeId], references: [id])
  id                    String    @id @default(uuid())
  typeId                String
  ideaConfirmed         Boolean   @default(false)
  organizerId           String
  organizer             User      @relation(fields: [organizerId], references: [id])
  date                  DateTime
  inPersonEvent         Boolean   @default(false)
  onlineEvent           Boolean   @default(false)
  notes                 String?
  venue                 String?
  venueContactName      String?
  venueContactPhone     String?
  venueContactEmail     String?
  announcementPosted    Boolean   @default(false)
  signUpFormSent        Boolean   @default(false)
  volunteersNeeded      Int
  volunteerRequestsSent Boolean   @default(false)
}

Hence, I would design the modules folder as such:

modules
  - community-event
     - controller.ts
     - router.ts
     - serializer.ts
     - service.ts
     - types.ts
  - event-type
     - controller.ts
     - router.ts
     - serializer.ts
     - service.ts
     - types.ts
  - user
     - (Same as above)
routes.ts
prisma.ts

controller.ts contains controller for each module (same as controllers folder as you suggested), router.ts contains the route specifications. serializer.ts contains serializer for our response (we only have one serializer called default, but we many need more in the future). service.ts contains our actual business logics. types.ts exports needed types since we are using TypeScript. Each module will contain these files + validation folder which @anjolaoluwaakindipe recently created for us.

I'm cool if you aren't happy with this structure. I was given a green-light to organize the backend however I want if I will be the first one to create the API.

[one2code]

@1234tgk I'm ok with splitting it by database model, but I think it's important we get a strong consensus from every contributor on what they would like / wouldn't like, and discuss this in detail, before building out. From my perspective, I have tickets with no information in them, and no prior clarification on what the structure would look like, no discussions on what structure ought to be (no discussions started or discussed). I see a merge out of the blue that defines the structure we are supposed to work with, with no prior communication on the reasoning behind this. This stuff is really important to discuss before-hand, given the recent history of friction in the project due to a lack of communication.

I do not want to see this repeated again, but this is exactly how we repeat history. I appreciate you taking the time to discuss your reasoning, but to me, it is of paramount importance that we have these important discussions in the discussion board before anyone takes the helm. Or at least do it asynchronously, e.g. lay out the structure and reasoning in the discussion board, and then put it up for a review. Just because someone else approved a review, does not make the lack of communication on the reasoning ok. The last time this happened, this project ran head-first into some serious friction that resulted in the loss of members, and the loss of association with the community that this project was founded in. I do not want to repeat history again.

[1234tgk]

@one2code I can see how something being merged so soon after my work was posted can be frustrating. I was given creative freedom from the lead developers to give a head-start on this issue, so everyone has something to work from. I will forward this with the lead developers with this issue.

[0916dhkim]

I thought the backend folder structure looked okay, so I merged the PR after approval. Because refactoring is not a big effort at this point, I'd like to keep moving forward while having an open discussion about the structure.

@one2code I am discussing the folder structure in #107 as well if you are interested.

Also, I think it will be worth it to write down the decisions we make somewhere in the repo.

[one2code]

@0916dhkim I agree with this, perhaps in a Wiki? Or implement decision records? I found out that I will have the weekend off this week, so I can implement some things like templates for issues, pull requests, etc, once we agree on the template. Or I can just pull from my brigade as a base template, and you can let me know if there's anything you would like changed.

[0916dhkim]

Coding style guideline in GitHub wiki sounds good to me 👍

I am satisfied with the quality of PR descriptions so far, so there is no immediate need for the PR template.