Hi, everyone. Welcome to the WP development panel on APIs and WordPress-related APIs. My name is Jonathan Daggerhart. I do WordPress development and plug-ins and whatnot. I have a little bit of experience with APIs, but our panelists here have significantly more. So I'd like to go through, I'd like to introduce you or have each panelist introduce themselves, starting with Julian, and tell us a little bit about their experience with APS. Thanks, Jonathan. So my name is Julian Melissa. My Twitter handle is at Julian Melissa. I'm a WordPress developer, front-end developer mostly. I don't know how much I'm supposed to say about myself actually, but I work on the Roots team. I also really enjoy building front-end web applications with JavaScript, and also I've started with WordPress, and that's very much still where my heart is. I recently have worked on a couple projects that use APIs for one reason or another. The most recent thing, actually, I built an API with Jonathan over a weekend project, and it helps to power a pretty full functioning Angular front-end before I was using Ember for part of that project. I've just been, you know, other things that I've used APIs for and find them in general, a really interesting topic and pretty helpful as well. My name is Micah Wood. I'm a WP scholar on Twitter, and I am a partner in CTO in a company called New Clarity. I do primarily WordPress enterprise projects. I've done, as far as APIs go, I've used Backbone and Ember to interact with the WordPress REST API, and in general I've done some integrations with a number of different Google APIs from Google Analytics to Google Geocoding, and so on and so forth. Hi everybody, I'm Jeff Bowen. My Twitter handle is alapapa. It doesn't mean anything. So I work at Automatic on WordPress.com. We have been using JavaScript front-end frameworks for a while. At first we were rolling a lot of our own stuff and using jQuery for network calls and just plopping it into the DOM like everybody else, but we started using Backbone on a few projects before Backbone was in WordPress 4, and we've kind of moved a lot of stuff off Backbone these days. We're doing most of our front-end views, our React components, but we have our own REST API that also predates the WP API that's just at version 2 that's the future plugin in WordPress. So we are interested in kind of coalescing our REST API with the WP API plugin using some code from there where it makes sense and vice versa. And yeah, thanks for sticking around. Hi everyone, I'm Adam Solerstein. I work for an agency called TenUp and we're a VIP third partner. We build a lot of enterprise websites. I have a good bit of experience dealing with the REST API. I've built a couple things on top of that and also several other kind of things that connect to other APIs. And in my spare time, I'm a farmer. Hey, I'm Will. I'm a senior developer for a company called Bodino Enterprises. We own and manage about 350 restaurant chains. And before that, I work for an agency that built a ton of WordPress stuff. And currently I'm building an Angular front-end REST API back-end for the enterprise for my company. And WordPress is part of that using the WordPress JSON REST API. And the other end is Coding Iron REST API. So I have really only done Angular front-end work, not to take anything away from the other technologies. That's just what I've always picked up and done. But I've also done a lot of jQuery and stuff like that. Thank you very much. So I'm going to get this started, I think, with the most relevant question, which is, APY. Why do you use an API? When do you use an API? Where is it valuable? And let's just start with Will with the microphone. So like I said, I'm in the enterprise level, so I'm looking long-term. One thing I do believe is in two, three, four, five years, I'm not sure what the best front-end technology is. So to me, building up a REST API for my PHP and my data and decoupling that from my front-end makes a lot of sense because I don't believe there's going to be that much change in PHP or the data or my SQL or anything like that. So I can build the foundation of that and then interchange the front-end as I see fit. So I don't care who or what, well, I care who's consuming it, but I don't care who in my organization is consuming my information for my REST API. It can be a native app, it can be a web app, or it can be a site. So that to me is the big promise of the REST API and building up a very front-end only client to consume it. Why use an API? I guess just to get a great way to get data for your application. I work a lot in WordPress Core. One of the things I'm excited about is being able to get and send data back to WordPress without the kind of legacy of backwards compatibility that we have to maintain in Core. So you can build things on top of the REST API that are independent. You're pretty much in your own world. All you really need to do is be sure that you're sending the information and receiving the information in the correct format and then you're free to do kind of whatever you want inside your application. Also, just an amazing amount of data out there that's usable and the way that you can combine multiple APIs. So I did one project where it was a search feature where you could put in a zip code and get a list of kind of nearby stores from this particular vendor. And it involved querying a couple of APIs. One was the Google API to kind of geolocate based on the zip code. And then once you had that location, querying another API that would actually, you know, that was from the vendor that would actually locate which stores were in that area. You can do that all right inside WordPress using the remote API that WordPress provides, cache that data, and then use your API to feed that data back to your application that's running in the client's browser. And then I guess the last piece is just that it's running in the client's browser. So the big advantage there is if you have a large scale application, you're kind of offloading a good bit of your processing to the actual client. You've got the data at the client and you can do a lot of manipulation of the data there as opposed to having to rely entirely on your server to do all that. So for me, the reason to use an API comes down to a couple of things, in addition to what these gentlemen have already said. The first one is testability. So if you're separating your concerns, your REST API or whatever the API has a set of input, which are the parameters that you give it, and it has an output, and those things are very easily testable. You can call it with a command line, curl, expect an output, get it, run it through your test suite pretty easily. Whereas if you're using traditional WordPress templating with the logic intersparse and that sort of thing, it's not impossible, but it's difficult to test that each component does what it's supposed to. And I guess that the other part is that it lets me think about them separately. It keeps them simpler. Your REST API functions only do one thing. They return the data. Your display functions only do one thing. They turn the data into a display. So it lets me think about them in a simpler fashion. It lets me let each component do its own job and not worry about what anything else is doing. It lets them be decently dumb about what other components do. So I'm going to again say that all that is great, and I'll try to add my bits and make sure that Julian has nothing left to talk about. For me, I think APIs are great when you want to do some rapid prototyping because there's so many things out there that already do bits and pieces of what you need that if you can just tie the right things together, you can come up with some awesome stuff and do it in a quick and relatively easy way. And after you've integrated with a few APIs, it gets easier and easier and easier to do. So that's one of the things that I like about it. And just because also, typically, there's some great services that do a lot of technical things that would take hours and hours and hours to build. It's kind of like WordPress. You have a great foundation, why throw it away and write it from scratch when it's right there and ready to use. So if you've got a good API that does something that would take you a long time to do, don't try and reinvent the wheel. Yeah, you guys said a lot of really good stuff. I think I can at least speak to, I'm probably the least full stack developer, at least with experience working full stack, then everybody here at the table. As a front-end developer, I recently worked on a project where I just did a lot of UX and UI design with my business partner who's a designer. I ended up writing all the HTML and CSS. I kind of came up with their own bootstrap for this company to use as repeating patterns throughout this application. And one hurdle that we found was I actually had off HTML and CSS files to the devs because they didn't have an environment that was like, I was able to get set up on my computer to directly work with real data. So the entire time I was working with completely fake data that wouldn't necessarily always cover the right use case. So one thing that would have been really helpful in that project would be for the back-end to have been built on an API. If the back-end was just, if I could just call JSON from their back-end and get some information back, I would be able to pretty easily render it, know what kind of data I'm looking at, and be able to, I think, more quickly work on the application without a lot of back-and-forth from the front-end to the back-end developers. And it's kind of what he said, we don't know what front-end's going to look like in five years. We don't know if there's going to need to be a mobile app down the road. So by very much separating your application logic and your data in the back-end and your presentation layer, you get a lot of that. It's a huge benefit, just maintainability-wise. Yeah. Awesome. Thank you. Any questions from the audience? Yes. I mean, it may sound like a foolish question, but it's a silly audience to me. You said, why aren't you the API? Why not? I mean, why aren't you the API? What's the alternative to using the API? Sure. Okay. So let's talk about some of the situations in which writing a front-end that consumes an API would be a disadvantage or just too much work. So, Julian, do you want to start? Maybe just list a situation in which you would rather not have to consume an API as a developer. Sure. I could also start, is everybody comfortable with the concept of an API? I guess we forgot to ask that. That might be valuable. I'm just wondering, is everybody get, we're storing data somewhere and we're doing all of our application logic there and then we're going to grab the data from that and use it, sometimes on the front-end, but also not always on the front-end in the client side. Okay. So we're good. So, my mind can be really small, but if I'm just starting out and I'm wanting to get down to the nitty-gritty of WordPress and kind of understand how it works, make some database calls, get how we're going to store post data and retrieve post data, we've been building WordPress sites for a really long time using PHP. You can echo a variable and you can put it on a page. That's going to get you very quickly more familiar with how it works than having to add a whole other layer on top of your project. So as a beginning developer, it might be better to start without an API in the mix. Okay. Yeah, and to add on to that, so there's plenty of times where, you know, an API is just another request, something that happens behind the scenes that could slow things down and if you're going for high performance or sometimes even flexibility, APIs can have limitations that could keep you from getting what you want. So, for example, I think Adam was mentioning using like the Google Geolocation API to find out the specific coordinates of a location and then hitting another API to try and figure out if this thing is near this other thing. I've done similar things, but I found that by storing some of that geolocation information in the database and then being able to run, like the HaverSign formula in PHP or in MySQL, I can get that data much faster than having to make another request to another API. So, speed and performance can be part of it. I kind of just to add on the inexperience point, if you really only know PHP or you really only have experience exposure to PHP, JavaScript can be a little daunting. So if you don't have any JavaScript experience at all, that would be a good use case for just keeping everything in PHP. Now, that's not to say that you can't use a PHP style architecture inside PHP. You can definitely do that. And I think it's important. We're kind of describing what an API is. It's important to talk about. Like an API isn't just a REST API. It's not just something that you call over the Internet. Any sort of interface to your logic that you are providing somebody else to use is an API. It stands for Application Programming Interface. And what it amounts to is it's a contract with your users that this is going to take the inputs that are described in the documentation. It's going to act in the way it says. It's going to output a format like this. So even if you're not using a remotely accessed API, if you're using WordPress functions, that's an API as well. It's just a different kind. So really, I think what we're talking about here is just the mentality of separating logic and putting things into components. So those are things that you eventually become better at after you do it time and time again. So I guess that an experience is really the best use case for not doing it. That was a good question, because I hadn't thought about that, like why I wouldn't use an API. A couple of things that have bit me with APIs before. Breaking changes, like the REST API, getting version two upgraded, suddenly the endpoint changed and the helper function to find the endpoint isn't in the beta. So sometimes things break. If you're relying on an external API and it changes. And the other one that I thought of is poor documentation. Elastic Search is a great example of this where with each version they may change some keywords or change some methodologies and then it's not well documented or the old documentation is still out there. So when you're dealing with third-party APIs, it can be very frustrating as a developer when they don't perform as documented. Yeah. The only part I would like to add is if you're building a WordPress marketing site, it would hard-press for me to really, other than it would be kind of cool just to try out not to use the WordPress templating system. If you're getting all your information from the WordPress database, you're building a WordPress site, it's probably best just to build out the normal WordPress site. I mean, you could just forget the templating system, use the JSON REST API and build the content by itself, but I would be hard-pressed to really find any real value to that unless somebody has just some deep pockets that really want something really flashy or cool, but nothing you can't do without WordPress. So to me, when you're looking at applications where you have multiple sources of input, you have much more back and forth. If I have a user entering stuff in, I don't want to wait on a page refresh. I want to have the JavaScript to send it back and forth to API. The single-page apps, that's where I really think the value of using a REST API is. But the majority of the time, I'm using it because that's kind of what I've gotten into in the pattern. You could just as easily do a PHP echo, if you're all set. Sorry to break the flow. On the single-page application, one thing that we talked about when we were chatting about topics and SEO impact, with a single... It's just something definitely important to mention, especially for beginners. What we're doing is we're grabbing data and your page never actually reloads, right? Like in a single-page app, your page never reloads. You might just stay at the root of that app. So what's going to happen, and Google has gotten a lot better about it, but there are still some technologies that either make it a lot harder or the process is fast or might not index at all. Your homepage is blank. If you haven't even gathered any data from the API and you haven't rendered anything, Google is going to see a blank page. So there's technologies to help combat this, like PhantomJS, which is a ghost that goes and crawls all your data and actually renders all the HTML as you make these requests. That's a lot of extra work. You can't make an application with 50 different views and expect all of those to show up. Your e-commerce store is going to be much more indexable if it's built out and can be rendered so Google can hit those pages, whereas, you know, they wouldn't be able to see it with the products if you built it in simply just the front end. Those are great points. So the question was if you have a one-page checkout, that might be a problem. Yeah. The one-page checkout is a different example because the Google doesn't need to be able to crawl the data on that page. I meant more like, say you have 6,000 products in your store and you just decided to code the entire front end in a single-page application. Google might not even know those products exist because when they load up the homepage, they just see, you know, nothing. Nothing. I think you brought up in your backbone talk that if users don't have JavaScript enabled, then a single-page application, the call is never going to happen, all they're going to get is what was rendered server-side. So if you are targeting government users or something like that, then you just can't use this pattern. Yeah. Great points. Thank you. Does anyone else have another question? If not, then let's move on and discuss specifically the new WordPress REST API that everybody's so excited about. We'll start with Will and let's just go through some maybe if you've run into any difficulties with it, things you like about it. Just give us your elevator pitch for... About a year ago, I was rolling my own REST APIs which were fine. I built some production sites on that and then I started using the REST JSON API plug-in that was supposed to be out last year. It still hasn't come out. It was great, very simple, very WordPress and to install the plug-in, you get a slash WP JSON and slash post and you get your post. So it worked very much like you would expect it to. Just recently with my the enterprise site, we're working on a communications platform so we need a bunch of users throughout the business so immediately I stood up a WordPress site and I'm going to use the JSON version 2.0 to allow it to tap into the HTML web app that I'm building out for the intranet. The experience has been probably three or four weeks in the project. It's been great. It's exactly what you would expect a WordPress component to be. They have filters to add endpoints and then within that filter you set a callback excuse the logic and then you just echo out your information and it handles the JSON return. In the version which I believe the first version didn't allow custom post types. I'm finding the second version is automatically picking up the custom post types. I don't know about taxonomy yet so it's been what you would expect a WordPress component to be very the API it uses is with a WordPress or API as filters and actions. It's been very easy. It makes I'm very happy to see how it's going. I'm looking forward to using it. I'm using that in addition to the other API that I've already built on another platform. Awesome. I have built some stuff on top of the API mostly the 1.0 and then on the 2.0 I did a little bit demo stuff. I'm really excited to see it go into core because I think once it's in core it becomes this massively usable thing that every WordPress site will have that the rest API is like the RSS feed of the new millennium. Guys remember RSS? Your website still has it. If you just go to slash feed you'll find a feed of all your data. This is the new way to get data out of and back into WordPress and I think once it's in place in core it's going to be really exciting to see what kinds of things are built on top of it. It's also going to open up the data that's in WordPress sites to the rest of the internet. It's just something where like every single WordPress site that is running this REST API will suddenly have a REST endpoint so people who are building things on top of APIs will think oh that's a WordPress site I can query that for sure. One of the advantages of having it in a plugin form is if you're trying to build something on top of it it becomes a dependency of your project and there is no dependency management so you're pretty much forced into kind of bundling it with your product and there's a little bit of a kind of user learning verb there. I guess sort of one of the concerns that I have about it being in core and being able to use it is what Thomas raised in his talk. Like right now with WPAJacks you pretty much load all of WordPress with every Ajax callback which is very inefficient. I hope that once it does make it into core we can figure out a way to provide some filters or hooks so that you can bypass a lot of the load if you don't need that. But I think getting into core is like the first step and I hope we can take that step really soon. I don't have a whole lot to add since I haven't worked directly with the WPAPI plugin except for just using a toy site to kind of play around with Jack Linux's theme that uses React. But I think it's, I think it will be helpful because it's really just a name change but when you're using Ajax everything's going over the same location. It's just a changing query variable and it's a little bit of like extra work to get the Ajax stuff set up as opposed to the REST API endpoint. So I think just the simplification of the PHP API is going to be helpful. So I've let's see, trying to think. So I've done a few things with the API. I've used Ember to integrate with the WordPress REST API to use Backbone to do the same. Ember definitely expects your data to be in a very specific format which the WordPress REST API doesn't necessarily give you right out of the box. I mean it gives it, the WordPress REST API is very reasonable and well-written API but with any API things can be done a little bit differently and Ember has certain expectations whereas the WordPress REST API was a little different but still equally valid. So there were some things that am I working with it where I had the choice of do I try to adapt the API on the PHP side so that it actually changes the functionality and the output of the API or do I go into Ember and try to to adapt it after the fact. So I think I actually started doing it in Ember at first and then realizing it probably better just to do these things in PHP. So I primarily work with the older API where it did actually support custom post types but you had to extend the class and then if you wanted to be able to get certain post meta you could use filters to add additional data to that but you had to do that in multiple contexts and several different things. So overall I think it's definitely this is the next big step that's going to allow us to do tremendous things with WordPress and so I'd be also very happy to see it in core. I personally have not used the API in any real project so I don't have a lot to add other than I am really excited to see it go into core, see it be more adopted. I think when I was originally getting into WordPress development Ajax was the way WordPress wants to Ajax was really hard for me to get around so I think API being more standardized through like a lot of developers now that aren't just WordPress developers but coming from other places will be a little more familiar with those methods and maybe I'll just like recode my site in something and then try to figure out how to get Google to index it but recode it in something so that I can have a chance to play with it. Awesome. So also something that should probably be brought to attention is that the WordPress API, REST API that we're talking about is not available through the repo. If you go search through the repo for JSON API you're going to find a different plugin. The one we're talking about can be accessed at wp-api.org It is in the repo now. Oh it's in the repo now. There's just one with almost the exact same name that shows right next to it. Okay. Oh, that's awesome. So it's look for version 2 in the repo available probably a long time ago and I had no idea. Oh, okay, awesome. All right, does anyone have any questions? Then let's move on to talk about consuming the API. I know quite a few of you have used multiple technologies for front-end frameworks, JavaScript all the buzzwords are out. Let's just get them on the table and let's have a third down. So I'd like for each of you let's get starting at Julian, let's go down the line and talk about just mention which technologies you've used and maybe some of the advantages and disadvantages if they were apparent when you used them. I've used two in real projects, two JavaScript buzzword frameworks. First I started out with Ember which was actually an interesting choice as a beginner because it was a really bad choice as a beginner. I really like the idea of convention over configuration that it takes from the Rails approach and I do enjoy working with Ruby on Rails. It was really rigid. Like he mentioned, the calls to your API are basically done automatically if you're using Ember data and asking for data but if your API doesn't have it in that format you've got to do a lot of work to get that to work. I actually recently moved a project over from Ember because I have done a lot of little projects in Angular. I think it's easier with Angular to just write whatever JavaScript you want just like Backbone doesn't really get in the way with that. I'm not saying Ember gets in the way with JavaScript in general but just the conventions you've got to do it that way. I've really enjoyed working with both of them. I could see different use cases for each and I also would really like to take some time like two isn't enough. I would love to take some time to play with Backbone and play with React for the view side because I think that you can use them all for different things but I think sometimes there may be the right tool for the job. Yeah. So I've used Ember for, like I said, this API. I've also used Backbone and recently had the opportunity to take a project I had completely done in Backbone that was relatively complex and moving it over to Backbone plus React. If you have the choice, just go straight to Backbone plus React. It will make things much faster and not to mention much cleaner and a lot less code and a lot easier to understand and work with. So I'll leave a little bit of the Backbone for you to talk about since your talk was on Backbone at this conference. So I'll talk about React a little bit. React, if you're familiar with the term NBC, Model View Controller, React tries to stay firmly in the view space. They don't try to do anything with your data access or anything like that. So as far as the fetching of data and the control through the application, Facebook has publicized Flux, which is the recommended way to get data into a React view component. And the kind of the way that Flux is supposed to work is you have a store, which is kind of analogous to a Backbone model, but the data is supposed to only flow one way. The views are supposed to be decently dumb about what the data is in the store and the store emits a change event when something changes. And then the view sees the change event, just gets the new values and renders it to changes. As far as calling the API, React is decently not involved. So your fetches have to be controlled elsewhere. And then you write a controller statement or a controller function that handles the input from the response from the server. You send it one way through your React store and then the views can only do an action. And then you hide all the implementation out of scope from the callers so that the store is the only way you can get data through the system. I'm going to have to check out React. I haven't done anything with that. I got into Backbone heavily when I got involved in WordPress Core and helped rewrite revisions for 3.6 and I continued in Core to be involved in various Backbone things that we've done. So that's my comfort zone and so when I had projects, 10-up that I had to build a front end component that communicated with the back end, I chose Backbone because what I'm familiar with. And it is very minimal and extendable. So like when you run into these issues where the data doesn't come back in the format you expect, it's very easy to kind of extend the sync method to change the data format to what you need. It's just kind of designed that way. Also have spent a good bit of time using the WP Remote API to consume data. So that's when you're in PHP and you're pulling stuff in from Remote APIs. I don't know what else I can say about Backbone. It's I feel like any of these frameworks are valid and good. I don't think one is really better than the other. People like to ask that question and mostly I think I've chosen to use Backbone because it is built into WordPress. It's sort of what Core has adopted and I haven't run into the limitations that people have with it. So that's nice. So I learned Angular because somebody was willing to teach me Angular at the same time someone was willing to pay for me to learn it. So that was about a little almost two years ago. And I came from the back end. So I was very much starting my life as a database back end and I've slowly moved up to the front end. And JavaScript was something I always hated touching. I used jQuery as little as I could because it just didn't make sense. Angular was the first time where I saw JavaScript using the MVC framework and it really made sense. It's very declarative. You put all your view logic into the HTML and declared a programming instead of listening to a click in jQuery you say ng click just like old school on click and that felt very natural to me and I just ran with it. So every project I could I knew of Angular, I learned a little bit more and no one's ever really taught me or paid for me to learn anything else. So that's the only reason I don't know Ember or anything like that. Also the fact that Google's backing Angular makes me feel more comfortable putting in my enterprise. I don't think it's going away anytime soon. But yeah, it's very flexible. I find it very easy to stand up working prototype very quickly, put some dummy data, manipulate the data and then you have all the view logic that falls into place from that. So there's no more DOM manipulation in the DOMs or in the controllers and manipulate the data and let the logic put in the view, manipulate that DOM. To me that makes a lot of sense because it felt very similar to what I was doing in PHP. So yeah, that's the reason why I chose Angular and not to take anything away from any of the other. Yeah, so personally I haven't used Angular, but just to kind of help differentiate between things like Ember and Backbone. So having experience with both the convention over configuration if you have something really complex that you need to do and it's going to follow these conventions, the fastest way to get up and running is to use something like Ember so that you spend a lot less time writing boilerplate code. But you have to know what those conventions are and have made the conscious choice to accept them and if you don't know what you're getting into sometimes that can be a little overwhelming. So it's important that you understand what you're getting into if you're going to just start doing stuff with Ember. But the nice thing about Backbone and why I think probably part of the reason why it's even in core is because Backbone is extremely flexible and you can only use the pieces you need. If you don't need a router, don't use a router. If you don't need models for some reason, don't use the models. And then with React, the reason why I think it's a valuable tool and even how I try to write my Backbone code. You have the option of doing it however you want but just being able to write code in a modular way where you can just drop it in and reuse it somewhere else one of the reasons why React is such a great thing because it forces you to write components and to think about how the data flows through there and so that changes the way you start to think about how you use tools like Backbone is because you start to think well how can I make this modular just because I'm using it here and I have a very specific use case doesn't mean I can't pull out the generic pieces and make it something that I can reuse and then just program a few specific business rules into it and make it work. I was just going to mention one thing, distinction wise if we start talking about Backbone focuses a lot on models and collections which means you know what your data looks like so if you have a car it has wheels, a tribute you have all these things Angular doesn't come with that out of the box so you've got to use something like that which I personally have never used Ember data does the same thing as well so you have to directly mirror your back-end data or at least what the JSON spits out with your front-end data and then so that's how it helps you get up and going really fast but the more you guys talk about Backbone the more I realize the next project I'm working on it could be really helpful to have that flexibility and also get that collection model component from it. I think Backbone is the easiest that we've mentioned to add on to an existing project if you have an existing project and you wanted to do something kind of new and javascripty and interactive and reactive it's easy to just include the library it's already in core you can just require or in queue some script that has available for you so it's really simple battle of the stacks learning time-wise being somebody who's looked into all four of these and probably not the smartest person at this table or two tables Angular is so easy to learn it's almost insane because you're writing HTML so you have a variable called things and you just repeat things and then they just spit out on the page so it's pretty cool I mean it's really easy to get into I think that's part of the popularity but I don't think it's always the right tool for the job and so it's interesting to hear you guys talking about this and this is probably why each of us have picked a certain two is based on like our needs or requirements where we were and also like who's gonna pass for it I just wanted to add something that I found helpful since the question was about dealing with API calls and remote calls and getting data and coming in so we use local storage heavily on WordPress.com and on any new project it's really helpful what local storage is it's kind of a schema-less database it's a key value store that your browser supports there's a limit of like 50 megabytes per site or something like that but you can just set any sort of data in there and it stores it as a string and you pull it back in later and so that's really useful so that the user can close out your site go do other things close their browser entirely and as long as those data are still valid you can render the page immediately when they come up you don't have to wait for it to come back from the server so if you're not using local storage definitely think about it and now I'm going to tell you a really easy way to use local storage which is Paul Irish has a jQuery plugin it's like less than 100 lines of code and basically any Ajax request you can add an option cash true and you get local storage caching for your Ajax requests Question 9 if you just Google local storage Ajax request but the author is Paul Irish and if you're not using jQuery local storage is a stupidly simple API to use natively and I think it's pretty much ubiquitous support yeah that's great thank you there's yes I agree with you that's like multiple sources from multiple domains that's exactly what the easier transport Jason's very lightweight and the exactly what you're getting I'm going to hijack the mic here and say that if you're not using jetpack related posts they're really good we use Elasticsearch internally and it offloads the processing off of your server so you can I think we actually have an API endpoint on .com so you can consume those even if you're not using the jetpack output it's really quite good and if you're on a shared host it's going to eat your processing cycles and it's going to slow things down to do related posts and a hosted service like jetpack it's super useful that was a really valid mic jack it's super good and for you to have to take the time to set up Elasticsearch they've taken care of it for you I was going to say if you don't do that really smart way to do it I would at least keep in mind you can absolutely consume that with the WP with the WP functions and one thing that you might want to do depending on how fast your content changes is store that in a transient even if it's just for a day or for two days you're not calling and it's also dead simple if you look at the WP Transients API you're going to call from one place call from another place call from a third place you don't want to have to do that every time and so just saving that information it would really reduce a lot of load thank you anyone else have a question yes sir do you have a situation where you're pulling information from a... so the question revolved around after you pulled data from a third party API and you want to add your own metadata to it is there a great way to store that or how do you keep up with it even keep the original data in sync so your specific use case I've done before so specifically with real estate data real estate API so we've had a couple of different use cases so you have featured properties so we've done a few different things for agents we've been able to filter by all the listings from the API like that but we've also been able to set it up where maybe they use a short code and they just set the MLS references to it and then just pull in those specific records we've also set up like override so if somebody wanted to override the description for real estate listing they could actually go in and we've set up a post type that mirrors and provides very specific fields that they can override and so that's basically a post type of metadata and then when we actually go to process and render the data on the site we just check to see if there's an override for that specific ID so here's how I'd solve that problem I would set up an API endpoint on your own site so that your front end is calling your own site you're not calling a third party from your front end there are a few reasons why you would want to do that and primarily the reason is that your API might be down another reason is caching so you can cache locally in your endpoint the response from the third party so you can have the front end always ping your endpoint and serve a cached response really quickly so to your question about how you would store the additional metadata is if you're going to cache this thing anyway I would store it in the cache so you get your response well this is the request is there a cache hit if there's a cache hit return if there's not a cache hit or if you need to update your cache then you go through call a third party then iterate through the response annotate it with whatever you need to annotate it with then save that data structure to the cache so the next time it just gets spit out as soon as it's requested this probably isn't helpful for you use case but I thought I would mention like maybe you're trying to merge two collections of data and you're doing this client side I thought this would be a good time to mention libraries like underscore not underscore's theme but underscore the javascript utility library as well as it's like other thing cousin low-dash backbone comes with underscore so you're going to get that if you're using native wordpress stuff low-dash and underscore both include like merge functions for objects so you've already gotten your array and you just want to add like maybe even just an identifier or like a counter if it didn't come with an ID you can easily use like an each function to help you add some of that metadata but this is again on the client side like javascript client side so and one of the things that you can do like with a lot of these javascript frameworks is particularly I know with Ember like you can have computed fields so like if what you're trying to add as metadata is actually computed you can actually create a field in the in the javascript environment that basically will take these two fields and calculate it and it will you know would you have absolutely anything right great any other use cases questions okay alright in that case I have a question I just want everybody to go down and tell me if I was going to pick up all of these frameworks tomorrow what is the must-have tool for your framework of choice so like I can do that I'm taking then you can the same tool it's cool okay cool thing about Ember data because it's in your client is that it's aware of the current state of your application where the data is in your application and again your applications in your browser so some brilliant souls built the Ember add-on for Chrome and that actually lets you inspect the current application state of your data where your views and components are being rendered like if they've mounted or not all of your applications routes and also kind of the current status of each individual view so if I was picking an Ember project I'd absolutely use that Chrome extension I think there's a Firefox extension too I just don't think it's kept as up to date as the Chrome one it's just well Ember data is an add-on that lets it do the data stuff like the models and collection stuff and a lot else but this is a Chrome extension if you just look up like the data I think it's Ember inspector Chrome extension but if you look for Ember Chrome extension that's the one that should pop up it's really handy to have yeah so as far as tools go so yeah really understanding what's going on is the most important thing so documentation is important but it's not really a tool so the next best thing is for me Chrome DevTools gives me a lot of functionality and I'm very familiar with it and can get a lot done there and when you're working with frameworks like Ember like you said having that debugging tool that's specific to that thing you're trying to do is extremely helpful and React actually has the exact same thing where you can actually hover over and it tells you that this thing you're on is part of this React component and that it pulls from the data source and so on so having those debugging tools are extremely helpful but then also on the other side when you're actually writing the code having an IDE or something that really recognizes the code you're writing if you're dealing with React it's JSX and it can do syntax highlighting and it can lint the code as you're typing it so that you can see that the second you type something that you've done it wrong and you can just go fix it real quick before you ever get to trying to compile and actually run the code so about React I think what really sets it apart is it's a couple things there are life cycle methods that are kind of built into the view framework like I said before React is the main portion and so you have life cycle methods like component is, or should component update that you can override and component will mount and component did mount and component will on mount so you know exactly when in the life cycle of this component this code is going to run you don't have to deal with callbacks or promises or anything like that it greatly decreases the cognitive overhead of components in the DOM and when your code is running so you don't have to deal with callbacks and crazy stuff and the other thing that React really stands out for me is it's really designed to be componentized and something that kind of took me a little while to grasp is the JSX format for writing the render method and it's really kind of interesting because it looks a lot like you're writing HTML it's kind of like Angular that you're writing declarative HTML but the thing that is a tag more often than not it's not an actual browser component like a div or a span or something like that it's going to be another React component that you require earlier in your module so I could say require slider or something like that and then I just do an open bracket slider past some properties give it some children like a slider cell that can be another React component and I think just that design architecture really helps you there are even third-party tools coming out that help you build React components without providing any data and you can build it separately from your app I think it's called React UI Builder there's a project that is really relatively new and you can build an entire layout and in fact like designers who don't code who know HTML can come in and use these things and build pretty robust layouts and programmers can then pick it up and add the state handling and put live data to it so I just think that the emphasis on the modularity of the view is really important Chrome Debugger I spent a lot of time in Chrome Debugger I don't know if there's a backbone Chrome Debugger extension but I'm going to go look at it and talk I'm just going to mention a couple other tools that I use a lot one is called Dash and it is an offline documentation repository works really well in combination with Alfred which is a kind of shortcut thing on the Mac and it's just super easy to hit the shortcut type Dash and the name of the function that I'm trying to reference I don't have to go on the web I've got it I can use it offline but it's more just that it's instantaneous and it's got documentation for everything you've ever used so it's not just for backbone it's for any library you use you can download a doc set for it so I really like that tool for querying APIs I've used Postman a lot which is a Chrome extension someone recently told me about a tool that's supposed to be better than Postman but I don't remember what it is called but Postman is awesome you can run it standalone as well and it just lets you set up like a specific API request and see the results kind of right in a place where you can easily adjust parameters and kind of mess them around with the request and have you do it programmatically so I'm completely dependent on PHP Storm it has almost everything it has the REST API tool a lot of the tools I need especially when I'm dealing with Angular and I too like the component if you look at my JavaScript I have many many files and all of them do very little things so to be able to hit a shortcut on a declared a function and it takes to where I've declared that function automatically and indexing that's really important to me and another thing would be grunt or gulp having something just running in the background I can put my files in my folders and it looks okay here's a SAS file I'm automatically included in your SAS here's a JavaScript file I'm automatically including it in your development so the way if you look at my index file when I'm developing I have all individual files on my page one by one as I'm developing and when I go to distribute it it's all concatenated into a single file so when I'm looking at the error code I know exactly what file I'm working on in development but I still have just by a click of a button it just concatenates, minifies and puts it on when I'm ready to push a production so I guess those two things which Storm is kind of a cheat because it has a ton of tools built into it but I don't know if I could develop without it. Thank you. Since you brought up build tools I'll throw out a blanket recommendation whether you're using grunt, gulp, make whatever, using a build tool for your JavaScript which is greatly de-complexifies things. It's kind of like what I was talking about with the React components you don't have to think about when things are coming because typically with JavaScript you include a script tag and your browser is going to go out and request it and it might take a couple milliseconds to come down you would have to think about in your code that you're writing your application code okay is this library loaded before I call it so the typical fallback is I'm going to wait now until the document's actually ready you know as long as the script tag's not in the footer or something like that if the document has been rendered then you're pretty safe to move on and assume things are defined but if everything is like you said concatenated into a single file whenever your application JavaScript comes down you know that everything is defined you know that you're able to just call it a thing that should be defined as it is and I was just going to mention as a tool if you're using Ember it's highly recommend you don't always have to because you can include it in the page but if you're using Ember it's highly recommended that you're using Ember CLI which is they have their whole build process with broccoli it's kind of like Gulp or Grunt and then they have a whole application project structure again with the rigid but a good tool awesome thank you all very much and I think that wraps up our developer panel on APIs let's give them a hand


