3 ms·

previous discussion: https://news.ycombinator.com/item?id=28511570 https://news.ycombinator.com/item?id=28511570

• preommr 3y ago
  Quite surprised at how much people agreed with this post. I personally don't think this is such a good idea - it's not that hard to write a general purpose API that covers 80% of obvious use cases, and have app-specific grouping of endpoints for the remainder. And I include things like rollilng multiple requests into one as part of the obvious use case. Because it's usually very easy to implement - either copy/paste, or 5 lines for more complex solutions like an orm, graphql, etc. It seems like a terrible idea to couple the backend with the front-end so strongly.
  • padjo 3y ago
    Seems like an over correction. Yes trying to make your front end API be your public API is probably a bad idea, but making your front end API completely coupled to the structure of your app structure is probably a bad idea too. Best approach is probably in the middle somewhere.
  • isaacremuant 3y ago
    It probably comes from misusing the API route and feeling they want to keep it simple, but instead heavily coupling things. A motivated BE that wants to be productive avoiding unnecessary work would probably hate being "support for frontend" whenever they decide to change something and a motivated frontend would probably want to turn themselves to full stack powers to not depend on someone else. It feels really bad as a pattern unless that webapp is your only concern and is constantly moving or something, or if there's no actually FE or BE but just few people maintaining stuff as a side concern (backend for frontend works there).