[miles-po]

Okay, let's spell it out. Your tool requires that you specify endpoints. Then call the ORM or make manual SQL queries. In the example, you have a Todo object.

Do you see the code right here? ``` endpoints.createTodoItem = async function(text) { ... } ``` You've already missed the point of tools like Postgraphile et al when you propose tools like that in a discussion like this. You don't have to write endpoints or even GraphQL schemas at all. You literally just start the tool, passing in the database connection info, and start using it. That's it. That's all. That's what I meant by simple, not how many lines of code they required (which is not much of a benchmark). That's what I meant by apples and oranges. I'm sorry you saw that as an attack, but it's true. It is not just a matter of replacing GraphQL for RPC as you suggest. Or REST for RPC. Simplicity from the point of view of the user, not the server parsing code. Your server is effectively writing a data schema to be consumed by a client. These GraphQL tools write the schema for you.

No code at all (other than database setup) is required to get this working. Zero. https://www.graphile.org/postgraphile/usage-cli/

I hear you on the comment "Is your API meant to be used by yourself? Use Wildcard." However at that level, ANYTHING works. If you start with REST or GraphQL, you may not need it now, but if your project grows, you'll have to rewrite everything. Another minor nit: GraphQL does not require HTTP or even a network layer. GraphQL in and of itself is 100% transport-agnostic.

Sure you could auto-generate RPC endpoints from your database schema, but that requires a tool that does not yet exist, does it? And at that point, what advantage does it afford over GraphQL? It's not markedly more efficient. For that matter, if you wanted the most efficiency regarding RPC, why not use something like gRPC that uses protocol buffers for serialization? If that level of efficiency isn't necessary, then how can you criticize minimal protocol efficiency differences between RPC and GraphQL?

Then there's the issue of vendor lock-in. GraphQL is a spec, and a relatively simple on at that. Nothing more. Nothing less. For the most part different GraphQL backend implementations can be replaced with another vendor/implementation. REST is the same. Can the same be said of your RPC implementation? Could someone seamlessly replace it with another tool without changing any client code? Who are your competitors? (Not necessarily looking to outdo you, just occupying the same spec-level niche.)

As for VC funding, Hasura just got some. Prisma has some. Postgraphile is a one-couple shop with a simple Patreon. The REST libraries don't have VC funding to my knowledge, so that comment from you was largely unwarranted and frankly rude. But more to the point, lack of funding or a development team is not an effective point. What happens to the organization using your software if you get hit by a bus? Why should they take on that risk? Sure they can take over your code since it's open source, but if they wanted to go down that road, why wouldn't they just write their own code anyway? I'm not saying you have to be a major multinational corporation, but single points of failure are not selling points to most folks whether those single points of failure be technical or social.

Lack of redundancy is a hazard. Lack of choice is a hazard. I for one am glad so many healthy competitors exist in the auto-conversion of relational databases to GraphQL.

All the best of luck to you in your RPC endeavors. I'm sorry for being harsh, but you jumped into multiple threads promoting Wildcard without in my opinion understanding what you were comparing against. I hope you find an appropriate audience and user base for it. I fear however that this isn't it for the reasons I enumerated.

[brillout]

I appreciate your elaborate answer. Thank you.

I'm a minimalist and as such I have a problem with complex solutions to simple problems. That's my whole point.

My dream ORM is a an ORM that is designed with a) an obsession on simplicty, b) simple ORM CRUD queries that cover 95% of the data mutation/retrival needs, c) allows you to write "native" (no)SQL queries directly for the 5% cases when you need more complex queries, and d) automatically takes care of migration for 90% of the cases.

The ORM should be trivial to understand, the documentation super small, and the ORM should get entirely out of your way if you want to use your database directly without the ORM. Most ORMs out there (if not all) get these things wrong.

Hasura, Prisma & other auto-generated GraphQL tools are essentially ORMs. Unfortunately, they also get the above listed things wrong. I like that they auto-generate a GraphQL schema, that's neat. That's not my problem. My problem is that they are tightly coupled with GraphQL. That's nonsense. Because (and Wildcard is a living proof of this) you don't need GraphQL for the vast majority of apps out there. People need to understand that GaphQL = generic API = third-party devS. You don't need to expose your data to third parties? You don't need GraphQL. Period. (I hear people arguing about decoupling frontend and backend by using a generic API but that's an old and out-dated idiom, which is another topic I'd be happy to elaborate if you want.)

