5 ms·

Exactly. Telefunc is about replacing generic endpoints (RESTful/GraphQL APIs) with tailored endpoints (RPC). That's why the trade-off is simpler architecture

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?
        Huh1337 4y ago
        No, but somebody created type checking, linting and testing. Not sure what's up with the CS people and their halting problem. In the industry we've solved (as in developed ways to deal with) the problem of verification decades ago. Also, debuggers. Nobody said the verification can't be done by a human.
        P5fRxh5kUvp2th 4y ago
        verifying software is correct implies solving the halting problem. What you mean is "no known bugs", so may be use those words instead. "verification of correctness" has a specific meaning in our industry. yeah yeah, I get it, those stupid CS people and their P=NP talk. Don't they know you can obviously verify correctness without verifying it for all possible inputs? What next, you can't prove a negative such as absence of bugs?!?
        4y ago
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.

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?
      - Huh1337 4y ago
        No, but somebody created type checking, linting and testing. Not sure what's up with the CS people and their halting problem. In the industry we've solved (as in developed ways to deal with) the problem of verification decades ago. Also, debuggers. Nobody said the verification can't be done by a human.
        P5fRxh5kUvp2th 4y ago
        verifying software is correct implies solving the halting problem. What you mean is "no known bugs", so may be use those words instead. "verification of correctness" has a specific meaning in our industry. yeah yeah, I get it, those stupid CS people and their P=NP talk. Don't they know you can obviously verify correctness without verifying it for all possible inputs? What next, you can't prove a negative such as absence of bugs?!?
        4y ago

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.