As per my uncderstanding it is ggod to implement tow type of APIs. For example, for login there should be tRPC implementation but for user resource REST API should be implemented. Please correct me if I am wrong.
In your POST request, how do you know the productId before the product is actually created :)? Do you use something like UUIDs, and then generating them on the client? Or would you consider the product name the productId when creating?
Re: the start figure: There is a difference between an interface or API you would use for an internal component and an external component. SO for anyone watching, the layers between DB and Controller would all be using internal interfaces in whatever language is being used, technically you could have REST or other external use APIs for these, but then security becomes a nightmare. For a good example of this take a look at all the bot hits on JS packages in wordpress that are using this method to access db APIs and other services externally from the core of the system. This is why ~80% (depending on year) of Wordpress sites are poisoned. I tend to avoid using put/patch as the DB interface should be able to 'see' if a record already exists and either run an update or an overwrite depending on the rules you have setup and in a SOLID system all the code to deal with the DB should all be contained together and not client specified unless absolutely required. Good explanation of RPC. GraphQL is essentially an interface for a DB query language, the difference is in the output elements are client generated rather than system controlled. GraphQL queries for 4d objects (with mutability between object types) ends up getting super complicated and very very long. I find you also need ot already know the design of the object pre query (although there are listing queries in the packages I have used), which ties FE/BE together a little more. I do still see SOAP used in the wild quite a lot (heck PayPal still allowed it last I checked). Haven't had to connect to it for a while though thankfully.
I'm not sure if you think I was advocating using a REST API internally or what your first paragraph is even referencing. I was just making it clear what exactly I was talking about. I'm not sure why you'd say that there is a different between an interface and an API when the I in API literally stands for interface. Please don't use GraphQL to interface with a DB, we realised that was a bad idea at least 3 years ago.
@@TomDoesTech you mentioned each one would have an api, for anyone watching who was not really familiar with how to do this (like script kiddies) I figured I'd pop in a little detail about internal vs external so they'd stop messing up when they inevitably make a WP plugin. Yeah I don't touch graphql for anything, haven't found a use-case where it is a better option than something that already exists, I guess maybe if you have multiple endpoints and you want to combine data from all of them instead of making multiple calls or setting up your own API for specific cases. But yet to see a point to it beyond making the client feel like they can customise the output and having a multi-source interface, guess I'm not a fan of broadly specified data. But most of the data GraphQL will retrrieve is usually stored in DBs, often over multiple systems eg: Facebook which wanted a sijmple way for their non-technical staff to request multi-source data from their different systems (which are DBs).
I don't think GraphQL is comparable to Prisma. They don't even live on the same layer on the graph at the beginning of this video. Prisma is an ORM (object relational mapping) which allows you to operate your databases in a higher level manner. On the other hand, GraphQL is a way to define your network API, it represents the way how other developers can interact with your system.
Nice tutorial as always!
Could you please create a tutorial about versioning an API ? 😊
Lol love the shirt change
Dear Tom, you wrote api/v1/products/{productId} for CREATE but I think you don't need productId for this, right?
Ahhh yeah, that's my mistake. You wouldn't create with a productID, it would give you one in the response.
thank you
Thanks Tom, Learned alot from your videos!
background music not useful,
I'll omit it from future videos
video is great, tho
Well Explained !!
Nice explanation! thanks
Thank you Tom, this tutorial is a gem!
Thank you for your amazing content. For me, background music was a bit distractive.
Yeah sorry, I'll make it much quieter next time
the intro was fun!!!!!!!!!!!! happy new year tom!
Glad you liked it :)
As per my uncderstanding it is ggod to implement tow type of APIs. For example, for login there should be tRPC implementation but for user resource REST API should be implemented.
Please correct me if I am wrong.
I don't think there is a `should`. You `should` do what works best for you and your app
Please diable music in the backgorund 😅
no
@@TomDoesTech I don’t know where music come from, it is quite noisy with your voice
for me it is always graphql. TRPC is good but i dont think we need to complicate our apis that much REST with typescript is more then enough
Yeah, I'm a bit fan of all 3 tbh, depends on the job at hand
In your POST request, how do you know the productId before the product is actually created :)? Do you use something like UUIDs, and then generating them on the client? Or would you consider the product name the productId when creating?
Yeah, that was just a bad example :facepalm
gRPC? Is that like tRPC but with GraphQL?..
Please be joking lol
Re: the start figure: There is a difference between an interface or API you would use for an internal component and an external component. SO for anyone watching, the layers between DB and Controller would all be using internal interfaces in whatever language is being used, technically you could have REST or other external use APIs for these, but then security becomes a nightmare. For a good example of this take a look at all the bot hits on JS packages in wordpress that are using this method to access db APIs and other services externally from the core of the system. This is why ~80% (depending on year) of Wordpress sites are poisoned.
I tend to avoid using put/patch as the DB interface should be able to 'see' if a record already exists and either run an update or an overwrite depending on the rules you have setup and in a SOLID system all the code to deal with the DB should all be contained together and not client specified unless absolutely required.
Good explanation of RPC.
GraphQL is essentially an interface for a DB query language, the difference is in the output elements are client generated rather than system controlled. GraphQL queries for 4d objects (with mutability between object types) ends up getting super complicated and very very long. I find you also need ot already know the design of the object pre query (although there are listing queries in the packages I have used), which ties FE/BE together a little more.
I do still see SOAP used in the wild quite a lot (heck PayPal still allowed it last I checked). Haven't had to connect to it for a while though thankfully.
I'm not sure if you think I was advocating using a REST API internally or what your first paragraph is even referencing. I was just making it clear what exactly I was talking about. I'm not sure why you'd say that there is a different between an interface and an API when the I in API literally stands for interface.
Please don't use GraphQL to interface with a DB, we realised that was a bad idea at least 3 years ago.
@@TomDoesTech you mentioned each one would have an api, for anyone watching who was not really familiar with how to do this (like script kiddies) I figured I'd pop in a little detail about internal vs external so they'd stop messing up when they inevitably make a WP plugin.
Yeah I don't touch graphql for anything, haven't found a use-case where it is a better option than something that already exists, I guess maybe if you have multiple endpoints and you want to combine data from all of them instead of making multiple calls or setting up your own API for specific cases. But yet to see a point to it beyond making the client feel like they can customise the output and having a multi-source interface, guess I'm not a fan of broadly specified data.
But most of the data GraphQL will retrrieve is usually stored in DBs, often over multiple systems eg: Facebook which wanted a sijmple way for their non-technical staff to request multi-source data from their different systems (which are DBs).
What was that in the beginning ? 😀
A fully sick skit
I think it was a "hot reload" =)
No, you don't have to know GraphQL, I prefer using Prisma
I don't think GraphQL is comparable to Prisma. They don't even live on the same layer on the graph at the beginning of this video.
Prisma is an ORM (object relational mapping) which allows you to operate your databases in a higher level manner.
On the other hand, GraphQL is a way to define your network API, it represents the way how other developers can interact with your system.
Who said you need to know GraphQL and what does GraphQL have to do with Prisma?
I think he might be referring to old days of Prisma covering the whole mile from DB to api with GraphQL schema?
not certain if I got that right though
Nice Thumbnail 😂
As always clear explanations
Glad you liked it