5 ms·

Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization

by kiney 2y ago

Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code

shados 2y ago
The backend for frontend pattern. Something most apps where frontend and backend are in the same organization (fullstack or otherwise) should have. It does wonder to maintainability and performance. Even though we use GQL here, we still have a B4F, so it's browser -> B4F -> GQL -> Database. The tooling we use make it trivial so it doesn't add any development overhead (often reduces it. No CORS bullshit for one), and our app goes ZOOOOOOM.
nurple 2y ago
I think it's elegant. I loved MVVM in the postback world, and with SPAs, I see view-specific endpoints as the view-model continuing to reside on the server while the view was split off to the client-side.
datavirtue 2y ago
Agreed. Specific endpoints. I was on a project recently where a 40+ yr old dev was going crazy over "pure REST." It's embarrassing. Sure, have your pure REST but FFS create specific endpoints if you they make sense.
- mgkimsal 2y ago
  You are literally Transferring the REpresented State of a given page/view/screen. Screen-specific REST endpoints will make their way as a default in to a JS-based framework in 2025 and people will pretend like this is some breakthrough advancement.
  - mjburgess 2y ago
    And finally HyperText will progress into the futuristic HyperCard
WD-42 2y ago
Yup. Especially when your api really only has 1 (possibly 2 in the case of a mobile app) real clients. People like to pretend their apis are generic but they aren’t. There’s a good argument to stop writing generic apis for your single application.
- hansonkd 2y ago
  Typically the endpoints clients are multiple frontend developers. If the frontend is blocked for every page they need waiting on the backend to expose data that massively increases the costs of features and reduces the time for delivery.
  - WD-42 2y ago
    This happens anyway.
    - hansonkd 2y ago
      Not nearly as often with Graphql and happens less and less as your backend and data models stabilizes. Most of our frontend features now don't have backend changes and we were able to increase the ratio of frontend to backend devs.
      - blowski 2y ago
        My experience is that the problem is avoided in theory, but not in practice. Making a good API on a large system with many clients is always difficult. GraphQL makes it easier in theory, but if you have average level devs working on it, they’ll make a bigger mess than if they use simple REST. The latter will still be complex, but at least it’s easier to have observability.
        ethbr1 2y ago
        Aka never underestimate the power of additional complexity to drive bad use, absent familiarity.
blowski 2y ago
I’ve heard this called the “backend-for-frontend” pattern.
marcosdumay 2y ago
The modern web development practices are just insane. The GP's idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. On the other extreme, we have the HTTP 1.0 developers saying something like "networks are plenty of fast, we can waste a bit of it with legible protocols that are easier to make correct", while the HTTP 2.0 ones are all in "we must cram information into every single bit!" Every place you look, things are completely bananas.
- klibertp 2y ago
  > idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. For me, what's crazy is that there are "web" developers who can't just add the endpoint they need while working on a frontend feature, or "web" developers who can't just add an element or a page for testing the backend endpoint. What ever happened to full-stack developers? The "frontend" and "backend" developer split is so incredibly inefficient that it's really jarring—you take something that should take 2 hours and magically, through tickets, delegation, and waiting for results (then repeat that for debugging, who knows how many times!), make it into a 2-3 day task. I once reproduced (black-box style!) a two-week effort by a three-man team in six hours of work simply because I had PyCharm and IDEA opened side-by-side and could write code on both sides at the same time. If someone has a good explanation for why the full-stacks that were once the norm went almost extinct, I'd be happy to give it a read!
  - riffraff 2y ago
    Because people have a limited appetite for complexity. I wrote some front-end stuff back in the days but I've lost track of whatever is happening these days. jQuery to append some stuff took five minutes to learn, but learning react hooks takes a determined effort. Likewise, adding a field to a graphql type is simple, but doing it with authorization, controlling n+1s, adding tests etc.. requires front-end folks to actually invest time in learning whatever back-end they're dealing with this time. Everything is just a lot more complicated these days, and if you've been around for a while you may not be excited anymore by the churn, but rather fed up.
deleted 2y ago
[deleted]
eddd-ddde 2y ago
This is the true purpose of REST. If you need to make multiple requests for a single operation you don't have enough endpoints. The idea that resources and the underlying data needs to map 1-1 is wrong.
charlie0 2y ago
Sounds good in theory. In practice, what I've seen is people don't just do single page endpoints with shared services, they follow this all the way down into the services and so you end up with lots of duplicate looking code. This isn't a problem until the application gets big enough and now you have business logic that should be the same spread out across an app. This leads to weird bugs where something that should work the same way doesn't depending on which page you're accessing things from. Of course, I don't a solution, solving things like this is what makes software engineering hard.
- Sammi 2y ago
  > In practice, what I've seen is people don't just do single page endpoints with shared services, they follow this all the way down into the services and so you end up with lots of duplicate looking code There is no easy or simple or final solution. The solution is to do the hard work of software engineering and catch this stuff at code review time or to plan and do refactoring later when you realize something needs normalization. I wish developers would just accept that software engineering is hard and do the hard work necessary. There's that whole "the best software engineer is lazy because he will automate stuff", but that does not give anyone a license to automate stuff in an unmaintainable way. Automating stuff is hard and there is no easy way out.
rbalicki 2y ago
GraphQL gives you this. https://relay.dev/docs/guides/persisted-queries/ https://relay.dev/docs/guides/persisted-queries/
- crubier 2y ago
  Came here for that. People in this thread basically reinventing GraphQL lol. "We need a http API endpoint that gives you all the data for one page. And also be able to reuse parts of it for other pages." Yeah bro, this is GraphQL.

