Ahad L. Amdani


7,220 Experience
72 Lessons Completed
0 Questions Solved


I agree with Chris.

One of the best things you both can focus on right now is determining how to communicate the various contracts between the front-end and the back-end. Even if you go down other routes for the process by which you two divvy up or pair up on work going forward, nailing this communication piece down right now is the right approach and works across all of those work routes. You want to at the very least define, between the front-end and the back-end, the following things:

  1. What the endpoint url/schema will look like for each piece of server-side functionality you need - /api/resourceName/{:id}/{action} for example
  2. What the data is going to look like - the JSON contract, for example, like { id: 1, name: "Mike Wazouski", email: "[email protected]" },
  3. What types of requests/responses you're going to want to handle - for example, if the front-end doesn't pass in the email on a particular request, but does pass in the id, what happens? or if the back-end has an internal server error, or doesn't find the resource, how does the front-end handle a 500 or a 404, and what do you display to the user in those exceptional cases versus your happy path? What happens if it's an unauthorized request because of a session timeout, and you send back a 401?

At some point, eventually, you'll both want to be exposed to the opposite side of the stack, so you can become more familiar with the type of work, effort of work, gotchas and significant things to note/remember as you work on your primary role. It's very hard to be truly full-stack as a developer, at least from a depth perspective, but you can get very hands-on and conceptually grasp a lot of the aspects from the front to the back, in terms of breadth, and that almost always helps you both, moving forward. I recommend keeping to your current roles so you can continue to move efficiently, but to (over time) take on items that are normally for the opposing role, and assist each other or pair up on those items, until you're both comfortable handling them (even if not efficiently) solo. Then, swap roles for a sprint or two, see how that goes. If nothing else, it will help both of you become familiar with the ecosystem of tools that the other person has to work with, generally.

Posted in Dependency Inversion Principle Discussion

I want to see more of this kind of stuff. I've now let you know in the comments below the video. :-)
logo Created with Sketch.

Ruby on Rails tutorials, guides, and screencasts for web developers learning Ruby, Rails, Javascript, Turbolinks, Stimulus.js, Vue.js, and more. Icons by Icons8

© 2020 GoRails, LLC. All rights reserved.