bitbucket.org/martinbockt/xu-student-manager-api

XU Student Manager

Members

• Sebastian Müller
• Martin Bock

Ideas

• Attendance
  • Management by lecturer
  • Overview for students
• Grades
  • Management by lecturer and exam office
  • Overview + download for students
• Forms
  • Sickness
  • Semester abroad
  • Examinations sign-up (retakes)
• Courses/Modules
  • Own site for each course
  • Course representation
  • Course materials
  • Final delivery section / overview
• Documents
  • Overview
  • Labeling
  • Search

Instructions on How to Run the Application Locally

• Find an exec file api in the root folder.
• Start it with the provided run-api.sh script.
• In case it doesn't work, you need to install Go and run the run-go-api.sh script.

Include a Postman Collection or Similar to Test the API Endpoints

• Enter the URL of the API into Podman, selecting GraphQL.
• Introspection is activated, so all the endpoints will be listed automatically.

Details of the Deployment Process for the Chosen Platform

• The Database (SurrealDB) is deployed on Fly.io:
  • Create an account.
  • Install Fly.io CLI.
  • Create a project consisting of a Dockerfile loading the DB image and a fly.toml file consisting of the Fly.io settings.
  • Now, you only need to run deploy.
  • Follow a more extended tutorial: Deploy SurrealDB on Fly.io.
  • Costs: $2/month.
• The Golang API is deployed to Render:
  • https://xu-student-manager-api.onrender.com // The first request can take up to 50 seconds, as we use the free service that shuts down the services after inactivity.
  • Create an account.
  • Select New Webservice.
  • Connect it to your git repository.
  • Select Go Project, provide secrets, and the build command.

A Brief Discussion on How the API Gateway Was Configured

• The GraphQL API consists of 3 Layers:
  • GraphQL Definitions
  • Authorization
  • DB Models
• GraphQL:
  • Since GraphQL runs over HTTP, we set up an HTTP server with simple settings that implement GraphQL, as you can see in the cmd/api/api.go file.
  • All the GraphQL types are defined in the internal/graphql/models folder.
  • We used the simplest implementation possible, so at the moment it's more like REST as we didn't implement Nodes and Edges. We did so due to time limitations and since it's not needed for a platform of this size.
• Auth:
  • At the moment, the Authorization part may look a bit like a redundant mapping, but we decided not to implement it for this assignment and start with it during the frontend development instead.
  • The Auth consists of two parts:
    • Authentication:
      • You can find the middleware in internal/service/identity/service.go.
      • It's currently not connected due to testing purposes.
      • If connected, it takes the provided Authorization Header, retrieves the user from Appwrite, and writes it to the context.
    • Authorization (Not implemented yet):
      • In the internal/student and internal/module folders, you find an authorization.go file.
      • It basically connects GraphQL to the Database. For the Authorization, we need to add the context to each function, retrieve the user of the request, and check if the team he is part of is allowed to do the request.
      • To do so, we will need to expand those files with several additional DB checks and not just a forwarding from GraphQL to DB.
• SurrealDB:
  • We decided to use SurrealDB over PostgreSQL since SurrealDB's structure is simpler and uses more advanced features built into Fields and entities. For bigger projects, it's probably still better to use joins, but with a platform of 10-20 Tables, SurrealDB simplifies Mapping Tables, Joins, etc.
  • All our queries are either done through the prebuilt surrealdb package ones, or we wrote them ourselves. You can find the self-written ones in the internal/module/internal/model/surql and internal/student/internal/model/surql folders.
  • The queries consist of surrealQL and the Golang Template syntax that allows us to add filters conditionally. SQL injections are not possible since we don't use it to assign values.

Make Sure All Endpoints Work

• All Endpoints are working as expected.
• On some Update endpoints, you don't receive the fully updated entity, so a few fields are empty. That is expected.