A simple ORM with a plugin that auto-generates a GraphQL schema? Hell yeah that's awesome. You'd then use the GraphQL plugin only when you need to expose your data to third parties. That's cool.

You don't need to expose your data to third parties? Use an ORM with RPC.

RPC is fundamentally simpler than GraphQL. Why on earth should I use something inherently more complex if I can use something so much simpler?

For example, have a look at how permissions work with Hasura and compare this to Wildcard. The difference is worlds appart in simplicty.

With Wildcard, permissions are written in code:

    // Node.js server
    
    endpoints.deletePost = async function(){
      // Only admins are allowed to remove a post
      if( !user.isAdmin ) return;
    
      // ...
    };

This means that you don't have to understand anything to do permissions -- simply write if statements, just like you are used to while programming other sutff.

With Hasura, you have to use Hasura's custom system of role-based permissions. What I find most annoying about these is that they are not defined in code. With Wildcard all permissions are written in the code - I can simply read them while reading queries.

I hear your arguments saying that Wildcard is new and I understand that you don't want to adopt something that is the "bleeding-edge". (From my perspective; from your perspective, experimental ;-).)

I agree that my way of promoting Wildcard on the whole Hasura thread was less than ideal, I'll improve.

[miles-po]

In code, as long as that code is JavaScript. Looking at endpoints.getPost, assuming you pass in an id, what does that result look like? "It can look like whatever query you're making" is not a good answer. Even if you're the only developer on a project, code you wrote six months ago might as well have been written by someone else.

Let's look at a GraphQL call in terms of simplicity.

  await fetch({
    method: 'POST',
    url: 'http://server/',
    body: `mutation {
             deletePost(id: '542543') {
               id
             }
           }`
  });

That's it for a client call, and I know from the query that it'll return the id of the post (if any) that was deleted.

Using Postgraphile as an example, nothing to do on the GraphQL server side beyond starting it up. In your database:

  CREATE TABLE post (
    ...
  );
  REVOKE ALL ON post FROM public;
  GRANT SELECT INSERT UPDATE ON post TO public;
  GRANT DELETE ON post TO app_admin;

Done. The issue with your approach is that different sections of code may invoke SQL that deletes data. Once a data model lives long enough, edge cases show up. By having the security model live with the data itself, you never have to worry about these edge cases. Set theory for the win! Security bubbles up from the data layer, through the app layer, to the client layer. Also means that if you have two apps talking to the same database, you are no longer required to keep those security restrictions in sync. Got one app in PHP with another in Ruby? No problem. Data security is still intact. Forgot to restrict deletes? Fix the data layer, and the security fix bubbles up. No worrying about all of the possible places that might be affected by this.

Data security at the app level is arguably the wrong level to be implementing it.

Now you may decry the complexity of a fully-formed solution, but honestly Postgraphile meets your requirements quite well. GraphQL really isn't complex on its basic level.

  query {
    post(id: 13245) {
      id
      subject
      body
      author {
        id
        name
        email
      }
    }
  }

Boom. That's the JSON that comes back—follows the structure of the query. Self-documenting. The generated CRUD endpoints cover 95% of needs. Native queries written with the database itself and exposed as functions. Migrations should be handled as either idempotent SQL DDL or repeatable sequence of files at the database level, not the app layer.

Performance-wise, I strongly doubt you'll be faster/more scalable that Postgraphile out of the box. And just because the browser isn't calling the endpoint doesn't mean that GraphQL or REST are useless. Far from it. It's absolutely not just for publicly accessible APIs. That is a false assumption on your part.

GraphQL really isn't as heavyweight as you seem to presume it is. It's just a spec. How someone implements that spec is what makes the difference. As far as request/response sequence, GraphQL is quite cheap computationally. Well documented. Only as complex as the queries you want to make. Hierarchy-aware.

You might as well argue that HTTP is too complex and inefficient; that raw socket calls are better. Why not set up an exokernel?

The reason most of us don't is that it violates the 80/20 rule. Premature optimization and all that. If 99% of the time is spent in the database doing queries and only 1% in your app, fixating on the "efficiency" or perceived "simplicity" of that 1% is a fool's errand.