5 ms·

I've never liked having an API team / Front End Team distinction. I don't think it makes good software in most cases, it creates that combative element between

I've never liked having an API team / Front End Team distinction. I don't think it makes good software in most cases, it creates that combative element between the teams due to different priorities that you saw. A team with a product, needs to have the freedom and ability to work at any level of the stack to get that product out, sure that rarely happens 100% and there is coordination between teams, but Vertical slice teams do it better than Horizontal slice teams in my experience.

mixmastamyk 4y ago
That's a major reason why graphql was invented, to my knowledge.
sibit 4y ago
I agree with this take. I work on a small team (2 backend devs, 2 frontend). The we are always arguing about the API. The frontend devs want the data for their components pre-formatted in 1 API call. The backend team wants to run a SQL query and return the entire record as JSON.
- keyle 4y ago
  FWIW here: The backend guys are wrong.
  - operatingthetan 4y ago
    The test is to ask ask a full stack developer responsible for both sides what they would do! (And of course, accommodating the data needs of the UI is the answer.)
    - sibit 4y ago
      Exactly. My understanding is the API accommodates the frontend data which accommodates the design which accommodates the users needs.
    - wruza 4y ago
      What a fullstack guy would do is irrelevant here, because if their requirements changed, they’d just redo it. It’s not about who does the job, but about where we end up at when the format becomes obsolete. Likely scenario: backend formats data and moves on / gets busy elsewhere. Frontend changes, so that data is now required in a different format. Frontend decides to just reformat it at their side because of schedules. Now it’s a mess and nobody knows why. The root of the problem is this stupid frontend/backend team division when it’s actually a single program. That’s where the idea of “let’s ask fullstack” comes from. But there’s no good answer this guy could give you, apart from “stop drawing stupid dividers across the whole”.
      - survirtual 4y ago
        This is why you version an API. Or just use GraphQL-esque methods, but versioning will poke its head in somewhere eventually.
      - operatingthetan 4y ago
        >What a fullstack guy would do is irrelevant here, because if their requirements changed, they’d just redo it That was obviously a really general rule of thumb not intended to be an actual architecture guideline...
  - ilyt 4y ago
    Entirely depends on how big the request might be
    - sibit 4y ago
      I agree. Sometimes it's easier to just return the record. It starts to suck when you get an array back and you have to loop through all n+1 results to query each additional record instead of just getting what you need in 1 request.
      - bombolo 4y ago
        Seems like you structured your db wrong.
        sibit 4y ago
        I was 5 when the DB was created so I don't think I structured anything wrong...
  - pdntspa 4y ago
    It sounds like both sides simply want to do the least amount of work possible.
- 1123581321 4y ago
  Hence Graphql’s political role, assuming the back end is willing to batch and to maintain types.
Freedom2 4y ago
I've been called a conspiracy theorist before, but I believe this is why many frontend developers make their tooling and stack so complicated - to carve out their own niche to remain relevant. Just compare how simple and easy Java is to get up and running.
- actionfromafar 4y ago
  Ehhh... Java didn't start out that way. It felt like confusing hell and I wasn't sure what I was doing for a good reason and what I did because that's just what you did. EJB, Glassfish, Apache, WAL, something something Enterprise. Java the language is quite nice, the tooling can be quite insane. Yeah, don't forget the custom convoluted setup at some companies which only work with Eclipse, which suddenly slows down for no reason until you restart it. Then, you throw in some plugins and 50% of your screen real estate is gone. Don't get me wrong, I quite like Java and the good tooling, but I'm more exposed to C# these days and Java feels like 90% the same, so I'm never compelled to go back. Or you are maybe sarcastic, impossible to tell in text... Side-edit: from the very beginning, Java was simple, when it was released. But in 2010 it felt super confusing to me.
- the-smug-one 4y ago
  >Just compare how simple and easy Java is to get up and running. Is it? I come from a very different background and I'm trying to get a small Java back-end up and running (Quarkus) and wow, it's so painful! There's a huge amount of buy in, to me, in the framework. I found Node, Go and Python to be easier in simply delivering a HTTP(S) server. I've gotta do it in Java for reasons.
  - isthiseasymode 4y ago
    People generally use spring when it comes to java. Spring is just a few annotations away from creating an endpoint. https://start.spring.io/ https://start.spring.io/ Of course with spring, there’s a lot of stuff that isn’t java that you have to know.
    - 4y ago
