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.
The backend language I work with is Go, so there are "two" problems that need to be solved for this to work:
- Resolving function name and encoding/decoding arguments from a url to a real function call
- Representing Go structs as Typescript interfaces for the client side code to look like regular function calls with regular types and all that.
For the second part, I have a writeup about how I'm doing it: https://hasen.surge.sh/go-ts-type-bridge.html
It's worth noting that the title of the OP website is wrong.
"Remote Functions Instad of API"
What do you think an API is? API does not stand for "HTTP Requests with JSON". It stands for "Application Programming Interface".