Developing ScholarX backend

Development ScholarX
1

This thread is to be used for scholarX backend development discussions.

Github repository for backend:

2

I’m working on “Adding JPA annotations to generate mysql tables”.

Issue: https://github.com/sef-global/scholarx/issues/15

Deadline: 2020-08-19T18:29:00Z

3

Hi @piumal1999 Thanks for working on the feature :heart_eyes: .Can you please create an issue for this.

1 Like
4

Added the PR. Please review and merge

1 Like
5

I am working on Admin APIs of ScholarX. I have sent a draft pull request for following tasks.

  • An endpoint to delete a mentee
  • An endpoint to get a list of mentors in a program
  • An endpoint to get update the state of a mentor

I’m not sure whether this is the most suitable way to complete the issue.
@YohanAvishke could you please check it and let me know.

2 Likes
6

Please review and merge

1 Like
7

I have checked it using Swagger UI. Btw I think we need to disable CSRF to make the APIs functional. @YohanAvishke is it okay if I add the security config file to my PR and disable csrf?

8

Sure @piumal1999, add a file named SecurityConfig in the config directory with the changes.
Make sure to create a different commit without squashing.

1 Like
9

Updated the PR. Please review and merge. https://github.com/sef-global/scholarx/pull/25

1 Like
10

@piumal1999 please add test cases to your PR. You can find examples in the above PR. Please ping me if you need any help.

1 Like
11

Updated the PR with requested changes
Added unit tests for 3 new admin APIs

12

Created issues for common and user APIs

Ps: Created issues for other APIs also

3 Likes
13

Created common APIs and unit test for those.

1 Like
14

Found a bug in this PR. (An infinite loop in GET mentors endpoint)
Fixed the bug with PR#49

Please review and merge

15

Created User APIs. Please review and merge

16

I created the mentor APIs with unit tests
But i couldn’t test the changes with a real database

17

curl --location --request PUT 'program/{programId}/mentees/{menteeId}/status'

In requests similar to above which require programId to identify an element, wouldn’t it be better to add the programId as a query param? Following are some points to support the statement,

  1. Param is an identification parameter, so it’s better to be in the query.
  2. We can simplify the resource paths:
    curl --location --request PUT 'mentees/{menteeId}/status?programId='
  3. This leads to a better and simpler folder structure.

WDYT?

1 Like
18

Yeah. That’s good. So, shall i update the backend?

19

Yeah update your PR with the change also change the directory structure accordingly

1 Like
20

Do we need to add the requested change to the user APIs also?

Pull request for USER API: