Ask HN: How well do your front end and back end teams work together? | Hacker News Reader

Ask HN: How well do your front end and back end teams work together?

3 pointsbryan_cooper5 comments

After working across the stack, it seems to be a rare find when you see front end + back end teams functioning together well. What tools / processes / rules does your company (2+ person eng team) use to communicate between front & back end teams?

View on HN

I'm a BE dev, and I can say (from my perspective) we work really well together. It's a REST system and when a FE needs something me and my fellow BE teammates do all we can to give them that something.

During development they use moc's for the payloads that we're not ready to give them. When we build things FOR them all members are happy.

A good rule is to have the teams come to an agreement on the data that they need to show the user. Then have the BE team build out a rough payload.

Paired programming on features is always good.

Myself personally. I have a simple thing to keep in mind. FE keeps the customer happy, I keep FE happy, ops keeps us all happy. As long as BE remember they are there for the FE, everything flows smooth.

Sometimes smooth, sometimes not so.

We use FETCH/HTTP and STOMP/WS to move the data, the main issue has always been spotty communication inside the team. A while ago, the situation was even worse, so some progress did happen. OpenAPI annotations to generate Swagger docs helped a bit, but I rarely bother to open these. Drafting endpoint signatures in TypeScript as a part of our workflow yielded great results, something concrete to talk about when things don't work as expected or during code reviews. Unfortunately, the agreements are as good as initial requirements, if the team does not understand or communicate these clearly, misunderstands are bound to happen. The other pain point is that OpenAPI only supports HTTP (https://github.com/OAI/OpenAPI-Specification/issues/55), there's no documentation for STOMP endpoints and custom RPC run over it. Another thing is when signatures change unexpectedly (I know, this should never happen; at least integration tests help here) in subtle ways and the UI suddenly starts misbehaving; types shared between frontend (TypeScript) and backend (Java) can partially alleviate the issue, but none of available tools provide what I'd really like to use, the results are either not expressive enough (no ADTs, unlike types authored by hand) or really hard to reconcile with existing code base.

Documentation and communication is key.

The frontend team will be using the APIs provided by the backend. It should at least be fully documented to avoid unnecessary back and forth.

Regular "get together" meetings (remote or not, not necessarily with everyone) can help exchange pain points and prioritize issues. But not too often to impact productivity.

Basically, the backend team should know what the frontend team needs to consume. And the frontend team should know what the backend's technical limitations are. Trust in each-others expertise is also important IMHO.

FE dev here. In my day to day work, I often find there is a communication disconnect between our FE and BE teams. We communicate over slack and in JIRA ticket comments but there is undoubtedly at least one aspect of a UI element I'm working on that has something not functioning as expected on the backend. I feel like if we just had more meetings or somehow cleaner lines of communication this would be avoidable.

I'm a front-end dev and recently started working independently with back-end dev, we look for clients to work for. We're mostly doing MERN. One thing that ended up being the most helpful tool for us is postman because it includes the ability to make very easy-to-navigate API documentations allowing me to quickly jump between endpoints without having to spend too much time finding out what data it's expecting and returning. https://learning.postman.com/docs/publishing-your-api/docume...

Reply on news.ycombinator.com