This is Vogel Timeline with your host, Joe Washington. With a project of this magnitude, almost every day reveals a major milestone and historic achievement, as we witness America's rebirth of nuclear energy here at Georgia Power's Plant Vogel. Some big things are happening here. Really big. This is the 900 ton containment vessel bottom head for Unit 3. It was lifted and placed onto its cradle in Unit 3's nuclear island recently, making this the heaviest lift to date. The bottom head is the first of several components that will make up the thick steel structure known as the containment vessel. This is where the reactor and associated steam generators and components will be housed. The bottom head was assembled onsite in the containment vessel assembly area, where we can see that work on the Unit 4 bottom head is well underway. Each bottom head is comprised of 58 plates that are welded together. And next to it, we can see the progress on the middle and lower rings for Unit 3. Once all the components for the containment vessel are in place, it will be surrounded by heavily reinforced concrete to create the shield building. Right now, the CA-20 module for Unit 3, which will be placed adjacent to the containment building, is being welded in the module assembly building. The CA-20 module houses equipment for used fuel storage and handling and various other reactor operation support systems. When complete, it will be the equivalent in height to a five-story building and will be the single largest component used in the construction of the AP-1000 units. The containment buildings for Units 3 and 4 will each be connected to their respective turbine buildings. And in the past couple of days, we've seen the Unit 3 turbine building rise from the Georgia clay and begin to take shape. It's exciting when structures here go vertical. It also makes heads turn when mammoth components like this deaerator for Unit 4 arrive onsite. Everyone looks forward to milestones like these, as we're living a little piece of history here every day at Vogel 3 and 4. To date, there are 2,650 workers onsite, and that number is expected to grow with the project. There are many different kinds of jobs and specialties here, and Quincy Robinson can tell us more about that. There are a lot of opportunities here as far as different crafts. We have all the lexical craft, carpenters, concrete printers, iron workers, pipe printers, and all these crafts offers our apprenticeship program, which consists of three to five years of training on job training to get paid at the same time. And this is a great opportunity for the future. This is the turbine 3 building of the Plant Vogel here. This is the actual area I work in, along with the raw buses, the carpenters, the laborers, the surveyors. The raw buses are the guys that's doing all the tides. It is a very important role as far as getting this steeling. It has to be done. And then it's poured with concrete so we can further the progress of the project. Thanks Quincy. Every single person who works at this construction site is focused on safety. CB&I's project director for Vogel 3 & 4, John Simmons, has more than 35 years of design, construction, and project management experience, and he's responsible for ensuring the project is completed safely, while meeting the objectives for quality, schedule, and cost. We have been in a ramp-up phase for about the last four or five months on the project. We've had 250 workers over the last three months. Most of those workers are supporting our concrete work and our module installation work. A lot of welders are being added to the project, and it's great to see the mix of the workers that are coming on to the site from Georgia. A lot of younger workers are coming in, and that's just great. It's great for the local economy, and we like to get that mix in here also. We're going to be continuing the work in the ox building and the containment. We just placed the first nuclear walls. That work's going to be continuing. We just placed the first mechanical equipment. That work will be continuing. We're going to be placing consolidated concrete that's coming up. The other thing that's going to be happening to the significant is we're going to be setting the condensers in Unit 3, and that's going to be a very large pick. Thanks, John. Together with consortium partners CB&I, Westinghouse, the designer of the AP1000 is responsible for the successful execution of the engineering, procurement and construction contract for the project, which is more than 50% complete based on contractual milestones. Scott Gray, Vice President for the Vogel III and IV AP1000 project for Westinghouse as more. We're targeting two major activities, at least. One being the setting of the CA-20 structural module and the Unit 3 auxiliary building. The other significant milestone will be the concrete placement or the first nuclear concrete for the Unit 4 base mat. Over the next six months, our goal is to achieve elevation 100, which is the surface level surrounding the nuclear island, which allows us to start the construction of, for example, the annex building, which will be used later on for us to install equipment which supports the initial energization start-up activities. We have a very collaborative working environment within the consortium. We work very closely together. We make decisions together in the best interest of the project. We work very closely with our customers of the nuclear to try to make sure that we address all the critical issues that everybody is interested in and is important to the construction of the project. The key to our success, whether it be on an individual activity basis or for the project as a whole, is the commitment that we've made as a team. It was a project to a strong nuclear safety culture, to the safety of our personnel, the quality of the work that we do, doing it right the first time, and continuous improvement. Thanks, Scott. Every activity here is performed with Georgia Power's uncompromising commitment to safety, as well as the Nuclear Regulatory Commission's oversight to ensure all safety goals are met. NRC inspectors are on site here full-time at the Vogel 1 and 2 operating facility, as well as at the construction site for units 3 and 4. And recently, Nuclear Regulatory Commission chairman Allison McFarland toured Plant Vogel and expressed confidence that safety objectives are being met here. In preparation for today's visit, I was able to spend time with our resident inspectors. We have resident inspectors at the site, both at the operating facilities and at the construction site. And both of these teams are, of course, focused on the main priority, which is the work and mission of the Nuclear Regulatory Commission, which is ensuring public health and safety. Construction here continues to be well-managed and is progressing toward Georgia Power's goal of providing a safe, reliable, clean and cost-effective source of electricity for today and for generations to come. That's all from here for now. Join us again for the next Vogel Timeline.