Hello everyone! Come join me to catch a glimpse of how things work under the hood in the EOS feature request system. You can enjoy the magic which happens behind the scenes to hold back our pleasing and engaging UI, a fit for all devices.
What did I do this week?
This week my focus was to implement a main part of the server side so that I have with me the API endpoints to interact with our applications data via the user interface.
This includes working on a famous Node.js based open source headless CMS called Strapi. The best thing I learnt about Strapi is that I can customize it and add my own logic according to the needs of my application. Strapi internally uses Koa.js, a new web framework designed by the team behind Express, which aims to be a smaller, more expressive, and more robust foundation for web applications and APIs.
I built a new content type for our feature request system. A content type is the schema of the data structure. I added suitable fields to it after some discussion about the design of our application with our mentors.
I later added another new content type on the server side for the feature requests status labels. This allows admins to create custom status labels according to their organization workflow. These have a relation with the feature requests just like a user so that we can select a status while creating a feature request.
I also came up with a custom solution for user authentication but updated it later as it did not fulfill all user cases. I customized the JWT authentication by storing it in a httpOnly cookie as discussed with my mentors earlier. This included some custom code in Koa.js to override the default behaviour of Strapi.
What is coming up next?
I will work on adding various OAuth and OAuth2 providers to enable authentication in our application. Strapi supports all major providers like Github, Facebook, Twitter and Google.
Further I will also connect the remaining login and forgot password UI to my authentication logic.
Did I get stuck anywhere?
Strapi internally uses JWT for user authentication. It returns the JWT along with the user information when the user registers or logs in. I had to customize the users-permissions plugin using the extension mechanism in Strapi .
This ensures that our front end application does not have to store sensitive data such as JWT in client side local, session or cookie storage for future authenticated requests.
I am familiar with Express and after learning basic Koa syntax I was good to go. I was then able to write some custom code in Koa to override the default behaviour of the plugin.
This closed the week and helped me learn a lot about how Strapi works internally. Stay tuned for my next blog where I will explain in detail about how I implemented a custom and secure authentication with React on the client side.