Like Tinder for finding jobs. If seeker matches with employer, a connection is made and they can message one another.
Seekers and employers can spend credits to do a super app, which appears as though they had matched with only one party taking action
Job Seekers
Employers
Stretch Goals
Clone repo
Create .env file withe following content
DEBUG=True
SECRET_KEY=NOTSOSECRETANYMORE
ALLOWED_HOSTS=localhost,127.0.0.1
DATABASE_URL=sqlite:///db.sqlite3Install virtual environment and packages using Pipenv
pipenv installActivate virtual environment
pipenv shellApply migrations
pyton manage.py migrateStart Django server
pyton manage.py runserverWe are using React as our frontend framework. Due to the various components that could be re-used, we chose React.
Our major frontend libraries include:
We have a re-usable component for our cards. Since there are many cards rendering on various pages, we created a single card that can be extended to most other pages.
As we all know, we’re using Django and DRF for our backend. Django is a framework for web dev applications and DRF is library for creating API.
Given that there were no requirements for dynamic data, we decided that a relational database would suffice. Postgres was a relational DB and also had the Array Field type that we thought could be useful for our Skills field. Django offered a robust ORM for Postgres
Creating multiple user: https://simpleisbetterthancomplex.com/tutorial/2018/01/18/how-to-implement-multiple-user-types-with-django.html
Having independent tables and having relations seems like a better fit
In our Django project we have one project called Job Matcher. Within this project we have a few apps:
Ideally, each app could allow for various people to work on various parts of a project without stepping on each other’s toes.
Each app is made up the following files (migration is the only folder)
Models seem like the place to start (for me). It’s where you define your tables. Each row in the table is known as an instance. This word is used throughout the Django and DRF documentation
Once your models are defined, you would run makemigrations to make the migration files. The migration files are the actual commands to create the schema of the table or model. Running migrate applies those migrations to the Model.
Now that the models are in place, we can start to look at the request and responses from the client (frontend).
This diagram is ugly.. But we’ll try and walk though it step by step:
https://docs.google.com/drawings/d/1Gq-G-UGtOmksNQebtll3BKxUdzQ9lPGQb9A_zdzXDiQ/edit
Everything starts with a request from the client. We know that we have authentication. This was provided by a 3rd part library for OAuth, specifically OAuth2 provider
Normally this authentication is set in the settings.py file. We have two settings there:
The authentication handles the initial authentication and the permissions handles all subsequent requests. We know that we sign_up wont have authentication as its set up after this call.
This call returns a Bearer token and this token is placed in all future calls.
DRF give us access to request.user and request.data. These two are used throughout the request’s lifetime.
The viewSets are the things that handle the requests/responses. They take in requests and respond with responses.
The serializer offer us a way to create/update/validate data into the database. There are 3 types of serializers we used in the project:
There are two main methods in the serializer. Update and Create. When getting a request from the client, we may have to update data or create data.
The instance is just a fancy word for row in the table:
Create instance using serializer:
Updating instance using ser;
Representing an instance/queryset using ser:
Representation is the opposite of the instance. The representation is the JSON format that is needed to send back to the client.
We have been able to integrate the Mailgun for our 3rd party Email service.
We have a fully documented API using the Swagger docs. https://stage.api.seekgeek.app/docs/
This documentation allows the user to see all endpoints and what is required on the endpoints.
We currently have continuous integration / continuous development / continuous deployment. I’m not sure the exact differences, but in my mind, we make a change on a branch, it automatically deploys. This IMO is so dope!
When you buy a domain, you tell Netlify and Heroku where you primary domain is. The mapping listed in the second diagram is done in netlify and Heroku respectively.
Sign Up
Sign In
Seek
Matches
Job
Profile
Our application has multiple levels of security