3 ms·

Web RPC protocols are not trying to replace local function calls though. They're trying to replace remote API calls (REST, GraphQL etc.). And all remote protoco

Web RPC protocols are not trying to replace local function calls though. They're trying to replace remote API calls (REST, GraphQL etc.). And all remote protocols have to solve problems like availability, latency, and reliability. Those problems remain. This is trying to solve a different problem with different trade-offs. The problem it solves is unnecessary protocol noise and the trade-off is tight coupling between frontend and backend code. I think it's obvious that the trade-off makes sense for small projects and MVPs: most changes require touching both ends and typically the team isn't differentiated between backend and frontend anyway. But even with large projects that have to cater to many clients, a tightly-coupled RPC system can solve problems like overfetching and underfetching as a straightforward method for implementing the BFF pattern[1]. [1] https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0 https://medium.com/mobilepeople/backend-for-frontend-pattern...

brillout 4y ago
Exactly. Telefunc is about replacing generic endpoints (RESTful/GraphQL APIs) with tailored endpoints (RPC). That's why the trade-off is simpler architecture (generic endpoints are often an unnecessary abstraction) VS decoupling (tailored endpoints require the frontend and backend to be deployed in-sync). In the long term I foresee RPC to be also used for very large teams. I've ideas around this, stay tuned. I can even see companies like Netflix ditching GraphQL for RPC, although this won't happen any time soon. In the meantime, RPC is a natural fit for small/medium sized teams that want to ship today instead of spending weeks setting up GraphQL.
- pragmatic 4y ago
  Every generation keeps trying rpc and learns its lesson…eventually. On windows it was DCom, then COM+ then remoting the WCF then who knows I lost track. Rest APIs are simple and easily debuggable, magic remote api layers are not. That’s why REST is still prevalent even in websockets had better better performance parameters (and in my testing it did have performance advantages) yet 7 years after my testing hire many sites are running websockets?
  - sseagull 4y ago
    For lots of APIs this is somewhat true. However, I recently took a deep dive into "REST" and realized that for many APIs, you really have to contort how you think in order to make it fit into that model. It generally works for retrieving data (with caveats...), but I found that when modifying data on the server, with restricted transformations that don't necessarily map 1-1 with the data on the server, it feels like forcing a square peg into a round hole. I tend to think of verbs in that case, which starts to look like RPC. ("REST" is in quotes because the REST model proposed by Fielding (ie, with HATEOAS) looks almost nothing like "REST" in practice).
  - brillout 4y ago
    If Telefunc is bug-free (which I intend to be the case), then you won't need to debug Telefunc itself. For error tracking, Telefunc has hooks for that. For debugging user-land, you can `console.log()` just like you would with normal functions. Do you see a concrete use case where this wouldn't suffice?
    - P5fRxh5kUvp2th 4y ago
      > If Telefunc is bug-free (which I intend to be the case), then you won't need to debug Telefunc itself. And if no one crashes, you don't need airbags. If I'm being blunt, reality doesn't give a shit what you think. It's better to design with the assumption there are bugs so that _WHEN_ it happens, the users are up a creek without a paddle. These sorts of implicit assumptions are how painful software is made.
      - Huh1337 4y ago
        Software can be verified to be correct, stupidity of others is unavoidable.
        P5fRxh5kUvp2th 4y ago
        Did someone solve the halting problem while I wasn't looking?
- pragmatic 4y ago
  Generic endpoits are a design smell. Junior devs making Junior dev problems because someone who's been coding for 10 minutes wrote a series on api design on Medium. See the backend for front end pattern. Debuggabilty wins.

brillout 4y ago

Exactly. Telefunc is about replacing generic endpoints (RESTful/GraphQL APIs) with tailored endpoints (RPC). That's why the trade-off is simpler architecture (generic endpoints are often an unnecessary abstraction) VS decoupling (tailored endpoints require the frontend and backend to be deployed in-sync). In the long term I foresee RPC to be also used for very large teams. I've ideas around this, stay tuned. I can even see companies like Netflix ditching GraphQL for RPC, although this won't happen any time soon. In the meantime, RPC is a natural fit for small/medium sized teams that want to ship today instead of spending weeks setting up GraphQL.

pragmatic 4y ago
Every generation keeps trying rpc and learns its lesson…eventually. On windows it was DCom, then COM+ then remoting the WCF then who knows I lost track. Rest APIs are simple and easily debuggable, magic remote api layers are not. That’s why REST is still prevalent even in websockets had better better performance parameters (and in my testing it did have performance advantages) yet 7 years after my testing hire many sites are running websockets?
- sseagull 4y ago
  For lots of APIs this is somewhat true. However, I recently took a deep dive into "REST" and realized that for many APIs, you really have to contort how you think in order to make it fit into that model. It generally works for retrieving data (with caveats...), but I found that when modifying data on the server, with restricted transformations that don't necessarily map 1-1 with the data on the server, it feels like forcing a square peg into a round hole. I tend to think of verbs in that case, which starts to look like RPC. ("REST" is in quotes because the REST model proposed by Fielding (ie, with HATEOAS) looks almost nothing like "REST" in practice).
- brillout 4y ago
  If Telefunc is bug-free (which I intend to be the case), then you won't need to debug Telefunc itself. For error tracking, Telefunc has hooks for that. For debugging user-land, you can `console.log()` just like you would with normal functions. Do you see a concrete use case where this wouldn't suffice?
  - P5fRxh5kUvp2th 4y ago
    > If Telefunc is bug-free (which I intend to be the case), then you won't need to debug Telefunc itself. And if no one crashes, you don't need airbags. If I'm being blunt, reality doesn't give a shit what you think. It's better to design with the assumption there are bugs so that _WHEN_ it happens, the users are up a creek without a paddle. These sorts of implicit assumptions are how painful software is made.
    - Huh1337 4y ago
      Software can be verified to be correct, stupidity of others is unavoidable.
      - P5fRxh5kUvp2th 4y ago
        Did someone solve the halting problem while I wasn't looking?
pragmatic 4y ago
Generic endpoits are a design smell. Junior devs making Junior dev problems because someone who's been coding for 10 minutes wrote a series on api design on Medium. See the backend for front end pattern. Debuggabilty wins.