 Thank you. My name is John Beyr. I'm the CTO of Zabnitu, so I'm going to just talk to you for hopefully, I was going to aim for Jamie's new target of five minutes, but it's actually a 20 minute talk. We talked a bit about how we're basically taking our Rails app, which is a sort of increasingly becoming legacy, moving that over page by page to Ember. So a lot of this work actually has been done by Aaron Chambers. I think most of you probably will know who Aaron Chambers is. He was doing a big talk on Ember CLI deploy at Ember Camp. So he's kind of, should take all the credit for this actually. So I'm just here. I just kind of gave him permission to do it, which was kind of fun. So yeah, hopefully it's good for you guys to sort of see how we're doing this. I think it's quite an innovative approach. There's probably alternatives, but it should be useful hopefully. So I'll just quickly go through a bit about Zabnitu. We're what we call an expert network platform, which might sound a bit crazy, but we basically provide networks of experts in any niche. So these are just a couple of examples. This one from Nature is scientists talking about how to be good at scientific writing. This one in the top here is a biofilms community. So these guys are all talking about microbiomes, which is kind of like gut bacteria. So what you're looking at here is kind of the front end of the Rails app, and as we're gradually sort of putting page by page, it's moving over to Ember. And I actually just wanted to just sort of double up a little bit on how important Aaron was for this. So I was searching around for a photo of Aaron Chambers, and these are the guys that came up on Google. It's actually this guy, so I think you'll know him. So he's the kind of brains behind most of this. I would also say that I'm fairly new to Ember as well, so at the end when questions come, be nice. So what we'll talk about is just want to give a quick refresh of MSCI deploy and sort of mainly the lightning pack, which is the approach we're using. I think most of you should be familiar with it. I would be surprised if you're not, but obviously we're using that in our approach. So I'll quickly go through sort of how we're using that. Give you a quick demo of our Ember CLI deployment. A quick demo of our Ember CLI deployment and how we're using that sort of page by page. So detail on our sort of Rails layouts and templates, how they've kind of changed a little bit away from a standard Rails conventions. Again, moving from the templates onto Rails controllers and a class that we've created, Aaron's created, called Ember Config Adapter. And now quickly just at the end I'll go through some alternatives because there are some alternatives to this approach in terms of embedding Ember with Rails. So I guess why do this, why not just rewrite the app? It's a question I think was there was a bit of a heated debate on this Ember Slack channels a few weeks ago about how the approach for sort of whether you just rewrite your app from day one is you've got a legacy Rails app. Why don't you just sort of throw it away and start again on a new lovely kind of Ember world. So for us that new toes not like VC backed. We don't have like millions of dollars to burn on crazy awesome offices and spending 12 months building stuff. So revenue is really driving our product. So we've got good revenue but not really enough to spend a long time rewriting a quite sophisticated big app. We have customers to keep happy. I know it's a crazy, crazy idea. But we've got basically we're an enterprise enterprise level sort of SAS provider. So we have at the moment half a dozen customers and they're really sort of driving product improvements. So we'd never get away with sort of saying 12 months of no new features. It wouldn't go down very well. So yeah, I guess we can't really wait 12 months just to deliver a nicer version of the same app. Did I labour that point enough? Yes, we kind of have no choice really, but to find an iterative way to do this. And so actually the other thing about this as well, which I think I'd sort of touch on at the end of the slides, is our strategy, technical strategy is to really be we are committed to Ember for managing our front end. We're not really want to stay in a world where Rails is managing our front end anymore. We really want to drive towards it. We have made a decision now to actually really split the two. And the Rails app will just be the API eventually. There's no kind of halfway place for us. So it is commitment to it, which I think Jamie would be happy to hear, I think. So just a quick recap on for those of you guys who are not fully aware on Ember CLI deploy. Essentially you have your server, Ember Dev server. Ember CLI deploy will push effectively a HTML file to Redis. And then your Rails server will pick that up from Redis. You can use non-Redis deployments, but that's a fairly typical one. So the Rails server will pick up the HTML file, send that down to the browser, and at the same time when you deploy Ember CLI deploy will push the static assets of JS and CSS, so on up to AWS S3. And obviously that's available for the browser to pull that down. So it's effectively what Ember CLI deploy does. And then you might be familiar with this diagram that Aaron put up during EmberCamp, which is the deploy pipeline. So effectively what Ember CLI deploy does is it's actually going the opposite direction. So from left to right it goes through a configure, build, prepare and upload steps. And then alongside that there's various plugins that you can use to make that happen. So in our case we're using build plugins, revision data plugins, which basically give you a fingerprint, S3, Redis and then gzipping. So that's effectively what Ember CLI deploy does. So it's just a quick recap really, just to set the scene on that. And so I've got just a quick video. It's only 30 seconds long, hopefully, of this actually happening. So just on the console, deploying to staging, this will go through and actually hopefully you can read it, it's a bit small. So it's gone through there, it's gone through deploying to Redis, building manifests, generating all the various static files that you need, gzipping them, just scroll back up so you can see those. It's actually off the screen a bit. So through build, gzipping, pushing to S3, pushing the HTML file to Redis and then finishing off. And at the end of this you'll get what we call a revision key, which is a fingerprint of all those assets together, which is actually this number here, 87073, this one here. So this is basically the unique key that we generate, which is stored in Redis as a unique key, and then that HTML file is stored in Redis as a value. In our case, we actually store JSON, but the normal convention for embassy-alized deployers you'd store in HTML file. So I've copied that revision key. And so just to quickly take a step back for a minute, this is one of our websites, one of our Zatnita networks called Biopharma Deal Makers, which is a network of biopharmaceutical companies. So just to go through this page here actually is a standard Rails page that you're looking at. There's no ember stuff on this page here actually. So just clicking through, going to the companies tab. You see a drop-down here at the top. So when I click on networkers here, this is going to an ember page. There's not a huge amount of stuff on here yet, it's fairly new, it's only a couple of weeks old. It's basically a list of companies. So everything inside this frame is ember. Rails is still generating the menu bar there. So what I'm doing, you can see I'm doing this without typing out hands, which is pretty awesome. Putting in the top just a query parameter there, which is enable ember, and then pasting in that revision key, which I copied from a deploy script. Having done that, what I'm doing here is just saying I want to load a different version of the app. So when you first looked at this page, it was loading the current version of the ember app. Having pasted that enable ember query parameter in the query string, I'm telling Rails to pick up a different version of the ember app. So I went through it a bit too quickly. It didn't look any different. The main difference was that they were alphabetically ordered. Ideally, I would have had a slightly better version of the app to show you. But you might take my word for it unless you want to watch the video again. So the cool thing about that really is that Rails is rendering the header and it's rendering the footer, which I think I've got highlighted somewhere. Next one. So the great thing about it really is that we can have multiple versions of the ember app deployed in production. And then we can put them on there and give it out to a bunch of beta testers and say test this for us before we actually activate it. So it's pretty awesome really. It's very different to the Rails world where we deploy it to Heroku and the whole app is deployed at once. With this, we can have as many versions of the ember app deployed as we want for which one we want. So that's kind of the scene really of what we're doing. So this really just to reiterate that kind of page by page, that enable ember URL parameter allows us to run the legacy Rails page alongside the beta ember page in production. So that example doesn't really show it very well, but you could have had on that page like an old version, a Rails version of that company listing, and then you could drop in the enable query parameter and it'll just swap out for the ember version. So you can actually progressively swap out Rails pages and swap them in with ember pages. Which is pretty nice actually. So to do that, basically we've got a method on the Rails application controller called render render ember if requested. So that's checking if that query parameter is there and if it is there it will render ember. And then we've also got another method called Rails application controller called render ember. So that will always, if we call render ember that will always render the render. Always render the ember app. Obviously with this one we'll do it if you request it. So just to quickly go through kind of a request cycle at a high level. We've got standard Rails, roots, standard Rails controllers. We've got a method of what we do basically in call. We come into the Rails controller we call render ember from the application controller. That we then load the style and script resources from Redis that we previously pushed up there. That we then assign what we call an ember config instance variable in the controller. So it's a standard Rails instance variable. And then we basically render a dedicated ember index template which actually has not much unit at all apart from just a div tag which the ember app boots from. And then basically inside that config you've got the js files and the cs files that you need to render the ember app. And that's just this custom. We've basically inside that ember index template there's one div which says ember app container and the ember app knows the boot from that rather than the body tag. So just to talk through quickly kind of how our Rails layouts have changed from standard Rails conventions. We've got our application html erb template basically hasn't hardly anything in it anymore. It's just got one line which delegates down to what we call layout space. So in that base template you've actually got down there as you can see it the standard stuff that you'd normally see in the application template. You know the html tag the body and the hit we're rendering a layout from a partial so rendering a head from a partial now from footer. So all that stuff you normally get in this file has been moved down. And then we've got a new file called ember application html and this has got a whole bunch of new stuff in which is specific for this approach where we're using content for tags so if that exists if there's content in content for link key then we'll take that ember config instance variable that I talked about before and that will contain hopefully will contain link tags for style sheets and then again for scripts. So we'll call that if we have the ember render ember method on the application controller called and then this will call down to base afterwards and then there's another file which is the head partial so this will the head partial will look for the ember link and the ember script content if it exists that's kind of like how the templates have been split up and they work kind of in parallel. So just quickly on the controllers that example where I showed the directories of companies that's basically what it looks like there's hardly anything in it really so there's an action on there called organizations and in this case we're just calling render ember so it knows just to delegate straight back to ember and then also we can call render ember if requested so that will check through if that query parameter exists so that's pretty straight forward really. Then application controller this is where most of the work on the rail side is happening that's what the render ember method looks like so that's assigning the first thing it's doing is assigning that ember config instance variable and that is basically calling through that's where it takes the query string parameter that's the version identifier and that adapter I'll talk about in a minute because that adapter is basically what's calling through to get the data from Rennes and the last thing it does is render that ember template that's just a pretty much simple helper method to get the query string parameter the key thing here with this is that if that enable ember query query parameter doesn't exist on the URL it will return the current word which basically is telling Redis to return what's been assigned as a current version it's pretty simple really and then the adapter this method basically is checking the environment we have an environment variable so in rails configuration in production you can tell it to use Redis or if it's development you can tell it to return a local version so we talked about this really this is what that ember index template looks like there's just one tag in it and this is really the structure of the JSON content that we push into Redis so in there you've got the most important stuff is the link array and the script array containing the fingerprinted CSS for our ember app and then obviously the fingerprinted JS for the ember app and then there's also some meta information there which tells ember to root off the ember app container that's pretty much what's just stored in Redis basically so then just to recap basically where that JSON object is used is obviously to use when we render this stuff here this is effectively what the ember config adapter looks like so in terms of the rails environment configuration in production we use a Redis version and in development we basically have a hard coded version which says call through to a locally running ember server so when you're working in development you've got a rails server running and you've got an ember server running and it knows to connect this is essentially what the ember config adapter code looks like so there's a Redis client which is really simple down here just using the Redis gem in rails to pull that value back is essentially using that key to pull it out of Redis there's not anything amazing in there it's just passing getting that JSON back and returning it back as a Ruby hash I know it's pretty standard but it's kind of awesome as well all at the same time so just to recap that step really so we've got standard routes which is that directory organisations controller we call render ember from application controller that ember version identifier from the query parameter tells us what version of the ember app we want to use we use the ember config adapter to get all that JSON from Redis we've got that ember assigned the instance variable and then we obviously call through to that virtually empty template to root off the ember app so that's basically the steps that we've gone through so just quickly to talk about some alternatives because there are other ways of doing this so the benefits of our approach for us really the ember CLI app is really loosely coupled from the Rails app it's just a standalone ember CLI app it doesn't really know anything about Rails it's not embedded in Rails so a development workflow for that is nice and fast and quick and really awesome we can deploy the ember CLI app independently of a Rails app so at the moment from CircleCI we'd probably deploy the ember CLI app four or five times a day the Rails app is getting deployed maybe once a day but they're totally independent of one another so developer workflow is developer workflow is separated it's not fully separated yet but it is getting there between the two apps again we're able to swap out the old Rails render page page by page so we can beta test the ember app in production and again as I said we're fully committed to ember so the thing about ember islands which uses ember CLI Rails is it's still sort of inside the Rails world I haven't really gone into detail yet of ember islands, when we first started this approach ember app was just about nine months ago ember islands were still quite immature at that time or less mature than it is now certainly and the other thing about this as well is with ember CLI Rails you sort of have to wait for those guys to when ember CLI gets updated you have to wait for those guys to get up to date so as we're fully separated we can just be as fast as ember CLI is as well which is great so some just quick drawbacks and drawbacks that we're kind of aware of the main one which is giving us a bit of pain at the moment is Rails is still still in Rails and we haven't figured out a way of sharing the SAS variables so you might want to do some coding on the ember app and you can get access to the SAS variables but you don't know anything about them at the moment all you have is a compiled CSS style sheet so we want to try and figure out a way of sharing them and in development you have to have Rails running locally to get a style sheet and to get the header and the footer so you do have to have Rails set up on your devs I mean it's not the end of the world but it's a bit of a pain so yeah other stuff really just kind of it's our first attempt like it's working really well but I think there's if anybody's got any thoughts or ideas on how to improve it particularly around the CSS problem would be or SAS problem would be would be appreciated so that's it any questions welcome actually what should say if you've got any questions save them for Aaron yep you don't need to be with your Rails app I think we we probably I think we were, we did start to go down that route recently and it kind of wasn't working so we kind of moved it back again it was kind of a bit of panic but I think that's what we do want to do is try to move it into the ember really because that's where it should be so it's just kind of getting to that that's it yeah or Mario might be able to answer actually why don't you try me and I'll give it a go so the unusual thing like you're saying one single ember application but only on certain pages at the moment yeah which means then that your navigation where you are in the ember application is not determined by what comes after a hashtag but what comes just your actual URL that you've requested you really have to write something to sort of pull out your actual location and then put you into the right bit of the route I guess we inferred this from the URL both from the roadside both in the ember CLI application so basically when you're visiting that organization, that whatever and we're rendering the ember CLI app it's aware of that and you have a roadmap to see a client-side application you have a roadmap to convert to client-side application what whenever like a flow that we're migrating a page say that a page is present on dash proof I would say now we need to ember finders so on the ember CLI app when we serve it we generate a route called dash proof so it's aware of that for example when you have three URLs like dash recognizations like dashed experts and apparently you navigate between them by rendering them in batch every time oh you say how do we treat links that are in ember but depends on the Rails page for example when you have posted pages and wanted to ember you want to make it client-side so yes for now we're basically re-rendering the entire thing so say that the organization's page and the ember app is rendering one container or there's another page that has also been ember so we basically just link to that and the Rails app serves the entire thing again and the app just serves but do you have any plans to migrate to client-side navigation? it will happen eventually it will happen at the moment we've got there's two main pages within the site which have got this there's that company directory and there's another page which is sort of an admin page but sooner or later the weighting between the two apps will mean that it's much more important to have the navigation and linking or with ember so at some point or another we're going to have to flip it over I suspect once we get to that point we'll bite the bullet and do the rewrite so it's kind of buying us time I think that's going to happen at some point that's all the time we have for questions thank you so much John