How do Rails developers work with JS developers on a project?

Hi there!

I've been the only developer at my workplace for a while now and I've been coding in Rails, primarily. I don't have any formal qualifications in development, but I've been self-learning this stuff online over the last few years (thanks a bunch to Chris and GoRails for all the times I've come here to learn stuff!)

However, about 2 weeks ago, we hired our first JavaScript Developer - something we've been trying to do for a while. The reason we went for a JS developer, was that we needed someone more skilled in front-end development and the guy we hired is just perfect (he works primarily on the front-end and mostly with React).

The problem is, I've never worked with other developers on a project before and have no idea how to structure the work. He, in turn, has never worked with Rails projects before and is very unfamiliar with how he can contribute either. (More than oncewe've discussed moving to a purely JS development environment, but that would take time for me to learn JS better as well).

So, my question is, how do I structure the work flow and how can we work together?

Hey Umar!

I've worked a lot in the past with frontend devs as the only backend developer. For the most part, we split responsibilities such that the frontend dev would tell me what information they needed, and we would figure out the params and response formats for API requests. We'd kind of split it there so the frontend dev could handle all his needs and as the backend dev I'd just be worrying about building the API endpoints for what he needed. Inevitably you start to learn how they're building out the frontend and the frontend dev is learning how the backend works over time.

That worked out quite well for us, but there are also lots of other routes you could go.

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: "mike.wazouski@monsters.inc" },
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.

That was really helpful! Thanks guys!

One follow up question - when you say to sort out the communication between the front end and the back end, do you mean that we will be creating it essentially as 2 separate microservices (so to speak) and that we connect them through API calls?

For example, having worked only with Rails, I create both the front end (i.e. my view files) and the backend (models, controller etc.) in one place - thereby, I don't actually make any API calls to connect the two.
But, if I understand you correctly, you mean that if the front end is being handled by a different system (like React), then it must be connected using APIs?

I think that depends Umar, if you are going the route of just having the front end as a separate application and backend in rails (where you will then have api controllers) or you can mix the two bye using something like https://rubygems.org/gems/react_on_rails to add react components in your rails application (https://cognitiveclass.ai/blog/react-on-rails-tutorial-integrating-react-and-ruby-on-rails/)

From Chris's videos on vue + rails thats how I have done it where as I add a vue component into my rails app.

Umar,

I would say no, you do not not microservices or separate frontend/backends.

You're free to use whatever frontend you want, but in a monolithic app, think of it more like the frontend dev works on the views, css and javascript while you handle more of the controllers and models. You can get everything ready for the frontend dev, setting up forms and instance variables so they can go ahead and work with the data you provided them.

That collaboration can work if you're using a frontend framework too though. You would provide urls for them to retrieve data, but there's no need for that unless you want to.