4 ms·
Is this using the Facebook GraphQL C bindings? If not, what's the advantage of a full reimplementation in Scala? I'm not implying that the bindings should have
by vimes656 11y ago
Is this using the Facebook GraphQL C bindings? If not, what's the advantage of a full reimplementation in Scala?
I'm not implying that the bindings should have been used. I'm now considering writing a implementation of GraphQL in Haskell and I'm trying to assess whether it's worth using the Facebook C bindings or it's better to implement the whole protocol from scratch.
- tel 11y agoPortability and easier compilation.
- tenshi47 11y agoIn contrast to some other languages, it's not common in JVM community to use native (platform dependent libraries written in c, c++, assenbly, etc.) libraries. I only saw examples of it for code that tightly integrates with the host hardware (e.g. directly uses drivers of some uncommon hardware devices) or other similar scenarios, where you generally don't have other choice but use native libraries. I think main reasons for this are platform independence and ease of building/packaging/deployment. Also JDK (standard library) and library ecosystem are strong enough to provide pure jvm-based library implementations for most of the scenarios. JVM performance is also pretty good, so there is no necessity to write/use native libraries just to make application more performant.
- leebyron 11y agoThe libgraphqlparser project only provides C bindings for a GraphQL language parser but not an query runner or validator which often have differing APIs to feel natural in each language. Sangria implements query running as well.