OpenAPI with a sprinkle ✨ of Hypermedia
Вставка
- Опубліковано 26 чер 2024
- OpenAPI is great for describing your HTTP API. It's used at design time when you're developing to understand how interact with an HTTP API. But on the other side is more runtime considerations that allow evolvability with Hypermedia. Here's how to use both.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via UA-cam
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo... - Наука та технологія
That is exactly how this should be done. It seems to cover majority of the logic in one place making the changes cheaper. Good job!
Lovely! Thanks for this video!
Yay! More work for the backend guy 😅
More control to backend guys
😂😂
But less work for the team as a whole ;)
03:14 being pedantic, but the original logic for checking if the user is admin was on the server-side as well in the Razor html syntax.
What pattern are you using for your Blazor app? MVVM?
Let's extend this idea and assume Blazor (WASM) frontend. When i get list of items over API and each item contains set of operations, how should we eventually build the frontend? Should operation really direct the frontend to load specific Blazor component? (Sometimes another page, sometimes a modal-based component, etc) And sometimes it's a POST request that should be done and as a result a current view should reload its contents? How should it eventually work together?
It's easy to zoom in and so it looks easy and logical. But once you bring in full-stack, how would you build it?
I'm not saying that the idea here doesn't work. I just see that there's an elephant still in the room that i don't remember you covering. Maybe you could? I would be really interested in that...
Maybe there are some generic hypermedia browsers, but with hypermedia it doesn't mean you have to make the *whole* frontend all dynamic based on the responses. Which superset of operations are available (implemented) in your frontend could be hardcoded. But the operations array of the response could control for which items, the delete or edit is available.
@@gruttewibe76 well, there is an option that with each item you will also give a bunch of flags, what can be done with it. But is that now the solution? Is it the same solution as provided here in the video? I see it as a complete alternative.
@@GigAHerZ64 I think there's pros and cons and it depends on what you're trying to achieve with this. If you just want to tell the client which ops are available, sure flags are probably good enough. An evolution of this concept is to send more data like the method & url to perform the operation so this way the client code can be somewhat simplified (at least for simple ops). If the url changes, your client won't break since the backend dictate the route (very useful when you don't control the client).
@@jbeaudoin11 and what you describe is exactly the sterile simple scenario that I referred to in my initial comment.
In real life, you don't have a "client" that does actions against any backend url or something. There are bunch of ui views, components and whatnot before any action will be taken from the backend perspective.
@@jbeaudoin11 The thing is, using the received URL and method in the front end is _never_ simpler. What payload do you send? What do you do with the response?
If the URL changes I’ll just make the old URL redirect to the new one. If literally anything else changes I’ll have to modify the front-end anyway. So what’s the benefit?
Even in this simple example, you don’t use the URL from the OperationViewModel in the front-end code. So is that still hypermedia? I don’t see the difference between that and a much simpler “CanUpdate” flag in the response in terms of coupling. You’re not actually allowing the front-end to perform arbitrary operations that it can discover at runtime.
Should you tell the front-end which subset of operations it can or can’t do in a given context, rather than duplicating the logic (in this case, checking the user’s role)? Absolutely. I would just call it good API design, though, not hypermedia.
The video also misses the most important part: deciding on whether logic should go client or server side
It has exactly the same meaning as canUpdate flag. The difference is that you aldo provide URL of how you do it. Seems excessive in simple case, but this should scale well when repeated and leaves no room for typos and desync of client and server
@@ahupondI disagree, the logic is server side and it was clearly said
@@MurtagBY The URL is hardly what I'm concerned is going to change. It almost never changes. When it's wrong, it's easy to notice. If it changes, you can simply redirect the old one to the new one. What I'm worried is going to change are the request/response models, which this doesn't address at all. And, imo, we _don't_ want to address, as it would make code less predictable and harder to test.
Lowkey shilling hypermedia
One day Derek will go straight shilling HTMX
Now there are more players than htmx
Hi! I just missing OpenAPI specification in the video, just seen swaggerUI. OpenAPI allow Hypermedia to be added into the specification with links, etc.. that's what i was expecting