Cyberbug — Bringing it all Together
It all comes down to this, the final hurdle of my journey through the Flatiron School Software Engineering program. Time to put the mountains of knowledge together in one final showcase project. I am excited to present my favorite project to date, Cyberbug. This is a fully functional app to help track and manage software bugs during any stage of a piece of software’s lifecycle.
Cyberbug is a full stack application, primarily based on the React.js frontend and Ruby on Rails backend acting as an API.
The frontend includes Redux for state management, Thunk middleware to handle asynchronous data requests with the backend, limited use of the Bootstrap UI framework, Google Charts for dashboard presentation, and for fun, a connection to an external API to provide motivational quotes.
The backend, based on Ruby on Rails, uses Active Record association between models and database. During development the app used a Sqlite3 database as it was simple and portable, moving forward, once hosted and in production will incorporate a Mongo DB database structure.
The Good:
One of my greatest takeaways from this project was how to incorporate React Components to create a fully functioning app. Creating singular components was straightforward, but the challenge came when dealing with the full CRUD data lifecycle, handling routing while maintaining a Single Page App, and handling user authentication and login. The organization of the component tree was crucial to achieve the desired behavior, to have certain components mount and unmount as required when changing pages and routes.
Aside from the functionality of the software, I really enjoyed the theme of the project and went full tilt with the ‘cyberpunk’ theme. This was a very challenging style and really pushed my understanding of CSS and html, working with frameworks such as Bootstrap, and incorporating all of these within React components.
I challenged myself to create most of the CSS styling from scratch and not exclusively rely on a framework such as Bootstrap or Material UI. I used a couple Bootstrap elements for progress bars and overrode the styling to make them fit my needs, other than that the CSS was fully developed from scratch.
My goal was to create a fun and unique style while still allowing for easy at-a-glance use with careful contrasting color choice that is also not overpowering. The visual flow of the app pages present info from broad on the left, and more detailed information as the eye moves to the right. This helps create an intuitive user experience and minimizes ‘hunting’ for buttons or info.
The Challenges:
My greatest challenge faced on this project was handling the flow of data between frontend state managed with Redux and syncing it with data stored on the Rails backend. It was important to ensure that data was not mutated by the frontend without a corresponding successful fetch response from the API.
When a user submits a form to either create or edit a project or bug, a dispatch action is called for the corresponding action. This action will first, initiate a fetch request to the API with the relevant GET, POST, PATCH, or DELETE method and appropriate headers, then the Rails backend will process the request, make the changes requested to the database, and return a JSON object with new or updated data. Once this response is received back at the fetch action, only then will the Redux Reducer be called to update the state and process the changes, displaying them to the use.
With this data flow, if an error occurs on the backend API, no State changes will be made and an error message will be presented, the user can then try to submit again with correct data or refresh the page and start over with clean data from the API.
My biggest headache and most common error I encountered during development was handling presentation components in the short time between starting a fetch request and receiving the response and updating the global state. Due to the nature of asynchronous functions, there is time when the components are looking for data stored in state that doesn’t exist yet while the app is loading. To combat this error, I created a filter that would only load data if the required key existed in State. If the data didn’t exist yet, the component would simply show ‘Loading’ and then grab the data once the state updates and triggers a render.
Throughout the development of this project, I continuously reminded myself to design the app with best practices in mind, including keeping things DRY, allowing for potential future scaling, etc. I build components to the best of my ability to be as pure and modular as possible, towards the end of the project I looked back and saw my Redux store connections repeating many, many times throughout components, and took the time to refactor and move the connect function to higher level components and pass down the data as props, as the majority of components used identical data from the store. This greatly simplified the data structure and improved the modularity.
Conclusion:
Overall, I am very proud of this project, I learned an immense amount throughout. This project help bring together many of the separate pieces we have learned over the program and really experiment with how the full stack works together using the same technology and many of the ‘real’ apps out there. I enjoyed working with the fun theme and wanted to take advantage of full design control before cracking into my first software development job.
Nearing the completion of this project, everything started to really click and was one of the first times I could confidently believe that I can pass as a software engineer. With imposter syndrome affecting a large portion of the software engineering world, especially bootcamp students, this was a huge relief and gave me a surge of excitement looking at the world of opportunities with my new skills.
On to the next adventure!