Sponsors


Sentry use the code "devchat" for $100 credit
TripleByte


Panel


Dave Kimura
Nate Hopkins
Charles Max Wood


Special Guest - Radoslav Stankov

 

In this episode, the panelists of Ruby Rogues speak with Radoslav Stankov about GraphQL and its implementation in depth. Radoslav is based out of Sofia, Bulgaria and is the head of the engineering team at Product Hunt. He is a full stack developer since 2002, working on JavaScript, Ruby on Rails, Elixir and GraphQL.

 

Show Notes:

0:00 – Charles introduces the panel and the special guest.

0:30 – Advertisement: Sentry - Use the code “devchat” to get two months free on Sentry’s small plan.

1:40   - Radoslav introduces himself and gives a short description about what he is working on.

2:20 - Charles asks him about the stack at Product Hunt and details about the company. Radoslav gives a brief historical background while explaining that they moved to GraphQL two years ago. He states that his team consists of about six full stack developers. He explains that GraphQL is their main API currently for communicating with the Rail backend and a React client in the front. He also mentions that they released a new iOS app recently.

5:12 - Charles asks if increasing number of websites are moving toward the mentioned model where Rails provides the backend API and rendering happens in the front. Radoslav agrees while saying Rails is faster but if the complexity increases, it starts becoming increasingly complex. He gives an example of views to explain his point. He interprets GraphQL as an update on REST API which is much cleaner and easier to work with. 

7:08 - Dave agrees that GraphQL is interesting and compares it to SOAP interface while explaining the comparison in detail. He asks Radoslav the reason why GraphQL is used internally without a client facing API. Radoslav answers that he prefers GraphQL to be private and explains with an example using it internally is very flexible, hassle free and can be used for anything that the user wants to do in a simple manner. 

11:30 - Dave asks does GraphQL handles versioning as the application matures. Radoslav elaborates on it by saying that versioning is similar to REST API and with GraphQL, the scheme is statically typed and it’s easy to identify information such as which field was requested frequently by the customer and which needs to be deprecated. 

14:08 - Dave asks if GraphQL has a documentation API like Swagger. Radoslav talks about a tool called “graphical” which is an IDE for graphical queries that generates automatic documentation.

15:31 - Nate asks about the origin of the metric tracking in GraphQL. Radoslav says that it comes from certain tools, that all the libraries such JavaScript, Ruby, Elixir have instrumentation hooks and information is obtained by plugging into them. 

16:22 - Nate then says that this is basically like hoisting SQL database to frontend layer and then goes on to ask how the database queries are optimized. Radoslav explains in detail that the optimization is done similar as normal Rails and explains the process of batching. He mentions that he has written two blog posts on the same topic - optimization for N+1 queries.

19:27 - Dave shares that GraphQL has a good feature where you can restrict the query based on what the user wants. Radoslav talks about the method of caching for optimization. 

21:30 - Charles asks if building resolvers has gotten better than before. Radoslav answers in affirmative and talks about the usage of classes, methods and mutations that makes the procedure simple. He explains that one of his libraries has a GraphQL plugin where you have to define search queries and it exports those to GraphQL types and arguments that can be plugged into GraphQL schema.

24:20 - Nate asks about the implementation of GraphQL components. Radoslav says that it is separated into a single namespace, exposed to a controller, the GraphQL types are matched to REST serializers. The frontend has Reac