 So I'm Chris and actually my partner Jonathan is over there. We're from a little startup called Brand Dicted. But we're here to show you a little example project we've been working on lately called Ramses. And I'll give the backstory for that a little bit. So we have this client, which is like a enterprise project management application thing. And our mandate is to do the backend. When we started the project last November, December, we inherited this super monolithic Django application that had, it was using Django REST framework. Can I see hands for everyone who knows about REST APIs and or has implemented them? What about those who have used Django REST framework before? Okay. Okay. Cool. So you might be aware that it's a little bit big or it's kind of hardcore. There's a lot of different things that you need to implement to use it. And we found that for a prototype project that was way too big and way too monolithic, and it was a pain. So we developed Ramses. So the thing is with REST APIs is that most of the time it's really, really simple. Or for what we need for the case of prototyping it's super simple, which is if you really want to do hardcore REST, it's you would do like hypermedia as the engine of application states. And you would have like these crazy, browsable programmable APIs that are magic, but nobody really does that. So we have our own definition of what REST really means. And it's the boring version, which is making life easy. And it's simply that, JSON crowd over HTTP. We don't want to do XML. We don't want to do really anything other than that. So we can make a lot of assumptions. We don't need half the features that Django REST framework gives you when we have such a constrained definition of what we want. And so therefore when we were... So when we inherited this prototype and we were having to add end points with attributes and stuff like every day, the requirements were changing. And it was a huge pain to have to do everything with Django REST framework. And because even with our boring definition of what REST should mean, that's what needs to be done every single time for every endpoint that changes. And as really, really lazy people, that was a pain. And it's kind of a lot of monkey work. It's all boilerplate having to put all those pieces together every time you need a change to an endpoint. So being lazy, we didn't like that. And especially because most of the logic lives on the client these days, it's like, why? It's just an extra like salt in the wound, knowing that all of that monotonous work is... I don't know. You don't even get a reward, really. So we didn't want to do all that. And we thought maybe there's a better way. So given our definition of REST, which is just JSON CRUD over HTTP, our goal being zero boilerplate. We just want to write a spec and then generate a whole app, a whole server just from that for prototyping. So I'll show an example if I can find it. So we found this thing called raml. Has anyone heard of raml before? Yeah. Okay. Cool. So it's just a YAML DSL for making REST APIs. Is my window fitting? Okay. Let's just do that. So here is a contrived example of an API spec using raml. So as you see, it's just a YAML config where you say what you want your endpoints to be. You say your methods. You can include schemas for validation. And it actually gets super crazy. You can do all kinds of inheritance and different kinds of traits and stuff. So to give you an example, here is like a user model. And we have a schema right here, which just says all the different types. And I don't think we have support for all of them yet. And so I'll show you. I should be able to run one here. So what it does, what we're doing with raml that's special with Python is that we're parsing it. And we're actually generating a pyramid application from it. So just like any other pyramid application, we run it. We're just printing out what was generated for development. So these are the endpoints that we're getting from this. And then I can do stuff like, I think it's 8080. So I can do users because I have my user's endpoint. And I can say name and I can say password. And I can say, I think email equals whatever. And so that should create a user for me. Oops. Oh, I'm sorry. It's username. So there's the validation network. OK. And then it responds with there's my user. Obviously, we're not doing any kind of password encryption or anything right now. And now if I do, I see my list of, well, I have one user now. So that's a super, super basic example of doing a JSON crud over HTTP. I don't have, I'm not going to show delete and everything. You get the idea. We can also post fixtures and stuff like that so we can fill up a database. And all the app is, so this is a pyramid application. We just have this little config file here. It's using Ramses, which is, we did the generic base classes in a library that we're importing. So that's the only config for the application. And the only Python for the application is this. It's just the entry point for the development server. And it just uses Ramses. And even if I showed you Ramses, the library, there's like two classes, one for generating views and one for generating data models. So that's the simple example. So that basically fixes a lot of problems for us. And I forgot to mention actually that because our client has sort of non or semi technical stakeholders and there's a lot of them. And there's also like seven or eight different artifacts that contain requirements and all in different natural language. And there's like, there's wireframes, there's Excel documents, none of it is like testable assumptions. And so part of our goal was to get away from implementing the configuration monkey work ourselves and getting the semi technical middle management type people to actually write the specs for us. So the interface is that they'll write this YAML file, which is as easy as it can possibly get. And we'll do the heavy lifting, but mostly by automating it and generating it. But in fact, there are some other things if it was actually had to be serious. If we needed to implement production applications, what you just saw is kind of really, it's a toy. It's a proof of concept so far. But we need to do all these other things. And it turns out that we actually did already have all of this stuff for our startup brand dictated. And this is where our sort of scheme to dog food everything comes in, which we're really lucky that after the fact we tested a bunch of different solutions. And finally, our own one is the best. So we actually get to use it. So this is Ramsey's partner in crime, Nefertari, his favorite wife. And so she actually powers the brand dictated API and is doing all the persistence and querying. Right now, we're using elastic search for reads. So that's basically to avoid doing boilerplate crud in our views and to avoid the temptation of writing fancy queries inside views when what we really want to do is be super hardcore about our constrained version of what REST means. So that's why we're using elastic search and you should try it. And then we had Mongo support before for our product and our client actually asked us to add SQL alchemy into the mix and we were using Mongo engine. And so we've actually added a database abstraction layer to handle all of those things. So this is the meat and potatoes really. So where do we want to go with this? Obviously, you can see that if you have this production level thing that is making real solid back ends and you're also able to generate them dynamically at runtime and you're able to work with non-technical people. It's kind of a bonus and you get to dog food your startup. So our goal is to actually bring them together and to be able to generate Nefertari apps with Ramses as opposed to just a simple pyramid app. So these are our goals. We want to combine them. We want to get people interested in doing that kind of stuff because it can save a lot of time and you don't have to do monkey work. So yeah, that's the presentation.