Build Better GraphQL APIs: Thinking in Graphs | Hacker News Reader

Build Better GraphQL APIs: Thinking in Graphs

graphqlme.com

98 pointsmengledowl32 comments

Blanking out the article and showing a newsletter signup form after less than 1 second on page = worthless. These tactics do not work, you just end up annoying readers and getting spam entries.

Do they really not work? Every bi department I’ve ever heard running the numbers, so far, have been sorry to say they do. I’ve never met a company happy to put them in, either. It’s always “ugh, the numbers show big tick ups in engagement, we have to do this -.-“

Do you have different experiences?

People do sign up for newsletters, but not before they even get a chance to read anything. It's a fine balance between value and trust.

Business websites are different, usually with some important gated material behind an email signup but even then there is plenty of spam. Most marketing departments never bother to measure the bounce rate and attrition from these tactics so if all you look at are email signups, then of course it looks like it works.

>People do sign up for newsletters, but not before they even get a chance to read anything. It's a fine balance between value and trust.

There was an article that did it really well. I forget who it was but it was a good article about Mongo, about 1/2 - 2/3rds of the way through, it put a CTA and an email input box inline. It was obvious what it was, but didn't shove it in your face.

This article could be as interesting as it gets, but opening the page yields a newsletter form with white background.

I thought I opened an article, not a newsletter subscription.

Who sane in their brain thinks this actually lead to new newsletter subscriptions? It's content hijacking.

> Who sane in their brain thinks this actually lead to new newsletter subscriptions?

They probably have metrics showing so. Otherwise they really are insane.

True. Much like spam, success rates - depending on the goals - can be measured in the low single-digit percentages. If you scare away 95% of folks but your target is harvesting 3% of visitors' email address, this is a successful approach.

That's fine, to each his/her own. I'll stick with the 95% that ignore the prompt or (in my case) close the window when the screen blanks.

I'd love to see the numbers on open rates of the emails he gets this way. (I am going to guess they are incredibly close to 0%). Let alone any conversion from the email.

> This article could be as interesting as it gets,

No, unfortunately it's shit. Not even a worked out full example.

A few articles on the same topic:

https://blog.graph.cool/thinking-in-terms-of-graphs-a9087423... https://dev-blog.apollodata.com/the-concepts-of-graphql-bc68...

And a more full featured tutorial:

https://www.howtographql.com/

Full disclosure - I'm the co-founder of Graphcool.

I was very disappointed to find out that GraphQL wasn’t a generalized query language and much more discreet manually defined API, more of a rest api pretending to be a query language.

That is to say I can only filter in ways the API developer thought of, specifically blessed.

Don’t get me wrong, it’s amazingly useful. A process that took us 40 seconds of back and forth with GitHub now takes less than one second.

There is a balance between arbitrary queries and predermined queries.

One the one hand, you need to be flexible. On the other, allowing any query no matter how horrendous can be bad for a public API.

IMO, GraphQL strikes the perfect balance for a public API.

I was very disappointed with the same thing! However, it is very easy to get rid of the resolver-based execution model and turn it into a generalized graph query language. We've done that at my company and it's been working well for us -- here's our blog post: https://blog.kensho.com/compiled-graphql-as-a-database-query...

We also open-sourced the GraphQL compiler code that lets us write graph queries: https://github.com/kensho-technologies/graphql-compiler

    pip install graphql-compiler

Have you considered trying orientdb?

http://orientdb.com

I'm implementing filtering in a graphql api now, on a sql backend (a fixed constraint). We decided we just can't support arbitrary filtering. Full table scans don't scale, and an index for every column is costly. So we'll support it only on indexed columns and add indexes selectively.

If graphql did require arbitrary filtering it would be useless to us at this point.

Have you looked into PostGraphQL?

https://github.com/postgraphql/postgraphql

That looks like a nice tool for generating a graphql schema. Resolving functions are still required.

Resolving functions are included. I'm using it to power a fully-functional GraphQL service backed by a PostgresQL database. There's a newer version at https://www.graphile.org/postgraphile/ by the same author.

Check out [0] and similar projects out there. GraphQL is a query language. It doesn't have to be used for APIs - the Apollo team is using it for state management [1] and others are using it to handle all sorts of non-API data. That being said, it is a Facebook technology released in the context of APIs and it is only three years (publicly) old, so naturally, that is where you are going to see the majority of usage.

[0] https://github.com/apollographql/graphql-anywhere [1] https://github.com/apollographql/apollo-link-state

As other folks have mentioned, there's no reason this has to be the case. It's totally possible to take a basic GraphQL schema and programmatically enhance it with generated filters based on field types. Graphcool offers this. I think it makes a much better platform for this than REST. My guess is that eventually, standards will emerge. We can already see it in Relay, with their connection pattern for pagination.

> Stop Thinking In Endpoints > How To Start Thinking In Graphs

Ok. I've started to think in graphs. You know. Neo4J, Tinkerpop Gremlin, all that.

Oh, wait. How does that help me create that graph in a sane and meaningful way from a relational database and a number of microservices, especially if all the requests can be ad-hoc graph queries?

Ah, yes. The article (and all other articles on GraphQL) never answer that, do they?

You build a "query language" that translates the GraphQL into a series of calls to your nanoservices ?

We refer to them as picoservices, but yes.

Why would I want to do that though? :)

It's quite an undertaking, increases the surface of bugs and attacks etc.

There are really elegant solutions coming out around this - I suggest watching some of the talks from this years GraphQL summit.

I propose that if you have tables and want graphs, you will have to consider the tradeoff in compute resources required to generate meaningful aggregate results (count all customers, etc). So the answer is usually keep your tables and use graphs when appropriate.

Yeah, IMO GraphQL is not at all hard to grok, and its benefits to an API consumer are pretty obvious. But I have no idea, as a developer, how I'm supposed to implement a GraphQL interface to my non-graphical database(s) in a secure, performant, and repeatable way.

My company has built and open-sourced a tool that can turn your ad-hoc graph queries into database queries. We've completely abandoned GraphQL's resolver-based execution model, and we simply turn the GraphQL directly into a database query and run it on the database itself.

Check out our blog post: https://blog.kensho.com/compiled-graphql-as-a-database-query...

Open-sourced tool: https://github.com/kensho-technologies/graphql-compiler

    pip install graphql-compiler

Hypermedia (HATEOAS, REST, etc) is graph thinking as well. “endpoints” is not synonymous with “REST”, it is merely an address (likely paired with an expectation (or affordance).

I really appreciate when anyone is willing to share knowledge and experience on subjects... but in this case none of what is said has any real unique insight to graphs over just really really basic data modelling. Even just the notion of needing to think in graphs for GraphQL is really an unnecessary conflation of modelling theory and technical abstraction.

GraphQL is really badly named. It is just REST vNext and it confuses a lot of folks on what it means and how to use it.

This looks very much like an email farming site. The article is very thin.

Reply on news.ycombinator.com