ilyt 4y ago
It makes a lot of sense when there is more than one other element using the API. There does need to be oversight over whole thing to avoid exactly what is described above.
makeitdouble 4y ago
In combative environments that's solved with a BFF maintained by the frontend team, and the backend gets away with exposing broad and generic API the frontend team reprocesses on their layer. In sensible work environments, that's solved by aligning incentives at project level. If your frontend team crucially needs something done, but the backend can't give a shit, the problems run deeper than area of responsibility IMHO. Either what the frontend works on doesn't matter, or the backend team wants to sink the ship, or there's way too many fires to put out and the ship is already sinking. Having mega teams or filling them with jack-of-all-trades types also has critical downsides.
- anonymoushn 4y ago
  a Best Friend Forever?
  - makeitdouble 4y ago
    Backend For Frontend, basically a glorified API gateway The simple result I get introducing the concept: https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0 https://medium.com/mobilepeople/backend-for-frontend-pattern...
  - meowtimemania 4y ago
    backend for frontend. It's usually another layer between the frontend and the "real backend". So frontend calls BFF (usually a node server), and BFF calls the backend.
dagw 4y ago
I've never liked having an API team / Front End Team distinction. If there is only one front end that talks to the back end, then yes I agree. If there are 20 different front ends from 20 different teams, some of them external, that are expected to talk to the same API, then it makes a lot more sense.
- survirtual 4y ago
  In the case of 20 frontends to 1 backend, it might make more sense to organize it as 19 frontends to 1 front/backend. In other words, have a team with front and back-end devs working together, with a frontend acting as a sensible default interaction to an API. This can be something as simple as a widget or component. This front end is expected to have a full suite of tests running through the API (or an api test device -- this test device can also be used to better communicate the requirements to backend devs), and be well documented in how and why it's doing something. That acts as an example for any other frontends. When they have questions or issues with the api, it also provides an immediate source of truth to show how to properly do something. And it provides confidence that the API is behaving in the expected fashion for the user experience being provided for. Just a thought.
  - gregmac 4y ago
    The most successful APIs I've worked with have been done this way. In one project we were rebuilding an old outdated UI. We started with being very strict about literally only implementing what was needed for frontend, for example not even a GET /widgets/{id} until there was a UI that needed it. We also explicitly built new models for this, separate from our database models, so it wasn't just "return everything in the table": if the UI only displayed half the fields, that's what was returned. A big benefit of this mindset was when we needed a list of things from joining multiple tables, there was no thought of pushing this to the front-end; we just made a viewmodel, did the work server-side and returned it. Also, pretty early on we implemented Swagger (OpenAPI) and built in docs to our code. This helped establish it as a part of dev and the coding style that any new devs quickly bought into, as opposed to an afterthought everyone sees as a chore. After we had a a dozen or so APIs done, we started opening it to customers. We'd add new things they'd request (but our UI didn't need), but strictly kept the use-case-first mindset, as well as continuing the UI port (page-by-page, effectively). Even a few years later, the feedback from our developer users was overwhelmingly positive, along the lines of "this is the best API I've ever used".

mixmastamyk 4y ago

That's a major reason why graphql was invented, to my knowledge.

sibit 4y ago

I agree with this take. I work on a small team (2 backend devs, 2 frontend). The we are always arguing about the API. The frontend devs want the data for their components pre-formatted in 1 API call. The backend team wants to run a SQL query and return the entire record as JSON.

keyle 4y ago
FWIW here: The backend guys are wrong.
- operatingthetan 4y ago
  The test is to ask ask a full stack developer responsible for both sides what they would do! (And of course, accommodating the data needs of the UI is the answer.)
  - sibit 4y ago
    Exactly. My understanding is the API accommodates the frontend data which accommodates the design which accommodates the users needs.
  - wruza 4y ago
    What a fullstack guy would do is irrelevant here, because if their requirements changed, they’d just redo it. It’s not about who does the job, but about where we end up at when the format becomes obsolete. Likely scenario: backend formats data and moves on / gets busy elsewhere. Frontend changes, so that data is now required in a different format. Frontend decides to just reformat it at their side because of schedules. Now it’s a mess and nobody knows why. The root of the problem is this stupid frontend/backend team division when it’s actually a single program. That’s where the idea of “let’s ask fullstack” comes from. But there’s no good answer this guy could give you, apart from “stop drawing stupid dividers across the whole”.
    - survirtual 4y ago
      This is why you version an API. Or just use GraphQL-esque methods, but versioning will poke its head in somewhere eventually.
    - operatingthetan 4y ago
      >What a fullstack guy would do is irrelevant here, because if their requirements changed, they’d just redo it That was obviously a really general rule of thumb not intended to be an actual architecture guideline...
- ilyt 4y ago
  Entirely depends on how big the request might be
  - sibit 4y ago
    I agree. Sometimes it's easier to just return the record. It starts to suck when you get an array back and you have to loop through all n+1 results to query each additional record instead of just getting what you need in 1 request.
    - bombolo 4y ago
      Seems like you structured your db wrong.
      - sibit 4y ago
        I was 5 when the DB was created so I don't think I structured anything wrong...
- pdntspa 4y ago
  It sounds like both sides simply want to do the least amount of work possible.
