I've been hearing a lot of developers raving about Graphql. After implementing in Ruby on Rails, I've begun to realize that it essentially does the same thing as JBuilder, which is built-in to Rails 5.
From a Rails perspective, what benefit does Graphql provide over JBuilder? Are they essentially used for the same thing? Is there something I'm missing in regards to Graphql?
One of the advantages of GraphQL is the fact, that it's a formally specified standard with its own query language.
It's safely-typed standard with its own specification. This means, you can interop with servers written in different tech stacks using the same query language and type system.
Since it's standardized, a few frontend js libs (Relay and Apollo) have taken advantage of that, making it very easy to cache and define tailored, client-scoped queries and mutations.
It exposes its own structure as so called Introspection API. This means that, you can document your API and query it using GraphQL itself - its self-descriptive. This gives a space for tooling support - example of such is GraphiQL, which allows to explore GraphQL schemas with ease. When using GraphQL, this feature is basically granted for free. You can see it in action i.e. in Github API Explorer, which also uses Ruby implementation of GraphQL AFAIK.
While most people think about it in terms of request/response, it also exposes publish/subscribe capabilities as GraphQL subscriptions via web sockets. Also within a standard.
Related
I've recently started development on what will be come a rather large mobile application (React Native) that consumes a Ruby on Rails API (in API mode).
On the frontend I've used TypeScript extensively throughout the code but I am having issues with how to approach building types and interfaces for data received through API requests. I've heard about transpiling C# database models into TypeScript types - but I can't find anything similar for Ruby on Rails. The only thing I've been able to find is how to handle types in mono-repos where both the frontend and backend is in a single repository.
I could build my types manually on the frontend but I feel like this wouldn't be sustainable over the long term, especially when new developers join the project.
Is there any gems out there for this or would I have to write it myself? Am I approaching the issue incorrectly?
I could build my types manually on the frontend
This is probably the best choice as it encourages decoupling between the frontend and the backend API application. The whole idea of automatically generating front end code based on your database sounds good in theory but your frontend is not talking directly to the DB - its talking to your API and should have no knowledge of the underlying data storage which is an implementation detail of the API.
This is also the reason why you only see this attempted in a monorepo - it requires a tight coupling which is very undesirable. If the backend schema changes it will break clients - which would not occur if they simply communicate through a versioned API. As long as the API remains consistent the clients are isolated to a very large degree from changes on the backend and can occur in tandem.
You also have to take into consideration that ActiveRecord is extremely dynamic compared to anything written in C# and most other frameworks. Model attributes are automatically definined at runtime by reading the schema directly from the database - its all superninja level metaprogramming. So you can't use any form of static analysis to create fronend code from the backend code alone.
I am trying to use Google's new speech to text api: https://cloud.google.com/speech/docs/rest-tutorial . They currently have python and node.js examples.
Unfortunately, my application is RoR. I was looking through https://github.com/GoogleCloudPlatform/gcloud-ruby , which is a gem that interacts with google cloud services (but not speech). I was hoping that I could use the two together to come out with a working solution, but my knowledge of how to use API's is limited.
Enough background, my questions are:
Does anyone know if Google is going to put out a Ruby version of the speech to text api? If yes, is there a timeline?
If I am impatient, how would I go about using their current API's. By this I mean, is there a good resource for someone to learn how to use generic API's?
The gcloud-ruby gem now supports google-cloud-speech.
To address your other questions, there are no language specific versions of the APIs themselves. They are all HTTP APIs (either REST or gRPC), so they can be used from anything that can make HTTP requests. It can be tricky to use them directly though, because of things like how authentication is handled, which is why client libraries exist for different languages.
If you want to learn more about how to use the REST APIs directly, first take a look at the doc 'Using OAuth 2.0 for Web Server Applications' to find out how to manually authenticate, which has examples for Ruby and raw HTTP/REST.
I am implementing an app that uses RoR for the backend and AngularJS for the frontend.
These layers are totally split, frontend talks to the backend over REST API. Due to nature of the system sometimes it must pass certain SQL-like conditions to the request in order to limit amount of retreived data.
Are there any de-facto standarized ways of doing this? Some conventions for naming parameters etc.? Preferably some solutions that have their Ruby implementations in gems, and JS libraries ready for AngularJS.
I don't want to reimplement the wheel.
I'm new to rails and am in the process of building my first app. The app in question needs to be built on top of an internally built API which is responsible for interfacing with our data layer.
Having read around on Stack Overflow and the web in general it seems as though Active Resource is a pretty neat tool for this however my question is whether it will work for the specific API I am consuming which is:
JSON output
Built in PHP and not Rails (although it is RESTful)
(point number 2 is the one I am most concerned about as, from what I have heard/read so far, Active Resource is primarily designed to consume API's from other Rails apps)
Thanks
JSON output - it will work. Default format is XML, but ActiveResource also supports JSON (PS: you will have to set format to :json somewhere in config).
API is built in PHP - as long as the response is in standardized format so ActiveResource can parse it, it doesn't really care whether the response was generated by Rails, PHP or monkey behind the typewriter :).
As you said, ActiveResource is used primarily as a way for several Rails applications to interact with each other, but it is also meant to be used in the way you intend to.
A Rails 3 application running on Postgresql needs to switch to a graph database to be able to grow up. There are many of them and they all offer different kind of API, REST mostly.
I am highly inspired by talks of Emil Eifrem, CEO of NeoTechnologies, about what can be accomplished with Neo4j. I must confess, I've played with it and this thing is absolutely what we need, but there are several obstacles.
REST API is not transactional.
Rails 3 apps are running on ruby 1.9.2, but not jRuby 1.5.3 or 1.6 to achieve native API.
Some databases are also driven by Java and offer REST API, so taking them changes nothing. Someother are not an option for us because of a license or a cost or a lack of team behind them.
I assume I'm missing something, so would appreciate any tip, insight or advice about what are our options and and what can play well for us. Thanks.
You can run Neo4jrb with Rails 3 on jruby 1.6, so that should not be a problem.
To run a transactional (REST) API on top of that you can easily write your own Neo4j-Server plugin/extension that could also use Neo4jrb internally but exposes an API that fits your domain and is less verbose/chatty than the fine grained Neo4j-Server REST API. This should also be easier to consume for your clients as it talks in your terms, vocabulary and use-cases.
We're currently working on creating a generic (j)ruby server extension that is able to consume posted code and make it available as new REST endpoints.