Technical architecture choices - backend

[zannis]

Select our datastore Add its dependency on package.json Figure out the main entities Decide on the schemas that these entities are going to have

Check out https://docs.google.com/document/d/1GLzZhdC4OKpwZWtJiuhBEsYBMn6ZDMR2irrgVWtTZtI/edit#heading=h.dsjc9qdzdo47

for further info

[student0b4dc0d3]

I see I should have added a comment here, instead I opened a new issue named "Thoughts on underlying data schema". Can a mod / admin please move this here? ty

[zannis]

Pasting @student0b4dc0d3 's comments here for visibility

Most projects are about collecting and manipulating Information.

Likewise, this project is data-driven, so I took the liberty to note a few thoughts about the underlying data schema.

Based on the initial draft, I discern following distinct data entities

"users" is a collection of information about people. Attributes of this entity may include : id, approval_pending, login_name, password, role, name, title, email, webpage phone, cell, physical_address, gender, birth_date affiliated_org (empty for private mentors), picture, description, etc...

"organizations" is a collection of info about organizations Attributes of this entity may include : id, approval_pending, title, info_email, phone, physical_address main_representative, contact_hours, webpage, picture, ( needs clarification ) documents, ( needs clarification, may produce additional entity ) etc...

"affinities" is a collection of information about areas of expertise an organizarion may strive for or "areas of activity" an organization includes

They are an entty, and not an enumeration, because
they are submitted together with the organization submission
so the org-rep should be provided the means to "create" them

Attributes of this entity may include : id, org_id approval_pending, title, description, webpage, etc...

As you can see, I have purposefully omitted any specifics of an underlying data management system/technology

Since the client has expressed a desire to further develop the project and has stated they "employ" their own dev(s), it should be reasonable to poll the client for any specific preference, which should be our guideline.

I would appreciate your thoughts and feedback. Thank you.

[NickPapacostas]

Assignees:

• Manolis (@student0b4dc0d3 )
• Michalis @ligopsychakis-michalis

[zannis]

Good work @student0b4dc0d3! I am in favor of adopting your proposed structures for our entities with the following considerations:

• Affinities would rather not be an entity, but an enumeration. It's possible values will be 17 hardcoded string values in English, based on the ones described in the smallbuddies.net website. As you mention, they will be selected during profile creation but from a prefilled list with these called. Both the user entity and organization entity will have a property called affinities which will be a list of up to 3 of these values.
• Let's group the user's contact info under an object. Even though minor, it will help to organize info based on what will be requested by the frontend.
• Since there is a high degree of uncertainty regarding the final schema, the NoSQL approach (mongodb) will make our lives much easier since we won't have to enforce any structure. Personally, I am more familiar with the mongodb package for node.js, but since you guys have already investigated mongoose, I am fine with choosing it as our mongodb driver.
• Relations between entities in a NoSQL data store can be tricky. So my recommendation in this area is to reference entities by an object that includes the entity's id as well as all the necessary data that will be required by the frontend. For users->orgs, this means a organization property on the user object, which will be an object containing the org id and the org name. For the reverse relation, we can use the user id, user name and contact details object.
• The app will require file uploads and I would rather have a single data store for all data and files rather than implementing custom functionality to upload images and documents in the filesystem. Even though mongodb is not ideally suited for file uploads, it does support them via a tech called GridFS. So let's use that for our file uploads. This will also keep our deliverables to the minimum, meaning only the git repo and a mongodb dump. Also, file uploads use requests with multipart content type. A nice library that supports this functionality is 'formidable' but I am open to alternatives as well.

With that said, let's continue the discussion to finalize our library choices based on the required functionality and close this ticket by adding the mongoose dependency as well as the necessary dependencies for uploading files.

Feel free to ask anything I might have not covered in this comment.

[student0b4dc0d3]

I have some minor concerns about the affinities being an enumeration array, and would like to elaborate on it : suppose there comes a rep one day, trying to register while representing an NGO with the affinity "Black Lives Matter". Now, since we haven't predicted such an affinity beforehand, they would have to register without it, and then somehow request from the admins to kindly add that affinity and also edit his registration to include it? Imho, this is a very round-about and time-consuming method to solve this. My suggestion would be to have the 17 default affinities in the enum, but also offer a free-edit affinity field. It would not endanger invalid data (such as cursing etc.. ) since all registrations, before opening to the public, have to receive an approval from an admin. I am, as always, happy to converse about any additional thoughts on this or any other matter. T.y.

[zannis]

My suggestion would be to have the 17 default affinities in the enum, but also offer a free-edit affinity field. It would not endanger invalid data (such as cursing etc.. ) since all registrations, before opening to the public, have to receive an approval from an admin. I am, as always, happy to converse about any additional thoughts on this or any other matter. T.y.

Hey @student0b4dc0d3 first of all, thanks for stating your concerns and for the time you put into this. Indeed, looking at this project at a mid/long-term basis, your engineering approach is definitely correct. I would also like affinities to be an entity and to be able to add new ones dynamically etc. However, we have a really specific scope in terms of time and limited resources so that is why I am pushing towards the simplest approach possible. This is why for the time being, I would encourage we stick to the most dumb and straight-forward implementation and iterate over it if and when we are requested to do so. (I wouldn't like to overengineer a graduation project right now). I am sorry if it seems pushy and it might turn out that a more holistic and future-proof approach would be better, but with the current requirement plan we have no indication that it might happen during the timeframe of this project. I hope you understand.

[student0b4dc0d3]

I see the point, and I agree with the simplification. I just needed to voice something that was growing on my mind since day 1 and I was trying to concentrate to put my finger on, until I did. Thanks for the clarification and consideration