This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-08
Channels
- # 100-days-of-code (1)
- # admin-announcements (1)
- # aleph (1)
- # announcements (9)
- # beginners (125)
- # cider (1)
- # cljs-dev (80)
- # cljsrn (2)
- # clojure (82)
- # clojure-czech (1)
- # clojure-dev (5)
- # clojure-finland (1)
- # clojure-italy (16)
- # clojure-nl (6)
- # clojure-spec (24)
- # clojure-uk (39)
- # clojurescript (35)
- # community-development (49)
- # core-async (3)
- # cursive (31)
- # data-science (17)
- # datomic (21)
- # emacs (5)
- # fulcro (92)
- # graphql (1)
- # jobs (2)
- # lambdaisland (1)
- # leiningen (19)
- # luminus (9)
- # off-topic (21)
- # parinfer (6)
- # pedestal (1)
- # portkey (2)
- # re-frame (12)
- # reagent (8)
- # reitit (4)
- # shadow-cljs (117)
- # spacemacs (5)
- # specter (4)
- # sql (2)
- # testing (2)
- # tools-deps (3)
- # vim (1)
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.
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.
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.
Make sure you have schemas/specs in place, its the only way to know way to know what’s being put in your db.
Make sure you enforce the foreign key constraints. Both when adding and deleting. Also, make sure you do cascading deletes.
Bottom line is that data inconsistencies is just eating for a chance to happen when you use Mongo.
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.
That is, avoid making fields non-nullable unless you have some kind of system guarantee that they will always be filled.
(It’s way too easy to assume that chunks of data will always be there just because they’re there most of the time)
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.