Nice tutorial as always! Could you please create a tutorial about versioning an API ? 😊
@WebDevCody2 жыл бұрын
Lol love the shirt change
@samiullahsheikh50152 жыл бұрын
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.
@TomDoesTech2 жыл бұрын
I don't think there is a `should`. You `should` do what works best for you and your app
@bugraotken2 жыл бұрын
Dear Tom, you wrote api/v1/products/{productId} for CREATE but I think you don't need productId for this, right?
@TomDoesTech2 жыл бұрын
Ahhh yeah, that's my mistake. You wouldn't create with a productID, it would give you one in the response.
@slipoch66352 жыл бұрын
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.
@TomDoesTech2 жыл бұрын
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.
@slipoch66352 жыл бұрын
@@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).
@testvb6417 Жыл бұрын
thank you
@rujor2 жыл бұрын
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?
@TomDoesTech2 жыл бұрын
Yeah, that was just a bad example :facepalm
@dprophecyguy2 жыл бұрын
What was that in the beginning ? 😀
@TomDoesTech2 жыл бұрын
A fully sick skit
@bugraotken2 жыл бұрын
I think it was a "hot reload" =)
@siavoshoon2 жыл бұрын
Thank you for your amazing content. For me, background music was a bit distractive.
@TomDoesTech2 жыл бұрын
Yeah sorry, I'll make it much quieter next time
@lovelytingy2 жыл бұрын
video is great, tho
@nabind472 жыл бұрын
Nice Thumbnail 😂 As always clear explanations
@TomDoesTech2 жыл бұрын
Glad you liked it
@Flash1362 жыл бұрын
gRPC? Is that like tRPC but with GraphQL?..
@TomDoesTech2 жыл бұрын
Please be joking lol
@pawel_8902 жыл бұрын
Please diable music in the backgorund 😅
@TomDoesTech2 жыл бұрын
no
@pawel_8902 жыл бұрын
@@TomDoesTech I don’t know where music come from, it is quite noisy with your voice
@WebGhost-wl5cj2 жыл бұрын
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
@TomDoesTech2 жыл бұрын
Yeah, I'm a bit fan of all 3 tbh, depends on the job at hand
@WarframeCrunch2 жыл бұрын
No, you don't have to know GraphQL, I prefer using Prisma
@Alan9101272 жыл бұрын
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.
@TomDoesTech2 жыл бұрын
Who said you need to know GraphQL and what does GraphQL have to do with Prisma?
@bbbo852 жыл бұрын
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