This time I let the title reveal the much awaited features that are up and running by the time you read this. I am really excited to experience that adrenaline rush when I get a chance to vote in the real elections and choose our leaders of tomorrow. For now I can fulfill my desire by contributing in selecting the best and most wanted user story of the season. Follow me to understand how I solved the mystery of votes and relations.

What did I do this week?

Recall that complex bug where Strapi could not find the schema for our user story model and kept flashing that weird error on my terminal despite repeated attempts. This time I dived deep inside to catch a glimpse of the internals of Strapi and finally solve that.

The fields of the newly established relations in the user story model were overlapping with each other because Strapi does not drop or migrate the database when a model is deleted or updated. They do so because users may start their application with a production database and a model name may not match with one of the tables in the database. Crash! :/ This is a work in progress and Strapi is improving it. I solved it by choosing a different one sided relation type of one-to-many and renamed it to followers.

Now I added client side logic for the voting system so that a user cannot vote more than once. Clicking on the like button for the second time removes the vote of the user and so on. Pushing all this to production gave me a sigh of relief. :)

After a deep breath I moved on to allow users to leave their valuable feedback and suggestions on user stories. Yes, comments. This way we can take into account the views of more users and design our next awesome feature accordingly.

Now it was time to step up the security as a lot of functionality was already in place. I wrote a custom controller in Koa which checks that the localStorage id matches with the id of the authenticated user and if the same user is the author of the story they are viewing. A positive response will allow the user to edit their story. I also modified the controller which creates a new story and now it can automatically assign the authenticated user to be the author of the story.

What is coming up next?

I will work on the notification system. It would be great to have three types of notifications — in app, push and email notifications.

These will notify the user story author and followers that their user story has been launched. Only organization admins can update the status of a story from the Strapi panel.

If time permits I will try to setup Cypress for testing our application.

Did I get stuck anywhere?

The React implementation to allow one time voting for each user was a bit tricky as there are a lot of state variables on our story page. However, I solved this by catching the previous state value by applying functional updates in my useState hooks to overcome the stale state problem which arises due to closures in React.

Writing controllers for my server in Koa was also new but I was able to learn the basics quickly as it is similar to Express.

This ended the week on a sweet note. Stay tuned and get ready to receive another set of notifications on your device. Do not worry. We will not throw those sales ads on you again. This time it will be about the launch of your own story. :P

The world is full of relationships. Everything around us is connected to each other in some way or the other. Sometimes relations can be hard to figure out. Join me as I help you create a unique relation with our user story system and some of its brand new features.

What did I do this week?

This week started with full action and thrill as usual and we decided to modify our models to align with our product name. This means all existing models had to be renamed according to the user story theme on the server side. A rename operation seemed like a small and simple task but I soon realized that Strapi does not update the GraphQL schema if we rename a model. This is because existing tables are not deleted or dropped from our MongoDB database and instead new ones are created. This started breaking everything on the server side.

I rolled back and created new models for user story system and imported all data from our staging database. This time the shadow CRUD functionality generated a perfect new schema for my use case. Server was good to go.

The schema changed so the next task was to change all GraphQL queries and mutations on the client side and align them with the new user story models. The docs for the schema helped me to complete this with ease.

Next I created a new model for all the products at EOS and related it to the user story system model. This allows users to filter stories according to the product and enhances user experience by allowing them to navigate faster among hundreds of user stories. I worked on the filter feature on the client side to fetch all products and filter them according to their status and product selected by the user via a drop down.

I eagerly wanted to allow users to respond to some amazing user stories so I moved on to implement the voting feature. This allowed users to vote for any user story to express their interest. Wait. It just sounds easy but some major problems and bugs were waiting for me at the end of the week before I could push the voting system to production.

MissingSchemaError: Schema hasn’t been registered for model “user-story”

My terminal kept flashing this message as I tried to figure out the problem in my new user story vote models and relations. It is still a mystery though because the same relations work fine with my comments model. I told you relationships can be hard sometimes. :/

What is coming up next?

I will work on the voting system for user stories. This involves establishing proper relations between the user story and user models. The mystery will be solved soon.

Further I would try to think of a nice implementation for the user notification system to tell users that their wait for the next awesome feature is over. This would be implemented later this week. Users really want to make comments so lets give them that privilege first.

Did I get stuck anywhere?

MongoDB relationships represent how various documents are logically related to each other. I faced a weird problem when I was establishing a one-to-many relation between my user story vote, users and user story models. MongoDB could not identify the schema for my user story model for some reason and kept throwing an error. The bug came to us at the end of the week and I am still trying to solve the mystery with my mentors. Moving forward we created a map of all our relations to get a nice picture of all relationships and find the conflicts and resolve them.

This ended the week with lots of rain which gave me some relief from the scorching heat. Stay tuned as I solve the mystery behind relationships and add new path breaking features to the user story system. The adventure is yet to begin. :)

