TL;DR: Keep it simple, build an RPC API when you’re creating a single-purpose API for an SPA.
Back in the days there were some heated discussions about RESTful API’s vs RPC API’s. SPA’s were not a big thing yet because almost everyone was rendering server side. API’s were build, but only for integration with external systems and therefore considered general-purpose. RESTful was a better standard for a general-purpose API compared to an RPC API, which were very specific.
A CRUD in a RESTful API looks like this:
GET /api/users: Fetch all users
POST /api/users: Create a user
GET /api/users/:id: Read a user by ID
PUT /api/users/:id: Update a user by ID
DELETE /api/users/:id: Delete a user by ID
The RPC counterpart looks like this:
GET /api/findUsers: Fetch all users
POST /api/createUser: Create a user
GET /api/readUser?id=:id: Read a user by ID
POST /api/updateUser: Update a user (with body)
POST /api/deleteUser: Delete a user
Because of API’s being general-purpose, the RPC-style wasn’t a great fit. Sometimes it would be
DELETE /api/users was considered an easier standard to create more consistency among systems.
This new RESTful way of doing things was great and pretty hyped back then. RPC and SOAP were taking a beating. Nowadays the tables have turned, RESTful vs GraphQL and RESTful vs Serverless are hot topics. RESTful is troublesome when combining resources (requiring multiple round trips) and overfetching is also a thing. With GraphQL you can just fetch the data you need (no more multiple round trips and no more overfetching).
So GraphQL is all nice, but what if your data isn’t all that Graph-like and you’re just building a single-purpose API for an SPA. Why would you need GraphQL? If you know what data is needed by the front-end you can just select all the data which is needed and return it to the front-end, right? However, the front-end might need data from different resources, so RESTful is a bit of a pain… You might start bending the rules of RESTful here with some ?include, ?expand or ?view query parameters, and then you still only need some fields of those resources. It’s quite a pain and it doesn't feel all good (talking from experience).
But there is also Serverless, then I can just create functions to return the data I need. No need for complex GraphQL queries and no need to comply with RESTful. But the Serverless architecture is hard to implement. You need a Lambda-like system and your development environment is not all that great. And then performance issues arise because of database connections and boilerplating. And the timeouts and jobs/heavy tasks might also be a thing.
Or something ancient?
But what about the RPC API’s which were discarded a decade ago… I’m not creating a general-purpose API anymore but a single-purpose API for an SPA using the BFF pattern (https://samnewman.io/patterns/architectural/bff/).
If I go pro/cons on this, it seems pretty simple when you’re creating a BFF and are a fan of YAGNI and KISS. Why not just make an API
/api/readUserAndPosts for that user view with it’s posts…
Why are we using complex frameworks instead of just keeping things simple with Express.js and functions. A single-purpose RPC API in combination with an SPA actually looks like a great fit now.
When you are creating a general-purpose API, then you should look into GraphQL (and no longer make a RESTful API). It’s a really good fit. And you should go Serverless if that is the right tool for the job. Serverless and GraphQL can actually be combined.
I really like all these new technologies by the way, but we should look back once every while to make sure we’re not running in circles :)
Thanks for reading! I hope you enjoyed the read. Please let me know what you think.
Buying me a coffee will help me to finance this hobby project and to keep me awake ofcourse :)