AMS, API, Rails and a developer, a Love Story
Moura, João M. D.
A lot of people have being using Rails to develop both their internal or external API, but building a high quality API can be hard, and performance is a key point to achieve it. I'll share my stories with APIs, and tell you how Active Model Serializer, component of Rails-API, helped me. AMS have being used across thousands of applications bringing convention over configuration to JSON generation. This talk will give you a sneak peek of a new version of AMS that we have being working on, it's new cache conventions, and how it's being considered to be shipped by default in new Rails 5.
 A.P.I. A.P.I. is one of the things that we have quite a business to do. We are always using it, we all have been using it, and it's pretty special for the internet to use to get to the mobile. A.P.I. is not new technology, it has been used way before the internet comes, and the internet has pushed it even further by increasing the power of how machines can communicate with other machines. How this mobile and wearable lifters are coming out, and how this movement that is going on right now, and who is pushing it even further, we as developers have been using it in radios, and a lot of other tools and other lifters, and now those are a few great APIs, and a great API that is a lot of time-lapse. My name is Juan Mota, I'm the co-founder of Jiggo from We Are Assas for identification. This is how you can find more computer, internet, and internal. Today we are going to talk about AMS, API, Rails, and another thing that we have been tied up by a lot of stuff. I tried to make a lot of stuff that could be a short part, but I probably should get started a little bit, so for those that doesn't know, I'm from Brazil. And Brazil is awesome. Actually, this is how far I am from home right now, just talking to me, it's like an hour of life. And what is funny is that every time, every time that I go to every conference in the world, and I tell them that I'm from Brazil, everybody asks me about all these things, and I'm just like, hey, I got an answer. So, every time that I tell people that I'm from Brazil, it's really funny because everybody asks me, what about all these trees and lakes and animals that you have around, it must be really fun. But actually, the thing that I came from, something like this, there's no trees, no lakes, no animals at all, and actually the largest city of the whole Americas, and also the largest city of the whole southern hemisphere. Yeah, it's pretty big, we have a lot of traffic, a lot of jam, so this is a picture of my usual Friday night, you can easily become one of those. What is funny about this picture is that if you take a look at this land type, even the motor cycles are having a jam. So, yeah, it's pretty tough. But one thing that we know how to do pretty well is to have fun. Yeah, we Brazilians love to have fun and love to hang out, and one of the major tournaments stuff that we have in our country is soccer. Soccer is huge in Brazil, everybody likes it, everybody tries at least to play it, and it's really cool. So, last year we had a World Cup, I was invited to join a startup as their CTO, called Alvitators, and it was a lot of fun. I talked a little bit about it on Vimecon, if you want to know more about it, you can watch the conference now. But the code was a mess. We are a couple weeks away from the World Cup, and we are not ready for a bunch of users there, we are about to get in the application. So, we have all types of problems that you can imagine. No background jobs, we had bad relationships, bad architecture, we had indexes that weren't missing, and we also had no cash at all. So, our APIs were really, really shit. Yeah, I have to be serious about it, we are really good at the World Cup, and I really know what I should do. So, that was when I found love, and I found love with AMS, and it wasn't me. AMS, how many of you have used active models to realize it? Alright, so you've learned a lot of these thoughts. But, first, let's take it easy. This is when I found love, I always loved open source, and I was about to contribute with people, and building new things. But, that time I really found love with Active and Modern Surrealizer and RAO's API. For those that didn't know, I'm one of the contributors for RAO's API, and Active and Modern Surrealizer, we are doing an amazing job, I talked a little bit about it from the end of 2000. But, first, to get started, let's talk a little bit about API. API stands for Application Programming Interface. And, I would like to dive into the story of this definition, that it's interface. Like, we are so worried nowadays about interface in general, like everybody knows how much user experience is important to an application. Everybody knows how much a user interface is important, and how much it can really take you apart from a bunch of other applications. But, what we usually do, again, is that APIs are also a kind of interface, because they are users that are going to use it, or they are customers, or they are developers, or they are team, or other developers that are going to integrate with it. So, yeah, we should be putting the same ford and the same amount of technology and for in-development APIs as we do with usual user interface and user experience. Because APIs can really be one of the great assets of a company. If we take a look at Facebook, for example, Facebook is the biggest ever-made social network in the story of your magnitude. And I don't know if you realize how much the API, their API, help them to achieve it. Like, nowadays, we are using this app, signing with Facebook movements all across the web. Like, we assume every time that you view the application, that we are going to integrate with Facebook. So, yeah, their API has been like a major tool in their expanding process. But it also can be one of the greatest liabilities of a company. Because if you don't do, if you don't write a good API, it should definitely come back to善 you. You're going to have to invest money to fix it, you're going to have to invest time and people to fix it, and you probably give a bad experience for everyone that is going to integrate with you. So, the question here is, how do we build a good API? What are the definitions of a good API? Well, in order to define the API, there are eight concepts that we have to use. Those eight concepts is what defines if you have a good API or a bad API. These concepts are, performance, scalability, reusability, aboveability, documentation. It must be easy to learn, it must be easy to use, and mostly, it must be hard to reach huge. So, these eight concepts, it's what defines if an API is a good API or a bad API. So, we have to start to worry about this. Well, there is a great talk about the fact that Joshua Lange is going to Google, Google Daystyle on 20th July, and he may like this code that it's really precise and really will help you to achieve a good API. You should do one thing and do it well. So, this is the, this is what we will start about thinking APIs for an hour, but if you actually do one thing and want to do it well. But if we take a look at the technical side of it, we have a lot of tools to build APIs. We have a lot of tools that might help us to build APIs. And I would like to tell you a little bit about why Rails is the best tool to build APIs. The thing is, I would like to talk about it, but it's not. Yeah. But it's a great one. We know that there's no super good, there's a lot of downsides where Rails is a great tool, and I will show you how we can use Rails in the development way. So, the things about why Rails is a great tool, is because if you take a look at that eight points that I pointed out for you, that the form of this kind of ability, RTU, ECU, RTU is used, all of them are deeply related with conventions. If you follow conventions, you probably have a performance. It's probably easy to document. It's probably easy to use, hard to misuse, and easy to scale. So, they are all deeply connected with conventions, and conventions by itself is deeply connected to Rails. Rails is all about conventions. So, yeah, this is why Rails makes APIs underway to develop APIs. But I have to argue it's something that Rails is indeed produced. So, yeah, Rails has a lot of parts that you might not want to use, and a lot of parts that you might want to use when developing an API. So, this is why Rails API exists. How many of you have already used Rails API? All right, two. What Rails API does is it removes the parts of the Rails that you don't really need and don't really want to develop an API, and it brings new functionality that you might use and might want when you make APIs. It's pretty much simple. And one of these specialities, one of these projects that Rails API has in union is Active Model for Reliance, also known as AMX. The easiest way to define Active Model Surveyorizer is that it brings convention over configuration to your table. So, it follows the Rails concept, it follows the Rails logic, and it also is made in a convention. But it adds a layer in your Rails application that will handle the conversion of an object that you have into a JSON object. So, I'll show you an example of what is a Surveyorizer on a Rails application. This is what a Surveyorizer looks like in a Rails application. I'm going to go through it. So, first things first, you have the definition of a Surveyorizer, no worries. We have a line that defines the actual boot that we want to return as JSON, in this case, title, body, and comments count. But the thing is, comments count isn't an attribute of post. So, it's a virtual attribute that you create on the Surveyorizer. So, this is the method that counts the comments of a post, and then gives it back to JSON. So, once that you have this Surveyorizer in your Rails application, this is the output that you're going to have. So, you're going to have a JSON attribute, every time that a post is returned to your client, and you have an ID, title, body, and comments count. Pretty much easy, right? Alright, so we have been using ALS, I think, some years from now. The first question that was kind of stable was the 08 version. How many of you use the 08 version? Alright, we have the online version. How many of you use it? Alright, cool. And we also have been working on 010 version. How many heard about it? Alright, it's cool. So, yeah, we are working really hard for several months in the 010 version, and I would like to give you a sneak peek of it, and the great features it has, and it will have, and you'll learn a lot, I'm sure, about it. So, the first feature is we implemented a Docker popup. So, what it means, right now, a Docker popup, it's a part of ActiveModerncy Realizer, that describes how the attributes will be serialized. It means that if you would like to use ActiveModerncy Realizer, to do an XML, for example, you could build an adapter by yourself, and you can create it with ActiveModerncy Realizer. So, it makes it easy for people that want to use other formats, harder than JSON, to use ActiveModerncy Realizer, and if they want to contribute, beauty and contributing to the project itself, by doing new adapters that don't work only with JSON. So, yeah, it was a great change, and a small one, so yeah, quick win for us. So, the second feature that I would like to talk about, and this one, it's really cool, and I really would like to focus a little bit about it, because I don't know how many of you have heard about it, it's JSON API. How many of you have heard about JSON API? All right, JSON API, the standard for building APIs in JSON. So, it started back some months ago, some of the brilliant and greatest minds and friends that I have, I know have been working on that, so you might know Steven Klaibnick, and he moved it and given another task, another conference, another room, so they started building it, and there's a lot of other brilliant people that are working on it right now. The concept is, they want to define a standard form to build APIs in JSON APIs, and it brings all the good things that conventions always bring, so you don't have to worry about negotiating it with your other employees and your other developers, you don't have to, a friend and developer don't have to worry about how long it's integrated, or which cubes will be returned as for API. So, yeah, it's really cool, it really makes it a lot easier to integrate APIs into new APIs and make it a lot faster, we really believe in that, and we are kind of glad to announce that we already commented the JSON API release in CapDate 3 in this new version, and the 1.0 version is supposed to be released on May 21, and we are already working on that, so after the release, we're probably going to also merge it with ActiveModels Realizer, and it's really cool because if you choose to use JSON API, you could build APIs way faster, follow up comments, that you anyone in the world who know what it's about, so yeah, it's really cool, and we're really proud of it. The next two features that I'm going to talk about are some features that I'm pretty proud of because I'm the one that made it, and I really think that it can really help a lot of developers out there, because it helped me on increasing and improving my APIs back then in WordCut. So, the first one is Cache. We have implemented a building Cache functionality inside of ActiveModels Realizer. So, it's a totally new implementation right in first patch. It's optimized and it's followed the real situation. I'm going to show you as a big pick of how it works. So, these are the usual serializer, a post-serializer with a title and body attributes. Let's say that you would like to cache it. All you have to do is add a cache method, and it's done. I have to do that, a cache method is a serializer, any part of it, and it will be cached, and it will reuse it. But you can go further than that. You can even specify a key for your cache, or even further than that, you can use all the Rails conventions. So, you can place X-parries in three hours, and this cache method X-parries every three hours, and it's really helpful. So, let's imagine that this serializer has a post-controller. So, this is a post-controller with an index definition, usual stuff, so every time that a user goes to the index method, it will generate the cache, as we saw in the post-serializer. The good part is, when the user goes to the show method, the same cache will reuse it across every action that uses the post-serializer. So, yeah, it's a really great optimization, and might make a lot of difference on your application API. The next feature that I would like to talk about, and it's another really cool feature, is Threadman Cache. Threadman Cache can really save you a lot of times. What it does is, oh, sorry, what it does is, it always follows the Rails conventions. It's always, it always, it always, yeah. It also follows the Rails conventions, and it's built to cache-specific attributes on a serializer. I'm going to show you this thing, pick up the two. So, take a look at this post-serializer. It's a little bit more complex. So, we still have a title, a body, and a comments count attribute, but this time, we are overriding the title attribute, and we are overriding the comments count attribute, and generating that inside the serializer. So, if you take a look at those two methods by themselves, you're going to see that the title, despite of being a modification of the usual title of the post, is definitely cached. But the second attribute that it calls how many comments it has, it's non-cached, because it can change very quickly. So, how can we cache one part of this serializer and get the other outside, and still have the improvements of the cache documentation? So, right now, all you have to do is add cache, home, title, also using the Rails convention. You can always, I think, always use the other ones, so accept, comments count, and it's okay. So, this is what you can do with, you put everything together. So, you can define cache, you can use a key, you can use all the Rails method, like it's firing in, and you can also use it to make it pregnant cache. So, yeah, it's really cool, and it's a really cool, two features that tie together really well. Now, there is this famous phrase, I mean, God, the truth is, and now the other is big data. What about how it can be problematic? How it can be concerned with the old versions of active models to realize it? Because this was totally he-righted. It was right in the scratch. So, well, I made some benchmarks. So, if we take a look at the oldest, the left version, the online version, this is what we look at like, a benchmark that I made with, like, 10,000 times, building an azimuth, a realizer. But if we take a look at the new version, we have a drop of, significantly, a drop of 10 seconds, obviously, and if we use cache, we're going to see, like, almost 15 seconds drop. So, yeah, it's a really great increase of performance, and it might really help very much. So, there's a lot of work in progress, too. Like, we still have a lot of things to do. We are really working hard to implement that much so we can push forward to have even faster response when loads are a lot of cache together. We are still working on a benchmark implementation that will help us to also keep track of the performance issues wherever we can. And there's one more thing I'd like to talk about that's really cool, and I'm not sure if I even believe it. It's that we made it, we have just released an AMS work-end like today, early this morning, just because of RailsConf. So, you are all able to use this as your work. So, you are all able to update your GAMs, you are able to update your applications, and use technical models to realize it. I'd like to try something new here, so if you'd like to teach about it, you can use the hashtag AMS-TAN. Yeah, if you would be like, whoa, what is AMS-TAN? Let's check it out. So, yeah, use the hashtag AMS-TAN alongside with RailsConf, and the people will be concerned about what it is, and you should check this out. So, we have released it this morning, you are all able to update it. We still have a lot of work to do, but yeah, it's really great. And actually, I have another thing to talk about, and it's really cool. Not sure yet, but I think that I should share with you because I'm excited about it. We have been touched with RailsConf team for some weeks from now, and we are really excited about the possibility of AMS joining Rails as a full. So, you would be able to use it in Rails application. It's not for sure yet, but we have been going through it, and it seems that it's going to happen, and I'm really glad that I shared it with you, so we can push forward and make it happen. I also would like to give you a special thanks for the whole AMS, Rails API team. They are amazing, specifically those four amazing guys that have been closely working with for the last months. There is a lot of other contributors, a lot of amazing developers, and amazing people that have helped us out, but there's four people who are amazing, they have been helping me in doing this. Actually, I haven't been learning for them a lot, and I think that I ended up going too fast. I was going to take like another 15 minutes, but I think it's great because you have some time for questions. I would like to thank you all for being here, and letting you know that it was amazing to talk to you guys. Thank you.
 A.P.I.  A.P.I. is one of the things that we have quite a business to do.  We are always using it, we all have been using it,  and it's pretty special for the internet to use to get to the mobile.  A.P.I. is not new technology, it has been used way before the internet comes,  and the internet has pushed it even further by increasing the power of how machines can communicate with other machines.  How this mobile and wearable lifters are coming out,  and how this movement that is going on right now,  and who is pushing it even further, we as developers have been using it in radios,  and a lot of other tools and other lifters,  and now those are a few great APIs, and a great API that is a lot of time-lapse.  My name is Juan Mota, I'm the co-founder of Jiggo from We Are Assas for identification.  This is how you can find more computer, internet, and internal.  Today we are going to talk about AMS, API, Rails, and another thing that we have been tied up by a lot of stuff.  I tried to make a lot of stuff that could be a short part,  but I probably should get started a little bit,  so for those that doesn't know, I'm from Brazil.  And Brazil is awesome.  Actually, this is how far I am from home right now,  just talking to me, it's like an hour of life.  And what is funny is that every time, every time that I go to every conference in the world,  and I tell them that I'm from Brazil, everybody asks me about all these things,  and I'm just like, hey, I got an answer.  So, every time that I tell people that I'm from Brazil, it's really funny because everybody asks me,  what about all these trees and lakes and animals that you have around, it must be really fun.  But actually, the thing that I came from, something like this,  there's no trees, no lakes, no animals at all,  and actually the largest city of the whole Americas,  and also the largest city of the whole southern hemisphere.  Yeah, it's pretty big, we have a lot of traffic, a lot of jam,  so this is a picture of my usual Friday night, you can easily become one of those.  What is funny about this picture is that if you take a look at this land type,  even the motor cycles are having a jam.  So, yeah, it's pretty tough.  But one thing that we know how to do pretty well is to have fun.  Yeah, we Brazilians love to have fun and love to hang out,  and one of the major tournaments stuff that we have in our country is soccer.  Soccer is huge in Brazil, everybody likes it, everybody tries at least to play it,  and it's really cool.  So, last year we had a World Cup, I was invited to join a startup as their CTO,  called Alvitators, and it was a lot of fun.  I talked a little bit about it on Vimecon,  if you want to know more about it, you can watch the conference now.  But the code was a mess.  We are a couple weeks away from the World Cup,  and we are not ready for a bunch of users there,  we are about to get in the application.  So, we have all types of problems that you can imagine.  No background jobs, we had bad relationships, bad architecture,  we had indexes that weren't missing, and we also had no cash at all.  So, our APIs were really, really shit.  Yeah, I have to be serious about it,  we are really good at the World Cup, and I really know what I should do.  So, that was when I found love, and I found love with AMS,  and it wasn't me.  AMS, how many of you have used active models to realize it?  Alright, so you've learned a lot of these thoughts.  But, first, let's take it easy.  This is when I found love, I always loved open source,  and I was about to contribute with people, and building new things.  But, that time I really found love with Active and Modern Surrealizer and RAO's API.  For those that didn't know, I'm one of the contributors for RAO's API,  and Active and Modern Surrealizer, we are doing an amazing job,  I talked a little bit about it from the end of 2000.  But, first, to get started, let's talk a little bit about API.  API stands for Application Programming Interface.  And, I would like to dive into the story of this definition, that it's interface.  Like, we are so worried nowadays about interface in general,  like everybody knows how much user experience is important to an application.  Everybody knows how much a user interface is important,  and how much it can really take you apart from a bunch of other applications.  But, what we usually do, again, is that APIs are also a kind of interface,  because they are users that are going to use it,  or they are customers, or they are developers, or they are team,  or other developers that are going to integrate with it.  So, yeah, we should be putting the same ford and the same amount of technology  and for in-development APIs as we do with usual user interface and user experience.  Because APIs can really be one of the great assets of a company.  If we take a look at Facebook, for example,  Facebook is the biggest ever-made social network in the story of your magnitude.  And I don't know if you realize how much the API, their API, help them to achieve it.  Like, nowadays, we are using this app,  signing with Facebook movements all across the web.  Like, we assume every time that you view the application,  that we are going to integrate with Facebook.  So, yeah, their API has been like a major tool in their expanding process.  But it also can be one of the greatest liabilities of a company.  Because if you don't do, if you don't write a good API,  it should definitely come back to善 you.  You're going to have to invest money to fix it,  you're going to have to invest time and people to fix it,  and you probably give a bad experience for everyone that is going to integrate with you.  So, the question here is, how do we build a good API?  What are the definitions of a good API?  Well, in order to define the API, there are eight concepts that we have to use.  Those eight concepts is what defines if you have a good API or a bad API.  These concepts are, performance, scalability, reusability,  aboveability, documentation.  It must be easy to learn, it must be easy to use,  and mostly, it must be hard to reach huge.  So, these eight concepts, it's what defines if an API is a good API or a bad API.  So, we have to start to worry about this.  Well, there is a great talk about the fact that Joshua Lange  is going to Google, Google Daystyle on 20th July,  and he may like this code that it's really precise  and really will help you to achieve a good API.  You should do one thing and do it well.  So, this is the, this is what we will start about thinking APIs for an hour,  but if you actually do one thing and want to do it well.  But if we take a look at the technical side of it,  we have a lot of tools to build APIs.  We have a lot of tools that might help us to build APIs.  And I would like to tell you a little bit about why Rails is the best tool to build APIs.  The thing is, I would like to talk about it, but it's not.  Yeah. But it's a great one.  We know that there's no super good, there's a lot of downsides where Rails is a great tool,  and I will show you how we can use Rails in the development way.  So, the things about why Rails is a great tool,  is because if you take a look at that eight points that I pointed out for you,  that the form of this kind of ability, RTU, ECU, RTU is used,  all of them are deeply related with conventions.  If you follow conventions, you probably have a performance.  It's probably easy to document.  It's probably easy to use, hard to misuse, and easy to scale.  So, they are all deeply connected with conventions,  and conventions by itself is deeply connected to Rails.  Rails is all about conventions.  So, yeah, this is why Rails makes APIs underway to develop APIs.  But I have to argue it's something that Rails is indeed produced.  So, yeah, Rails has a lot of parts that you might not want to use,  and a lot of parts that you might want to use when developing an API.  So, this is why Rails API exists.  How many of you have already used Rails API?  All right, two.  What Rails API does is it removes the parts of the Rails  that you don't really need and don't really want to develop an API,  and it brings new functionality that you might use and might want when you make APIs.  It's pretty much simple.  And one of these specialities, one of these projects that Rails API has in union  is Active Model for Reliance, also known as AMX.  The easiest way to define Active Model Surveyorizer  is that it brings convention over configuration to your table.  So, it follows the Rails concept, it follows the Rails logic,  and it also is made in a convention.  But it adds a layer in your Rails application  that will handle the conversion of an object that you have into a JSON object.  So, I'll show you an example of what is a Surveyorizer on a Rails application.  This is what a Surveyorizer looks like in a Rails application.  I'm going to go through it.  So, first things first, you have the definition of a Surveyorizer, no worries.  We have a line that defines the actual boot that we want to return as JSON,  in this case, title, body, and comments count.  But the thing is, comments count isn't an attribute of post.  So, it's a virtual attribute that you create on the Surveyorizer.  So, this is the method that counts the comments of a post,  and then gives it back to JSON.  So, once that you have this Surveyorizer in your Rails application,  this is the output that you're going to have.  So, you're going to have a JSON attribute,  every time that a post is returned to your client,  and you have an ID, title, body, and comments count.  Pretty much easy, right?  Alright, so we have been using ALS, I think,  some years from now.  The first question that was kind of stable was the 08 version.  How many of you use the 08 version?  Alright, we have the online version.  How many of you use it?  Alright, cool.  And we also have been working on 010 version.  How many heard about it?  Alright, it's cool.  So, yeah, we are working really hard for several months  in the 010 version,  and I would like to give you a sneak peek of it,  and the great features it has, and it will have,  and you'll learn a lot, I'm sure, about it.  So, the first feature is we implemented a Docker popup.  So, what it means, right now, a Docker popup,  it's a part of ActiveModerncy Realizer,  that describes how the attributes will be serialized.  It means that if you would like to use ActiveModerncy Realizer,  to do an XML, for example,  you could build an adapter by yourself,  and you can create it with ActiveModerncy Realizer.  So, it makes it easy for people that want to use other formats,  harder than JSON, to use ActiveModerncy Realizer,  and if they want to contribute,  beauty and contributing to the project itself,  by doing new adapters that don't work only with JSON.  So, yeah, it was a great change, and a small one,  so yeah, quick win for us.  So, the second feature that I would like to talk about,  and this one, it's really cool,  and I really would like to focus a little bit about it,  because I don't know how many of you have heard about it,  it's JSON API.  How many of you have heard about JSON API?  All right, JSON API,  the standard for building APIs in JSON.  So, it started back some months ago,  some of the brilliant and greatest minds and friends that I have,  I know have been working on that,  so you might know Steven Klaibnick,  and he moved it and given another task, another conference,  another room, so they started building it,  and there's a lot of other brilliant people  that are working on it right now.  The concept is, they want to define a standard form  to build APIs in JSON APIs,  and it brings all the good things that conventions always bring,  so you don't have to worry about negotiating it  with your other employees and your other developers,  you don't have to,  a friend and developer don't have to worry about how long it's integrated,  or which cubes will be returned as for API.  So, yeah, it's really cool,  it really makes it a lot easier to integrate APIs into new APIs  and make it a lot faster,  we really believe in that,  and we are kind of glad to announce that we already commented  the JSON API release in CapDate 3 in this new version,  and the 1.0 version is supposed to be released on May 21,  and we are already working on that,  so after the release,  we're probably going to also merge it with ActiveModels Realizer,  and it's really cool because if you choose to use JSON API,  you could build APIs way faster,  follow up comments,  that you anyone in the world who know what it's about,  so yeah, it's really cool, and we're really proud of it.  The next two features that I'm going to talk about  are some features that I'm pretty proud of  because I'm the one that made it,  and I really think that it can really help a lot of developers out there,  because it helped me on increasing and improving my APIs back then in WordCut.  So, the first one is Cache.  We have implemented a building Cache functionality  inside of ActiveModels Realizer.  So, it's a totally new implementation right in first patch.  It's optimized and it's followed the real situation.  I'm going to show you as a big pick of how it works.  So, these are the usual serializer,  a post-serializer with a title and body attributes.  Let's say that you would like to cache it.  All you have to do is add a cache method, and it's done.  I have to do that, a cache method is a serializer,  any part of it, and it will be cached, and it will reuse it.  But you can go further than that.  You can even specify a key for your cache,  or even further than that, you can use all the Rails conventions.  So, you can place X-parries in three hours,  and this cache method X-parries every three hours,  and it's really helpful.  So, let's imagine that this serializer has a post-controller.  So, this is a post-controller with an index definition,  usual stuff, so every time that a user goes to the index method,  it will generate the cache, as we saw in the post-serializer.  The good part is, when the user goes to the show method,  the same cache will reuse it across every action  that uses the post-serializer.  So, yeah, it's a really great optimization,  and might make a lot of difference on your application API.  The next feature that I would like to talk about,  and it's another really cool feature, is Threadman Cache.  Threadman Cache can really save you a lot of times.  What it does is, oh, sorry, what it does is,  it always follows the Rails conventions.  It's always, it always, it always, yeah.  It also follows the Rails conventions,  and it's built to cache-specific attributes on a serializer.  I'm going to show you this thing, pick up the two.  So, take a look at this post-serializer.  It's a little bit more complex.  So, we still have a title, a body, and a comments count attribute,  but this time, we are overriding the title attribute,  and we are overriding the comments count attribute,  and generating that inside the serializer.  So, if you take a look at those two methods by themselves,  you're going to see that the title, despite of being a modification  of the usual title of the post, is definitely cached.  But the second attribute that it calls how many comments it has,  it's non-cached, because it can change very quickly.  So, how can we cache one part of this serializer  and get the other outside,  and still have the improvements of the cache documentation?  So, right now, all you have to do is add cache,  home, title, also using the Rails convention.  You can always, I think, always use the other ones,  so accept, comments count, and it's okay.  So, this is what you can do with, you put everything together.  So, you can define cache, you can use a key,  you can use all the Rails method, like it's firing in,  and you can also use it to make it pregnant cache.  So, yeah, it's really cool, and it's a really cool,  two features that tie together really well.  Now, there is this famous phrase,  I mean, God, the truth is, and now the other is big data.  What about how it can be problematic?  How it can be concerned with the old versions  of active models to realize it?  Because this was totally he-righted.  It was right in the scratch.  So, well, I made some benchmarks.  So, if we take a look at the oldest, the left version,  the online version, this is what we look at like,  a benchmark that I made with, like, 10,000 times,  building an azimuth, a realizer.  But if we take a look at the new version,  we have a drop of, significantly,  a drop of 10 seconds, obviously,  and if we use cache, we're going to see,  like, almost 15 seconds drop.  So, yeah, it's a really great increase of performance,  and it might really help very much.  So, there's a lot of work in progress, too.  Like, we still have a lot of things to do.  We are really working hard to implement that much  so we can push forward to have even faster response  when loads are a lot of cache together.  We are still working on a benchmark implementation  that will help us to also keep track  of the performance issues wherever we can.  And there's one more thing I'd like to talk about  that's really cool, and I'm not sure if I even believe it.  It's that we made it, we have just released  an AMS work-end like today, early this morning,  just because of RailsConf.  So, you are all able to use this as your work.  So, you are all able to update your GAMs,  you are able to update your applications,  and use technical models to realize it.  I'd like to try something new here,  so if you'd like to teach about it,  you can use the hashtag AMS-TAN.  Yeah, if you would be like,  whoa, what is AMS-TAN? Let's check it out.  So, yeah, use the hashtag AMS-TAN alongside with RailsConf,  and the people will be concerned about what it is,  and you should check this out.  So, we have released it this morning,  you are all able to update it.  We still have a lot of work to do, but yeah, it's really great.  And actually, I have another thing to talk about,  and it's really cool.  Not sure yet, but I think that I should share with you  because I'm excited about it.  We have been touched with RailsConf team  for some weeks from now,  and we are really excited about the possibility  of AMS joining Rails as a full.  So, you would be able to use it in Rails application.  It's not for sure yet,  but we have been going through it,  and it seems that it's going to happen,  and I'm really glad that I shared it with you,  so we can push forward and make it happen.  I also would like to give you a special thanks  for the whole AMS, Rails API team.  They are amazing,  specifically those four amazing guys  that have been closely working with for the last months.  There is a lot of other contributors,  a lot of amazing developers,  and amazing people that have helped us out,  but there's four people who are amazing,  they have been helping me in doing this.  Actually, I haven't been learning for them a lot,  and I think that I ended up going too fast.  I was going to take like another 15 minutes,  but I think it's great  because you have some time for questions.  I would like to thank you all for being here,  and letting you know that it was amazing to talk to you guys.  Thank you.
