5 ms·

>Your back-end and front-end are always coupled. So trying to split them in anything but the most extreme circumstances is an exercise in futility. >If your ba

by kgeist 3y ago

>Your back-end and front-end are always coupled. So trying to split them in anything but the most extreme circumstances is an exercise in futility. >If your back-end team want to move in one direction, they've got to align with the front-end team. We have different backend and frontend teams and I can't agree that it's futile or hard to decouple etc. The only "coupling" which we have is the public API of the backend. Before a product or a feature is started, the teams design and agree on the API between the backend and the frontend, as part of our overall architecture design process (doesn't take more than a couple of days of 1-2 senior engineers if it's a big feature). After that, the two teams work completely in parallel. The frontend team has a framework which allows them to test the UI without the backend ready (using mock API). The backend team checks their API implementation using end-to-end tests. When the both teams are ready, we have the integration phase to see if it works together. Sure, often some edge cases are found and the API has to be changed a bit, but overall for me it has been quite a pleasant experience.

thomaslord 3y ago
I think there are pros and cons to this. I can definitely see how, in a company with larger teams, separating the frontend and backend can help with productivity. On the other hand, I'd wager that decoupled applications are less efficient with API calls something like 90% of the time. When I build a fully-coupled application, loading any given page after the CSS/JS files are cached requires a single HTTP request which always includes exactly the data that's required for that page. When I've built decoupled applications, I frequently end up doing 4+ HTTP requests to load various pieces of data that don't make sense to include in the same API request. In some cases these API requests will depend on data from a previous API request, which leads to multiple sequential round-trips before the page is fully usable. I started out at my current job working on a fully coupled system that's basically as "legacy" as you can get, and eventually started modernizing it - as part of that process, we decoupled the frontend from the backend. At first it felt more productive simply because it wasn't the old system and the new frameworks actually had documentation, but once I compared it to building a coupled system with modern frameworks I realized the coupled system made me much more productive. I'm currently the only developer at my company, though, so I feel like I'm probably the perfect target audience since I don't have to worry about team coordination at all.
- alamortsubite 3y ago
  > When I've built decoupled applications, I frequently end up doing 4+ HTTP requests to load various pieces of data that don't make sense to include in the same API request. In some cases these API requests will depend on data from a previous API request, which leads to multiple sequential round-trips before the page is fully usable. I'm not disagreeing with your fully-coupled approach, but you can also create a new handler to process what would otherwise be separate requests. Server-side, this new handler routes the bundled requests to existing handlers as needed and returns a single response to the client. So one trip and no duplication of logic.
  - hakunin 3y ago
    This is not necessarily a good solution to duplication problem, because you're still forced to keep each endpoint isolated, and can't efficiently combine data acquisition from, say, a database. A much cleaner logic reuse is to do it in your programming language. Build an endpoint that returns exactly what's needed for this front-end view, and build another, generic API for others to consume, but reusing a lot of the logic under the hood on the backend.
    - rokkitmensch 3y ago
      Et voilà, you now have: - a public API - a purpose built API (possibly one each for iOS, Android, and your browser app!) - 1-3 UI implementations closely coupled to your per-view API :golf-clap:
      - hakunin 3y ago
        I'm honestly unclear, are you trying to say it's a bad thing? Where is the issue?
        rokkitmensch 3y ago
        Merely that it's an extremely expensive way to get to a tight coupling between UI and API.
hakunin 3y ago
So then, are you building your backend API directly to meet the needs of your front-end? Or are you trying to keep it generic for all needs, but also serve the front-end? Are you telling the front-end team to download multiple resources from multiple endpoints when they need to render one thing? Do you have real life other consumers of your API? Are you juggling their requirements vs internal requirements? Is your backend team telling the frontend "it's not a good API design if we give you exactly what you need, so instead please pull these multiple resources?" Can you adequately measure your page load performance when front-end is making many parallel requests to the back-end and not all of them are required to consider the page "loaded"? There are countless architectural downsides associated with not just giving the front-end exactly what they need, and there has to be a very good upside for doing this. Front-end freedom is not one of them, because the freedom is minimal and mostly accidental. A good upside can be: you're building specifically an API for building your kind of web application, and you want to dogfood your own work. Otherwise, it seems an incredible amount of unnecessary contention and complexity. That said, I don't disagree that it _kind of works_ the way you describe, but it could've worked a lot better if your API could just give the front-end exactly what they need. You could've designed it with the exact same process, and they could've worked off of mocks the same way. They just would have all the data sent to them in a much more streamlined fashion. Disclaimer: I'm the author of https://max.engineer/server-informed-ui https://max.engineer/server-informed-ui
- kgeist 3y ago
  We have different schools of thought internally. Some prefer to tailor the backend API to the needs of the frontend, others prefer to have the backend API super generic so that changes in the frontend (say, a redesign) didn't require changing the backend. The latter is easier for backenders but harder for frontenders. It's vice versa for the former. So, the complexity stays the same, it influences which team (the frontend or the backend team) gets more complexity. However, when desiging the backend API, we always involve at least 1 frontender so that there were no "surprises".
  - rokkitmensch 3y ago
    This turns into "BFFE" (backend for frontend) in my experience, and that's not even the dumbest possible decision.
