Show HN: RPC Between Front End and Back End (Node.js) – REST/GraphQL Alternative | Hacker News Reader

Show HN: RPC Between Front End and Back End (Node.js) – REST/GraphQL Alternative

github.com

5 pointsbrillout3 comments

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... 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.

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.

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.

Reply on news.ycombinator.com