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