
Show HN: RPC Between Front End and Back End (Node.js) – REST/GraphQL Alternative - brillout
https://github.com/reframejs/wildcard-api#readme
======
gengstrand
I find the comparison to REST and GraphQL in this README to be a bit of a
miss. GraphQL queries and REST add more value than just being another RPC. I
cover this in
[http://glennengstrand.info/software/architecture/microservic...](http://glennengstrand.info/software/architecture/microservice/graphql)
where I discuss how GraphQL queries and REST add order and structure that make
their APIs more readable and understandable than just any RPC. I realize that
there is currently brewing a backlash to this additional order and a desire to
return to the simplicity of RPCs. This README is full of that attitude. It may
be simpler to produce ad hoc RPCs but I believe that, in the long run, you
will net an overall lower complexity if you design your APIs following REST or
GraphQL guidelines.

~~~
brillout
I can see the need for large projects to add structure between frontend and
backend.

But until you hit that point you're better off with RPC. "Premature
optimization is the root of all evil" holds here as well. A startup should
start with RPC and solve structural problems as they arise. RPC has no lock-
in; you can progressively replace RPC endpoints with a REST/GraphQL API.

The nice thing here is that, once you hit structural problems, it will become
much clearer what the right solution is. Will it be REST or GraphQL? Or maybe
something else entirely such as domain-driven separation of concerns? You will
know better than today.

It is virtually impossible to know the needs of an architecture that doesn't
exist yet.

Today REST and GraphQL are the default choice. But really, it is RPC that
should be the default choice. And that's a widespread mistake in the dev
community.

Wouldn't you agree? I'm curious to know what your thoughts are.

~~~
gengstrand
It sounds like what wildcard is targeting is early stage startups with single
digit number of developers that are still pivoting heavily. Otherwise, you
would already have encountered enough "structural problems" to arrive at a
basic data model. In which case, why optimize prematurely with an API at all?
Why not just go with an everything included MVC framework such as Django or
Adonis? The only early stage startups that I know of that have to have an API
are mobile first so consider adding Cordova and React Native bindings for the
client.

