 Can you guys hear me? This works? Awesome. I am very, very excited to be here. I have not given a talk in Boston before. And I have to say, though, that this weather thing is really messing up, messing with my mojo. Because I have had to redo the intro to my talk three times already. Because I was thinking, OK, I'm going to an island. It's going to be warm. It's going to be nice. We're going to, like the 200 of us are going to hand out and have a great time. And I was very excited. So I was thinking of this intro to talk with nice umbrellas for the sun and nice cocktail glasses and beach chairs and stuff. And I actually did check the weather forecast as well. And then it said, oh, it's going to be fine. And then I arrived here yesterday. I was like, crap. But it's fine. Then I was like, OK, I'll just redo the intro. And then I was like, oh, I just made fun of the fact that it's always raining here in the weather strappy. And I had that intro. And then now, it's actually nice to get. So I don't really know what to do about it, except put. Oh, the boss, man. Yes, this is the best thing I could get. But anyhow, I was very, initially when I saw that there's a wicked good ember this year, I was in Europe. And I wasn't sure whether I actually want to make the trek all the way here. But then when I realized it's on this island, and this is where the part where I would say, oh, and we don't have any source of weather and everything would have gone otherwise. But when I realized that we don't be on this island and it's going to be awesome, I decided I'd really have to come here. And then I looked at the IFP, and I was like, I should really submit a talk. But at the time, I was feeling kind of lazy. And trust me, feeling lazy really gets to you, catches up with you at some point in your life. I was feeling kind of lazy. So I was like, I don't really have a new talk I want to give. But we can do the ember seems to be just a couple of days after we're going to release ember 2.0 and ember data 2.0. So I was like, let's just talk about that. Let's just say we released ember data 2.0. And that is not among the wisest things I've done. Because giving the talk four days after you're supposed to be releasing something leads to maybe, especially if it involves both talk preparation, traveling, and releasing all at the same time, leads to a bit of a stressful life for a few days. So actually, this is by far the most stress I've had for a week, because also a client of mine has released this week. So I would put actually giving the talk on the list of some of the unwise things I've done. And actually, I have basically given, I thought about this. I was like, yeah, I'll just say we released it, and I'll talk about what we've done. But immediately, I started having doubts, because I was thinking, well, what happens if we screw up? And then I thought, well, even if we screwed up, even if we didn't release, I mean, what is the worst possible thing that could happen? And then I started thinking about that, and I was like, you have 200 ember developers whom you hyped all these releases with you on an island in the middle of nowhere for two days. So basically, that added, that sounded very similar to a horror movie I watched, where this is actually also an island in Massachusetts, which made me very, very stressed and very scared. But fear not, we have not released, because IE8 stood us literally 15 minutes ago, when we were supposed to push the release. We have an IE8 bud, but we have branched the release. And sometime during my talk or immediately after, we are going to have released the ember data stable release. So hopefully, I'm safe at least for this couple of days here. But before I, and I'm very, very excited for this release, we have a lot of people have worked on it for a very long time. And I'm very excited to talk about it. But before I go into specifics and I talk to you about the actual release, let me just talk a bit about the philosophy and ideas of releasing and versioning and basically how version numbers and our releases work. Because if I really wanted to get away from the whole fact that if we had missed this release, we could have released anything and called it like 1.0. And I've been like, yeah, we have a 1.0. This is a release. And basically, there seems to be lots of people have very different opinions about release versions and somewhere and version numbers. And it seems to get into very heated debates. So before I actually show you what the newest ember data release is, I just want to first talk a bit about how we think about releases and what version numbers represent to us. So for example, if you think about different projects and their versioning strategies, they vary very widely. For example, you have libraries like underscore that don't really believe in somewhere. You have, for example, languages like Java, which don't believe in integers. And you also have different philosophies. You have people who claim that you cannot run out of numbers. But then, apparently, if you're liners, you cannot run out of numbers because literally the argument for why liners is 3.0 is because they don't want to go past 40. And the number is too high, so let's list the 3.0 for the 20 years of liners. Or if you have a real product, if you have a Gmail, you have kind of a version that says beta, but then you have no version number. And it really ties down not only to your personal philosophy and how you think about the world. It also ties down really tightly to your dev processes. So for example, if you have a small startup, if you have a small product, your dev process is basically right tests made them fail, made them pass, and then refactor. And your product probably won't even have release versions because your release cycles are so fast that every day you're releasing at least a couple of times. If you are a big, huge company with a lot of marketing pushes, you can think about your dev process being like, well, we'll release a lot of new features one year, and then next year we'll just polish them up. And then basically you have a two-step release process where every next release is either a lot of new features or a lot of polish. And I think that for a lot of projects, that kind of versioning system tends to work really well. If you're, for example, liners, your dev process is probably sent PRs to liners and hope he doesn't smite you with his anger, and hopefully they eventually get in. But when I think about the Embers development process, and when I try to think about how it works, well, some people would say that the Embers development process is remarkably simple and easy. It's basically go bother Rojax and tell him your problems and then see your problems resolve the next day. But I would argue that Embers release process in a lot of practical terms resembles Intel's release process with the famous TikTok releases, where Intel, if you ever looked at their processors, has kind of also a two-step release process in which one year they release a new architecture of their processor. And then next year they just use smaller gates and smaller transistors and use the same exact architecture but just make it smaller and faster. And then next year after that, they release another architecture version. And then next year after that, they make it smaller again. And until a couple years ago when our processor stopped getting faster, and now we just pay them money because they ship Apple ships new Macs. But basically Intel had this very, very stable release process. And I kind of think about Embers release process in the same way, where we also have a TikTok and a talk, except we don't release processors, we release software. So what we do is we refactor existing code and we have big band releases that don't add many new features, even though they're very hyped. Like with Intel, what people care about and what gets hyped, a lot of the times it's the new architecture, the new things you can do with a processor. But for engineers and the people who really care, you know that that's not really the important part. The important part is the refactoring. It's reducing the transistors in the process size because everything that's enabled us to get faster. Putters has basically been just the ability to make smaller and smaller processors. So for Ember, we kind of hype our refactor releases much more. So for example, if we go to some of the recent releases, Ember had like a MetalView release that got rid of the strip tabs. And while that was almost a feature, because you don't have to look at them and people don't troll you about them anymore and your CSS works better, this release did not actually add many new features but it was extremely important and hyped because it enabled other releases that would add features. So for another even better example is the Ember JS 1.9. If you look at 1.9, you'll see that the big thing that we released then was the stream refactor, that refactored how template it works. But that, if you just started using 1.9, this refactor wouldn't give you that much benefit. You would maybe code run a bit faster or maybe if you looked at the internals, they made a lot of sense, but there wasn't many new features. But yet if you go to Ember 1.10 and 1.11, you start getting a lot of really cool things. You get, for example, the component helper that's a new feature based on this refactor and is basically only 50 lines of code because this refactor enabled it. And you get, for example, the new helper's API that the IRC got implemented and merged recently. And this is also been enabled by the stream refactor. So what ends up happening is you get a release that everybody's very excited about that actually adds no new features and then over time you reap the rewards of these releases. A great example is the very, very hyped HTML bar release which was in Ember 1.10. And everybody was super excited about it if you looked at Ember 1.10. It was neither that much faster, neither it had any new features. But then if you look at a couple of releases afterwards and what we got from HTML bars, you got the bind adder, you got the inline if and it kind of paved the way for the new glimmer engine. And basically, I think that this is a really important way of thinking about Ember's releases because you'll hear a lot of people be very excited about something and then it lands and you look at it and you're like, well, this doesn't seem to actually affect me in my day-to-day work. But the reason that people are excited about it is because they're developers and they're excited about all the, well, first by getting to look at much, much cleaner code every day when they work on it, but mostly because you end up reaping the rewards over time over multiple releases and multiple new features. And for me personally, releasing features does not feel nearly as good as refactoring because releasing features mean you could screw up and you have to support it throughout the version while refactoring just means you're cleaning your own crap that you added earlier. So again, glimmer, it made everything faster and is a huge refactoring, but even more important value of it are all the new features that are coming to Ember 2.0 cycle. If you've been following the Ember RFCs, there's a lot of discussion about the new components style and a lot of things that are coming to Ember mostly because that are enabled by this bit band release. So how does this apply to my talk and is this like a just a giant diversion from trying to talk about Ember release. But basically, in the last year and a half, I think Ember data had lots of releases like that that for large refactoring and features, partially features that then enabled much better future work. So for example, we had the really big, in the last year and a half, we had the really big single source of truth branch that fixed relationships and loading of relationships and changing of relationships immediately. But it also enabled in later releases a bunch of new features. So we got better rollback in your new records. We got better removing deleted records from arrays and it also paved the way for some of the relationship rollback that we are going to add. Or for example, the find-crawl-s thing, which is the feature that we added a while ago that enables you to coalesce different finds for multiple records, is also, was also kind of cool and an internal reflector, but the real benefit of it came later in all the other barred fixes and features that we added with it, which is basically a much better link support for your relationships. Fits for when, if you had, for example, before the find-crawl-s thing, if you had, if it has many relationships with a couple of hundred IDs, you couldn't even fetch them because you would try to make a URL for them and the URL would be too long because apparently URLs have length limits and this enables us to break out the URLs by size and it also gave us much better, has many belongs to relationships and much better support. Or for example, the snapshot code, like couple of months ago we released snapshots which are basically an abstraction that lets you don't have side effects in your civilization code because if you have async relationships, our models are very, it is very easy to cause a bunch of async requests when you fetch relationships and it was pretty hard, almost impossible before this to serialize relationships properly. But now it's very easy because in your serialized method instead of getting a DS model, you get a snapshot of that model that lets you mess with it as much as you want to without actually modifying it or causing any side effects. So for example, now if you get a snapshot that's a post, if you access its comments, you can synchronously access them whether they're loader or not or also you can also get the IDs from the snapshot. Before if you tried doing this, you would cause a bunch of requests to your backend being like, hey, you asked for these comments, you don't have them, let me go fetch them and you're like, well, I'm actually giving them to you. Why would you want to fetch them? I'm just trying to send you the model. So this was also an important factor that because it enabled this but it also enabled a bunch of new features that we're gonna add and you will actually see some of them today. And the last thing that the last big refactor we landed about a month ago has been the internal models refactor which basically means that if you think about your Ember models, your Ember models are things like DS model that you extend and then define yourself. But the problem is that up to a couple of months ago as soon as data entered the system, we were using these Ember objects you define yourself in order to store data internally. And we have refactored that and now we do not use your DS models to store data, we have our own JavaScript objects that are much faster and we use them to store data internally which then enables us not only cleaner code and better performance but much better support for things like polymorphism and slugs because we currently have polymorphism in Ember data but it's not fully fleshed out because there were a lot of problems, for example, if you wanted to fetch a model whose type you didn't know beforehand that was pretty much impossible because we had to create a DS model for you and if we did not know the type we do not know what DS model to create. Now this is basically trivial because we keep the data in our backend in JavaScript objects and then we basically just instantiate DS model whenever you actually need it in your templates. So this leads to much better performance and also many more refactors. So this is basically what we have done up to couple of months ago. This has been the most major features and refactors in last year of Ember data and there are a lot of other random fixes but I think one of the other important things that happened in Ember data in the last six months is that we partially adopted Sember because at some point if you have users you can't afford to keep pissing them off by breaking changes. So for the last about six to eight months of Ember data more and more changes that we made were following Ember's model where we deprecated stuff first and still kept the support and then added new features and just told you to upgrade at your leisure and that's basically for the last couple of months I can't think of a single feature or change that we made that wasn't followed up with a proper deprecation and followed up with a proper upgrade pad the same way Ember would. So I think that basically we gradually kind of even though we were in the beta stage started following Sember by accident almost mostly because we already have users who use us seriously and can't afford to have to rewrite their apps every couple of months when they upgrade. So that kind of ties into basically what today's release is about because one of the there's a lot I'm gonna show you a lot of exciting things but one of the biggest and most important part is to give you an upgrade pad and to give you basically a sense of security the same way you have with Ember the same way you can now upgrade to Ember 113 and refactor and go further we want to give you the same sense of security when you use Ember data. So first let's just think about Ember itself. First I was going and looking at the first commit in Ember and this is the wrong I screwed up the link as I was refactoring stuff. The first commit in Ember was I looked it up couple hours ago was in April of 2011 and first commit in Ember data was in December of 2011. So Ember kind of had a six month start on Ember data but if you actually think about it it's a much, much longer start because Ember came off well though a completely flawed Sproutcore system Sproutcore still had lots of years to polish its object model that Ember took and all the other things that Ember took from Sproutcore while Ember data also kind of came out of Sproutcore data but Sproutcore data was not really impressive or fully fleshed out library anyhow. So the way I think about our current position in the Ember ecosystem and where we are is basically that we're kind of a year and a half behind Ember because we kind of started half a year later we are still unstable as of yesterday and we were basically had to refactor our code multiple times to kind of figure out the best way to approach the problem of data storing and synchronization. But now and also today when I looked at it it really reminds me of the way I looked at Ember a year and a half ago when Ember 1.0 came out we have now more than 300 contributors I actually looked up Ember had almost around 300 contributors when 1.0 came out, now it has like about 500 we have over 100 pages of commits on GitHub and we also for the last eight or nine months we've had a Ember data core team that meets every week to discuss PRs and features and I think it's one of the main reasons that you have seen a lot of improvement in Ember data is because there's this continuous push and a continuous scare that we basically put into it every week and it really reminds me of the way Ember when 1.0 came out because that is when major changes to the core team happen it is basically when they adopted Sember and they got behind a serious release process so I think it's time for Ember data to basically catch the Ember train and get up to speed with Sember and get up to speed with basically enabling you to build your apps without worrying about breaking stuff but the problem is that we can't just leave people behind and tell them, hey now we figured out how to do this better and trust us this time we're not gonna change it in six months and we are not gonna make you rewrite your app in half a year again so we can't afford to leave people behind without an upgrade path and I really wish that we had an audio out here but we don't so I can't play music but I would love to play safety dance for these titles but basically in order to support this and in order to support you upgrading and in order to support you getting up to Ember data stable release I am announcing today not one but two Ember data releases. We're gonna be releasing Ember data 1.13 and Ember data 2.0 beta 1 because we have basically spent a bunch of time making sure that we work with latest Ember. We have spent a bunch of time deprecating and making sure you can upgrade and we have basically for the last couple of months have been syncing up with Ember's progress so what we wanna do is have a final version of current Ember data that is guaranteed to work with Ember 1.13 has I8 support if you need it the same way Ember does which is why this is still not published because we still have a couple of random I8 bugs but yet we wanna in the future sync up with Ember itself and we wanna make people confident that when they get a version of Ember and a version of Ember data that they work together and they have the latest and best things and that's why all the primary libraries of Ember like so things like Ember data, ListView, LiquidFire will be adopting the same version numbers as Ember so when you get an Ember 2.3 you know that there's an Ember data of 2.3 that's guaranteed to work with it and there's a LiquidFire 2.3 that's guaranteed to work with it and there's a ListView 2.3 that's guaranteed to work with it so basically in order to catch up with the train we had to jump a couple of version numbers in order for maybe people here wouldn't mind as much but if Ember is successful I'm pretty sure that the number of people who are gonna use it in the future hugely dwarfs the number of people who use it today and when you're a newcomer to Ember it's really important to have the confidence and safety of knowing what actually you need to get and currently if you look at it you're basically saying oh there's an Ember JS that's 1.13 there's this Ember CLI thing that's 0. something am I supposed to be using that there's an Ember data beta is that like which one should I need like an Ember beta to use Ember data beta so this is the reason that we're basically gonna start go and sync up with Ember's versioning system so as I said Ember data 1.13 is gonna be a long-term support release in terms of security bugs only because we and is the last release that supports I8 the same way Ember 1.13 supports I8 and is the last release of the Ember 1.0 cycle and also I'm not sure a lot of newer site intents here but for the current users there is a plan for upgrading and deprecating that's basically the exactly the same as in Ember today so basically if you're using Ember data today and you wanna upgrade what you need to do is you go to Ember data 1.13 you get rid of all the deprecations you go to Ember data 2.0 and all your stuff is gonna work so the same way that Ember 2.0 does not introduce any new features Ember data 2.0 beta 1 does not except for one breaking change that we could not figure out how to deprecate properly Ember data 2.0 also does not introduce or remove any fully supported features it basically just removes deprecations and makes sure that you're on the right path so what is new in Ember data 1.13? I think the biggest when I think about why use Ember and what I like about it well the actual reason why I use Ember is because when I showed up to my first day of work my boss told me hey we use Ember and I told him and I told him what's that why wouldn't you use something like bad bone but if I was to and that's probably why my boss has a PhD and I don't but if I thought about it of like what I like the most about Ember I think it's world vision of programming is hard and complex and very frustrating and I think a lot of approaches and frameworks basically kind of give up on it and says the stuff we do is too complex the only way we can move forward is if we make our things simple and easy to read and easy to understand and that's the only way basically we can battle this complexity and Ember's philosophy has a bit more of a world changing view which is basically more similar to Rails where it says well yes it's true that our stuff is hard and it's very hard to deal with the problems that we have but maybe if we all work together and solve each other's common problems and it turns out that none of us are special most of us are solving the exact same problems every single day and if we solve 80% of people's problems maybe if we join and work together we can make tools that work conventionally and that are canonical and that allow you to move forward with much greater speed in the future rather than trying to reinvent your stack every time using small building blocks and that's I think one of the only ways that we like when people wrote first programming languages and wrote and went from assembly you could have given up and said this stuff is hard but you didn't you basically built very solid abstractions that cover 95% of cases and made us much productive and able to now instead of spending years building airline systems can spend months making fun mobile apps because we have basically built up all the stats up to here so what makes me the most excited about this Ember data release is something that we have been working on for years now and that is basically that about a month ago JSON API released its 1.0 final version and Ember data has adopted JSON API fully and in the 2.0 and 1.13 we'll be first having a native JSON API adapter and serializer that comes with Ember data itself and is not an outside add-on and in 2.0 it's gonna become a native basically a default way you write adapters and serializers in Ember data it is basically the happiest of the happy pats where we want to ensure that people if they're starting a new app today they come to us and ask us hey what kind of API should I have I know my server guys are telling me to do this but maybe you guys also build front end apps all the time can you tell me what you recommend and that becomes like a very long and complicated discussion and it's not gonna be a long and complicated discussion anymore because we're gonna tell them just use JSON API and we guarantee that your stuff is gonna work and then also all the JSON API extensions and support for things like pagination and filtering are coming in 2.1 and 2.2 releases of Ember data because we can reason about it and we can know what JSON API supports and we can offer native basically support in Ember data itself and make a very, very happy path and there's already a JSON API adapter that was out for like a year now that Kerco maintained and big thanks to him but I think that's something as important as conventional as APIs should really be part of core of Ember data so that took all his tests and worked with him and basically rewrote all our internal tools to basically use a new JSON API serializer that's gonna become default in 2.0 but not only are we using a JSON API adapter serializer we also rewrote our internal format so if you remember if you use like things like store.push this accepted some sort of a JSON format where you had to look for dots that we kind of dot ourselves this is now deprecated in 1.13 store.push that just states a JSON API object document as all the serializer adapter so our serializer actually I hyped it as this great release but our serializer doesn't do much because all our serializer does it states the payload process some arguments and gives it back to the store because our internal format in Ember data is also becoming a JSON API compliant this also enables bunch of new features because links it gives us better support for links and uses better support for meta and all the stuff that much better performance and all the stuff that people thought about for all the stuff that people thought about through years of trying to design JSON API are now become native in Ember data the other part is so we have a new serializer adapter API so we have a JSON API adapter and serializer we have used JSON API as our internal format another thing we've done for the 2.0 release and 1.13 is we have refactored our serializer and adapter API if you have tried to extend JSON API and REST serializer while they work pretty well and are pretty stable they're very confusing to use because they have APIs that are like extract array and extract single and normalize payload and normalize and then you should sit there and you're like well what's the difference between normalizing the signal thing and extracting the signal thing am I not normalizing it when I extract it what happens here and the problem the reason that these APIs are designed like this is because if you have a payload that looks like this where you push a single thing if you have a very complex payload if you have a payload that's like all the users and all the teams of those users and all the admins it's a very complex payload that can't just couldn't have just been pushed into the store you would have to process it and then push it one by one the new JSON serializer is much simpler it basically so this is how it used to look and if you had a payload that looks like let's say you had a payload that had some data and some included stuff you would have to parse it and find everything included and then manually store that, push it and mess with it and that also means that your serialization layer had side effects because as you were parsing it you were also pushing stuff into the store and that sounds very crazy scrolling something that normalize or serialize shouldn't really affect any of your state that makes it much less testable and much harder to reason about so we have completely refactored our serializer API and now it basically looks like this you get a response from the server turn it into JSON API and give it back to us and we'll make sure it works so it is much easier basically for something you basically turn whatever payload you get you turn it into something that looks like this and this has no side effects has much better performance and is much, much easier to understand so for example this is how most of our trend of the new normalize function how the way it looks like now is much, much simpler you basically say hey I want the attributes and relationships and the ID and the type and you just return that and that's basically everything you have to do so I think also for people who are trying to design their own serializers reasoning about how do I turn this JSON into something like JSON API is much, much easier and better than trying to figure out okay so what does Ember data want me to do here? Should I be pushing these records or should I be returning them? In what cases do I need to return it and how does this whole thing work it basically becomes a much bigger mess and much harder to reason about so I'm one, the serializer refactor is something I'm personally very, very excited about we worked very hard to refactor it and back did a bunch of work on it and made me very like looking at the method that looks like this compared to the way that our trend normalization method looked like makes me extremely happy this also then having all these new serializer methods allows for much nicer metadata support because before as you were pushing stuff the only way to get or set metadata would be as a global object and that makes absolutely no sense there's a bunch of use cases that are not supported by this so we are deprecating this API and we are adding nicer metadata basically JSON API already knows what metadata is you can now and we'll parse that and attach it to our objects so now you can not only is it not global you can attach it at any level of your payload if you want metadata for the whole request we'll know how to parse that if you want the metadata for a specific user we also know how to parse that as well and that is going to enable a much easier pagination much easier filtering and much easier partial attributes and many other use cases that were very hard to support right now so all of these new features are awesome but I at least hyped a bit of the upgrade part and the applications so let me tell you how you can go from whatever you're having now to all this new goodness basically 113 we have a couple of very clever solutions that basically 113 has all the new APIs but also is completely backwards compatible and if you upgrade to 113 your app should continue to work with no problems except you'll get a bunch of deprecation warnings so all you have to do is go to EmberData 1.13 to look at the deprecation warnings and fix them and that is actually not as hard as it seems because if you're using the default serializers and if you're using the default serializers you have zero work to do everything will just work for you if you're using a community supported serializer we'll make sure to work with community authors of the adapters and serializers so in time for 2.0 to be ready so you can use it if you have customized serializers all you have to do is see the deprecation that tells you hey you have customized something in your serializer you might want to double check if it still works with a new serializer we'll publish some transition guide of how to convert your extract methods and whatever traces you have into the new simpler methods and basically you then turn on a flag to say hey I have opted into the new API please let me use the new API and in 2.0 the new API is the only API and then your flag can just go away but this can also be pretty stressful and annoying and kind of very error prone so one other thing that I'm announcing today that is not yet ready but will be for the 2.0 full release is that the ember inspector is going to get a civilization tab and you're going to be able to see all your methods and all your civilization methods and how they start together and what actually every single one of them is doing and this is super when I talk about civilizations and normalizations what ends up happening is I see my record came back and I'm expecting to see 10 IDs here but instead of IDs I'm seeing empty strings so obviously one of the 10 normalization steps in the normalization pipeline failed so let me put a break point and spend half an hour walking through this and trying to understand where which one of the methods failed and using the ember inspector it will be much much easier you'll basically just walk through it and see the results immediately and see what the result of every single of your normalization method is and if you want to debug a specific one for a specific record you can basically just put the checkbox and say hey whenever I hit this create record for this record just throw me into the debugger and ember inspector can use the debugger APIs to basically for the for Chrome to put a break point there for you and this will lead to a much much easier debugging experience and will help you a lot if you need to debug crazy serializers or upgrade them to the latest serializer API and we are also working on ember Watson helpers that will take your existing structures and rewrite them for you Adolfo actually wrote one already we are basically we are also deprecating we are in 2.0 we are making async relationships the default so currently sync relationships are the default and async you need to opt into using async through which is a very bad workflow because your relationships should be async by default and really only if you're doing something super custom should you opt into sync relationships so in the future you all your current code all the sync ones by default will have to say sync through and all the ones you have async through don't have to say anything but you don't have to do that yourself because if you just use ember Watson it's already in today you can just run ember Watson against your code base it will go through every single of your relationships and upgrade them automatically because it can see whether it was sync or async and just replace it for you and there's other couple of very exciting Watson helpers we are working on for example I showed you that the push if you use store.push with the old format you need to turn it into new format and that's very common to do in the tests because of all the backcompat work we had to do to keep support for both we have a bunch of helpers that do that automatically so we're working on an ember Watson helper that will go through your entire code base find all your store pushes and just automatically rewrite them from the old API into the new API for you so basically so you can get all the mechanical stuff done out of the way and get 90% there to using ember data point 2.0 so these are the some of the things I talked about JSON API adapter, JSON API like basically refactoring our entire code base to support JSON API as a first class citizen I am running out of time but there's one at least one more super exciting thing I really want to talk about is that is we have refactored the find APIs currently ember data started with a simple store.find and as any framework kind of drew into a mess from there because we started okay what do you need to get data? Let's use, you just need to say store.find and you can get a specific type you can for example get all your users or you can get a specific user you can say give me user one but then later we were like well maybe you need to do a specific query so we added store.find type with an options hash that does a query for that type then we were like oh maybe you need to have nested URLs and you need to pre-load some data so we added type ID and then like a pre-loaded data where you can say my user has a relationship with this post and you can automatically go to slash post slash user URL but then what we needed to support was maybe sometimes you don't want to use the identity map maybe sometimes you want to always get the freshest data so we added store.fetch maybe you needed a sync maybe you just wanted to know what's in your store so we added store.getbyd and if you look at our current find APIs there are a complete mess because there's at least seven or eight different methods that are all not named symmetrically and are basically very hard to understand and are not intuitive especially for somebody new to use so we have settled down on a couple of naming conventions and a couple of methods that are going to do all this crazy work for you and basically in EmberData 113 we have added find.all and find.record and every single method if you have basically have a find and peak find goes to the server peak gives you local data you'll have find.all you have peak.all you have find.record you have peak.record and that's pretty much it all you have and basically now that we have a structured API it's much easier to pass options to your adapter so now you can also optionally pass options to your adapter if it needs to do something crazy with your API and find.record so currently the way find.behaves is it fetches data from the server first time and then saves data into your identity map and otherwise then always gets you still data and then you have to opt into basically refreshing and you have to call reload manually this is not a very intuitive workflow especially for somebody who's writing a very conventional app so what we're going to do by default in the future is render but then fetch in the background to get the latest updates this is completely customizable if you actually always want the freshest data it will be very easy to say find.record and then reload through to force it to get only the freshest data but also this works really well if in your code you know oh I'm doing something very important I always want the freshest data these kind of APIs that I've showed you both the new ones and the old ones are not very easy to use if you for example have an API that will give you an expires tag if your API tells you hey this is a resource it expires in 24 hours or 2 hours or 15 minutes you need to refresh it after that and there's there was no way for your adapter to have any say into whether you're going to fetch something or you're not going to fetch something so we have added actually not only the support for manually passing options like reload or fetch in background your adapter can also be customized and look at things like meta or expires header to tell you whether you need to background fetch or you need to wait for reload so for my formatting got a bit messed up but there are two new adapter methods there's actually an IFC you can look at and there's a should refresh record is an adapter method that will take a snapshot of the record and tell the app hey this record looks very fresh you can keep it or this I looked up a meta on this record with expires header and you really need to go you cannot show it to the user because it's an important record they need to go refetch it so basically should refresh will tell the app whether it needs to go refetch it immediately or can show still data to the user and should background update is basically telling the app hey you have shown user your current data should you now go and update it in the background and maybe here you can see if you're currently offline you have no network connection don't try to background update if you have a network connection go and background update or if you or also customize it per adapter and per meta tags and it's also much easier now to have if you have a store.find for example it was much harder to pass specific options to the adapter especially for things like save when you do a save you often need to do tell something specific to your adapter and now you can because we have a very conventional API you can pass things like adapter options to adapter and it will just receive them on the snapshot and all of this all these new APIs are still backwards compatible if you use them in 1.13 your code will still continue to work you'll just get a bunch of deprecations to use the new methods so for example find will because currently find that there's no background updates that could mess with your app if you do store.find it will behind the scene use find record and say do not update in the background and it will tell you hey you seem to be using an old method please update and please please set your background update methods to false if you want to keep that behavior or if you want your data to automatically get refreshed set just don't touch it because the new default is that we will try to always background update it because we think that leads to the best user experience possible so yes these are all fully backwards compatible and we'll just throw a bunch of deprecations a couple other things that I have I don't think I have time to go through we have much better error support we have slimmed down our errors we had there were a couple of issues with how errors were today in that we leave the jQuery object we now have nice hoards that refactor your errors again into the JSON API error spec and we'll be able to work much easier and much better out of the box and yes that is basically everything in EmberData 1.13 in EmberData 2.0 you're basically getting EmberData 1.13 with couple of breaking changes and I don't think I have time to go through this one but it basically currently if you delete something it immediately gets removed from record arrays this makes it very hard to build good UIs that like show a spinner or draw out records we will not do this by default but we will make sure that if you have relationships for relationships your stuff will still work and yes so basically if you serialize stuff you even if you delete things they will still they will not be there again so this is the only breaking change because we cannot really deprecate whether records appear or not but they'll be a very very easy upgrade path so I just want to thank everybody who worked on this because it took a lot of effort, lots of time just these two releases had 46 contributors and these are some of the people who worked other than the core team who worked super hard and also some of our sponsors who donated their time, energy, money or resources into helping us ship this so thank you that's pretty much it also as part of the one point of which we have released a lot of people have been asking me for support for partial records how do you get a single record if you ask for all the posts you get all the posts that have only a name and if you ask for a specific post you get a name plus a bunch of other data this is a super common request we have released an add-on that does that really easily for you and out of the box and will be super easy to use I don't have time to show it to you right now but trust me it's pretty awesome words with promises and out of the box thank you we're going to have time for one question Igor will be available to answer questions out the words but I know we're running pretty late today so who's the lucky person who gets to ask the question don't be shy one person, one person, one person oh there we go are you considering support for PUTCH? I think now by default JSON API accepts PUTCH but we are sending all the changes as of right now we need to have better relationship tracking and relationship rollback I see that landing sometime around 2.2 probably as soon as we finish oh yeah I'll try to be faster but I don't think we can do it before 2.2 but yes that's how we basically will add PUTCH and relationship rollback support together because you kind of need to know what changed to rollback and to send a PUTCH for as many as thank you