5 ms·

Gotta say I disagree with this idea. RESTful APIs have become the norm for a reason, and in my opinion it's dangerous and damaging to suggest abandoning them fo

by jaza 3y ago

Gotta say I disagree with this idea. RESTful APIs have become the norm for a reason, and in my opinion it's dangerous and damaging to suggest abandoning them for a whole swathe of back-ends. Re: YAGNI. I worked on a product where, about 10 years ago, they decided to build proper APIs (for the first time), mainly to power their own front-end, but they also told the paying clients that they were welcome to use them. Didn't take some clients long to start using and loving those APIs. (Granted, they were enterprise clients, with their own significant dev resources, that's not the case for all software.) Re: front-end doesn't really have freedom. Yes it does! If one day page A needs a list of X, and there's already a nice generic API endpoint to list X, then only a front-end code change is needed.

weego 3y ago
No, what we have is everything trending towards a monoculture where every solution is a minor iteration or flavour change to systems that solved problems for companies at scale such as meta/google. We regularly see developers talking about optimising js loops, dom updates etc in products that are little more than blogs with a few interactive elements. Most of us work on things that will get ripped out and redone within a couple of years, yet dev culture tells us we should be focusing on developing for every possible future with reuse and scale in mind, and that's unfortunately false.
- szundi 3y ago
  At my company most code we did in 20 years ago is there and working. Providing b2b service for 5k customers. Thanks god it’s Java. Our competitors are lost trying to tinker with the old PHP or redoing everything with cutting edge node/js dead end techs.
  - whynotminot 3y ago
    You think node js is dead end tech?
    - halfcat 3y ago
      I interpreted the statement as, “dead end tech, which happens to use node/js”.
- marginalia_nu 3y ago
  > [pointless changes] in products that are little more than blogs with a few interactive elements. I wonder if a lot of this isn't busy work to justify having engineers on staff. You need engineers on staff to make changes when that is necessary, but you don't typically need to constantly be make such changes. At the same time the engineers can't be seen doing nothing, so this type of work is invented.
  - zelphirkalt 3y ago
    You are saying engineers should build software, that doesn't frequently require changes to fit some new use case? Outrageous. Then we would have to do proper engineering and make things flexible, anticipating potential use-cases. We would have to heed advice written in books such as PAIP (or more recently "Software Design for Flexibility"). Can we be expected to know literature of our own field?
- davidmurdoch 3y ago
  I agree with everything but > We regularly see developers talking about optimising js loops, dom updates etc in products that are little more than blogs with a few interactive elements. In which I see the opposite. Developers don't optimize because "DevEx" is a feature of a codebase, but performance is treated as an afterthought.
sdflhasjd 3y ago
> RESTful APIs have become the norm for a reason What would you say those reasons are though? I think they mostly boil down to cost. I agree with the article, but mostly for a reason the article didn't press on: performance and responsiveness. Making loads of small requests sucks, and on a mobile, it sucks times ten. HTTP/2 and whatnot have improved things but when you have even a small dependency tree of data, you can't avoid the network latency and it can quickly add up to a second or more of unresponsiveness. Obviously this doesn't apply (or matter) in some circumstances, but in many applications I think it's worth the extra cost.
- timeon 3y ago
  > and on a mobile, it sucks times ten People often like to design for mobile devices but not for mobile connections.
tootie 3y ago
There's a well-established answer to this that I've done for years that satisfies both and it's the BFF pattern. The crux of which is an orchestration tier. A simple pass-through API gateway which can interface with all your thoughtfully-designed, single-purpose APIs, extract and transform one or more payloads and serve up a single payload that maps one-to-one with a frontend. I've deployed this architecture for years on some large-scale sites. It works very nicely. Bonus is that you can manipulate and even swap out entire backend pieces without worrying about your frontend.
- NovaX 3y ago
  qlio [1] was a really elegant implementation of this pattern before it was named and popularized. That provided a nice decoupling of the FE/BE teams by allowing very quick iterations, with an early means to compose apis to simplify the marshalling. [1]: https://tech.ebayinc.com/engineering/announcing-ql-io https://tech.ebayinc.com/engineering/announcing-ql-io
gorjusborg 3y ago
I also disagree. I agree that pretending you have multiple clients sets up a more difficult bar to meet. I agree that bar might be overkill for some projects. The idea that it is overkill for all projects is a leap I can't follow. Optimizing for greenfield development speed is something inexperienced devs often do, and that's what this feels like.
Attummm 3y ago
The other added benefit is sharing the data with other teams, and of companies. Everything has the same flow. And if a custom api call is needed for a particular frontend page, it can always be made. But won't be the norm.

by jaza 3y ago

weego 3y ago

No, what we have is everything trending towards a monoculture where every solution is a minor iteration or flavour change to systems that solved problems for companies at scale such as meta/google. We regularly see developers talking about optimising js loops, dom updates etc in products that are little more than blogs with a few interactive elements. Most of us work on things that will get ripped out and redone within a couple of years, yet dev culture tells us we should be focusing on developing for every possible future with reuse and scale in mind, and that's unfortunately false.

szundi 3y ago
At my company most code we did in 20 years ago is there and working. Providing b2b service for 5k customers. Thanks god it’s Java. Our competitors are lost trying to tinker with the old PHP or redoing everything with cutting edge node/js dead end techs.
- whynotminot 3y ago
  You think node js is dead end tech?
  - halfcat 3y ago
    I interpreted the statement as, “dead end tech, which happens to use node/js”.
marginalia_nu 3y ago
> [pointless changes] in products that are little more than blogs with a few interactive elements. I wonder if a lot of this isn't busy work to justify having engineers on staff. You need engineers on staff to make changes when that is necessary, but you don't typically need to constantly be make such changes. At the same time the engineers can't be seen doing nothing, so this type of work is invented.
- zelphirkalt 3y ago
  You are saying engineers should build software, that doesn't frequently require changes to fit some new use case? Outrageous. Then we would have to do proper engineering and make things flexible, anticipating potential use-cases. We would have to heed advice written in books such as PAIP (or more recently "Software Design for Flexibility"). Can we be expected to know literature of our own field?
davidmurdoch 3y ago
I agree with everything but > We regularly see developers talking about optimising js loops, dom updates etc in products that are little more than blogs with a few interactive elements. In which I see the opposite. Developers don't optimize because "DevEx" is a feature of a codebase, but performance is treated as an afterthought.

sdflhasjd 3y ago

> RESTful APIs have become the norm for a reason What would you say those reasons are though? I think they mostly boil down to cost. I agree with the article, but mostly for a reason the article didn't press on: performance and responsiveness. Making loads of small requests sucks, and on a mobile, it sucks times ten. HTTP/2 and whatnot have improved things but when you have even a small dependency tree of data, you can't avoid the network latency and it can quickly add up to a second or more of unresponsiveness. Obviously this doesn't apply (or matter) in some circumstances, but in many applications I think it's worth the extra cost.

timeon 3y ago
> and on a mobile, it sucks times ten People often like to design for mobile devices but not for mobile connections.

tootie 3y ago

There's a well-established answer to this that I've done for years that satisfies both and it's the BFF pattern. The crux of which is an orchestration tier. A simple pass-through API gateway which can interface with all your thoughtfully-designed, single-purpose APIs, extract and transform one or more payloads and serve up a single payload that maps one-to-one with a frontend. I've deployed this architecture for years on some large-scale sites. It works very nicely. Bonus is that you can manipulate and even swap out entire backend pieces without worrying about your frontend.

NovaX 3y ago
qlio [1] was a really elegant implementation of this pattern before it was named and popularized. That provided a nice decoupling of the FE/BE teams by allowing very quick iterations, with an early means to compose apis to simplify the marshalling. [1]: https://tech.ebayinc.com/engineering/announcing-ql-io https://tech.ebayinc.com/engineering/announcing-ql-io

gorjusborg 3y ago

I also disagree. I agree that pretending you have multiple clients sets up a more difficult bar to meet. I agree that bar might be overkill for some projects. The idea that it is overkill for all projects is a leap I can't follow. Optimizing for greenfield development speed is something inexperienced devs often do, and that's what this feels like.

Attummm 3y ago

The other added benefit is sharing the data with other teams, and of companies. Everything has the same flow. And if a custom api call is needed for a particular frontend page, it can always be made. But won't be the norm.