1123581321 4y ago
Hence Graphql’s political role, assuming the back end is willing to batch and to maintain types.

Freedom2 4y ago

I've been called a conspiracy theorist before, but I believe this is why many frontend developers make their tooling and stack so complicated - to carve out their own niche to remain relevant. Just compare how simple and easy Java is to get up and running.

actionfromafar 4y ago
Ehhh... Java didn't start out that way. It felt like confusing hell and I wasn't sure what I was doing for a good reason and what I did because that's just what you did. EJB, Glassfish, Apache, WAL, something something Enterprise. Java the language is quite nice, the tooling can be quite insane. Yeah, don't forget the custom convoluted setup at some companies which only work with Eclipse, which suddenly slows down for no reason until you restart it. Then, you throw in some plugins and 50% of your screen real estate is gone. Don't get me wrong, I quite like Java and the good tooling, but I'm more exposed to C# these days and Java feels like 90% the same, so I'm never compelled to go back. Or you are maybe sarcastic, impossible to tell in text... Side-edit: from the very beginning, Java was simple, when it was released. But in 2010 it felt super confusing to me.
the-smug-one 4y ago
>Just compare how simple and easy Java is to get up and running. Is it? I come from a very different background and I'm trying to get a small Java back-end up and running (Quarkus) and wow, it's so painful! There's a huge amount of buy in, to me, in the framework. I found Node, Go and Python to be easier in simply delivering a HTTP(S) server. I've gotta do it in Java for reasons.
- isthiseasymode 4y ago
  People generally use spring when it comes to java. Spring is just a few annotations away from creating an endpoint. https://start.spring.io/ https://start.spring.io/ Of course with spring, there’s a lot of stuff that isn’t java that you have to know.
  - 4y ago

ilyt 4y ago

It makes a lot of sense when there is more than one other element using the API. There does need to be oversight over whole thing to avoid exactly what is described above.

makeitdouble 4y ago

In combative environments that's solved with a BFF maintained by the frontend team, and the backend gets away with exposing broad and generic API the frontend team reprocesses on their layer. In sensible work environments, that's solved by aligning incentives at project level. If your frontend team crucially needs something done, but the backend can't give a shit, the problems run deeper than area of responsibility IMHO. Either what the frontend works on doesn't matter, or the backend team wants to sink the ship, or there's way too many fires to put out and the ship is already sinking. Having mega teams or filling them with jack-of-all-trades types also has critical downsides.

anonymoushn 4y ago
a Best Friend Forever?
- makeitdouble 4y ago
  Backend For Frontend, basically a glorified API gateway The simple result I get introducing the concept: https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0 https://medium.com/mobilepeople/backend-for-frontend-pattern...
- meowtimemania 4y ago
  backend for frontend. It's usually another layer between the frontend and the "real backend". So frontend calls BFF (usually a node server), and BFF calls the backend.

dagw 4y ago

I've never liked having an API team / Front End Team distinction. If there is only one front end that talks to the back end, then yes I agree. If there are 20 different front ends from 20 different teams, some of them external, that are expected to talk to the same API, then it makes a lot more sense.

survirtual 4y ago
In the case of 20 frontends to 1 backend, it might make more sense to organize it as 19 frontends to 1 front/backend. In other words, have a team with front and back-end devs working together, with a frontend acting as a sensible default interaction to an API. This can be something as simple as a widget or component. This front end is expected to have a full suite of tests running through the API (or an api test device -- this test device can also be used to better communicate the requirements to backend devs), and be well documented in how and why it's doing something. That acts as an example for any other frontends. When they have questions or issues with the api, it also provides an immediate source of truth to show how to properly do something. And it provides confidence that the API is behaving in the expected fashion for the user experience being provided for. Just a thought.
- gregmac 4y ago
  The most successful APIs I've worked with have been done this way. In one project we were rebuilding an old outdated UI. We started with being very strict about literally only implementing what was needed for frontend, for example not even a GET /widgets/{id} until there was a UI that needed it. We also explicitly built new models for this, separate from our database models, so it wasn't just "return everything in the table": if the UI only displayed half the fields, that's what was returned. A big benefit of this mindset was when we needed a list of things from joining multiple tables, there was no thought of pushing this to the front-end; we just made a viewmodel, did the work server-side and returned it. Also, pretty early on we implemented Swagger (OpenAPI) and built in docs to our code. This helped establish it as a part of dev and the coding style that any new devs quickly bought into, as opposed to an afterthought everyone sees as a chore. After we had a a dozen or so APIs done, we started opening it to customers. We'd add new things they'd request (but our UI didn't need), but strictly kept the use-case-first mindset, as well as continuing the UI port (page-by-page, effectively). Even a few years later, the feedback from our developer users was overwhelmingly positive, along the lines of "this is the best API I've ever used".