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
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
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
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.