Planning your Rails backend now, can save you hours of headaches in the future.

As I enter the final week of my phase 4 project week at Flatiron school, I cannot help but think about all the challenges faced during the development of the blogging application project I just completed. One particular challenge I faced was having to refactor a lot of the code on the font end due to last minute changes to the code on my backend Rails API. In hindsight, knowing exactly what json data I needed to render to my React front-end ahead of time, would have saved me hours of trouble shooting errors. And the only way to accomplish this is through proper planning ahead of time.

First thing you need ask yourself is this… “What do I want my user’s experience to be?” This needs to be planned out ahead of time. Some of the tools you can use to plan your user experiences are as simple as a note-book, post-it-notes or a white board. If you really want to plan everything in a neat organized fashion, you can use online programs such as “Figma” or “GitMind”. They offer easy to use tools to help organize and plan any ideas you have through the use of flow charts and almost anything you can imagine.

You should plan every single aspect of how your application will run on the front end. From the first page the user sees, to how they sign up and login, what features and information that users and non-users will need to have access to. I want to stress the part of “what information your users will need to have access to”. This is key in planning your backend, and must be implemented early to save you from having to refactor code later and avoid major headaches.

For instance, let’s say you have have a blogging application like the one I developed for my phase 4 project. In the initial design and implementation, I did not think far enough ahead when designing my Rails back end posts_controller. As the project started to mature, I though to myself, “users need to see who was the original poster of a particular blog is”. So when making a blog post, the backend will also needed to send not only the post object to the front end, but also the user who made the post. (see image below for example).

Originally the object rendered to the front end was just a post with a title and content. I did not have username included like you see above. So I needed to code the backend post_controller to include the user who created the post. The object shown above is rendered from my Rails posts_controller.rb. By simply setting the model relationships (User has_many :posts), (Post belongs_to :user) we are able to return the “user” information with each post. Now when a post is made we can include the user object with each post to be displayed on the screen.

Notice below, how we simply include: [‘user’] in the json being rendered to the frontend.

This all sounds pretty straight forward if you’ve coded several projects. But let’s say for instance you had your React front-end already coded and running without any errors and you decided to implement a change to your backend post_controller to now include users. Your frontend would probably break in several different components. You would then have to follow the flow of information one by one until you hopefully solved the problem. Depending on how complex your app is, you could be spending a long time fixing a broken application. A problem which could have been prevented with proper planning before coding your application!!!

So how do you plan a project? My first tip is to just start writing stuff down. If you’re visual like me, as soon as you begin writing down ideas and making changes you will begin to visualize the process. My number one tip that I used while at Flatiron school is to just simply create a “USER_STORIES” file in the root directory of your application in VS Code.

In that file you can begin planning your application by writing down your ideas (even if they are not the best ideas, just begin writing…you can make changes later).

1. Figure out what kind of app you want to make.
2. Figure out what models you need for that app and what their relationships would look like.
3. Plan out what kind of tables each model will need to have in order to work the way you want your application to work.
4. Begin writing down what your user stories (what you want the user to experience) when they visit your site.
5. Once you have some basic ideas you can play around with it and tweak those ideas before moving them to a more robust platform like Figma or GitMind.

Below is an example of what is in my USER_STORIES file inside of my actual blog application. This is the initial planning stages you should implement with each project. Then begin changing the plan little by little as you flesh out the details of your project. Then take your ideas to Figma or GitMind and begin adding and adjusting until your sure you have almost everything planned out. Of course things change and that is just part of coding. But hopefully you better plan your next project with the tools and information provided here.

It is my hope that through proper planning, you can avoid making same mistakes I did while developing my first full-stack application. And if you don’t, that is okay. As humans we all learn through mistakes. We will continue to make mistakes and learn from them. But if there is one thing you get from this blog post sincerely hope that it is the planning phase of your project. Utilize the tools recommended above to help visualize your project. Not only for you but if you’re working with a team and need to get an idea across to the team, having visual aids to help relay your idea across to everyone will be a great tool to have in your arsenal.