Sometimes we are not able to express all our thoughts and ideas in one go. A great idea may strike later or you may want to comment and give some suggestions and feedback to stories of other users. Come explore with me some exciting features that I added to our feature request system using Strapi , GraphQL and React this week.

What did I do this week?

A strange bug starts the week with some thrill and action. Our whole application breaks when a user logs in to the system and submits a new user story. Crash!

We were checking and dividing our user stories on our client side according to their current status. No status gets assigned by default to a new user story as that is an admin or root level permission feature. In Strapi I cannot assign a default status to a relation type field because relations between models can be of various types. I solved the bug on the client side by assigning every new user story a status of “Under Consideration” in my GraphQL mutation.

A user may want to check out their own stories at some point of time so I implemented a GraphQL query to fetch all user stories based on their user id. Users need to be authenticated to access their own stories. They can check their stories for status updates, votes, likes and comments from other users.

The next was the most awaited feature of allowing our beloved users to edit their own user stories. However, they cannot change the already added description. Content can just be added to the existing information. This is just to avoid trolls. :P

What is coming up next?

This week I will create a product model so that we can relate all our products at EOS Design System with a separate user story system. Users can filter their stories for different products.

I am also working on user comments system so that we can display all comments properly and further allow users to add more comments.

Did I get stuck anywhere?

Development without getting stuck is no fun. We learn fast from our mistakes. Initially I was happy to complete the edit story functionality and it worked well. Then my mentors could hack into the system easily. Security compromised. :P

They could edit stories of other users as well after writing into the famous localStorage . I solved the bug easily by implementing a function to verify and allow editing only if the user is the owner of the story.

This ended the week on a sweet note with quite some features added. Stay tuned for more fun and action. :)

You definitely received exactly what you wanted and you enjoyed using it. Now you just want to know how this actually works under the hood. Is it real magic? Did god just shaped it according to your needs and sent it down from heaven? Come with me and I’ll answer all your GraphQL queries.

What did I do this week?

It took me some time to realize that GraphQL is not another programming language. It is a specification or a technical standard. This mean it can have several implementations and variations. GraphQL.js is the JavaScript reference implementation. Legends like Strapi implemented a fully customizable GraphQL plugin which creates a new endpoint /graphql and the GraphiQL interface. The plugin adds a new layer to easily request the API using GraphQL, without breaking the existing endpoints.

GraphQL secures all queries by default and the plugin plays well with the users and permissions plugin. When we are making a query with GraphQL we are hitting the same controller’s actions as we were doing with the REST endpoints.

I utilized the introspection system of GraphQL to fetch all categories available to our user while making a new story.

I also used a mutation to create a new user story which takes in all data entered by the user as parameter. I pass all my GraphQL queries through a set of custom policies before they hit my custom authentication controllers in the customized Strapi back end. This completed the feature to create a new user story.

On the server side I created a new model for the comments on the stories which contains 3 fields. The first is a rich text field to write the comment and the remaining two are relation fields with user and feature requests models. This means I also had to add a relation field to the feature request model to connect it with my comments model.

The next big feature of the week was to add functionality to display all stories on the home page according to their current status. The shadow CRUD feature of Strapi GraphQL plugin automatically generates the type definition, queries, mutations and resolvers based on our models. The feature also lets us make complex query with many arguments such as limit, sort, start and where. This helped me to implement a GraphQL query to fetch the required details of all user stories and sort them according to the highest number of votes and most recently created stories. I used the query response to display the title, description and the no. of votes and comments for all stories on the home page.

All these features for the week helped me to catch up with GraphQL really fast. It was completely new to me and I was feeling stuck just a week before. Now by the end of the week I am happy that I am able to understand how it works so efficiently deep down the layers.

What is coming up next?

I will work on displaying all information about each user story on a separate page. This requires a query to fetch all story details by the story id. The date of publishing and author details will be available on this page as well.

The system needs an edit feature which may allow our beloved users to add information to their story. They will not be allowed to edit the existing description though.

Did I get stuck anywhere?

Sometimes rare bugs can be difficult to catch and you may feel stuck while trying to solve them. This week I came across something strange.

All my code and functionality was running successfully on my development environment. After getting merged, the Gitlab CI deployed it to our staging servers and the whole application crashed, both the client and server side.

I finally solved all bugs and got to learn that Strapi stores all the roles and permissions that we assign to our users in the database. In this case our development and staging servers are using different database. Simple :)

We just exported all our models data from the testing database to the one used by our staging server.

Another bug was to specify the exact cors origin which can access our server as I used withCredentials : true in my Axios configuration to store the cookies in the browser and send them back in future requests.

This ended the week with the first evaluations in which I received an awesome feedback from my mentors and passed with flying colors. I thanked them for all their support and guidance. Looking forward to a great journey ahead :)

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.