Yea, I've seen a lot of folks doing this and it's neat. Most projects don't really need REST/GraphQL. So many waste so much time implementing a perfect GraphQL setup even though they don't need it :sweat_smile:.
I don't think "API" just means "programmatic interface". It also denotes some kind of decoupling. A library API => decoupling between lib user and lib author. GraphQL API => decoupling between backend and frontend.
The point of Telefunc is precisely to not decouple frontend and backend. Telefunc is all about bringing backend and frontend tightly together.
So, the tagline is very much on point ;-).
But, yea, you make me think that "Remote Functions. Instead of REST/GraphQL." is maybe better. I'll think about it.
It really is a game of semantics as another person commenting mentioned. It might feel like there's something distinct here but all RPC was remote procedure calls aka functions and produced tightly coupled clients and server code. And the term API is not specifically owned by HTTP calls or REST/GraphQL, it's a definition of an interface for consumer some service. Even in your case whether you feel like you see it or not, every function is part of an API.
I don't think "API" just means "programmatic interface". It also denotes some kind of decoupling. A library API => decoupling between lib user and lib author. GraphQL API => decoupling between backend and frontend.
The point of Telefunc is precisely to not decouple frontend and backend. Telefunc is all about bringing backend and frontend tightly together.
So, the tagline is very much on point ;-).
But, yea, you make me think that "Remote Functions. Instead of REST/GraphQL." is maybe better. I'll think about it.