Envek

8 ms·

1. 1.▲
   Kubing Rails: stressless Kubernetes deployments of Ruby apps with Kuby(evilmartians.com)

   10 points by Envek 5y ago|0 comments
2. 2.▲
   by Envek 5y ago

   > I would have guessed a post like this would be satire! It is… burlesque!
3. 3.▲
   by Envek 6y ago

   > the natural assumption would have been that ActiveRecord model classes should double as GraphQL result objects, and there would be a nice DSL for specifying how to safely expose those objects to the API. GraphQL-Ruby Types _is_ that DS
4. 4.▲
   by Envek 6y ago

   > have created a completely parallel schema - new classes for every object in the GraphQL graph, which are analogous but separate from the Rails models, each one acting like a combination of controller and presenter And IMO this is good.
5. 5.▲
   by Envek 6y ago

   There is also abandoned graphql-preload gem with absolutely amazing API (it wraps graphql-batch under the hood): https://github.com/ConsultingMD/graphql-preload It is very sad that its creators are left and current own
6. 6.▲
   by Envek 6y ago

   +1 on this. GraphQL is a great way to actually decouple your API from underlying database schema. When you start thinking not about specific REST endpoints, but about API data model in general, it turns out that it is much better to hide ma