Extract Frontend and API team dev simulation projects

[dearshrewdwit]

https://www.notion.so/boolean/Team-Development-Simulation-73c2a738c9444e3aa0514f2166e9d354

Server app: https://github.com/boolean-uk/team-dev-server/ Client app: https://github.com/boolean-uk/team-dev-client

[dearshrewdwit]

Server app: that is 'complete' Client app: at the starting point

• preparing the task boards
• preparing the live applications (confirm with me for prod auth details)
• integrations with discord
• what anchor skills do we need to prepare cohort (git workflow, environments)

[dearshrewdwit]

Teacher Facing: original brainstorm: https://github.com/orgs/boolean-uk/projects/4/views/1

Student facing: eg: https://github.com/boolean-uk/team-dev-client/projects/1, https://github.com/boolean-uk/team-dev-server/projects/1

Potential Idea: https://github.com/orgs/boolean-uk/projects/6/views/2?layout=board

[glowkeeper]

Using this to save some notes on the stuff I've done so far.

I have stripped back team-dev-client (https://github.com/boolean-uk/team-dev-client) to a point before cohort 5 began sending in PRs - here's the repo: https://github.com/boolean-uk/team-dev-frontend-client - in terms of the codebase, I reckon that's ready to go as a starter for the forthcoming react frontend team dev project (Cohort 7?).

I've also been using the existing team-dev-client as a tool to test drive team-dev-server and see how it behaves (https://github.com/boolean-uk/team-dev-server). My motivation was to see whether it could serve as the backend for the forthcoming react frontend team dev project? My initial thoughts are yes - huzzah! :)

I had to tinker a bit with team-dev-client to test drive prohibited 'TEACHER' routes. On elephant SQL, I had to run:

update "prisma"."User"
set role='TEACHER'
where id=1

And on the client, I had to add the line loggedInUser.role = 'TEACHER' in the App component - that is probably unnecessary if you create a TEACHER user on Elephant SQL first, but hey ho, I know that now :)

The next steps are to deploy stuff to production servers and start documenting things, like the server's API etc...

[glowkeeper]

https://github.com/boolean-uk/team-dev-server deploys to https://team-dev-frontend-server.herokuapp.com

https://github.com/boolean-uk/team-dev-frontend-client deploys to AWS Amplify at https://main.d3auuogvq1hhel.amplifyapp.com/ (I've updated the README with those details

So they're ready to go :)

[glowkeeper]

I've created the discord webhook for https://github.com/boolean-uk/team-dev-frontend-client

Can't yet create a project board for that repo - I think that's because it's a fork, so I've asked GitHub to detach it - I'll checkin again tomorrow to see if they've done that - if not, I'll just create a fresh repo...

[glowkeeper]

I've created some issues for the frontend client, here: https://github.com/orgs/boolean-uk/projects/6/views/1

While creating those issues, it became apparent that I wasn't clear on the intention behind some of the routes on the server - e.g. it has routes for /conversations and /posts - what's the difference between those? And even /messages - is that intended to be a DM thing (the code suggests not, but that would make sense to me)? We may need to reconcile/simplify that stuff...

[glowkeeper]

The heroku backend is at https://team-dev-frontend-server.herokuapp.com/. That interfaces with the following postgres instances on elephantsql:

postgres://naputmat:fD2RJtSgBhXF09RnpgpitLBPkIGanQXI@lucky.db.elephantsql.com/naputmat?schema=prisma
postgres://nmfhddot:HZQoDHDVQ6gq2QvZbzvbhscvu4mPM9Ek@lucky.db.elephantsql.com/nmfhddot?schema=shadow

[glowkeeper]

I'm going to use this space to log some issues I'm aware of from the team dev frontend simulation we've just run...

Currently, the backend (team-dev-frontend-server) does not respond in a standard manner - errors are returned in many different formats, and successful data is returned as single objects with different keys, some as an array etc. It would greatly simplify coding the client if the server's response was the same, no matter what. Maybe something like this: https://jsonapi.org/, or this: https://google.github.io/styleguide/jsoncstyleguide.xml

[vherus]

Just sticking a note in here RE response standards. The server uses the JSend response specification: https://github.com/omniti-labs/jsend

It looks like there are some student contributions from previous simulations, so it's diverged a bit. E.g. this line: return sendDataResponse(res, 201, { deliveryLog })

Should really be return sendDataResponse(res, 201, { ...deliveryLog })

[glowkeeper]

Just sticking a note in here RE response standards. The server uses the JSend response specification: https://github.com/omniti-labs/jsend

It looks like there are some student contributions from previous simulations, so it's diverged a bit. E.g. this line: return sendDataResponse(res, 201, { deliveryLog })

Should really be return sendDataResponse(res, 201, { ...deliveryLog })

Excellent that it uses a standard - that was hard to see because it defo diverges :(

[glowkeeper]

The API docs are heading in the right direction, but there is still some work to do to ensure all the docs are correct. Furthermore, the openapi yaml could probably be significantly simplified...

[glowkeeper]

ps. I created a couple of tags for team-dev-frontend-client:

v0.1.0 is the commit BEFORE Cohort 7 started working on the frontend Cohort-7-Complete is where Cohort 7 finished...

[glowkeeper]

I tried to add some info to help get the cohort started - i.e. the README on team-dev-frontend-server now includes the database ERD, and team-dev-frontend-client describes learning objectives. However, I reckon some intro blurb describing the initial requirements would be a great help, i.e.

You are a small team working for a teaching startup that needs an application for managing its day-to-day activities...

etc....

[glowkeeper]

The team-dev-frontend-client tagged at v0.1.0 (the starting point for cohorts) might want someone to go through it all.

There are no massive issues, but the API now returns data in camelCase, whereas some of the code in the client is expecting snake_case. And there are a few instances of Material UI - maybe they should be removed (since we don't teach it)? Should all the CSS be in a single styles directory? Rather than .js, maybe .jsx for components that return JSX?

etc. i.e. maybe we should ensure that the codebase we give out is better? Or, we tell the story that it's not perfect, and it's your job to improve it?

[glowkeeper]

I've added a seed.js to populate the database, but this could be improved ;)

[glowkeeper]

team-dev-frontend-server is much improved from where it was (see the many commits made over the past couple of weeks ;) ), but it's still deficient in that it doesn't support all of what's possible within the database. For example:

1. I don't think the conversation API endpoint is quite correct, so users can't send messages to one another
2. The Course->Module->Unit tables are unsupported - you can get courses, but since the seed doesn't contain any course data...