Working in the field of software engineering for a decade, I experienced the rise and fall of SOAP, adopted REST and assessed GraphQL. The web race is for speed, every new alternative technology adopted today is justified only if it makes our web applications faster, more efficient, maintainable and more scalable.
GraphQL became a good candidate to avoid the problems I had when implementing APIs using REST. Some of them are, over-fetching, under-fetching and back-end negotiations on status codes and HTTP verbs.
In the first attempts to use GraphQL, I began to worry about performance issues around N + 1 queries, so, instead of continuing to spend more time reading an extensive and well-written specification and recipes for problems that I have not yet encountered. I decided to create my own library to query APIs regarding the following goals:
- Low learning curve (easy to pick and use).
- More efficient than existing tools(faster).
- Straight from the web (not a new language or specification, just augment what we have today).
- More freedom for the API consumer (allow the consumer to specify exactly what they want).
- Predictable query cost (increase consumer awareness and responsibility, related to goal 4).
- Don't reinvent the wheel (this really doesn't matter to me, however, it also works as a motivation).
With that in mind, and several proofs of concepts, I thought I could query the APIs using JavaScript as a query language. That's it, without proposing a new DSL. Let's take into account that there are enough specialized query languages for APIs out there, the most noticeable, GraphQL, Falcor, OData, restQL. The intention was just send the JS code to the server à la PostgreSQL DO or Redis eval. It is a crazy idea, but at the same time it became a hard to ignore challenge.
I end up with a TypeScript library for NodeJS and the browser which allows to query API in the following fashion:
const getArticle = func(async (slug: string) => {
const { name, date } = await BlogApi.getArticle(slug)
return {
name,
date,
}
})
getArticle('fancy-slug').then(...)
Remote-func not only met the proposed objectives. It also,
- Makes end-to-end type safety possible if used with TypeScript.
- Allows greater independence between frontend and backend developers.
- Can fetch multiple resources at once.
- Allows to reduce the data before sending the response to the client.
- Can batch and deduplicate requests.
- Can stream data from server to client in a single HTTP response, and dispatch in the order of arrival.
And a little more features that you might find useful.
Top comments (2)
From what I understood, you are basically sending a function to the server calling the server function?
Sort of that, but there is a lot under the hood, loop protection, sandboxing, and more. Currently the development is focus on avoid malicious memory manipulation. The goal is to create a safe runtime environment to run untrusted JS code.