
GraphQL Tooling, Today and Tomorrow [video] - sgrove
https://www.youtube.com/watch?v=JilN_PvQOqs
======
nailer
As a JS/TypeScript dev: just give me typing, DB schema, and an API in one
place.

Currently we have TypeORM, which does typing and DB schema but requires you to
make a separate API. And we have Prisma, which is a DB schema and API, but
still requires you to maintain types.

~~~
adamkl
I always hesitate to model an externally facing API to match the underlying
database schema because you end up coupling consumers of the API to its
internal implementation. Mind you, I'm coming from an enterprise background
where systems live way longer than you expect them so, so you need that
flexibility.

If that's not a concern, and you want speed/ease of development, take a look
at _TypeGraphQL_ [1]. They have a couple of examples [2][3] of how nicely it
plays with _TypeORM_. You can create one set of domain object classes,
annotate them with decorators for both TypeGraphQL and TypeORM, and then
expose a GraphQL schema that matches the underlying database with a minimal
amount of code (you could probably even get clever with some generic fucntions
to cut down the code you'd need to write for the resolvers).

[1] [https://typegraphql.com/](https://typegraphql.com/) [2]
[https://github.com/MichalLytek/type-
graphql/tree/v0.17.5/exa...](https://github.com/MichalLytek/type-
graphql/tree/v0.17.5/examples/typeorm-basic-usage) [3]
[https://github.com/MichalLytek/type-
graphql/tree/v0.17.5/exa...](https://github.com/MichalLytek/type-
graphql/tree/v0.17.5/examples/typeorm-lazy-relations)

~~~
jayd16
Agreed. Api, business logic, and normalized DB all have different
requirements. Smashing them together works great for prototyping but in the
long run it leads to pain.

~~~
nailer
Business logic is seperate from typing, schemas and APIs. APIs and schemas are
the same thing - the API is literally a query language for the DB.

~~~
adamkl

      the API is literally a query language for the DB
    

No, SQL is literally a query language for the DB.

The API is the contract you define for how people with interact with your
application. While some people may choose to model this after their underlying
database, conceptually, they are very different.

On small applications, maybe you can get away with treating them as one and
the same, but for longer-lived applications which need to integrate and co-
exist with other systems/services, that choice can come back to bite you.

I'm not saying you shouldn't/can't treat them as the same thing, just be sure
you know the trade-offs and long-term repercussions.

------
nitinreddy88
We are in the process of debating ODATA Api vs GraphQL for data analytics.
Anyone with extensive experience can share some light/guide us.

~~~
_92eu
With HTTP2, it's now almost always better to go with a RESTful API, especially
if you need to do heavy calculations and display dashboards with a lot of
data.

You will be able to fine tune your cache settings and monitor the performance
of your endpoints ([https://medium.com/@__xuorig__/why-graphql-performance-
monit...](https://medium.com/@__xuorig__/why-graphql-performance-monitoring-
is-hard-41381bc7c44d))

You will be able to fetch resources in parallel and start displaying data
faster (GraphQL Apollo is also able to do some king of streaming, but it
relies heavily on non-standard network hacks).

You will be able to use Vulcain
([https://vulcain.rocks/](https://vulcain.rocks/)) which will allow you to
fetch your whole resource graph at once using HTTP2 Server Push.

The only reason you may choose GraphQL is if you need to go fast and want to
profit from the DX of the awesome React libraries available such as Relay or
Apollo.

~~~
strken
This is misleading and parts of it aren't true. Comparing GraphQL to REST is
apples to oranges and misses most of the advantages.

GraphQL is a way to dynamically generate API endpoints[0] from A) a schema
describing a graph, B) a query describing the endpoint, and C) functions which
fetch objects from the graph defined in A.

Why would this be useful? Can't you just write endpoints or use a single
RESTful endpoint per model? Well, on some large projects, you have a very
large number of endpoints supporting a slightly different set of views that
are all based on the same data, and most of those endpoints load more data
than they need. GraphQL allows you to replace an entire suite of presentation
layers with a declarative schema that's smaller and more easily reasoned
about, and which only loads what you actually need.

You also get some other things for free - n+1 queries happen within the data
centre and are therefore faster, you can avoid opening a lot of HTTP1
connections, etc. - but these things are only side benefits. The core benefit
is making your big procedural presentation layer smaller and more declarative.

[0] This is not strictly true, a GraphQL query isn't an endpoint, but for me
they occupy the same conceptual space.

~~~
deckard1
> Comparing GraphQL to REST is apples to oranges

Just because you say that, doesn't make it true.

> most of those endpoints load more data than they need

GraphQL proponents seem to forget query parameters exist. It has _never_ been
the case that REST _has_ to return more than you need. Never. Not now, not ten
years ago. Why people keep repeating this obviously false claim is bizarre.

The hoops you have to jump through to get GraphQL efficient as off-the-shelf
REST are rather insane. Caching, both client and server side, have to be
entirely reinvented. What Apollo does may be open source but it's also
proprietary. And at this point, a single corporation controls the entire
stack. Without Apollo, GraphQL is a terrible joke.

~~~
strken
> GraphQL proponents seem to forget query parameters exist. It has never been
> the case that REST has to return more than you need. Never. Not now, not ten
> years ago. Why people keep repeating this obviously false claim is bizarre.

You need to use something that does the same thing as GraphQL, e.g. allows you
to define a graph of relationships and then query them, and can have many of
the same tradeoffs, e.g. not being cacheable or not allowing you to stream the
result. If you like the other thing better than GraphQL (I've used
[https://jsonapi.org/](https://jsonapi.org/) and
[https://loopback.io/](https://loopback.io/), among others), by all means use
it.

This is what I mean when I say comparing GraphQL to REST is apples to oranges.
REST is general and broad and GraphQL is narrow and specific, so the
comparison isn't meaningful unless we start talking about specific libraries,
frameworks, specs, or patterns that use REST to do the same thing GraphQL
does.

~~~
digitaltrees
Check out Graphiti.dev it shows how a few common sense conventions in REST
give most or all the power of GraphQL.

I think the phrase “comparing apples to oranges” is a bit misleading in this
context because it is normally used to imply that such comparison is
impossible or not useful (i.e. a fruitless exercise, sorry, I couldn’t help
it). But here there is a lot to compare.

REST is built with the basic infrastructure of the web in mind so massive
amounts of infrastructure like caching, error messaging do need to be rebuilt.
GraphQL has some real benefits so a comprehensive comparison is worth it.
Ultimately both are an api design to facilitate getting data. It’s sort of
like comparing Postgres to MongoDB. Yes there are major differences but the
expected use is to store data. Comparing is crucial.

Either way. Have fun building cool stuff.

------
dominotw
when i make a graphql request in chrome request is an unformatted string. Is
there an extension someone would recommend that would make it easy to spot
server interactions in a formatted way.

~~~
striking
[https://chrome.google.com/webstore/detail/graphql-
network/ig...](https://chrome.google.com/webstore/detail/graphql-
network/igbmhmnkobkjalekgiehijefpkdemocm)

------
swyx
great talk! :)

