EmberConf 2024 - The State of Front End Deployments with Ryan Dagg and Yehuda Katz

all right um I'm Ryan dag lead front engineer at Heroku been at Heroku for almost two years been doing Ember for about three months um I think you all know I think you all know Yuda Heroku for three months and doing Ember for 10 years since since yeah so I've been working closely with Yuda since he um joined so let's see here we're going to be talking about state of front deployments and deploying the back end easy way um how we'd like things to work one you build your app you follow your instructions and you don't think about the deployment and then you push no step four um this was actually my first experience deploying to a server um it was working get push Heroku main I was in a debot camp and I did not know which way was up and I still got this to work and it was it's the dream it's what we were hoping for um yeah this is basically when people say what's a p that's basically what they're talking about things got obscured since then but we're just saying you you didn't think about deployments when you made your app and then it worked you didn't you didn't have to think about it when you pushed either that's all that's all I have to say about that slide yeah got it and then how does this how exactly does this work right follow your framework's instructions and don't think about deployment that's it's a big jump It's a leap um right why should it work your local development environment doesn't have that much in common with your production environment why should we expect to be able to blindly write an app locally and then magically have it work in production well most modern framework prati framework practices are already compatible with deployment environments which helps quite a bit oops too much to cover here but for the purpose of this talk config one moment um config config vars have largely been standardized um but in 2010 that wasn't entirely true enter the 12 Factor app in 2010 the 12 Factor app philosophy defined framework agnostic best practices that allowed us to that are not coupled with the development environment um one of the ways that 12 Factor changed the industry that was iconic for me at least was by getting people to stop hard coding Port 3000 and in said use the port nvar it's actually also in that boot camp the first nvar I had ever encountered um as an example right just I like code personally uh paramed API host variable here that you're pulling from your environment not terribly like uh something you think about too much right now but we'll get into why this is important um especially right compared to hard coding which I think was a standard for quite some time uh if your yeah if your server communicates with another service right this is the way to do this uh and you'll get different behavior in development staging and production okay so that's cool that's basically the story of Heroku like a lot of people experienc it through boot camps it's also my experience you like you built your app you didn't even know what deployment was you just got it working you get pushed everything uh everything worked and like you didn't think about it um but like 10 years after all that happened and after we had all that standardization it's still it's totally normal to make a web app that has a front end directory and a backend directory like I've do it all the time and it's also pretty easy to get it working locally but today like on any platform it's really painful to deploy that now you might be thinking like is that right like should people do something when they deploy it seems like it's easy but actually it actually is part and here's why so if you want to use any front end framework you want like Ember and you want to use the best backend framework for the job which is probably not like whatever your framework told you to use or Express it's like you want to use rails or Django or something then and you just want to build your app the normal way and not like go to your platform's website and have them tell you exactly what you need to do to build your application so you just want to like go to the Ember website follow the instructions and get it working like again this is just the um then you're just kind of out of luck and that's not to say there's no options at all you could you could use a front-end framework that has a built-in backend story alternatively you could let your platform tell you how to write your app and either of these approaches totally works both of those are things people do you've probably done them totally works but it's not quite what we want um remember how we said it was like really awesome to build your app locally get it working locally and then not worry about deployment until you're ready I don't want my deployment platform to tell me how to write my back end I want to pick the best tool for the job and this sounds like a cool story and I'm here like it's a marketing pitch I'm telling you like you should use Heroku but you probably actually don't deploy your Ember app to Heroku so like why is that so it's actually the answer is subtle so remember how we said earlier that the 12 Factor app made off-the-shelf backend Frameworks compatible with deploying to production so that meant like we were able to use the 12 Factor Manifesto to get people's documentation to not to stop hardcoding ports stop hard coding other configuration um the problem is that this doesn't solve the problem for front end so we said that 12 Factor app standardized configur as Ryan said that so we can stop avoid hard coding URLs and let our code adapt to different environments that is awesome and it was a big advance in the deployment state-ofthe-art but unfortunately the 12 Factor app went further than standardizing config bars it it also says that config variables are always provided to the application at runtime and bear with me for a second here the problem is that this bakes in the fact that backend apps get their config variables through runtime environment variables into the whole design of of config bars so the thing that Ryan showed earlier where he's like you should just write API URL like that problem also exists on the front end but this solution which is like you're running inside of a container and I have provided to you as an environment variable does not work on the front end um front end applications need the config bars to be included in the build like now that I said this this should be obvious right it's like ends up in the actual payload that you put on your CDN and this detail is not fundamental like if you go read the 12 Factor Manifesto there's no actual reason why this is what the 12 Factor Manifesto says but it actually is what the 12 Factor Manifesto says and it is also what Heroku does and therefore like what everyone else does so when I started at Heroku in November like one of my priorities was just to try to dig into to like why I am not using Heroku to deploy most of my Ember apps and it was good timing because there's a bunch of Architects at Heroku that were getting ready to start thinking about refreshing the 12 Factor app and that gave me a good opportunity to help think through the problem like like it's always good there's a bunch of people thinking about something it's not like a product discussion it's a thinking conversation that was a good place for me to be like I don't really know anything about this company but like something seems wrong here um and I also really wanted to make sure that like our community like front application are well represented cuz it just would be really easy for the same mistake that like allowed front end applications to not get the right Behavior to just like keep following through the refresh like that wasn't what people had in mind and so I wanted to try to represent front end in the conversation and like this is basically the Northstar that like every conversation I've had in that working group like what I say is you basically want to have this repo that I showed earlier with a front end and backend directory you would like to be able to get push the repo to Heroku like you would like the back directory to be detected like the same way that any other backend is like the that's the part of the story we know and love and like you've probably done now we also would want the front-end directory to be detected by a front-end Bill pack and that that has to solve the problem of baking the config vars in right and what that would end up meaning is that the thing we said before where we could use whatever front-end framework we want whatever back end framework we want and have it get deployed seamlessly the thing that worked in 2011 for backend like would actually work for front end and it would exist in the world which is nice um unfortunately we still actually do need to fix that problem and that that's why we're thinking about it um and I don't have much else to say here other than like we are thinking about it there's a reason we're thinking about it and I think we are going to I think um Vish our Chief Architect already announced that Heroku is going to be leading an effort to revitalize the 12 Factor app and I like I want to ask the people in this room and like any frontend people like be be around and help because little weird things like this actually are the reason why we end up not getting what we need and it's very subtle it's not like something that people notice so definitely when you see people announcing it like don't think oh that's probably not for me that would like keep the problem going try to participate and I think there's a good opportunity for us to like make a good thing happen be great okay thank you [Applause]