simonhamp 3y ago
Really pleased that you've found a way to make it work. But do you need it?

by kgeist 3y ago

thomaslord 3y ago

I think there are pros and cons to this. I can definitely see how, in a company with larger teams, separating the frontend and backend can help with productivity. On the other hand, I'd wager that decoupled applications are less efficient with API calls something like 90% of the time. When I build a fully-coupled application, loading any given page after the CSS/JS files are cached requires a single HTTP request which always includes exactly the data that's required for that page. When I've built decoupled applications, I frequently end up doing 4+ HTTP requests to load various pieces of data that don't make sense to include in the same API request. In some cases these API requests will depend on data from a previous API request, which leads to multiple sequential round-trips before the page is fully usable. I started out at my current job working on a fully coupled system that's basically as "legacy" as you can get, and eventually started modernizing it - as part of that process, we decoupled the frontend from the backend. At first it felt more productive simply because it wasn't the old system and the new frameworks actually had documentation, but once I compared it to building a coupled system with modern frameworks I realized the coupled system made me much more productive. I'm currently the only developer at my company, though, so I feel like I'm probably the perfect target audience since I don't have to worry about team coordination at all.

alamortsubite 3y ago
> When I've built decoupled applications, I frequently end up doing 4+ HTTP requests to load various pieces of data that don't make sense to include in the same API request. In some cases these API requests will depend on data from a previous API request, which leads to multiple sequential round-trips before the page is fully usable. I'm not disagreeing with your fully-coupled approach, but you can also create a new handler to process what would otherwise be separate requests. Server-side, this new handler routes the bundled requests to existing handlers as needed and returns a single response to the client. So one trip and no duplication of logic.
- hakunin 3y ago
  This is not necessarily a good solution to duplication problem, because you're still forced to keep each endpoint isolated, and can't efficiently combine data acquisition from, say, a database. A much cleaner logic reuse is to do it in your programming language. Build an endpoint that returns exactly what's needed for this front-end view, and build another, generic API for others to consume, but reusing a lot of the logic under the hood on the backend.
  - rokkitmensch 3y ago
    Et voilà, you now have: - a public API - a purpose built API (possibly one each for iOS, Android, and your browser app!) - 1-3 UI implementations closely coupled to your per-view API :golf-clap:
    - hakunin 3y ago
      I'm honestly unclear, are you trying to say it's a bad thing? Where is the issue?
      - rokkitmensch 3y ago
        Merely that it's an extremely expensive way to get to a tight coupling between UI and API.

hakunin 3y ago

So then, are you building your backend API directly to meet the needs of your front-end? Or are you trying to keep it generic for all needs, but also serve the front-end? Are you telling the front-end team to download multiple resources from multiple endpoints when they need to render one thing? Do you have real life other consumers of your API? Are you juggling their requirements vs internal requirements? Is your backend team telling the frontend "it's not a good API design if we give you exactly what you need, so instead please pull these multiple resources?" Can you adequately measure your page load performance when front-end is making many parallel requests to the back-end and not all of them are required to consider the page "loaded"? There are countless architectural downsides associated with not just giving the front-end exactly what they need, and there has to be a very good upside for doing this. Front-end freedom is not one of them, because the freedom is minimal and mostly accidental. A good upside can be: you're building specifically an API for building your kind of web application, and you want to dogfood your own work. Otherwise, it seems an incredible amount of unnecessary contention and complexity. That said, I don't disagree that it _kind of works_ the way you describe, but it could've worked a lot better if your API could just give the front-end exactly what they need. You could've designed it with the exact same process, and they could've worked off of mocks the same way. They just would have all the data sent to them in a much more streamlined fashion. Disclaimer: I'm the author of https://max.engineer/server-informed-ui https://max.engineer/server-informed-ui

kgeist 3y ago
We have different schools of thought internally. Some prefer to tailor the backend API to the needs of the frontend, others prefer to have the backend API super generic so that changes in the frontend (say, a redesign) didn't require changing the backend. The latter is easier for backenders but harder for frontenders. It's vice versa for the former. So, the complexity stays the same, it influences which team (the frontend or the backend team) gets more complexity. However, when desiging the backend API, we always involve at least 1 frontender so that there were no "surprises".
- rokkitmensch 3y ago
  This turns into "BFFE" (backend for frontend) in my experience, and that's not even the dumbest possible decision.

simonhamp 3y ago

Really pleased that you've found a way to make it work. But do you need it?