Fork me on GitHub
#off-topic
<
2018-11-08
>
yen00:11:33

People often talk about the N+1 problem in GraphQL, which is a legit concern

yen00:11:45

But Rest suffers from the same N+1 problem

yen00:11:10

only difference is that this is between the user and the backend server

yen00:11:28

where network calls are orders of magnitude more expensive

đź’Ż 4
gklijs06:11:18

Where with GraphQL you have some advantage I think where you can determine kind of how it's used, while with rest you don't really no up front. For example say you have a rest for getting a list and a separate one for getting the details, you kind of need to know up front what the users op your api want for the summary. But they might end up calling the detail view for everything if they want something else.

gklijs06:11:03

My current team is about to start working on a new api, but I seem to be the only one in favour of GraphQl, but also since we're on mongo I'm not sure if it's a great idea. On the other hand we could just keep the schema very flat.

slipset06:11:44

When your app is backed by mongo, rest vs GraphQL is the least of your problem. It is a Greenspun’s tenth waiting to happen.

slipset06:11:29

If I may offer some advice as someone working on a mongo-backed backend:

slipset06:11:45

Make sure you have schemas/specs in place, its the only way to know way to know what’s being put in your db.

slipset06:11:49

Make sure you enforce the foreign key constraints. Both when adding and deleting. Also, make sure you do cascading deletes.

slipset06:11:45

Bottom line is that data inconsistencies is just eating for a chance to happen when you use Mongo.

slipset06:11:07

Just to finish this off. When working in a language where all your entities tend to be maps, it’s nice to have some definitions of the shape of the data somewhere.

3Jane07:11:24

If you use GraphQL for that, take care to make your schema flexible

3Jane07:11:42

That is, avoid making fields non-nullable unless you have some kind of system guarantee that they will always be filled.

3Jane07:11:38

(And make sure people who write the downstream check for nulls.)

3Jane07:11:14

(It’s way too easy to assume that chunks of data will always be there just because they’re there most of the time)

gklijs07:11:53

The current problem is more that we have multiple definitions for the some things then none.. Also we're moving some things to Postgres already, and might do more. But we've had a lot of problems related to data consistency indeed.

gklijs07:11:32

I'm more worried when they are going to do some 'joins' but we could prevent that from the schema and/or make the data in such a way it's not needed.

orestis07:11:33

There is a #graphql channel btw ;)

slipset07:11:26

Are you saying we’re #off-topic ;) ?

orestis07:11:41

Hehe, just that this is a useful to have in a dedicated channel :) I monitor both of course because FOMO on all the good discussions that happen in this Slack. I learn something new every day!