Magic with Strapi and GraphQL in the feature request system in GSOC’20

It is a dream come true situation when you get exactly what you want, neither more nor less. This also gives a sense of satisfaction and fulfillment. You already know what I am talking about. If you feel lost by now then either you are not a GraphQL fan or you are not aware of real magic. Follow along to catch a glimpse of GraphQL in action with Strapi.

What did I do this week?

Users can register, login and logout from the feature request system by now. Some forget passwords really quick. I have got you covered. You can now reset passwords with a click. Now users would like to move on to ask for a new feature they really want to see. This demands an engaging interface where we can really engage users to fill in their needs.

We are almost there. I completed client side implementation of the new request components along with Devesh (my awesome gsoc partner). My Strapi server includes a field for description of the feature requests which has a type of rich text. Here is where I thought of using the same rich text editor React component which is used by Strapi.

Strapi internally builds on top of Draft.js , an open source rich text editor framework for React . This gives birth to the Wysiwyg component (what you see is what you get). I could not reuse the exact same component as we wanted to allow for least text editing features to maintain consistency while displaying the requests and eliminating unnecessary pre-processing. I ended up using the ckeditor API to come up with a custom editor which fulfills all our needs and use cases and provides basic formatting features as well.

Next was my brief encounter with a beast, GraphQL. APIs generated with Strapi are, by default, REST APIs. The idea with the famous GraphQL plugin was to add a new layer to easily request the API using GraphQL, without breaking the existing endpoints. I had to fetch various feature request category names from my Strapi GraphQL server to fill the drop down in the UI with the available category values. GraphQL allows us to fetch exactly what we need with queries. I used Introspection feature of GraphQL here to examine one specific type.

The last thing was to implement a drag and drop component which can show a preview of the image files added without interacting with the server. I will explain the implementation in detail in my next blog post in this series.

What is coming up next?

I will complete the logic to connect the new feature requests page to our server so that it can be pushed to our staging environment.

I will also try to come up with implementation to display all the feature requests on the client side after fetching some specific fields using GraphQL from our server.

Did I get stuck anywhere?

I am quite new to GraphQL so I faced some problems while trying to fetch data from the server. The concepts and syntax are really new to me but I will be good soon after I complete some reading and self study. I experimented with the playground to come up with the type introspection to solve it.

I was also stuck when I tried to display previews of images which were being added via the drag and drop interface. However, it was a minor problem with my JavaScript function and I could solve it quickly.

This ended the week with some really nice news for me on the professional front. I will share it soon in my next blog. Stay tuned as I come up with some exciting features involving extensive use of GraphQL queries and mutations.