
Rejoiner: Unified GraphQL schema from gRPC microservices - patrickaljord
https://github.com/google/rejoiner
======
adamkl
We were looking at an architecture exactly like this (GraphQL front end,
backed by gRPC microservices), because we liked the strongly typed interfaces
of gRPC, and the flexibility of GraphQL, but we ran into some technology
issues (http/2 support in our PaaS) that made it a non-starter.

We found that we could get the same benefits (minus the performance of gRPC)
by just using GraphQL for all of our microservices, and dynamically stitching
them together with Apollo’s graphql-tools[1].

We’re really high on the approach because it lets us develop independent
services, each with a strongly typed interface, and then mix and match them
into a single GraphQL interface on the fly.

It’s been gaining a lot of traction internally at my company. We even put
together a “create-react-app” for GraphQL so our teams can easily spin up new
services.

[1] [https://www.apollographql.com/docs/graphql-tools/schema-
stit...](https://www.apollographql.com/docs/graphql-tools/schema-
stitching.html)

~~~
Sirupsen
GraphQL for RPC is an interesting approach. What do you see as the
disadvantages? It'd seem to me that not all services can be neatly represented
as a 'graph', which gRPC works well for. Have you run into this?

~~~
the_duke
How you model a GraphQL schema is up to you.

You can just treat it as a realitvely flat, rest-like schema that does not
have much in terms of graph relations.

The Graph in GraphQL is mostly optional.

~~~
adamkl
Exactly!

------
friendly_chap
It seems like slowly but surely the industry is realizing the incredible
productivity penalty of microservices/fas etc, and just generally any model
compared to your good old ORM in a monolithic codebase approach.

I still feel like we are way ahead with the concepts in (shameless plug alert)
[https://github.com/1backend/1backend](https://github.com/1backend/1backend)
when it comes to the big picture of building microservices that actually build
on each other, although it's statistically very likely this is just a personal
opinion :)).

Anyway, I'm generally happy that this space is advancing, as someone who spent
most of his recent career in this space I almost gave up hope: simply there
was not even a common vocabulary to properly discuss ideas, everybody just
wanted microservices because that was the next cool thing, and looked
absolutely perplexed when explained the pitfalls.

GraphQL, this, and all the different kind of faas platforms popping up
nowadays all help as a point of reference.

I truly think we are on the verge of radically changing how we build
applications soon - I think these technologies can be viewed as a new breed of
web frameworks, a breed which has the distributed principles in its core.

~~~
chuhnk
Remember there's a trade-off to everything and that systems naturally move
towards being distributed as they scale. Not just technical systems but all
systems in nature. There's always a singular starting point and the move to
distributed systems is one where trade-offs are being made to solve specific
problems. Taking this approach pragmatically leads to the adoption of
microservices and functions at the right time.

This library solves a specific problem at the query layer. It's definitely
time we had something like this across microservices and functions. There have
been other attempts but in unstructured ways.

It's likely in the long term systems architectures are multilayered.
Monoliths, microservices and functions along with graphql or other query
models all within the same environment.

~~~
friendly_chap
Very nicely put. I agree it's an evolution, but I see a lot of companies waste
a lot of time on the monolith -> services transition phase.

Usually what happens is that they try a complete rewrite which turns out to be
rather expensive (especially in opportunity cost). They should ideally just
move the pain points (ie. performance problems) to services and optimize that,
but the enthusiasm towards the shiny new way of doing things that will fix
their problems is so high that they opt for the riskier move of rewriting all
the things.

That scenario is simply so dangerous and expensive that companies will be
better off starting with a proper distributed framework - which doesn't really
exists yet, but we are slowly getting there.

Anyway, this is just my 2c but I have seen this pattern of full blown rewrite
at a lot of places.

~~~
chuhnk
The rewrite approach is definitely painful but that can at times also stem
from failures in previous attempts at moving from monolith to services. The
problem usually arises because there's no real definitive structure or
architectural choices around the breakdown. It's a very ad-hoc thing that
results in building an even more brittle system.

When you start to breakdown the monolith you may end up with 10 services all
using different databases, message queues and message formats. Going the whole
rewrite approach usually involves defining an architecture and single uniform
approach to development which eventually leads to higher productivity since it
eliminates choice and lets you focus on the important tasks.

I do however agree that not everyone who does it needs to.

------
KenanSulayman
> Note: This is not an official Google product.

~~~
eugenhotaj
Yea not directly supported by Google, but being built by Google engineer(s).

~~~
thangngoc89
This is from the README of the project. I think the reason this was posted
here because the original title of this thread was "Google released ..."

------
brango
Looks interesting, but TBH I'm still waiting for full swagger spec generation.
It should be easy to go from grpc->swagger to generate REST client libs.
Unfortunately in practice the swagger generator has many holes in it making it
useless in several use cases. So... without being able to generate swagger
specs it looks like gRPC is no use for a large number of use cases. Shame
really since it has promise but still seems half-baked.

~~~
bognition
> It should be easy to go from grpc->swagger to generate REST client libs.

I theory yes, but would you want to? In my experience I've found that building
REST services is very different than building a GRPC service. The contract
between the client and server are totally different.

> gRPC is no use for a large number of use cases. Shame really since it has
> promise but still seems half-baked.

gRPC is half-baked? You realize that the a large portion of the google backend
is built on top of gRPC. Its an extremely well tested tool.

~~~
tejasmanohar
How much of the Google backend is actually built on top of gRPC? My
(outsider's) understanding is gRPC was the "open-source version/rewrite"
(typical Google) of Google's internal software, stubby. IIRC, _some_ of the
Google Cloud public-facing APIs use it, but what else?

As a proponent of gRPC, I can say that some of the libraries, tools, docs,
etc. are definitely half-baked. There are plenty of severe issues in the
(confusing codebase of) grpc-go that have been open for over 1.5y.

~~~
anameaname
FWIW, the primary maintainer of grpc-go left the team and it was passed on to
a new maintainer. The new maintainer inherited the mess. Not justifying the
project or anything, but I think that's why. Look at the Github top
contributors to see what I mean.

