Speaker 1: Hey everyone, and welcome to another deep dive.
Speaker 2: Always fun to do these.
Speaker 1: Today we're diving into ember data. It's a JavaScript library
Speaker 1: that really helps with managing data in web applications.
Speaker 2: Yeah, for sure, we're going to.
Speaker 1: Be looking at excerpts from pro ember Data. Getting mber
Speaker 1: Data to Work with Your API by David Tang sounds
Speaker 1: good and basically our mission today is try and figure
Speaker 1: out what is ember data all about, what it's key components,
Speaker 1: and how does it make talking to APIs a much
Speaker 1: smoother and easier experience.
Speaker 2: Yeah, it's a really powerful tool. I think that's for sure.
Speaker 2: Without something like ember Data, developers would have to wrestle
Speaker 2: with a lot of manual beta handling, right, and that
Speaker 2: can quickly become really complex and error prone.
Speaker 1: Absolutely. Okay, well let's jump into it. Let's start with
Speaker 1: the basics. Ok. What's the big idea behind mber Data's architecture.
Speaker 2: So at its core, mber Data acts as a bridge
Speaker 2: between your front end application and the back end API.
Speaker 1: It simplifies those data interactions much like a universal travel
Speaker 1: adapter helps you plug your devices into different outlets around
Speaker 1: the world.
Speaker 2: I like that analogy, sooth. It's adapting our front end
Speaker 2: to work with all these different APIs, no matter how
Speaker 2: how they're structured or what their quirks are exactly.
Speaker 1: Yeah. And one of the central concepts in EMBER data
Speaker 1: is the store.
Speaker 2: Okay.
Speaker 1: It's essentially the brain of your applications data management system.
Speaker 2: Okay.
Speaker 1: Think of it as like a central repository where all
Speaker 1: of your data lives. It ensures consistency and it prevents duplication.
Speaker 2: So the store is really important because it's preventing us
Speaker 2: from having multiple copies of the same data floating.
Speaker 1: Around exactly precisely. The store uses what's called an identity
Speaker 1: map to keep track of all of the data records,
Speaker 1: guaranteeing that you're always working with a single authoritative source
Speaker 1: of truth.
Speaker 2: That makes a lot of sense.
Speaker 1: Yeah, Now, how does MBER data actually cannet to all
Speaker 1: these different APIs. They're not all built the same way.
Speaker 2: That's where adapters come in. They handle the specific details
Speaker 2: of communicating with a particular API, like figuring out how
Speaker 2: to send requests and receve responses in the correct format.
Speaker 1: So the adapter is kind of like the translator. Yes,
Speaker 1: it's making sure that our MBER app can speak to
Speaker 1: all these different exactly ATI dialects.
Speaker 2: ATI dialects.
Speaker 1: Yeah, okay, what about the data itself? How does mber
Speaker 1: data actually represent all these different types of information?
Speaker 2: So, just like a database schema, mber data uses models
Speaker 2: to represent the structure of your data. Each model has
Speaker 2: attributes okay, with specific data types like strings, numbers, or dates.
Speaker 1: So attributes are like defining the fields or columns in
Speaker 1: a database table. Yeah, exactly.
Speaker 2: And each attribute can have what's called a transform associated
Speaker 2: with it, which ensures that the data is properly formatted
Speaker 2: both when sending it to the API and it back.
Speaker 1: So transforms are really important for maintaining consistency. Yes, like
Speaker 1: making sure dates are format the right way before we
Speaker 1: send them to the API.
Speaker 2: Exactly. Now, the book that we're looking at today actually
Speaker 2: dives into several different types of adapters. Each adapter has
Speaker 2: its own strengths, and it's kind of suited for specific
Speaker 2: API styles okay. One very common adapter is the rest adapter.
Speaker 1: Okay, So if I'm working with just a standard RESTful API,
Speaker 1: RESTADA is probably what I want to go with.
Speaker 2: Yeah, most likely. Yeah, But let's say you're working with
Speaker 2: an API that strictly adheres to the json dot API specification. Okay,
Speaker 2: that's a specification that's known for its strong emphasis on
Speaker 2: convention and consistency.
Speaker 1: Ah, so it's like a little more rigorous than just
Speaker 1: a typical rest API.
Speaker 2: It is. Yeah, and for those scenarios you would use
Speaker 2: the Jason APA adapter. It's designed to handle all the
Speaker 2: specific nuances of Jason dot apia like it's strict format
Speaker 2: for URL's diference for pat cch over put for updates,
Speaker 2: and built in support for efficiently loading relationships between data.
Speaker 1: Gotcha, So rest adapter for common rest APIs, it's Jason
Speaker 1: ap adapter for following the Jason dot apispeck exactly. Okay.
Speaker 2: You also have the Active Model adapter, which is specifically
Speaker 2: designed to work seamlessly with APIs that are built using
Speaker 2: Ruby on Rails Active Model framework.
Speaker 1: Cool. So that handles all the sending of data. Now,
Speaker 1: what about receiving data back from the API? I understand
Speaker 1: Mber Data uses something called serializers exactly. Yeah.
Speaker 2: Serializers translate the data received from the API into a
Speaker 2: format that mber data can understand. They handle both serialization,
Speaker 2: which is preparing data to be sent out, and normalization,
Speaker 2: which is taking that incoming data and kind of fitting
Speaker 2: it into the MBER data store.
Speaker 1: So it's this two way translation process to make sure
Speaker 1: that our front end and the API can speak to
Speaker 1: each other exactly clearly. What are some of the the
Speaker 1: built in serializers that mber data offers.
Speaker 2: So the json serializer is the most basic one, okay.
Speaker 2: It works well with simple API responses where the JSON
Speaker 2: keys directly map to your ember model attributes.
Speaker 1: Let's appreciate forward.
Speaker 2: Yeah, okay. What about if we have a more complicated API, Yeah,
Speaker 2: what about then you might consider using the rest serializer.
Speaker 2: It adds a little bit more structure to the data
Speaker 2: by using root keys that correspond to your model names.
Speaker 1: Gotcha.
Speaker 2: It also supports sideloading, which allows you to include related
Speaker 2: data in a single response, which reduces the need for
Speaker 2: multiple API calls.
Speaker 1: So it helps to streamline data retrieval and it probably
Speaker 1: improves performance.
Speaker 2: Y exactly.
Speaker 1: Okay.
Speaker 2: And then you have the third one, which is the
Speaker 2: Jason a P serializer. Okay, And this is specifically designed
Speaker 2: to handle responses that strictly follow the json dot API specification.
Speaker 2: It expects a very specific format for resources, relationships and sideloading.
Speaker 1: Gotcha. So json a P serial if our API is
Speaker 1: designed according to json dot API exactly. Okay. Cool. So
Speaker 1: now one of the things that I'm seeing here is
Speaker 1: mber data is really powerful because it's so flexible it is,
Speaker 1: And the book really spends a lot of time talking
Speaker 1: about how you can customize adapters and serializers to handle
Speaker 1: APIs that don't necessarily follow these standard conventions exactly. What
Speaker 1: are some common scenarios where we might need to kind
Speaker 1: of roll off our sleeves and do some customization.
Speaker 2: Well, for instance, some APIs might use singular nouns in
Speaker 2: their URLs instead of the standard plural form, or they
Speaker 2: might have naming inconsistencies between their Jason keys.
Speaker 1: Right, because APIs will often have their own little works
Speaker 1: and naming conventions. Yeah, so how do we handle those situations?
Speaker 2: We can guide mber data by overwriting specific methods in
Speaker 2: our adapters and serializers. For example, if an API uses
Speaker 2: companied as a foreign key in the response, but your
Speaker 2: ember model is expecting a relationship named company, we can
Speaker 2: actually tell ember data how to map that foreign key
Speaker 2: to the appropriate relationship.
Speaker 1: It's like we're bridging the gap between what the API
Speaker 1: gives us exactly what Ember data is expecting.
Speaker 2: Exactly, okay, And these customizations can actually get quite complex,
Speaker 2: especially when you're dealing with nested data structures or non
Speaker 2: standard error responses. The book does a great job of
Speaker 2: walking through those situations and providing solutions.
Speaker 1: Okay, I think that's a really good overview the kind
Speaker 1: of the foundational concepts here. Yeah, maybe we should pause
Speaker 1: here for a second.
Speaker 2: Yeah, let's take a break and let's all sink in. Yeah,
Speaker 2: good idea.
Speaker 1: Okay, sounds good. All right, so welcome back. Yeah, I'm
Speaker 1: excited to dig into some real world examples here meet
Speaker 1: and actually see how all these ember data customizations work
Speaker 1: in code.
Speaker 2: Yeah, the book has some great hands on scenarios, and
Speaker 2: I think walking through those really solidify our understanding.
Speaker 1: So let's start with one that I found pretty interesting. Okay,
Speaker 1: it's the books example of actually using local storage as
Speaker 1: a data source. Yeah, that seems like a kind of
Speaker 1: unconventional use case for mber data.
Speaker 2: It is, it is, but it's a great illustration of
Speaker 2: how adaptable mber data can be. So instead of interacting
Speaker 2: with a remote API, we can actually use this adapter
Speaker 2: system to store and retrieve data directly in the user's browser.
Speaker 1: So no network requests, yeah, just data manipulation locally. So
Speaker 1: what are the key differences when we're setting up mber
Speaker 1: data to use local storage.
Speaker 2: Yeah, so the core concepts are the same. Okay, we
Speaker 2: still have models, adapters, and serializers. Okay, the key difference
Speaker 2: is how the adapter actually interacts with the data source. Okay,
Speaker 2: so instead of making these AJAX calls, our custom adapter
Speaker 2: for local storage is going to use methods like local
Speaker 2: storage dot item, local storage, dot set item, and things
Speaker 2: like that to actually manipulate data in the browser's storage.
Speaker 1: Interesting. Yeah, but you know, local storage doesn't have like
Speaker 1: the concept of these auto generated ideas like a database would.
Speaker 1: So how do we handle that when we're creating new records.
Speaker 2: That's a great point, and the book actually outlines a
Speaker 2: pretty clever approach. Basically, what you can do is you
Speaker 2: can simulate auto incrementing IDs okay by sorting the existing
Speaker 2: records in local storage by their ideas and then just
Speaker 2: assigning the new record and ID that's one greater than
Speaker 2: the highest existing idea.
Speaker 1: Okay, that's neat. Yeah, so we're kind of maintaining this
Speaker 1: sequence even just local storage. Yeah. Now, another thing that
Speaker 1: I noticed is that local storage treats everything as strings,
Speaker 1: but Ember data expects specific data types for attributes. So
Speaker 1: how do we make sure that the data is formatic correctly?
Speaker 2: So that's where serializers come into play again.
Speaker 1: Okay, we would create.
Speaker 2: A custom serializer okay that basically handles the conversion between
Speaker 2: JavaScript objects and the stringified format used by local storage.
Speaker 2: So it's basically like a translator making sure that the data.
Speaker 1: Is the data is formatted correctly.
Speaker 2: It is formatted correctly.
Speaker 1: Yeah, and there's integrity yeah okay cool. Yeah, So that
Speaker 1: example I think is really cool.
Speaker 2: Yeah, it's a fun one because.
Speaker 1: It shows how adaptable the adapter and serializer system is.
Speaker 1: It really does in ember data. Yeah, but let's go
Speaker 1: back to those nested resource paths. Yeah we were talking
Speaker 1: about earlier. The book mentioned something called relationship links, right,
Speaker 1: could you elaborate a little bit on what those are?
Speaker 2: Certainly, so, relationship links are a way for APIs to
Speaker 2: actually provide direct URLs to related resources within a jason response. Okay,
Speaker 2: So imagine a scenario where you're fetching a blog post.
Speaker 2: Instead of including all of the author's data within the
Speaker 2: post's response, the API might just provide a link that
Speaker 2: allows you to fetch the author's details separately.
Speaker 1: Okay, So it's kind of a way to optimize the
Speaker 1: data transfer.
Speaker 2: Yeah, it's all about efficiency.
Speaker 1: And not repeat things unnecessarily.
Speaker 2: And the good news is the rest adapter has built
Speaker 2: in support for handling those relationship links, making it really
Speaker 2: easy to fetch that related data on demand.
Speaker 1: Cool.
Speaker 2: Now, not all APIs are designed to provide those convenient links.
Speaker 1: So what happens when we run into a situation is
Speaker 1: the API is using nested resource paths, but it doesn't
Speaker 1: give us those explicit relationship links.
Speaker 2: So the book actually provides a solution for this common scenario.
Speaker 2: It can override specific normalization methods in our serializers to
Speaker 2: kind of guide ember Data on how to construct those
Speaker 2: appropriate URLs for fetching the related data.
Speaker 1: So we're giving mber data this little Yeah, it's like
Speaker 1: a roadmap, roadmap showing it how to navigate through the
Speaker 1: nested structure. Yep, okay.
Speaker 2: And so this customization basically ensures that ember data can
Speaker 2: correctly fetch and associate related data even when the API
Speaker 2: doesn't explicitly provide those relationships in the response.
Speaker 1: Clearly spelled out exactly. Okay. Cool, And this leads us
Speaker 1: very nicely to our real world example here. Yeah, consuming
Speaker 1: the Reddit API.
Speaker 2: Yes, the Reddit API now, reddit.
Speaker 1: It's fun is known for its let's say unique unique
Speaker 1: yeah api structure.
Speaker 2: Yeah, it's a great test case.
Speaker 1: So I'm really curious to see how ember data handles this.
Speaker 2: It really demonstrates ember Data's flexibility.
Speaker 1: Okay, So the book walks us.
Speaker 2: Through creating custom adapters and serializers to interact with the
Speaker 2: Reddit API, specifically fetching posts from a subreddit and retrieving
Speaker 2: subreddit details.
Speaker 1: So we're dealing with nested endpoints, asynchronous relationship exactly, all
Speaker 1: those things like typical of a complex API.
Speaker 2: Yeah, exactly. And one key takeaway from this example is
Speaker 2: that we can create specialized adapters for different aspects of
Speaker 2: an API. So in this case, we create separate adapters
Speaker 2: for posts and subreddit details, but both of them extend
Speaker 2: from this base Reddit adapter that handles kind of the
Speaker 2: shared configuration.
Speaker 1: So that's a nice way to modularize the code and
Speaker 1: keep things organized exactly. Okay.
Speaker 2: Yeah, and the Reddit API example also involves serializer customization
Speaker 2: as well, because we need to tailor our serializers to
Speaker 2: handle the specific format of reddits responses, which involves extracting
Speaker 2: relevant data from these nested structures and then mapping it
Speaker 2: correctly to our ember models. The book demonstrates the use
Speaker 2: of methods like extracted attribute.
Speaker 1: And normalized find record response for this purpose.
Speaker 2: So it's kind of a combination of adapter and serializer magic.
Speaker 1: Exactly working together. Yeah, to tame that Reddit API beast. Okay,
Speaker 1: As with any real world API integration, there's bound to
Speaker 1: be a few unexpected hiccups along the way.
Speaker 2: What kind of hiccups did the Reddit API throw at us?
Speaker 1: Well? One issue that the book highlights is that you
Speaker 1: might get a warning message that can come up because
Speaker 1: of a mismatch between the requested subreddit ID and the
Speaker 1: ID that's returned in the API response.
Speaker 2: An ID mismatch that could.
Speaker 1: Yeah, that can lead to all sorts of confusion and errors. Yeah,
Speaker 1: but the book provides a simple fix for this. We
Speaker 1: basically update the ID within the normalized fine record response
Speaker 1: method to ensure that there's consistency.
Speaker 2: So it's a small detail.
Speaker 1: Yeah, it's a small thing. It can save you a
Speaker 1: lot of headaches. It's one of those things that if
Speaker 1: you don't catch it early on, exactly, it'll come back
Speaker 1: and bite you. Okay, So the Reddit API example, I
Speaker 1: think really shows the power of ember Data. It does
Speaker 1: even when we have these really kind of intricate API
Speaker 1: structures and all these unexpected quirks, we could still leverage
Speaker 1: all the flexibility to create this really smooth and reliable
Speaker 1: data interaction layer.
Speaker 2: Yeah, and that actually leads us nicely to our last
Speaker 2: big topic, which is polymorphic relationships, where a single relationship
Speaker 2: can hold records of different types.
Speaker 1: Right, so we briefly talked about this before, Yes we did.
Speaker 1: Can we actually see how these polymorphic relationships are implemented
Speaker 1: in code using the rest serializer?
Speaker 2: Absolutely? Okay, So let's go back to the example we
Speaker 2: talked about earlier of a user having multiple purchase products,
Speaker 2: which could be courses or books. So that of many
Speaker 2: relationship needs to be able to accommodate both of those
Speaker 2: product types.
Speaker 1: So it's a relationship where the type isn't.
Speaker 2: Fixed exactly, the type is not fixed.
Speaker 1: Okay.
Speaker 2: So ember Data handles this beautifully using the polymorphic option
Speaker 2: when we define that relationship in our model. So in
Speaker 2: our user model, we would define the purchase products relationship
Speaker 2: like this at has polymorphic as sink it o true
Speaker 2: purchased products.
Speaker 1: So the polymorphic that's the key that tells ember data
Speaker 1: that this relationship that it can hold can hold records
Speaker 1: of any type that inherits from our base product model.
Speaker 2: Yeah, so both the course and book models could be
Speaker 2: part of this purchase products relationship as long as they
Speaker 2: both extend that product model.
Speaker 1: That's really elegant.
Speaker 2: Yeah, that's pretty cool.
Speaker 1: So how does mber data actually know which specific model
Speaker 1: to use when it's fetching data for that relationship?
Speaker 2: So by default, the rest serializer looks for a key
Speaker 2: named product type in the API response to determine the
Speaker 2: type of each product. So let's imagine an API end
Speaker 2: point that returns all of a user's purchase products. The
Speaker 2: response might look something like this purchase products one type
Speaker 2: course title introduction to mber data type book title pro
Speaker 2: ember data.
Speaker 1: Okay, so the type property there is indicating whether it's
Speaker 1: a course or a book. So ember data is using
Speaker 1: that informations to know which model.
Speaker 2: To stantiate the appropriate marmali.
Speaker 1: But what if the API doesn't follow that product type convention?
Speaker 1: What if he uses like a different key.
Speaker 2: Yeah, so that's where customers like to make it altogether.
Speaker 2: If the API uses a different key, we can simply
Speaker 2: override the key for polymorphic type method in our serializer
Speaker 2: to tell Ember data.
Speaker 1: Hey, this is the key we're telling Ember data.
Speaker 2: You need to look for it exactly. And if the
Speaker 2: API uses like a completely different way of representing these
Speaker 2: polymorphic relationships, we have the flexibility to override the extra
Speaker 2: polymorphic relationship method and handle those customs scenarios.
Speaker 1: So, no matter how the API structures those relationships exactly,
Speaker 1: Amber Data gives us the tools, the tools to adapt
Speaker 1: and interpret them correctly. Yep, and that's true for both
Speaker 1: has made.
Speaker 2: The same principles belongs to the apply to polymorphic belongs
Speaker 2: to relationships as well.
Speaker 1: Okay, it's all about having that flexibility to map these
Speaker 1: different API structures exactly into.
Speaker 2: Our Ember models exactly.
Speaker 1: Okay. Cool, So I feel like we really Yeah, we
Speaker 1: dug deep, dug deep into the nuts and bolts here. Yeah,
Speaker 1: I'm starting to feel much more confident. That's great to
Speaker 1: hear and Amberdida's capabilities.
Speaker 2: Yeah, I think we've earned a short break okay before
Speaker 2: we wrap things up.
Speaker 1: Sounds good.
Speaker 2: So when we return, we'll just share a couple of
Speaker 2: final thoughts and leave you with some resources to continue. Okay,
Speaker 2: your Mber Data exploration.
Speaker 1: Okay, so we're back for the final part of our
Speaker 1: Mber data deep dive. Yeah, we've gone through a lot. Yeah,
Speaker 1: we went through those core con steps info, we delved
Speaker 1: into customizations. We even tackle the Reddit api. We did.
Speaker 2: So.
Speaker 1: Hopefully you're feeling empowered now, I hope so to handle
Speaker 1: all these data interactions in your Ember apps.
Speaker 2: Yeah, for sure, with.
Speaker 1: A little more confidence.
Speaker 2: Absolutely.
Speaker 1: Now before we wrap up any parting words of wisdom
Speaker 1: for our listeners out there, Yeah, I would say you're
Speaker 1: ready to just become.
Speaker 2: One of the most important things.
Speaker 1: Ember data masters to remember.
Speaker 2: Is to embrace that flexibility that Mber data offers. Okay,
Speaker 2: don't hesitate to customize those adapters and serializers to perfectly
Speaker 2: match the structure and conventions of your API.
Speaker 1: So customization is really like having It's like having a
Speaker 1: set of precision tools.
Speaker 2: It's a good set of tools, yeah, that you can
Speaker 2: use to really tailor Examber data to your exact needs.
Speaker 1: Yeah, and remember through testing, right is crucial whenever you're customizing, Yes,
Speaker 1: test those adapters and serializers both in isolation and through
Speaker 1: the Ember Data st just to make sure.
Speaker 2: Yeah, to make sure everything's playing nicely.
Speaker 1: Everything integrates smoothly and works as expected.
Speaker 2: Testing is our safety net, Yes, it is. It's making
Speaker 2: sure that those custom data interactions are actually robust and reliable.
Speaker 2: Exactly what resources would you recommend?
Speaker 1: Okay? Well, obviously, who want to learn even more?
Speaker 2: The book that we've been using as our guide pro
Speaker 2: Ember Data by David Tang.
Speaker 1: It's been our trustee companion for this whole deep dive
Speaker 1: for sure. Are there other resources? Yeah? The official you'd recommend?
Speaker 2: Ember Data documentation is always a good reference. It's a
Speaker 2: great place to find detailed API info and some guides. Okay,
Speaker 2: And don't underestimate the power of the Ember community. They
Speaker 2: are incredibly supportive.
Speaker 1: The Ember community is and.
Speaker 2: Always willing to share knowledge.
Speaker 1: The fantastic resource true forums and blog posts and conferences.
Speaker 1: Any final thoughts before we sign.
Speaker 2: Off, just remember that mastering data management in your Ember
Speaker 2: application can really be a game changer.
Speaker 1: Yeah.
Speaker 2: It streamlines development, reduces complexity, and ultimately helps you to
Speaker 2: create more robust and efficient application.
Speaker 1: I think that's a great point to end on. Well,
Speaker 1: it's been a pleasure exploring the world of Ember data
Speaker 1: with you today.
Speaker 2: Likewise, the pleasure was aline to.
Speaker 1: Our listeners out there. Thank you so much for joining
Speaker 1: us on this data driven adventure. Thanks everyone, Until next time,
Speaker 1: happy coding,