5 ms·
I can remember when Git began to replace Subversion, but a lot of companies resisted the trend, because Git was so radically different. Subversion was comfortab
by lkrubner 11y ago
I can remember when Git began to replace Subversion, but a lot of companies resisted the trend, because Git was so radically different. Subversion was comfortable: everything was centralized, and the revision numbers went up in an orderly fashion: 1, 2, 3, 4, 5, 6... You always knew where you were in history, with Subversion. It was clear that Git was better in some fundamental way, and yet it took effort to understand it, conceptually, at first.
I feel like the same thing is happening now with GraphQL versus REST. On some level it seems like GraphQL is altogether better than REST, but we don't see a mad rush to adopt GraphQL, because it represents a big shift in thinking, and those of us who just spent the last 10 years creating RESTful interfaces, we are a bit slow to throw out all of our work and start over with GraphQL. Also, the frontend needs to change as much as the backend, so it requires a full re-write of everything.
All the same, a title like "Scale vs. Node.js as a RESTful back end server" does strike me as an anachronism in 2016. Who cares? I doubt I will ever again build a RESTful interface. Rather, on the project I'm working on right now, we are getting rid of the RESTful interface and we are looking at our GraphQL options:
https://github.com/chentsulin/awesome-graphql https://github.com/chentsulin/awesome-graphql
Is Scala or Node.js the best option for building a GraphQL server? That would be an interesting article.
- pjmlp 11y agoI use Subversion daily. I am yet to experience an enterprise customer that has jumped into Git.
- yareally 11y ago> I am yet to experience an enterprise customer that has jumped into Git. My company recently did (1000+ employees), though from what I've seen, many of my coworkers familiar with only svn are still using git like svn. We also have a lot of legacy code still within svn (various reasons outside of my team's control), so the transition is pretty messy IMHO.
- kazagistar 11y agoI have a question I have been trying to figure out for a while. All the examples of clients that use GraphQL seem to be javascript; is there any support for writing, for example, a Java client to talk to a GraphQL backend? This would really help make it easier to port infrastructure over piece by piece.
- hackerboos 11y agohttps://github.com/chentsulin/awesome-graphql#lib-java https://github.com/chentsulin/awesome-graphql#lib-java
- kazagistar 11y agoI found that link before, but aren't those all backends?
- lkrubner 11y agoYou can write the server in any language, and you can also write the client in any language. As a point of comparison, consider SQL databases such as MySQL or Oracle or MongoDB. There are clients written in dozens of different languages.
- e1g 11y agoGraphQL defines the query language, but uses simple HTTP as the transport. It's not like like redis or mysql - those use custom protocols and so require special clients to use them. GraphQL backends are like Elasticsearch backends - you access them by hitting the exposed HTTP endpoint with your query in plain text. You could do this with any HTTP client library in any language, or even with curl.
- kazagistar 11y agoThats true, but in a typed, structured language, you generally build some kind of data structure to deserialize responses into. With REST endpoints, each response can be translated to a specific predefined object in a client library. GraphQL seems to, by design, ignore this kind of usage in favor of the "heterogenus untyped dictionary responses"... do I really have to write custom data types for every single different query?
- deleted 11y ago[deleted]
- xirdstl 11y agoIt is wise for most companies not to rush to the bleeding edge as technology changes.
- daxfohl 11y agoHow would it be different? This article could be retitled "Is Scala or Node the best option for building a backend server", without any other changes, and it would cover both use cases (plus plain old html server etc).