Hacker News Reader

Comment by cryptica | Hacker News Reader

I can see three contenders:

1. CRDTs/sync solutions (like Firebase)

2. GraphQL with real-time subscriptions

3. A variant of REST over WebSockets with real-time subscriptions

I don't think #1 will be able to cover all necessary use cases because it is much more computationally expensive (in terms of memory, CPU and bandwidth). Both #2 and #3 are good solutions but I think #3 will prevail in the end because it's a lot simpler.

You can break-up RESTful resources into individual fields which each have their own independent real-time subscriptions (so each observable model on the front end can hold a single property of a resource). With GraphQL, you may end up with overlapping fields between different 'views' and it makes it harder to track/manage subscriptions.

View on HN

This list is very interesting!

Which one performs the best in:

• Raw Performance

• Proven Architecture

• Robustness & Congestion Tolerance

• Backward & forward compatibility

• Customizability

Is ASN.1 by Fabrice Bellard the fastest serialization format? http://bellard.org/ffasn1/

Here's a lits of all formats: https://en.wikipedia.org/wiki/Comparison_of_data_serializati...

GraphQL and REST solutions will almost certainly be much faster than any CRDT solution. I think that the REST solution should be more efficient than the GraphQL solution but it probably won't be a drastic difference.

The essence of the REST philosophy is to deal with data as small atomic building blocks - I think that this is one of the most important and well-tested ideas in software engineering so on that basis, I would go with REST. Though you could also argue that the idea of querying (which is what GraphQL essentially is) is also well tested.

CRDTs are bad with bandwidth and they require very heavy/complex clients that are difficult to implement - Once implemented, they make life easier for many use cases but take away flexibility and customizability.

I think the main challenge with GraphQL actually might be doing access control on the back-end. If you have a GraphQL query that fetches many different resource types, it's a lot more difficult to establish whether or not a user is allowed to access all these resources at once (GraphQL approach) vs just a single resource at a time (REST Approach).

With GraphQL you may have to deal with partial access rights - where the user is only allowed to see part of the query's result. With REST, each request can only have a single allowed/blocked response.

GraphQL should not deal with that at all imo (authorization). the underlying service (rest/database) should be responsible for that. What GraphQL implementation should do is "tell" the underlying service who is making the request and let it handle authorization. And endpoints/fields in GraphQL schema should not be "hidden" based on who is currently logged in.

Just like in sql you are free to see all the available tables in the databases and do "select * from secret_table" it does not mean you will get back any data. The same way you should be able to query any field in graphql but get an error in case you are trying to access data that you are not supposed to.

> The essence of the REST philosophy is to deal with data as small atomic building blocks

It's actually not; that seems to be something imposed after the fact by association of REST with a thin layer over a normalized DB model.

REST is neutral about both the size and atomicity of resources.

Only when you read a filtered list of resources but not for CRUD operations (CRUD operations make sure you deal with a single resource at once). My main point is that writes are atomic.

I thought GraphQL subscriptions are specifically _not_ a "live query", so not to be used as real-time subscriptions?

Or a I reading the current status of the RFC[1] wrong? If so, cool! Would love to have something more standardised than just a 1:1 mapping from rethinkdb or thinky calls over websockets/socket.io.

[1] https://github.com/facebook/graphql/blob/master/rfcs/Subscri...

Reply on news.ycombinator.com