by kiney 2y ago

shados 2y ago

The backend for frontend pattern. Something most apps where frontend and backend are in the same organization (fullstack or otherwise) should have. It does wonder to maintainability and performance. Even though we use GQL here, we still have a B4F, so it's browser -> B4F -> GQL -> Database. The tooling we use make it trivial so it doesn't add any development overhead (often reduces it. No CORS bullshit for one), and our app goes ZOOOOOOM.

nurple 2y ago

I think it's elegant. I loved MVVM in the postback world, and with SPAs, I see view-specific endpoints as the view-model continuing to reside on the server while the view was split off to the client-side.

datavirtue 2y ago

Agreed. Specific endpoints. I was on a project recently where a 40+ yr old dev was going crazy over "pure REST." It's embarrassing. Sure, have your pure REST but FFS create specific endpoints if you they make sense.

mgkimsal 2y ago
You are literally Transferring the REpresented State of a given page/view/screen. Screen-specific REST endpoints will make their way as a default in to a JS-based framework in 2025 and people will pretend like this is some breakthrough advancement.
- mjburgess 2y ago
  And finally HyperText will progress into the futuristic HyperCard

WD-42 2y ago

Yup. Especially when your api really only has 1 (possibly 2 in the case of a mobile app) real clients. People like to pretend their apis are generic but they aren’t. There’s a good argument to stop writing generic apis for your single application.

hansonkd 2y ago
Typically the endpoints clients are multiple frontend developers. If the frontend is blocked for every page they need waiting on the backend to expose data that massively increases the costs of features and reduces the time for delivery.
- WD-42 2y ago
  This happens anyway.
  - hansonkd 2y ago
    Not nearly as often with Graphql and happens less and less as your backend and data models stabilizes. Most of our frontend features now don't have backend changes and we were able to increase the ratio of frontend to backend devs.
    - blowski 2y ago
      My experience is that the problem is avoided in theory, but not in practice. Making a good API on a large system with many clients is always difficult. GraphQL makes it easier in theory, but if you have average level devs working on it, they’ll make a bigger mess than if they use simple REST. The latter will still be complex, but at least it’s easier to have observability.
      - ethbr1 2y ago
        Aka never underestimate the power of additional complexity to drive bad use, absent familiarity.

blowski 2y ago

I’ve heard this called the “backend-for-frontend” pattern.

marcosdumay 2y ago

The modern web development practices are just insane. The GP's idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. On the other extreme, we have the HTTP 1.0 developers saying something like "networks are plenty of fast, we can waste a bit of it with legible protocols that are easier to make correct", while the HTTP 2.0 ones are all in "we must cram information into every single bit!" Every place you look, things are completely bananas.

klibertp 2y ago
> idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. For me, what's crazy is that there are "web" developers who can't just add the endpoint they need while working on a frontend feature, or "web" developers who can't just add an element or a page for testing the backend endpoint. What ever happened to full-stack developers? The "frontend" and "backend" developer split is so incredibly inefficient that it's really jarring—you take something that should take 2 hours and magically, through tickets, delegation, and waiting for results (then repeat that for debugging, who knows how many times!), make it into a 2-3 day task. I once reproduced (black-box style!) a two-week effort by a three-man team in six hours of work simply because I had PyCharm and IDEA opened side-by-side and could write code on both sides at the same time. If someone has a good explanation for why the full-stacks that were once the norm went almost extinct, I'd be happy to give it a read!
- riffraff 2y ago
  Because people have a limited appetite for complexity. I wrote some front-end stuff back in the days but I've lost track of whatever is happening these days. jQuery to append some stuff took five minutes to learn, but learning react hooks takes a determined effort. Likewise, adding a field to a graphql type is simple, but doing it with authorization, controlling n+1s, adding tests etc.. requires front-end folks to actually invest time in learning whatever back-end they're dealing with this time. Everything is just a lot more complicated these days, and if you've been around for a while you may not be excited anymore by the churn, but rather fed up.

deleted 2y ago

[deleted]

eddd-ddde 2y ago

This is the true purpose of REST. If you need to make multiple requests for a single operation you don't have enough endpoints. The idea that resources and the underlying data needs to map 1-1 is wrong.

charlie0 2y ago

Sounds good in theory. In practice, what I've seen is people don't just do single page endpoints with shared services, they follow this all the way down into the services and so you end up with lots of duplicate looking code. This isn't a problem until the application gets big enough and now you have business logic that should be the same spread out across an app. This leads to weird bugs where something that should work the same way doesn't depending on which page you're accessing things from. Of course, I don't a solution, solving things like this is what makes software engineering hard.

Sammi 2y ago
> In practice, what I've seen is people don't just do single page endpoints with shared services, they follow this all the way down into the services and so you end up with lots of duplicate looking code There is no easy or simple or final solution. The solution is to do the hard work of software engineering and catch this stuff at code review time or to plan and do refactoring later when you realize something needs normalization. I wish developers would just accept that software engineering is hard and do the hard work necessary. There's that whole "the best software engineer is lazy because he will automate stuff", but that does not give anyone a license to automate stuff in an unmaintainable way. Automating stuff is hard and there is no easy way out.

rbalicki 2y ago

GraphQL gives you this. https://relay.dev/docs/guides/persisted-queries/ https://relay.dev/docs/guides/persisted-queries/

crubier 2y ago
Came here for that. People in this thread basically reinventing GraphQL lol. "We need a http API endpoint that gives you all the data for one page. And also be able to reuse parts of it for other pages." Yeah bro, this is GraphQL.