 Hey, so I'm Marcus. I work with artificial labs and we're basically just around the corner at Bankstation. And yeah, today I'm going to introduce you to sales chairs. I assume that most of you haven't heard of it. But basically to give you just a quick idea, as the name chairs suggests, it is built on top of no chairs. And similar to Rails chairs, it's Rails chairs. Similar to Rails, it comes with the idea of convention over configuration. And I've read some people even call it the Rails on nodes. Maybe that's why it rhymes. But yeah, before I get into any details, what was actually the problem that we tried to solve at artificial labs? Well, we started with ML chairs not too long ago and we saw quite quickly how awesome it is, how everything just works based on the same conventions. And coming from a PHP background, PHP just quickly started to feel clunky and like all this manual labor that you have to do just felt like, yeah, why do that? And so we were looking for better solutions than this. And one that Ember or Ember data provides as a default is fixture adapters or basically creating a mock API. So you just create your model in Ember itself. And then you can just get coding with the front end itself and get quickly started without having to worry how exactly does my API look, like is my server running, like all this is set up. But it works fine until you go into production because then you still have to write the API and still make sure that everything integrates. And this extra step just felt a little bit wrong for us. And one quite obvious solution, which I think a lot of Ember people know would have been obviously Rails. And it would have been probably a very good solution. But we still kind of felt there's overhead, it wasn't built for the front end. So we thought why not find a solution that combines the amazingness of Rails having the conventions, but sort of combining it with like a mock API, sort of like a framework that is built for the front end and that it doesn't get in your way of rapidly coding the front end. And that is exactly where sales chess comes into play. And yeah, sales chess is built for the front end, just to give you a little bit more of an idea of what features it has and what it provides before I'm going into a live demo. Yeah, the idea behind this is that it is built for the front end. So no matter if you use Angular chess, Ember chess, or just write it for a WhatsApp or for your iPhone app or Android app, that's exactly what the intention behind sales chess was. And but on top of that, it still has all the features that you would expect from any framework. So it has a quite beautiful ORM system. So it works with any database that you would want it to work. And one really awesome feature that we have found while we worked with sales chess, in fact, you can even use multiple databases in one app and it hides effect from you. So to give you an example, let's say you have a user model and the user can write posts, then you could store the user model in the Redis database, you have quick access to all the users, but then you could store all the posts the user writes in a MySQL or Postgres database and all you do is you tell sales store this model in Redis, this model in MySQL and then it completely hides this fact from you and you have exactly the same API and it works as if you would store both in the same database, basically, from a developer's perspective. So that was pretty amazing and we didn't expect this when we started out originally with sales. And one other feature is built on Node.js, so obviously it is JavaScript and one thing you might think, you know, it gets both JavaScript and Node.js, I can share code, it hasn't really been our experience that much so far. We in fact, for our apps that we have so far, we actually don't share like any templates or any models or anything because it's two completely separate projects. But one very nice thing that we found is you can use the same libraries on the front ends and on the back ends. So for example, Moment.js which handles dates. So when you work in the front ends, you do some date conversion, you can immediately like, you know, you just switch to the back end, you don't even have to like do a mental switch to a different language, you use the exact same API and yeah, that just gave it much more of a smooth feeling like, yeah, this is how it's supposed to be. And yeah, similarly, obviously, you know, JavaScript, so you know, like learning the one helps a little bit with learning the other. And in fact, one of, I would, I call it freebies that we got from switching to sales chairs as our back end. One of our back end developers has seamlessly transitioned into a full stack developer because you know, MR chairs, you know, it just blends back end and front ends basically together. And that was also very nice for us. And yeah, another awesome thing since it's built on Node.js, I know maybe some of you know Socket.io. So sales chairs has Socket.io built in as a default. So every API that is being generated just supports Socket.io slash real time out of the box. So you don't have to configure anything on the server, you just have to integrate it with Ember. And there is already a community adapter for that, which I can, I have the link to it afterwards if anyone is interested. And yeah, then the core feature which made us interested in sales chairs is that it auto generates restful APIs for you. And yeah, I'm not really going to talk much about it. I'm just going to show it to you since I think this is more of an effect. So, at first, I'm just going to show you sales itself as it comes out of the box. So it doesn't, so the JSON returns doesn't work with MR data as is, but I'm just going to show it to you for now. And afterwards, we've written a little starter kit which basically integrates Ember and sales without having to do any further setup. Yeah, as you know from, if you've ever used the Ember CLI or I think Rails works similarly, you've got command line features as you would expect. Do you want the thumbs down bigger? Oh, yeah. Oh, yeah, that works. Is that good? Bigger. Bigger. Bigger. Bigger. Better. That works. Can everyone see in the back? So yeah, you just write sales in your test app. It just, you know, scaffolds out everything in your test app folder. And if you're interested in the folder structure, yeah, in config, it has all the config files. You could also render views on the server side if you want to. And you can, in fact, use handlebars with it since it's NodeChase. It supports Node packages out of the box. But we haven't really used it. And then in APIs where everything lies, so there you have your model views and controllers. Yeah, controllers, models. Yeah, not UVUs, but yeah, your controllers and your models. And let's just start the app up to show you how it works out. I just have to quickly change port settings since I'm already running another server in the background. Blop, blop, blop, blop, blop. There we go. One, three, three, eight. So this starts up the server and even has a nice little boat. So I've already got this open somewhere. Let's see. Yep, there we go. So this just renders its default view that it has at the beginning. And it gives you, let's make this a bit bigger as well. So this basically gives you a quick introduction on how you can generate your API and how you can get started with it. So I'm just going to show you this real quick how this actually looks and how this looks on a command line and how this looks in a browser. So quickly just going to stop the server. Here it tells you that it has created the controller and the model. And here is where the conventions come into play. So all you need is the controller file and the model file. And then sales has something that is called blueprints. And basically based on the sales blueprints, it automatically creates the routes and it automatically creates all the right functions to return a chase and a get request, to have a put request, to have a delete request, you know, like all the things that you expect from an API. And further, what I also forgot to mention, it supports auto migrations, which is very nice in development. So if you add some attributes to your model, you just write sales lift and it automatically populates the database with those attributes. And right now, if you just start the server, it will actually ask me about that fact if I want to use auto migrate or if I don't want to do that because in production, you shouldn't use auto migrate. Otherwise, you might lose data. So actually, let's do alter. And as a default, sales uses their own database adapter, which is can compare to SQLite. It just draws a file on a database, but it works a bit like MongoDB. You don't have to define any attributes or anything. It just stores everything in there that you sent to it. So if we now go, I love playing around with ports slash user, you just see the empty JSON response since we have nothing in there. And what sales does as well, it gives you four development purposes. It provides you with a route that you can just create new models in the browser very easily. And yeah, let's just use the same thing that I've done beforehand. And here you just see like the response. So every model automatically has a created at an updated at field. You don't have to do anything for that. Let's just add a second one. Yeah, there we go. Oops, that is not what I wanted there. So if we now go back to our user route, you will see that there is, yeah, you see that they're both are in the database. And you could just, you know, switch it out with MongoDB or PostgreSQL or whatever and it would start in an actual database. So now if you've worked with emmer data before, you can see that this doesn't work with Emma chess. So the JSON structure looks a little bit different. And also the URL is a little bit different. So for that, there is two nice community projects. One is called sales emmer blueprints, which basically is the idea it modifies the server. So it returns the JSON exactly in a way that emmer data expected. Or the other way is doing it on the front end. There is a sales emmer data adapter, which you don't have to modify anything in the server. And emmer data just converts it the way it wants it to have. And this emmer data sales adapter also comes with a socket IO adapter. So there's also the real-time functionality built into emmer. So we have created a little starter kit, which you can access and play around with if you want to. So we've chosen the route of modifying the sales server to give us the JSON that emmer data expects with its default REST adapter. And just to give you a little introduction into the folder structure. So you've got the server. This is just what I've scaffolded out beforehand. Just the only thing different is you can see here there's a blueprints folder. And this basically overrides sales chest defaults with whatever defaults you want it to overwrite. And then we've got the client folder. So we've taken the approach of treating four developments, treating the client, the emmer client, completely separate from the server. So we've got the amazing features of using Ember CLI. And this is just a scaffolded out project from Ember CLI. So you will see in a second I will fire up the server. And so during development it basically treats the sales chest server as a third-party server. So at least in development you need to have cores enabled, like cross whatever it's called. Just, you know, you've seen an incident or action incident or whatever the word is. But then obviously for actual production you just build the app, emmer build. And then right now, and then basically serve it through the sales chest server. So right now this is the major weakness still with our app, with our starter kits. Right now you have to manually copy over the distance, you know, drop it in the sales chest assets folder. But yeah, we're working on automating that step as well. So this feels a bit better. Yeah, so to show you an action, there we go. I've created a little demo. So here we are just, so this is basically, let's just try it real quick. So here you just see that is basically emmer starter kits just cloned down like as it is. The only thing that I've done on the front end, I've basically coded a quick front end. But the server is exactly as it is if you would just do a clone so there doesn't exist any model, any controller or anything. So in this demo I basically want to show you like you have a front end but you don't have a back end and all you need to do is write one command and you can just, you know, like have the front end work together with the back end. So here we've got the clients just run an emmer server. This files up the server. Ignore the JS hint. So yeah, so we've got this running on localhost 4200. And yeah, we've got, it's just a simple sign up page basically. And so if you now just create a user. Comes there one, two, three, four and click register says not found because this is an error from this era. I'm just here. I'm just returning the default error seven even looked into creating any nice error messages or anything. But to get this working, you go back to the sales server. And all you have to write is sales generate API surgeon. We call our model surgeon. But the one thing that is wrong here. This URL just uses default URL, but you can actually change in the config to pluralize it and you can also give it a name space. So the URL would actually be slash API slash V1 slash surgeons, which is what emmer data expects if you also give it a name the same name space. So if you now register. Should work. Oh, yeah, starting the server. That is clever. There we go. And we're locked into the dashboard. Amazing. But just to show you that it actually is stored on the server. Let's just go quick on on the server itself. And if you just go to API V1, you know, surgeons, we don't want to use those surgeons. There's just some desk data that I created before. And you see here, that's indeed we've just created Thompson with a password of one, two, three, four. Very secure. That's what we want from from production ready applications. But yeah, that is basically it just, yeah, manages to sort of like get out of your way to just let you get started with developing your front end straight away and actually have a back end that you can very easily get into production. All you have to do is fill in the right attributes in your model file. And yeah, that's about it. So get back to the presentation. There we go. So here again, you see the URLs to the resources. So the first one is our starter kit, which you can just clone to get started right away. Then the second one is the one that we're using for our starter kits to just integrate sales with Amber. And the second one is what I've mentioned before. It's if you rather prefer to have, you know, like the front ends at here to the server. Or if you if you want to look into how to get soccer day or working with say stress, this is probably also a very good starting point since it already does it for you. But yeah, what's what's is still planned for the future. So says chess is compared to other frameworks like rails or even some PHP frameworks, relatively new and hence not as mature. But especially over the last half year or so, the user base has been growing. And yeah, there have been some some pretty amazing people doing some pretty amazing work. And you can really see I almost feel like this is sort of like Amber like before, like when it was in release candidates days or like when it was just about 1.0 times where people really start to get interested in it and really start to contribute to it. And yeah, so there is there is lots of different libraries that are coming. And yeah, we, as it says, we ourselves want to work on on even better integration of sales and emerges. We're planning on sending a pull request to sales to just give it a default command that you can just can just tell them like, hey, when you create a new project, you know, like created in in chasing API format. As Amber expects, so you don't even need like any custom adapter or anything anymore. And obviously, automating the process of of compiling or building your app and serving it through the sales chess server. That is the next big thing. Yeah, just to sum it up again. Yeah, sales embraces conventions as you're used to from Emerges or if you've used Rails before. It does all the work of creating the rest API for you. And hence it's just perfect to just get coded quickly and just, you know, get your app working. And yeah, if you use our starter kits, it plays very nicely with Amber. So yeah, that's that's about it. And if you want to have access to this presentation, it's available through this URL. And yeah, if you if you still have any questions afterwards, or you want to see about our experience putting an app into production with that stack, you can just talk to me afterwards or send me an email or send me a message on Twitter. And also, if you find any of that stuff exciting, we're always looking for developers. Just again, come talk to me or shoot us an email. Yeah, thank you. Are we seeing the death of the backend developer? That is a very good question. Now, I wouldn't say so. There, I think there's still various use cases. I mean, very important things for, I mean, wasn't the right choice of words, maybe, but still very important things for it. What I really like about the backend, you have it under control, you know, on what server you're putting it. And you don't know, you know, like what the client is doing, like what phone does he have, what server does he have. And so I think there's always, you know, you always need a server to do, you know, like some grant work to, you know, like do powerful calculations. Or in our app, we actually use Phantom Chess for PDF rendering. So we just created basically our PDF with handlebars and CSS and all that stuff. And then just used Phantom Chess to take a screenshot and brand it as a PDF. And you don't really want to do that on the front-end because, yeah, if someone comes with an Android, a five-year-old Android, maybe not five-year-old, but two-year-old Android would probably take like five minutes or something. But I feel more, I see it more as like a harmony, sort of. Like, yeah, as we saw, like, there's no barrier anymore between, or much smaller barrier between backend and front-end. It's almost, if you can do the one, it's very easy to get to the other. Yeah, that's the way I see it. Any other questions? Yes, in terms of further work, could you see, like, some kind of automatic mobile generation on both backend and front-end? Yeah, that would be something really cool. I've actually been thinking about that. Yeah, that would probably be sort of like an easier solution. What I'm wondering, or what I would find really cool is if you sort of have just one file, and then you can sort of define if you want the things on the server or on the client or in both. Because in some cases, you just, you know, you don't want your front-end, you know, to have certain secure data. But I think that would still be a long way to go to just have, like, one file. But I think that is a very good idea. And I might put this in our sort of, like, to-do list. But yeah, I mean, that is definitely possible. You just need to write some kind of generator. But yeah, very good idea. What was your reason for choosing the data that reverses the backend? What was your thought process there? Yeah, that was, again, sort of what I said before. I kind of liked the feeling of having things more under control. And I mean, I know that if you use a third-party API, you have to do, you know, like, modify the ember data standard on the front-end. But I kind of feel if I can do it on the back-end and just let ember use its default, I sort of, you know, like, have it on my server and have it more under control. I don't think there's really a logical reason, a big logical reason behind it. But that's sort of just how I personally see it. And I don't think there is one is, you know, much better than the other. More like a matter of preference. I guess the only one thing is now it's very easy to create a pull request to sales. Just tell them, you know, like, just give this option to use these plugins. And then you don't even have to do anything anymore. That might be the only thing, but apart from that, there isn't any preference, really. Anything else? Props the option. Yeah, I actually saw that. And I was like, I could use that, but then I have to learn something new. So I have to admit it was pure laziness that I didn't look into that. And I was like, I know how course works. I know that I can, but yeah, I've seen that. And when I have some free time at some point, I might try to implement that or look into that, how this compares. But yeah, it was just out of pure laziness reasons. And also because, yeah, I mean, all you have to make sure that, I mean, for that, that we put into production, the only thing that we had to make sure, since it's only an internal API, that we set course to false, like when you put it in production so that you can just do a post request from another server, which is just a simple environment setting. Any other questions?