AMS_0_155.png AMS_156_8471.png AMS_8472_16403.png AMS_16404_17291.png AMS_17292_19307.png AMS_19308_21251.png AMS_21252_23987.png AMS_23988_24131.png AMS_24132_24299.png AMS_24300_24635.png AMS_24636_24683.png AMS_24684_24947.png AMS_24948_25967.png AMS_25968_26735.png AMS_26736_27083.png AMS_27084_27167.png AMS_27168_27527.png AMS_27528_29591.png AMS_29592_35159.png AMS_35160_35627.png AMS_35628_35804.png
A.P.I. A.P.I. is one of the things that we have quite a business to do. We are always using it, we all have been using it, and it's pretty special for the internet to use to get to the mobile. A.P.I. is not new technology, it has been used way before the internet comes, and the internet has pushed it even further by increasing the power of how machines can communicate with other machines. How this mobile and wearable lifters are coming out, and how this movement that is going on right now, and who is pushing it even further, we as developers have been using it in radios, and a lot of other tools and other lifters, and now those are a few great APIs, and a great API that is a lot of time-lapse. My name is Juan Mota, I'm the co-founder of Jiggo from We Are Assas for identification. This is how you can find more computer, internet, and internal. Today we are going to talk about AMS, API, Rails, and another thing that we have been tied up by a lot of stuff. I tried to make a lot of stuff that could be a short part, but I probably should get started a little bit, so for those that doesn't know, I'm from Brazil. And Brazil is awesome. Actually, this is how far I am from home right now, just talking to me, it's like an hour of life. And what is funny is that every time, every time that I go to every conference in the world, and I tell them that I'm from Brazil, everybody asks me about all these things, and I'm just like, hey, I got an answer. So, every time that I tell people that I'm from Brazil, it's really funny because everybody asks me, what about all these trees and lakes and animals that you have around, it must be really fun. But actually, the thing that I came from, something like this, there's no trees, no lakes, no animals at all, and actually the largest city of the whole Americas, and also the largest city of the whole southern hemisphere. Yeah, it's pretty big, we have a lot of traffic, a lot of jam, so this is a picture of my usual Friday night, you can easily become one of those. What is funny about this picture is that if you take a look at this land type, even the motor cycles are having a jam. So, yeah, it's pretty tough. But one thing that we know how to do pretty well is to have fun. Yeah, we Brazilians love to have fun and love to hang out, and one of the major tournaments stuff that we have in our country is soccer. Soccer is huge in Brazil, everybody likes it, everybody tries at least to play it, and it's really cool. So, last year we had a World Cup, I was invited to join a startup as their CTO, called Alvitators, and it was a lot of fun. I talked a little bit about it on Vimecon, if you want to know more about it, you can watch the conference now. But the code was a mess. We are a couple weeks away from the World Cup, and we are not ready for a bunch of users there, we are about to get in the application. So, we have all types of problems that you can imagine. No background jobs, we had bad relationships, bad architecture, we had indexes that weren't missing, and we also had no cash at all. So, our APIs were really, really shit. Yeah, I have to be serious about it, we are really good at the World Cup, and I really know what I should do. So, that was when I found love, and I found love with AMS, and it wasn't me. AMS, how many of you have used active models to realize it? Alright, so you've learned a lot of these thoughts. But, first, let's take it easy. This is when I found love, I always loved open source, and I was about to contribute with people, and building new things. But, that time I really found love with Active and Modern Surrealizer and RAO's API. For those that didn't know, I'm one of the contributors for RAO's API, and Active and Modern Surrealizer, we are doing an amazing job, I talked a little bit about it from the end of 2000. But, first, to get started, let's talk a little bit about API. API stands for Application Programming Interface. And, I would like to dive into the story of this definition, that it's interface. Like, we are so worried nowadays about interface in general, like everybody knows how much user experience is important to an application. Everybody knows how much a user interface is important, and how much it can really take you apart from a bunch of other applications. But, what we usually do, again, is that APIs are also a kind of interface, because they are users that are going to use it, or they are customers, or they are developers, or they are team, or other developers that are going to integrate with it. So, yeah, we should be putting the same ford and the same amount of technology and for in-development APIs as we do with usual user interface and user experience. Because APIs can really be one of the great assets of a company. If we take a look at Facebook, for example, Facebook is the biggest ever-made social network in the story of your magnitude. And I don't know if you realize how much the API, their API, help them to achieve it. Like, nowadays, we are using this app, signing with Facebook movements all across the web. Like, we assume every time that you view the application, that we are going to integrate with Facebook. So, yeah, their API has been like a major tool in their expanding process. But it also can be one of the greatest liabilities of a company. Because if you don't do, if you don't write a good API, it should definitely come back to善 you. You're going to have to invest money to fix it, you're going to have to invest time and people to fix it, and you probably give a bad experience for everyone that is going to integrate with you. So, the question here is, how do we build a good API? What are the definitions of a good API? Well, in order to define the API, there are eight concepts that we have to use. Those eight concepts is what defines if you have a good API or a bad API. These concepts are, performance, scalability, reusability, aboveability, documentation. It must be easy to learn, it must be easy to use, and mostly, it must be hard to reach huge. So, these eight concepts, it's what defines if an API is a good API or a bad API. So, we have to start to worry about this. Well, there is a great talk about the fact that Joshua Lange is going to Google, Google Daystyle on 20th July, and he may like this code that it's really precise and really will help you to achieve a good API. You should do one thing and do it well. So, this is the, this is what we will start about thinking APIs for an hour, but if you actually do one thing and want to do it well. But if we take a look at the technical side of it, we have a lot of tools to build APIs. We have a lot of tools that might help us to build APIs. And I would like to tell you a little bit about why Rails is the best tool to build APIs. The thing is, I would like to talk about it, but it's not. Yeah. But it's a great one. We know that there's no super good, there's a lot of downsides where Rails is a great tool, and I will show you how we can use Rails in the development way. So, the things about why Rails is a great tool, is because if you take a look at that eight points that I pointed out for you, that the form of this kind of ability, RTU, ECU, RTU is used, all of them are deeply related with conventions. If you follow conventions, you probably have a performance. It's probably easy to document. It's probably easy to use, hard to misuse, and easy to scale. So, they are all deeply connected with conventions, and conventions by itself is deeply connected to Rails. Rails is all about conventions. So, yeah, this is why Rails makes APIs underway to develop APIs. But I have to argue it's something that Rails is indeed produced. So, yeah, Rails has a lot of parts that you might not want to use, and a lot of parts that you might want to use when developing an API. So, this is why Rails API exists. How many of you have already used Rails API? All right, two. What Rails API does is it removes the parts of the Rails that you don't really need and don't really want to develop an API, and it brings new functionality that you might use and might want when you make APIs. It's pretty much simple. And one of these specialities, one of these projects that Rails API has in union is Active Model for Reliance, also known as AMX. The easiest way to define Active Model Surveyorizer is that it brings convention over configuration to your table. So, it follows the Rails concept, it follows the Rails logic, and it also is made in a convention. But it adds a layer in your Rails application that will handle the conversion of an object that you have into a JSON object. So, I'll show you an example of what is a Surveyorizer on a Rails application. This is what a Surveyorizer looks like in a Rails application. I'm going to go through it. So, first things first, you have the definition of a Surveyorizer, no worries. We have a line that defines the actual boot that we want to return as JSON, in this case, title, body, and comments count. But the thing is, comments count isn't an attribute of post. So, it's a virtual attribute that you create on the Surveyorizer. So, this is the method that counts the comments of a post, and then gives it back to JSON. So, once that you have this Surveyorizer in your Rails application, this is the output that you're going to have. So, you're going to have a JSON attribute, every time that a post is returned to your client, and you have an ID, title, body, and comments count. Pretty much easy, right? Alright, so we have been using ALS, I think, some years from now. The first question that was kind of stable was the 08 version. How many of you use the 08 version? Alright, we have the online version. How many of you use it? Alright, cool. And we also have been working on 010 version. How many heard about it? Alright, it's cool. So, yeah, we are working really hard for several months in the 010 version, and I would like to give you a sneak peek of it, and the great features it has, and it will have, and you'll learn a lot, I'm sure, about it. So, the first feature is we implemented a Docker popup. So, what it means, right now, a Docker popup, it's a part of ActiveModerncy Realizer, that describes how the attributes will be serialized. It means that if you would like to use ActiveModerncy Realizer, to do an XML, for example, you could build an adapter by yourself, and you can create it with ActiveModerncy Realizer. So, it makes it easy for people that want to use other formats, harder than JSON, to use ActiveModerncy Realizer, and if they want to contribute, beauty and contributing to the project itself, by doing new adapters that don't work only with JSON. So, yeah, it was a great change, and a small one, so yeah, quick win for us. So, the second feature that I would like to talk about, and this one, it's really cool, and I really would like to focus a little bit about it, because I don't know how many of you have heard about it, it's JSON API. How many of you have heard about JSON API? All right, JSON API, the standard for building APIs in JSON. So, it started back some months ago, some of the brilliant and greatest minds and friends that I have, I know have been working on that, so you might know Steven Klaibnick, and he moved it and given another task, another conference, another room, so they started building it, and there's a lot of other brilliant people that are working on it right now. The concept is, they want to define a standard form to build APIs in JSON APIs, and it brings all the good things that conventions always bring, so you don't have to worry about negotiating it with your other employees and your other developers, you don't have to, a friend and developer don't have to worry about how long it's integrated, or which cubes will be returned as for API. So, yeah, it's really cool, it really makes it a lot easier to integrate APIs into new APIs and make it a lot faster, we really believe in that, and we are kind of glad to announce that we already commented the JSON API release in CapDate 3 in this new version, and the 1.0 version is supposed to be released on May 21, and we are already working on that, so after the release, we're probably going to also merge it with ActiveModels Realizer, and it's really cool because if you choose to use JSON API, you could build APIs way faster, follow up comments, that you anyone in the world who know what it's about, so yeah, it's really cool, and we're really proud of it. The next two features that I'm going to talk about are some features that I'm pretty proud of because I'm the one that made it, and I really think that it can really help a lot of developers out there, because it helped me on increasing and improving my APIs back then in WordCut. So, the first one is Cache. We have implemented a building Cache functionality inside of ActiveModels Realizer. So, it's a totally new implementation right in first patch. It's optimized and it's followed the real situation. I'm going to show you as a big pick of how it works. So, these are the usual serializer, a post-serializer with a title and body attributes. Let's say that you would like to cache it. All you have to do is add a cache method, and it's done. I have to do that, a cache method is a serializer, any part of it, and it will be cached, and it will reuse it. But you can go further than that. You can even specify a key for your cache, or even further than that, you can use all the Rails conventions. So, you can place X-parries in three hours, and this cache method X-parries every three hours, and it's really helpful. So, let's imagine that this serializer has a post-controller. So, this is a post-controller with an index definition, usual stuff, so every time that a user goes to the index method, it will generate the cache, as we saw in the post-serializer. The good part is, when the user goes to the show method, the same cache will reuse it across every action that uses the post-serializer. So, yeah, it's a really great optimization, and might make a lot of difference on your application API. The next feature that I would like to talk about, and it's another really cool feature, is Threadman Cache. Threadman Cache can really save you a lot of times. What it does is, oh, sorry, what it does is, it always follows the Rails conventions. It's always, it always, it always, yeah. It also follows the Rails conventions, and it's built to cache-specific attributes on a serializer. I'm going to show you this thing, pick up the two. So, take a look at this post-serializer. It's a little bit more complex. So, we still have a title, a body, and a comments count attribute, but this time, we are overriding the title attribute, and we are overriding the comments count attribute, and generating that inside the serializer. So, if you take a look at those two methods by themselves, you're going to see that the title, despite of being a modification of the usual title of the post, is definitely cached. But the second attribute that it calls how many comments it has, it's non-cached, because it can change very quickly. So, how can we cache one part of this serializer and get the other outside, and still have the improvements of the cache documentation? So, right now, all you have to do is add cache, home, title, also using the Rails convention. You can always, I think, always use the other ones, so accept, comments count, and it's okay. So, this is what you can do with, you put everything together. So, you can define cache, you can use a key, you can use all the Rails method, like it's firing in, and you can also use it to make it pregnant cache. So, yeah, it's really cool, and it's a really cool, two features that tie together really well. Now, there is this famous phrase, I mean, God, the truth is, and now the other is big data. What about how it can be problematic? How it can be concerned with the old versions of active models to realize it? Because this was totally he-righted. It was right in the scratch. So, well, I made some benchmarks. So, if we take a look at the oldest, the left version, the online version, this is what we look at like, a benchmark that I made with, like, 10,000 times, building an azimuth, a realizer. But if we take a look at the new version, we have a drop of, significantly, a drop of 10 seconds, obviously, and if we use cache, we're going to see, like, almost 15 seconds drop. So, yeah, it's a really great increase of performance, and it might really help very much. So, there's a lot of work in progress, too. Like, we still have a lot of things to do. We are really working hard to implement that much so we can push forward to have even faster response when loads are a lot of cache together. We are still working on a benchmark implementation that will help us to also keep track of the performance issues wherever we can. And there's one more thing I'd like to talk about that's really cool, and I'm not sure if I even believe it. It's that we made it, we have just released an AMS work-end like today, early this morning, just because of RailsConf. So, you are all able to use this as your work. So, you are all able to update your GAMs, you are able to update your applications, and use technical models to realize it. I'd like to try something new here, so if you'd like to teach about it, you can use the hashtag AMS-TAN. Yeah, if you would be like, whoa, what is AMS-TAN? Let's check it out. So, yeah, use the hashtag AMS-TAN alongside with RailsConf, and the people will be concerned about what it is, and you should check this out. So, we have released it this morning, you are all able to update it. We still have a lot of work to do, but yeah, it's really great. And actually, I have another thing to talk about, and it's really cool. Not sure yet, but I think that I should share with you because I'm excited about it. We have been touched with RailsConf team for some weeks from now, and we are really excited about the possibility of AMS joining Rails as a full. So, you would be able to use it in Rails application. It's not for sure yet, but we have been going through it, and it seems that it's going to happen, and I'm really glad that I shared it with you, so we can push forward and make it happen. I also would like to give you a special thanks for the whole AMS, Rails API team. They are amazing, specifically those four amazing guys that have been closely working with for the last months. There is a lot of other contributors, a lot of amazing developers, and amazing people that have helped us out, but there's four people who are amazing, they have been helping me in doing this. Actually, I haven't been learning for them a lot, and I think that I ended up going too fast. I was going to take like another 15 minutes, but I think it's great because you have some time for questions. I would like to thank you all for being here, and letting you know that it was amazing to talk to you guys. Thank you.
and I found love with AMS, and it wasn't me. AMS, much the API, their API, help them to achieve it. conventions, and conventions by itself is deeply APIs underway to develop APIs. But I have to that Rails API has in union is Active Model for brings convention over configuration to your would like to give you a sneak peek of it, and standard for building APIs in JSON. So, it lot of other brilliant people that are working on feature that I would like to talk about, and it's cache, you can use a key, you can use all the about how it can be problematic? How it can be look at the new version, we have a drop of,