└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # High-level backend development is an open problem 2 | 3 | There are multiple approaches to develop a backend/API to your Web or Mobile app nowadays. 4 | My goal here is to structure and categorize them to hopefully get a more precise picture 5 | on what is going on here. 6 | 7 | In 2020 there's no obvious way to approach API building. Like in 2012 it was still believed by many 8 | that REST can be implemented "correctly" to "solve all our problems". It couldn't be further 9 | from the truth but there was hope at least. Not anymore. Twitter, Facebook, Netflix, Google and many 10 | other teams tried-and-discarded the very idea of REST layers/hierarchy as something worthy. 11 | 12 | One of the key ideas of REST (documentation should be somehow tied to data) was viable but approached 13 | from an entirely wrong angle. Bloating your HTTP with unrequested links and metadata, from the present, 14 | looks almost insane. This was solved by GraphQL (among other key points) in kinda the opposite way to what was originally proposed 15 | by Roy Fielding. It's easy to judge with a hindsight, of course, but the point is: GraphQL is a drop-in REST replacemend with mostly pros and no cons. 16 | 17 | So what next? Many original questions on how to approach API remain and new ones keep emerging. 18 | "The perfect API" now looks less achievable then ever, despite all the collective effort of scientists, engineers, programmers and all the other. 19 | 20 | TODO: redefine pros and cons per vendor, not per category. Many of pros and cons are vendor-specific. 21 | Also categorization is unsolvable in general as most popular vendors are quite unique in their feature sets. 22 | 23 | ### 🔮 0. Previous state of the art in REST 24 | 25 | #### Examples 26 | 27 | 👉 [Firebase](https://firebase.google.com/?hl=ru)
28 | Used to be considered expensive, now is fine in comparison ;) Realtime out of the box.
29 | Limited filtering and data-modelling capabilities. 30 | 31 | #### Pros & Cons 32 | 33 | ± Automatic REST API
34 | − Performance (too many queries)
35 | − Ergonomics (no static typing => no precise docs, nothing like GraphiQL, etc)
36 | − N+1 problem: Dataloader helps with Child → Parent, fails in Parent → Child (filtering is pushed from DB to App)
37 | 38 | ### 🔮 1. Custom GraphQL API 39 | 40 | #### Examples 41 | 42 | 👉 [Apollo-Server](https://www.apollographql.com/docs/apollo-server/) + [Dataloader](https://github.com/graphql/dataloader)
43 | Pretty good and intuitive tools. 44 | 45 | #### Pros & Cons 46 | 47 | ± Custom GraphQL API (magic vs boilerplate)
48 | − Custom Migrations
49 | − GraphQL to SQL is too complex to inline in your business logic
50 | − N+1 problem: Dataloader helps with Child → Parent, fails in Parent → Child (filtering is pushed from DB to App)
51 | + Single API layer
52 | + Deployment freedom
53 | 54 | ### 🔮 2. Runtime GraphQL Query → Relational Query 55 | 56 | #### Examples 57 | 58 | 👉 [Join-Monster](https://github.com/join-monster/join-monster)
59 | Seems abandoned. Only basic sorting! Slow, according to feedback. :| 60 | 61 | 👉 [SQLMancer](https://github.com/danielrearden/sqlmancer)
62 | Draft state. Going for a full rewrite a.t.m :| 63 | 64 | #### Pros & Cons 65 | 66 | ± Custom GraphQL API (magic vs boilerplate)
67 | − Custom Migrations
68 | + no N+1 and derivative problems
69 | + Single API layer
70 | + Deployment freedom
71 | − Performance (runtime query parsing is expensive)
72 | − Performance (potential drops for join-heavy cases)
73 | 74 | ### 🔮 3. Runtime GraphQL Query → Graph Query 75 | 76 | #### Examples 77 | 78 | 👉 [Neo4J-GraphQL-JS](https://github.com/neo4j-graphql/neo4j-graphql-js) (GraphQL → Cypher)
79 | Draft state. 80 | 81 | #### Pros & Cons 82 | 83 | ± Custom GraphQL API (magic vs boilerplate)
84 | − Custom Migrations
85 | + No N+1 and derivative problems
86 | + Single API layer
87 | + Deployment freedom
88 | − Performance (runtime query parsing is expensive)
89 | + Performance (no joins, graphs!)
90 | 91 | ### 🔮 4. Relational DB → GraphQL API 92 | 93 | #### Examples 94 | 95 | 👉 [PostGraphile](https://www.graphile.org/postgraphile/)
96 | Interesting project, many unique ideas. Small team – slow progress. 97 | 98 | 👉 [subZero](https://subzero.cloud/)
99 | Kinda like cloud-only PostGraphile. Doesn't look like in active development. 100 | 101 | 👉 [Super-Graph](https://github.com/dosco/super-graph)
102 | Basic API generator. Written in Go (can be ±). 103 | 104 | #### Pros & Cons 105 | 106 | ± Automagic GraphQL API (magic vs boilerplate)
107 | + Takes care of Migrations
108 | + No N+1 and derivative problems
109 | − API can't be derived from tables in general. Requires an extra API layer and many meta-data hints in DB.
110 | + Deployment freedom
111 | − Performance (runtime query parsing is expensive)
112 | − Performance (potential drops for join-heavy cases)
113 | 114 | ### 🔮 5. Graph DB → GraphQL API 115 | 116 | #### Examples 117 | 118 | Not aware of any 119 | 120 | #### Pros & Cons 121 | 122 | ??? 123 | 124 | ### 🔮 6. Prisma 125 | 126 | [Prisma](https://prisma.io/) is a high-level, database-agnostic, typescript-friendly ORM + Migration tool + Data UI. 127 | Generates a typed DB client from DSL models and migrations from DSL model diffs. Reusable TS types are also generated. CLI experience is pretty good with helpful error messages. API is also good: properly typed, autocompletion works. I've noticed some bugs, e.g. I have to restart IDE (Webstorm) to pick the correct types after a migration. Data UI is way too simplistic a.t.m and should not be considered a feature. So basically it's a good ORM + migration tool + ecosystem so far. 128 | Ecosystem: Nexus, Amplication, Prisma Platform (cloud). DB modelling is not fully agnostic, there're incompatible differences between Mongo and SQL dialects and even [within SQL](https://github.com/prisma/prisma/issues/2219) family as well. 129 | 130 | #### Pros & Cons 131 | 132 | + Mid-level, typed DB handling.
133 | − Yet another DSL, adds to the "model/type" DRY fatique. Does not generate API layer by itself. There're experimental projects (Nexus, etc) allowing to derive API from Prisma DSL but they are too immature and incomplete (and rely on another codegen layer 😞) a.t.m.
134 | 135 | ### 🔮 7. Relational DB ← Custom Data via UI → GraphQL API 136 | 137 | #### Examples 138 | 139 | 👉 [GraphCMS](https://graphcms.com/).
140 | Good UI. Kinda buggy. Pretty expensive at the moment.
141 | 142 | ± Automagic GraphQL API (magic vs boilerplate)
143 | + Takes care of Migrations
144 | ± Performance (potential drops for join-heavy queries)
145 | + Single API layer in simple cases
146 | − Extra API layer in other cases
147 | 148 | ### 🔮 8. Relational DB ← GraphQL Types → GraphQL API 149 | 150 | #### Examples 151 | 152 | 👉 [Hasura](https://hasura.io/)
153 | Interesting project. Seem to know their stuff. Got >100M investments...
154 | Gains traction recently. Good docs in comparison, many examples, established a community.
155 | 156 | ± Automagic GraphQL API (magic vs boilerplate)
157 | + Takes care of Migrations
158 | + Single API layer in simple cases
159 | ± Performance (potential drops for join-heavy queries)
160 | + Autogenerated CMS
161 | − Extra API layer in other cases
162 | + Deployment freedom
163 | − Pretty expensive at the moment
164 | 165 | ### 🔮 9. Graph DB ← GraphQL Types → GraphQL API 166 | 167 | #### Examples 168 | 169 | 👉 [FaunaDB](https://fauna.com/)
170 | Looks promising. Very limited filtering and sorting capabilities.
171 | Supports two languages: FQL (main) and GraphQL (basic, beta).
172 | Promise to add even more languages (instead of focusing) :shrug:
173 | 174 | #### Pros & Cons 175 | 176 | ± Automagic GraphQL API (magic vs boilerplate)
177 | + Takes care of Migrations
178 | + Distributed transactions
179 | + Performance (single GQL query = single DB query)
180 | + Single API layer in simple cases
181 | − Extra API layer in other cases
182 | − Extra language to learn (FQL)
183 | 184 | ### 🔮 10. GraphQL-speaking DBs 185 | 186 | #### Examples 187 | 188 | 👉 [Dgraph](https://dgraph.io/)
189 | Looks promising. Sparse docs. Supports two languages: GraphQL± vs GraphQL.
190 | The question of which-to-use-when is not addressed in docs :shrug: 191 | 192 | #### Pros & Cons 193 | 194 | ± Automagic GraphQL API (magic vs boilerplate)
195 | + Distributed transactions
196 | + Performance (single GQL query = single DB query)
197 | + Single API layer in simple cases
198 | − Extra API layer in other cases
199 | − Potential performance loss for cross API roundtrips (e.g. Dgraph permission resolving)
200 | 201 | --- 202 | 203 | ^ the above are my subjective opinions. 204 | 205 | [graphql]: https://raw.githubusercontent.com/github/explore/80688e429a7d4ef2fca1e82350fe8e3517d3494d/topics/graphql/graphql.png 206 | 207 | --- 208 | 209 | ## Honorable Mentions 210 | 211 | - [Supabase](https://supabase.com) is a Firebase rival. RESTp & GraphQL API & SDK. TypeScript support is [WIP](https://github.com/supabase/supabase-js/issues/170). File uploads. No aggregation queries. 212 | - [NHost](https://nhost.io/) is built on top of Hasura, Hasura-Auth and S3. No self-hosting option. Barebone docs, URQL support is not documented [a.t.m](https://issuehint.com/issue/nhost/nhost/271) 213 | - [AppWrite](https://appwrite.io/) is another Firebase rival. Does not support GraphQL [a.t.m](https://github.com/appwrite/appwrite/discussions/1280) 214 | - [Amplication](https://amplication.com/) is an API & Auth code generator (GraphQL and REST). Models can be created in UI and CLI (imperatively :thinking:) 215 | (reconsider if switches to DSL) 216 | - [EdgeDB](https://www.edgedb.com/) -- ?? 217 | - [8base](https://www.8base.com/)-- ?? 218 | 219 | ## Other's people Comparisons 220 | 221 | [Perferct DB in 2022](https://dev.to/jdgamble555/firebase-is-dead-what-is-the-perfect-database-in-2022-4o9a) 222 | --------------------------------------------------------------------------------