a RESTful API with CRUD functionality that helps build a simple behavioural recruitment interview template for interviewers or interviewees
The API is designed to be RESTful and is aspirational - that is, I know that it isn't fully REST compliant yet, but it's well on it's way and I intend to learn a lot about REST while doing so.
Accessible here: https://behavioural-recruitment-api.azurewebsites.net/
The API was built first as a node.js/express app that serves content from a backend. I fleshed it out quite a bit to include a client with documentation and a few tools to allow fast/easy testing and demo of some of the API's functions.
Initially the API was hosted on heroku, but had to be migrated to repl.it after the service terms and conditions changed. I'm not currently 100% happy with replit's service as the API goes dormant if not in use and needs to be "woken up" which causes delays. I believed Microsoft Azure may make a better home for it overall and begun migration.
Migration to Azure posed a number of problems, the build and deploy process from github actions to azure web api was fairly complex and making sure that all the jest tests passed before deployment was a key obstacle that needed to be overcome.
Optimizations
I made a number of changes to the API over time, especially in getting it REST compliant. Using https://restfulapi.net/ as a guide.
Initially the interface and query/parameters were a little disjointed and inconsistent. I changed them to be more consistent and to follow a more logical path. Ideally after using the API a few times you should be able to intuit how it will generally behave.
The backend is fully functional and serves content to any requests not just from the provided client. Ultimately I will convert this to be just a backend API with no client functionality beyond detailed documentation explaining how it works so it can fully comply with the client/server model.
The API is already stateless, doesn't require a handshake of any kind and serves content in one step on request. One optimisation here is that I plan to add API keys for "unsafe" changes (e.g. POST, PUT or DELETE requests) currently it's not needed though.
Not currently implemented, but definitely on my wishlist of features to add.
Not currently implemented, but would be good to get this done with some refactoring. Currently the app structure is a little basic and operates only from the server.js file. that said, changing the structure should be quite easy once I decide on an optimal way to do it.
Not really needed for this API since we are only serving text based output.
The first thing I learned was how easy it is to get a simple API up and running, but how difficult it is to have a high quality API.
Setting up the routes was quite easy but then in retrospect and after reviewing the consistency of the routes - I wasn't thinking 100% about how good the user experience would be when I first built it - I was just trying to make it work.
My attention to detail improved a lot after taking a "user-eye view" of the API and documentation, adding in UI optimisations and bug checking every single route possible - after that I added a level of consistency, so after using one part of the API - you could logically figure out how the rest of the API might behave.
The Unit and Integration tests I added to the api forced me to dramatically improve the quality of the code in order to be suitable for deployment to Azure web api. I had to add in a handling system to the server to be able to deal with multiple connections and the JEST tests needed to be more strictly configured to gracefully disconnect mongoose and close down the server in a more elegant way.
One of the routes caused significant problems on deployment (it was pulling every record from the database each time it was called) which led to it being removed since it wasn't long term scaleable.
In the future I want to add more features, security considerations like API keys and to potentially publish it on rapidAPI. With a little structure and consideration the API could be useful in a recruitment context for both interviewers and interviewees.
Take a look at these couple examples that I have in my own portfolio:
-
https://github.com/TheWoodenMan/twm-cpd-log CPDEasy - The work I did on the behavioural recruitment API gave me more confidence in the back-end to build a more complex and ambitious app that handles leadership journal entries.
-
https://github.com/TheWoodenMan/NASA-photo-of-the-day NASA Photo of the Day - Before I built my own API I learned to query the APIs built by others, this simple web app takes a user selected date and returns a range of data and images for you.
make a .env file with the following environment variables:
PORT MONGO_URI
- Randomise a single question ✅
- Pull out a particular question by Id Number ✅
- Add new Questions ✅
- Delete Questions ✅
- Bulk add questions ✅
- Update the leadership values of a specific question
- show all questions with a given leadership value ✅
- Show a selection (10x) questions randomly ✅
- Show a selection (10x) questions randomly based on a leadership value ✅
- Make it look good ✅