I love watching Ben videos because he does not force audiences to use any specific libraries. Instead, he points out libraries pros and cons. Every library is good and made by incredible people. Excellent video!. Thanks Ben
15:29 - "For this, I'm focusing on React, because that is the framework...excuse me, _library_ that I use." Ben, this is only the second video of yours I've watched because I just built my first working GraphQL server using express-graphql and I want to learn more. I clicked the Subscribe button because of the sentence above.
I personally like to front my data and business layers with either a restful or rpc interface that graphql then communicates to to get the data needed for its consumer.
Great video. I really like the TypeORM + TypeGraphQL. Even though I'm not a big fan of class syntax (preference) but this seems very efficient. Isn't KnexJS a query builder and Objection uses KnexJS under the hood. Prisma 2's Photon is an interesting ORM
9:23 - I have come from the future, where the current future of typeorm is uncertain (the maintainer isn't sure if he will be spending more time on it going forward). After much research, I have decided to use mikro-orm instead. Anyone that might be making the same choice, I hope my decision proves helpful.
When you're dealing with big schemas that you're not familiar top to bottom, code-first gql is REALLY cumbersome to read and detters people from contributing to the codebase. If you're going to work on an app with multiple people, especially large teams, I'd advise you go for the schema-first approach.
this is where graphql-playground comes in handy to see the entire schema I actually like code-first better for large projects because the typedefs and resolvers are together
Great overview about GraphQL. What would you use for debugging a GraphQL that seems to respond correctly but it's showing the schema incorrectly? I would like to know what's going on but I have no error message.
Thanks for your videos Ben! I have a little request 🥺, can you make a video using serverless and Apollo server. I couldn't find any good example with a postgres connection.
I think there's a lot of misconceptions in what GraphQL should be used for; You talked about having to sync your database to the GraphQL schema. A better way is actually to split up the concerns of how you store your data and how that data is accessed and operated upon. GraphQL is a great way to think about what data your application provides without leaking the specifics of how that data is stored. You could have multiple databases in different ways, and unify the access through GraphQL. You could argue that generating the types would be helpful, but then you're tying your GraphQL schema to your database and that has the consequence of having to update the schema on each change to underlying data. A way to think of this is, when you flesh out details about what your application is about, GraphQL can be a great tool to specify the kinds of data that should be visible in the UI. It's establishing a contract between consumer and provider, rather than implementation details.
@@bawad That is true for TypeORM in this case, but my point was more that you could use GraphQL to define the data that your UI needs, rather than defining the schema 1:1 with the database. Coupling GraphQL to your database has its drawbacks. First, you leak information about _how_ your data is stored, rather than _what_. This can make it difficult to keep a consistent schema across services and databases. It also makes scaling very hard when using different data sources. You'll need to define a source of truth for what data is available. I say this from my experience working with GraphQL and a variety services with different databases and endpoints. We ended up with a single GraphQL schema that defined the data that should be available in the UI. Types can be based on the data that different services provided, and the resolvers would take care of fetching and prepare the data when being queried. This also tied perfectly in with caching as we can use the schema to verify the schema of data in cache (using in-house tools) and deprecate anything with GraphQL if needed.
There many useful hidden features. For example, whenever you update PostgreSQL schema (migration), it automatically updates all the TypeScript definitions for db tables and enums (see yarn db:reset).
Hi Ben, Could you make a video about authentication system and basic product CRUD with this stack. Backend: Node.js + GraphQL + Passport.js(local strategy) + postgresql with sequalize / frontend: react react-apollo? I can't find tut video for if you can do this would save my life.
There's two problems you didn't meation but pretty important. 1. Auth. 2. Local state. 1. This belongs to middleware or server, apollo server could handle this, but others' solutions are pretty different. It confuses many people. 2. How to handle local state in frontend, apollo-client always try to beat Redux, but their solution really sucks, I'm wondering if I should use their solution(I know it's a little combersome, but I really don't want two sources of truth), or set up a separate context store.
Perfect, almost all the stuff I'm using for my current project is what Ben recommends. type-graphql together with TypeORM is really nice, for SPOT/SSOT's sake, don't miss it.
I noticed you were a big fan of feather js 2 years ago, but you don't mention it any more in the eco-system ? Is there a reason? I just discovered this framework and I think it's great ... Your view on this would be greatly appreciated, thank you.
Hi Ben, great video! One thing I’ve really been struggling with is how to do offline and handle sync merge conflicts without using AWS appsync. I saw a library extending apology called offix and also read about using pouchdb but offix seems too new and pouchdb I think doesn’t map relations? Could really use some advice before I commit to one.
Hi Ben, i really like your videos. I have a question: graphql sacrifice performance in comparation with a rest api? Like in the amount of request per second, i cant find a good benchmark
What is your opinion on the fact that TypeORM has currently over 1k open issues? It feels like the project is just not actively maintained which is why I went with Knex/Objection instead, but I'd be curious to hear why you'd still recommend it.
Yeah it was unmaintained for a while, but I think it's getting some attention now. But yeah that part of it is unfortunate. If you could mix GraphQL with the Objection/Knex models I would recommend them, but right now only typeorm can do that
@Ben Awad I have a question if you do not mind, have you ever used Redux when using graphql with apollo-server. and what are your thoughts on using Redux with graphql and apollo-server ? Thank you very much and love your content.
Haven't done any videos specifically with join-monster/dataloader and typegraphql, but it should be the same ru-vid.com?search_query=benawad+dataloader
is realm still active with react native, i am not able to find any latest videos realm database in 2019 or even 2018, all videos are almost 2 years old :) should i use it or not ?
What lead you away from Postgraphile/Hasura? I've been trying out Postgraphile and love it in theory, but finding authentication + mixing in my own mutations to be a bit of a bottleneck in reality.
I really love hasura, but the biggest problem is auth. Another problem is I don't wanna use many serverless functional, so I'm wondering if I should write native postgres functions in my datadata to achieve some business logic.
