No more magical webservices feat. ServiceStack
Daugaard Poulsen, Stefan
Getting tired of adding services via “Add service reference”? Annoyed by the fact that the configurations are so hidden and easy to forget? Wish you could be a little bit more in control of your service channels? Now there is the option to have it all solved, enter Service Stack, giving you the power back but doesn’t set you back to the days of the *.asmx. With Service Stack you get the power of controlling what should be flowing in your application, e.g. no more boxing to ObservableCollection just to push data over the web. This session will show you how easy it can be to regain power of your networking layer, and how little code it actually requires. With Service Stack you don’t actually have to spend much time worrying if you need to support other serializers, most frequent used are in the box. Last but not least, how easy RESTfull services can be.
 So, can anyone hear me? Yep. It's nice to see that more than two people turned up, so it's going to be fun. I'm here to talk about Service Stack and how many have heard about Service Stack or used Service Stack? So, around five or six people. That's great. I'm mostly doing this to inspire people and say there's other stuff than Web API or Nancy or whatever you want to use. So feel free to leave if you don't want to be inspired. Why I'm here? As you can see, I'm a developer at a company called Atia in Denmark and I'm pretty sure some of the Norwegian guys have heard about Atia, but it's an IT infrastructure and we're like four or five developers out of 1500 workers, so it's fun. I've done.NET development since 2002 and I think it was probably.NET 1 back then and did Silverlight last year with a lot of web services and as you can see, I kind of got caught in a discussion on Twitter around November. I might have made a mistake by saying that I didn't mind WCF. It was great. I had no problems with it. That pretty much went right back in my face later on. And I got annoyed by the RPC style you tend to do in WCF. And I assume you're all nerds, so you're probably going to like being here. It doesn't matter what you use or who you are. It's going to be fun. So what are the bad ideas for doing web services? If we look at the code generation, how many people have tried a WCF service adding it as a reference and the code just doesn't work? You get an external tool error, something, something, around half of you. And did it tell you how to solve it? No, absolutely not. And what happens when you change the service and update the reference, check in the code? What happens when the other developer actually did another method as well? Just blows right in your face and you have merge conflicts all over. That's some of the fun stuff. And then we have the archaic XML configuration. I think everybody can agree on that we should kill XML configurations as much as possible now. Yeah, as I said before with the mergers, I've actually seen a guy by mistake pushing stuff to a production server and it almost killed all the data in the server. So that was no fun. And then we have defaults. How many have been fighting defaults in WCF? Max objects and graph? Does it sound familiar? Or timeouts? And why do we have to go and set values? Why not use reasonable defaults? It's taken directly from Demi Bellard's words, the guy who primarily do all the coding on service stack, but have reasonable defaults. There's no need for us to go into these default configurations and overrides and so on. They should just be working. Fixed serialization. I haven't dug really deep into WCF if I could publish two serializations on the same endpoint, but wouldn't it be nice just to say, I want this to run JSON and by the way, if you can handle my XML and some other formats as well, that would be great. It would be awesome. I don't need to do new stuff if we get new developers. And the RPC style, it's a maintenance hell, as I said. And we have chatty services. It's not really a bad thing about WCF or any other framework. We should be bulking stuff instead of just pushing small method calls all the time. So that's some of the bad stuff. And as you can see, you've been burned before. Don't do it again. So what is this weird service stack thing? The official subtitle is, WebServices done right. Rest services done easy. Yeah, I remember that correctly. I'm not going to go into this huge rest debate today, hopefully not. But it's really, really easy to get up and running and do some rest services if you want. I'm going to show you how to later. Simple and model driven. If we put our models in a separate assembly, we can pretty much share it on the server and the client. We've done that in WCF as well. But this is the primary focus of service stack. Let's start with the model. Don't start off by generating weird stuff on the client side. End point ignorant. I was talking about these civilizations. You can pretty much get any format you like in service stack. It's IOC based. Everything should be IOC based these days. Easy access to HTTP. I'm going to share later on where we can pretty much just push HTTP codes or get stuff from the request and so on. It's in the box. Fast as lightning. I don't know if anybody heard about the Jason serializer from service stack. Yeah, a few of you have. At the moment, it's the fastest one. I'm going to come back with a graph later on so you can see the stats. It's amazing how fast it is. And I saw a guy called Mike Strobel the other night. He was tweeting to Demi Bill at about, I think I found a way to increase the speed by 25 to 33%. When you're the fastest and you're like somewhere between six and 30 times faster than the other ones, it's pretty impressive to find another 25%. Cross platform. Anybody running mono in here? A few guys. Awesome. You're going to like this. Oh, yeah, the clients are in the box. We don't generate any clients on the client side. We just use what's in service stack and use ways to grab data in that way. Yep. What's in the box? If you get the Nougat package called service stack, you're going to get the service stack text. You're going to get the common. That's pretty much what you need if you run on the client. And then you get the Redis and in a micro or M called or M light. That's in the box. I would have preferred this one. I don't see why I should get Redis and SQL light or the or M light into the default configuration. I really have no need for it. And it's just a pain to have assembly. You don't need. And then we're going to look at some code. That's going to be a lot of code. I hope you'll stay awake for it. And I'm probably going to do a lot of mistakes so you can point and laugh at me. Yep. We're going to start off by the eye service. Eye service is the basis of the service running in service stack. You can do your services directly from eye service. It's not recommended, but you can do it. If you go for the service basis that they've done some error handling for you, like wrapping it and putting it in a nice way and sending the right error codes from time to time. And you have the rest service base. It's pretty much which flavor do you like. Are you going to go for the single execute method or are you going to go for the rest way? And you can do other stuff as well. Yeah. And well, just in case you didn't notice, you can cut off an arm. It's really easy to do. But if you like your teddy bear like that, you can do it. But now let's look at some code. It's way more fun. I'm pretty sure. So I have my great solution here and I added some references. There's a lot of Winchester stuff and RavenDB, not important. But I pulled in service stack. And as you can see, it just pulled in the rest of it. That's actually quite easy to get going. As far as I remember, if you do it in an MBC project, it's going to set up some of the stuff I'm going to set up now automatically. But I decided to go on my own. So here we go. First of all, we need to register the correct handlers. As you can see, I have a location called API. And that's pretty much going to be a subfolder where I'm going to host my API. If you run the MBC project, it automatically puts it at an API. So I'm just going to create that, taking the slow road. So now we have the API folder. And that one should just go away. And then I have some stuff in my global ASACs. I'm going to come back in a minute when I've done the API host. You pretty much set up an app host space, as far as I remember, to run all this stuff in. You can hook up different stuff inside the app host. But just to tell you a short story, I've added some drinks to my RavenDB. I'm pretty sure everybody had a drink or two during the week. And what an obvious topic for the last session on a Friday. So it's going to push some drinks into my RavenDB. And then we'll be able to make some drink cards later on. Pretty much have a drink card with the name and type of drinks or the drinks. And then you'll find out if it's an evening card, noon card, or whatever it is. And there's a small trick you can do in Service Stack. How many know about the mini-profiler, Sam Saffron, and some other guy did? Or any other profiler you can run just pushing it? Or is it Glimpse, the other one? I think so. Well, support for mini-profiler, let's build in. Let's just leverage that. And then I have my API host. And then I'm going to push in an app host base. That's quite easy, but I get some stuff I don't want. That's a bit too much. Let's see. I have a... Where did that go? Yeah, in case you use another IOC, then the funk one that's built into Service Stack, you give it an adapter. So pretty much I'm getting my Windsor adapter. I have somewhere else. And I'm just going to say it was a container adapter, as far as I remember. Yep, and as I said, a lot of misspelling. Then we'll supply a service name. Could be drain... NDC, drink cart service. And then I have once an assembly as well. API host assembly. And then we want to do some configuration. That was pretty much most of the setup we need to do. But since I decided to put stuff in a subfolder, I need to do some set config as well. And I'm probably going to do this wrong. Let's see if I can remember which one it is. So much stuff to remember on this. So pretty much what I've done here is just set to a service stack host that I'm actually not hosting in the root directory. I'm hosted in the API folder. So the handle is set up for the API folder and service stack is now set for API folder as well. And that's pretty much it, except that it's not much fun doing web services without a service. So we're going to create a basic service as well. Let's see. We're going to create a drink service. Here we are. I could go for the iService if I wanted to. It would look like that. And I could say drink. Then I will get this. That's all nice. And I've actually got some services I need to refactor because I did the iService before actually read on upon the stuff, but legacy stuff, running in my private stuff so it doesn't really matter. If I wanted to expand this, I could actually do it. If I just wanted to support the get keyword from REST, I could just add a partial interface for it. Now what would happen if I call the service, if I did a post or anything like it, it would actually go for the execute method. If I do a get, it hits the get method. So you can actually have different flows in your service. That's pretty cool, but I'm not going to use this. This is just way too hard and I need to do error handling and so on. So we're going to delete that. And that's more fun. And you might have noticed that this time it's a run instead of an execute. Somehow I'm a bit split. It could have been the same. Just would have been easier to change it. But well, who cares? Now if I want to request a single drink, I could just do request drink ID. That was different from my GUI.empty. Then I could just, oh yeah, I know what I need. I'm running a RavenDB so I might want to get hold of my document session. And if somebody looks at my code later on and you see the registration for RavenDB, yes, it is wrong. I have the wrong lifestyles. So I just want to grab that single drink. So we'll do a drink. It's pretty easy. And then I can just return that drink if I want to. Usually, you end up having a drink response. Because wouldn't it be nice to just get the same response and if I get one in this list, well, I have one drink. If I have many, I have many. It's just easier to pack stuff up and do batch loading. So I'm going to return a new drink response. Yeah, like this. Go away. So now we have actually done our first service, but we kind of want an option to get all the drinks as well. So we're going to just add drinks. It's fun looking at me writing queries to RavenDB, right? And misspelling. So, a new drink response. So that was pretty much it for our service. As you can see, it's pretty easy to do a web service and service stack. It doesn't really require much code of you, and that's pretty much it. One thing you need to do before you get it up and running, you need to add a route as well or route or however you want to say it today. And that is most often for me done in the app host base. You can decorate your DTOs, but I don't like decorating my DTOs for service stack when they're in a different assembly. That just seems so wrong for me, and somehow I don't like putting attributes everywhere. So I'm going to add a drink, and that would be most likely be drinks. So now we could get the drinks, but we kind of wanted the option to get a drink, a single drink as well. So we're going to add another one, and we can do drinks, and hit something wrong. And do the ID. Does that seem familiar when we're talking about RESTs? I hope so. And hopefully everything builds and runs. Yep, it's succeeded. That's fun. One of the awesome things about service stack is that it's actually quite intelligent, because it's going to look at my code now and generate a meta page for me at some point if I did it right. Oh, yeah. It doesn't matter how many app hosts you do if you don't actually start it up. Minor defect. Yep. So now we should have a service. Except I come to stuff out in my installer as well. Now this is fun. How many did come to see me fail? Awesome. A few guys. At least you're awake. I'm going to put my container. I'm going to eat the service. Sorry for that. We ever got the ES blown out. Those familiar with Castle Winter would notice that I'm just pulling a lot of stuff in everything that matches and I service will get into this and spun up. So that's quite nice. And it should be able to run now. Anybody else have a laptop without an SSD? This is quite nice page we got from service stack. We can actually see we have operations on drinks. And we can actually look at the bottom and see in case we want to hand this off to someone else and they don't want to use service stack, we can supply them with SSDs and whistles. It's quite easy. I actually tried it the other night. I don't know why but I did. And then we have the options of the different formances up here. So here you can see pretty much I registered for all works on drinks and drinks ID. And you pretty much have a small example on how am I going to use this. But there's another cool thing about it. What if I try to go for that URL? Awesome. I have an empty database for some odd reason. That's weird. I should have some stuff. Let's just take a peek at this. If anybody spots my mistake please say so. I would guess that I needed to do this to a list because I'm pretty sure that Revenby doesn't like this. Or service stack doesn't like this. We'll see some drinks. Nope. Drinks are gone. My if condition? Is it the other way around? No, I don't want to hit that one. I pretty much want this. And this one. I'm actually doing the regular get. So I just want to get all the drinks. I didn't supply an ID. This was fun. Why did I decide to go for live coding? Ah, no drinks. Oh, I didn't do the app start because I didn't restart my application. I decided to go and clear my complete Revenby database before I went in here. So all the stuff being run from the server, it's pretty much not being run. Let's move this. And we should be able to season drinks, hopefully. Nope. Who ate my drinks? Pretty sure that I added some drinks. Hmm. This is going to be fun showing off drinks when I have none. Let's see. Yeah, created my Revenby. Should be okay. Let's see. Now, isn't it fun looking at people messing up? Give me a break. Yeah, yeah, I know. So let's see if we're lucky this time. We see a button in the database. That's a good start. That's actually quite a good question. Hmm. I'm pretty sure it wasn't this way last night. Let's see. So this is how to completely fail your demo. Anybody remember if you can actually do breakpoints in global ASX? Or did I just change the run code last night? We might have done. I think I know why. So pretty much it should insert some drinks now. Nope. So who killed my code last night? Is this in store? So can anybody see any Revenby errors? What? Clever man. I talked to the Revenby guys the other night and they pretty much convinced me that I should stop using repositories. So this is what happens when you throw away your repositories. So, well spotted. I'm not just nerve-wracking anymore. We might have drinks in a moment. I just killed it. It should be there now. Yep, there it is. Just going to remove that and that. And we are going to get... Yay! Drinks for everyone. So just to make sure that we could actually get a single drink. I'm just going to paste that so it's as easy as that. But that was drinks we were meant to do like a drink card. And that should be fairly easy to do. Since I'm a really lazy bastard, I'm going to take full advantage of using resharper. And I'm going to do a wrist service base and drink card. So that's fun. If you get ticks from me tapping around, just raise your hand. So, I only want to handle on git in the first run. I might want to do some put as well. It's going to be hard to get new cards into the system. Post. This is pretty much what we need to do. As you can see, I don't have to set up all the different types of keywords or verbs. I can just go along as I need to. I could have done it the other way around as well with the eye service and just adding these separate words. There's a lot of options and do whatever fits. If we get a request with an ID, it's always nice doing ID stuff. Go to empty. Then I would like to get a drink card. Somehow I have a tendency of missing Raven the Beast off today. It's funny listening to me when I'm silent. Just going to return the drink card. That's fine. We want to just grab all drinks, cards, not crats. Excuse me for my ADD. I can't do misspelled stuff and just doesn't work for me. What the hell am I misspelling? What? Oh, in. I wouldn't think that you would remember that. Card. Select DC. It's nice to have people correcting me. Come on. Be nice. Memorized clone. Why would I do that? So everybody's heavy. We got drink cards as well. It's not going to be much fun if we don't add them. We're just going to grab and say decision store. I'm pretty sure if I've done my fallback to my demo I had in my repo, it would have been failing in the same places. I could say return new HTTP request results. I want to try that. I can pretty much do like this and wrap it inside an HTTP result. But if I wanted to give it a specific HTTP code, I could do that as well. How is it? Status code. And I could say create it. That's some of the options. But the client on the other side would actually accept this and just say, oh, you just send me some extra stuff and I'm just going to grab the drink cards or the single drink card I got. So that's pretty much what we need to run our drink service. And we need to, of course, add the routes as well. So if we go to the card. I wish we pretty much have everything. And as we will see, it should just add another option to our major page in a moment. And all of a sudden we got drink cards as well. And if you look in the output you would see somewhere up here. I think I forgot to add the log manager. But actually when it starts hooking up the services you would get a log entry saying, I just registered this service. So you can actually just see that it does it correctly. And of course we can do stuff like drink cards. And nothing comes, of course. As you see, the profile is running in the upper right corner. It's nice to have. I'm just going to add a logger. So log manager. It tends to be a bit confusing when you have two classes being the same thing. I don't know how many times I've been adding the in-log instead of the actual service stack log manager. And I could say, Nero, do I have an in-log? Yeah, no, that's the wrong one. I knew it in-log factory. It's nice and confusing to have several stuff. Really? No. Stop doing this to me. Did I lose my logging? Yeah, so apparently I forgot to pull my service stack in-log. Oh well, who needs logging anyways? So we could have had logging. So I hope you're okay without logging. And if we wanted to use this great API we just did for drinks, I made a small really, really stupid console app. Somehow everything should be in the terminal these days, so why not do a drink cart manager in the terminal as well? And as you can see, I'm setting up the URL for it. That's quite simple. Of course, we need to know where our API is. And then you just can do a JSON service client. If I go fastly to my slide. Yep, let's see here. So you have all sorts of clients. You have the service client and you have the rest client and the rest async client. Of course, it doesn't really make sense to push the rest clients on the service client, but you can have a service client, rest client, and rest client async for the rest of the stuff. And as I said before, you can actually do the whistle way if you want to do it. We'll just go through this again. The first thing I want to do is of course grab all my drinks. How much fun is it creating a drink cart if you don't know what the drinks are? So I pretty much grabbed the list and I'll put it later on. So this is just like basic crotch stuff, adding things. And in the end, we're going to do a post to our drink cart service and just say, hey, here's some drink carts. Have fun. Get drunk. And I'm just going to run this and create a short small drink cart. Oh, Jesus Christ. Somehow I managed to remember my fun sizes and so on, but not in a nice way for you. So new cart. It's always nice to have new cart somewhere. And it's the afternoon, right? Or are we going for evening? So we have the list of drinks. We can see that pulled the drinks directly from the service. We might want a white Russian. We want a Long Island IST in Manhattan. And somehow that didn't work. We were supposed to see the right results, but the quick reader might notice that I actually did this wrong because I just returned the drink cart. I didn't wrap it inside my drink cart response. So actually I'm a bitch stuck right now and I need to add my drink cart response, which should be fairly fast to do. Cards. The way service stack handles this when it gets to the response, I say I'm saying like, if you look at this right here, I expected a drink cart response. It will actually try to serialize the response into the drink cart response. But if you try to use it, you would get an awful exception with like, ah, I can't deserialize this. It seems wrong. It's just weird. But it doesn't really just flip upside down and pukes all over the place. It didn't have that many drinks. Yeah, I don't care about the type. How many is annoyed by the automatic typing stuff? And we need to do this as well. Cards, new. Ah, both of them. What am I missing? Ah, yeah. There we are. Yeah, have fun with all the curly braces. Let me just check everything works. As you can see again, it's great not having an SSD. So we actually did put the cart into the stomach of the RavenDB, and we would have gotten this back again, and I could have shown you the JSON. I'm not going to create another one, just, it's just lame doing another one right now. Then we have a lot of extension points for service stack, which is actually quite fun. I talked about the logging. You pretty much set the log factory on it, and how fun wouldn't it be if we could like, do our own custom format? I have prepared a small custom format. If you want your own content type, why don't just do an x-drink card and say it's text. I added the serialize to stream, but I kind of skipped the deserialize, because I don't really care about deserializing these. Yeah. Now you're reusing the types on the server and the file. Yep. Do you have to do that? I would recommend that you reuse your types, because it's just easier to maintain the types. There's no need to have other types, but you could have other types on the client, as long as they serialize to something it matches in the other end. It's possible. You could send raw JSON as well if you want. I just like working with objects. We have a custom serializer here, and the way you could add it was like this. You can see the drink card formator. What you can see is it's going to show up with another drink, another formator in this list as well. It's actually quite nice that it looks at which formators do I have, and here are the options. As you can see in the middle, right here, we have the drink card now. It's quite fancy. We could actually use it right away. If you want to see it drink card formatted in a really weird way. Yes, I accepted. This is our custom formatting. It's really that easy. Just go along, do your own business. That was one of the fun parts doing. What if I wanted to remove some stuff? I could actually do that as well. Let's see. Pretty sure I'm grabbing the wrong thing here. Yes, I thought so. Wrong place. Enable features. They were so nice that they actually added features all. When you want to remove stuff, you go features all, and you pretty much just say that you want to remove a single thing. That could be like whatever. We could remove the XML. If you're really quick, you could notice that it supports protocol buffers as well. How many have ever heard about protocol buffers? Nice. It's a way, as far as I remember, it's optimizing the payload you send over the wire. It's awesome if you need really, really small segments or a lot of compressed data. Now we should see XML disappearing. Hopefully. Maybe. Come on. Faster. Magic. Yay. That wasn't a good demo. Ah, CSV. Not XML. Notice if CSV was gone. Ah, this, yeah. I don't know who uses CSV for serializing. It seems weird. We could do request filtering as well if we wanted to do statistics on our website. We have the option of going to request filters and say just saying add, and we could do requests, response. And then we just go along and do whatever we wanted to do, because we have access directly to the, we could like track the user agent. We just grab it right off every request and we can do it the same on the response as well. So there's a lot of hook points and you can actually just do whatever you like. So it's nice that it's just plain simple when it comes out of the box, but if you really want to do wicked stuff, you could just go do it. I don't know if wicked is the right term to use, but that's how it is right now. And then I have some more fantastic slides. So we talked about the clients and you can pretty much switch to another client if you just wanted to serialize the other way. You don't have to do anything on the server. If I wanted to change my JSON service client, I could just do it and say, I want the GSV service client. So that's pretty nice that I can just switch to whatever client I like. I think it's pretty handy from time to time. And then it's a freaking Swiss Army knife. And why is it a Swiss Army knife? Well, we have a lot of options. Hmm, I think that's a bit like long list of SQL service supported, but it's really, really nice that you can just grab another NuGet package and you have it in the box. So it supports all these. And if you want authentication besides the built-in ones, the built-in ones are, as far as I remember, basic and some other authorization stuff. And they have Twitter and Facebook authentication. Why would I need that on my web services? I don't get it. If somebody knows why, please come and tell me afterwards. And I think it was Monday or last week, they added the N-hybernate to the authentication plan. And if you want to do caching in the box comes, of course, the RITIS. And it has memory client, file client, file and XML disk written client, whoever wants to use disk cache. Or you can just grab Azure or memcached. And of course, protocol officers support it. It was in the list of options, but it's an add-on you grab on later. And of course, it supports logging. My favorite is N-Log, but if you want to run Log for NET, and yes, it does exist in a strong signed and a non-strong signed for those who cares. And you have Elma and EventLog, of course. Yay, you can sleep in it and you can eat it. And of course, as I said, if you have the need for speed, this is going to be awesome. If we take a short look, we see Jason.net here. He actually did a complete performance release, but apparently he didn't beat him. And way over here, we have service stack doing this text. And if you look at it, going from JROC or JavaScript serializer to this, that's going to do a really, really huge impact on your serialization. And imagine if they can cut even 25% more of it. That's going to be awesome. And it's cross-platform. There was a few Linux guys or Mac or whatever you're doing. It supports asp.net, HTTP listener-based. And as you can see, if you have a really, really old server, that's not a problem. Just third-eyed. I was running the demos of my IIS Express. And in my production code, I actually have a Windows service hosting my API. So there's a lot of options if you need it. And that's all the... I was about to say weird Linux and OSX stuff, but I might sound wrong. But if anybody knows about this stuff, I'm pretty sure you would not and say, this is okay, this works, this is what we're doing. And there's a small surprise in the end, because how many would like to see service stack running on an IOS device? They actually did a demo where they ran Monotouch. I don't know why on Earth I would host web services inside an IOS app, but apparently somebody liked it. So we can fly. Yay! Where can you find more stuff about this? If you go to the source, you can grab whatever you need. It's right there on GitHub. And you can find a lot of help in the Vika pages. And you have a docs section as well. It's a bit split. I think the Vika pages are more up-to-date than the docs pages. And the docs pages are mostly about extension points or other plugins they have. And then we start wondering, would we actually use service stack in the production environment? As I've already said, I'm running it as a Windows service. And it's going to be quite good. We're going to do a production release by the end of this month. And it's not like some kid in Texas just sitting along, drinking Coke, having a pizza and just doing some random stuff. It's actually quite old. As you can see, the first commit was done in 2008. So it's not a new product. It's actually quite old. The first version didn't look like it at all. And in case you didn't read it yet, yes, DemiBillard works for Stack Exchange. I'm pretty sure he's a valid guy for this stuff. If you don't trust him, I'm willing to send him an email saying people don't trust him. And it's quite well maintained. Actually, when I did my code last week, I was running 3.7.9 or something like that. And I did the, you're about to fail speaker because I updated my assemblies this morning. And as you can see, there's coming a lot of commits and it's really nice. There's always a new commit. And that was pretty much everything I have to tell you today. If anybody has questions, I'll try to answer them the best I can. Also, I'll let you leave early for your flight or your train or your car or drinks or whatever you like to do. And I would like to give a shout out to the Code 52 guys. You should check out the projects. It's a fun place. A lot of new stuff going on. Anybody have any questions? None? It does support all weird kinds of authentication if you want to dig into that at some point. You have a question? Awesome. How does it handle SSL yet or no? The question is if it handles SSL yet. It was actually one of the first things I started looking at and it turns out a bit weird. It's not in a box story because you need to do some registrations because it doesn't really handle SSL. You do a lot of wicked, nasty command line tools and whoopty. You have SSL support. It is supported. You can do it. But it's actually not something in service that handles it. Anybody else? I think we'll say that's it. Thank you for coming. It's quite nice to see so many people showing up even though it's the last session of the day. Thank you very much for coming. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
 So, can anyone hear me?  Yep.  It's nice to see that more than two people turned up, so it's going to be fun.  I'm here to talk about Service Stack and how many have heard about Service Stack or used  Service Stack?  So, around five or six people.  That's great.  I'm mostly doing this to inspire people and say there's other stuff than Web API or Nancy  or whatever you want to use.  So feel free to leave if you don't want to be inspired.  Why I'm here?  As you can see, I'm a developer at a company called Atia in Denmark and I'm pretty sure  some of the Norwegian guys have heard about Atia, but it's an IT infrastructure and we're  like four or five developers out of 1500 workers, so it's fun.  I've done.NET development since 2002 and I think it was probably.NET 1 back then and  did Silverlight last year with a lot of web services and as you can see, I kind of got  caught in a discussion on Twitter around November.  I might have made a mistake by saying that I didn't mind WCF.  It was great.  I had no problems with it.  That pretty much went right back in my face later on.  And I got annoyed by the RPC style you tend to do in WCF.  And I assume you're all nerds, so you're probably going to like being here.  It doesn't matter what you use or who you are.  It's going to be fun.  So what are the bad ideas for doing web services?  If we look at the code generation, how many people have tried a WCF service adding it as  a reference and the code just doesn't work?  You get an external tool error, something, something, around half of you.  And did it tell you how to solve it?  No, absolutely not.  And what happens when you change the service and update the reference, check in the code?  What happens when the other developer actually did another method as well?  Just blows right in your face and you have merge conflicts all over.  That's some of the fun stuff.  And then we have the archaic XML configuration.  I think everybody can agree on that we should kill XML configurations as much as possible  now.  Yeah, as I said before with the mergers, I've actually seen a guy by mistake pushing stuff  to a production server and it almost killed all the data in the server.  So that was no fun.  And then we have defaults.  How many have been fighting defaults in WCF?  Max objects and graph?  Does it sound familiar?  Or timeouts?  And why do we have to go and set values?  Why not use reasonable defaults?  It's taken directly from Demi Bellard's words, the guy who primarily do all the coding on  service stack, but have reasonable defaults.  There's no need for us to go into these default configurations and overrides and so on.  They should just be working.  Fixed serialization.  I haven't dug really deep into WCF if I could publish two serializations on the same endpoint,  but wouldn't it be nice just to say, I want this to run JSON and by the way, if you can  handle my XML and some other formats as well, that would be great.  It would be awesome.  I don't need to do new stuff if we get new developers.  And the RPC style, it's a maintenance hell, as I said.  And we have chatty services.  It's not really a bad thing about WCF or any other framework.  We should be bulking stuff instead of just pushing small method calls all the time.  So that's some of the bad stuff.  And as you can see, you've been burned before.  Don't do it again.  So what is this weird service stack thing?  The official subtitle is, WebServices done right.  Rest services done easy.  Yeah, I remember that correctly.  I'm not going to go into this huge rest debate today, hopefully not.  But it's really, really easy to get up and running and do some rest services if you want.  I'm going to show you how to later.  Simple and model driven.  If we put our models in a separate assembly, we can pretty much share it on the server  and the client.  We've done that in WCF as well.  But this is the primary focus of service stack.  Let's start with the model.  Don't start off by generating weird stuff on the client side.  End point ignorant.  I was talking about these civilizations.  You can pretty much get any format you like in service stack.  It's IOC based.  Everything should be IOC based these days.  Easy access to HTTP.  I'm going to share later on where we can pretty much just push HTTP codes or get stuff from  the request and so on.  It's in the box.  Fast as lightning.  I don't know if anybody heard about the Jason serializer from service stack.  Yeah, a few of you have.  At the moment, it's the fastest one.  I'm going to come back with a graph later on so you can see the stats.  It's amazing how fast it is.  And I saw a guy called Mike Strobel the other night.  He was tweeting to Demi Bill at about, I think I found a way to increase the speed by 25  to 33%.  When you're the fastest and you're like somewhere between six and 30 times faster than the other  ones, it's pretty impressive to find another 25%.  Cross platform.  Anybody running mono in here?  A few guys.  Awesome.  You're going to like this.  Oh, yeah, the clients are in the box.  We don't generate any clients on the client side.  We just use what's in service stack and use ways to grab data in that way.  Yep.  What's in the box?  If you get the Nougat package called service stack, you're going to get the service stack  text.  You're going to get the common.  That's pretty much what you need if you run on the client.  And then you get the Redis and in a micro or M called or M light.  That's in the box.  I would have preferred this one.  I don't see why I should get Redis and SQL light or the or M light into the default configuration.  I really have no need for it.  And it's just a pain to have assembly.  You don't need.  And then we're going to look at some code.  That's going to be a lot of code.  I hope you'll stay awake for it.  And I'm probably going to do a lot of mistakes so you can point and laugh at me.  Yep.  We're going to start off by the eye service.  Eye service is the basis of the service running in service stack.  You can do your services directly from eye service.  It's not recommended, but you can do it.  If you go for the service basis that they've done some error handling for you, like wrapping  it and putting it in a nice way and sending the right error codes from time to time.  And you have the rest service base.  It's pretty much which flavor do you like.  Are you going to go for the single execute method or are you going to go for the rest  way?  And you can do other stuff as well.  Yeah.  And well, just in case you didn't notice, you can cut off an arm.  It's really easy to do.  But if you like your teddy bear like that, you can do it.  But now let's look at some code.  It's way more fun.  I'm pretty sure.  So I have my great solution here and I added some references.  There's a lot of Winchester stuff and RavenDB, not important.  But I pulled in service stack.  And as you can see, it just pulled in the rest of it.  That's actually quite easy to get going.  As far as I remember, if you do it in an MBC project, it's going to set up some of the  stuff I'm going to set up now automatically.  But I decided to go on my own.  So here we go.  First of all, we need to register the correct handlers.  As you can see, I have a location called API.  And that's pretty much going to be a subfolder where I'm going to host my API.  If you run the MBC project, it automatically puts it at an API.  So I'm just going to create that, taking the slow road.  So now we have the API folder.  And that one should just go away.  And then I have some stuff in my global ASACs.  I'm going to come back in a minute when I've done the API host.  You pretty much set up an app host space, as far as I remember, to run all this stuff  in.  You can hook up different stuff inside the app host.  But just to tell you a short story, I've added some drinks to my RavenDB.  I'm pretty sure everybody had a drink or two during the week.  And what an obvious topic for the last session on a Friday.  So it's going to push some drinks into my RavenDB.  And then we'll be able to make some drink cards later on.  Pretty much have a drink card with the name and type of drinks or the drinks.  And then you'll find out if it's an evening card, noon card, or whatever it is.  And there's a small trick you can do in Service Stack.  How many know about the mini-profiler, Sam Saffron, and some other guy did?  Or any other profiler you can run just pushing it?  Or is it Glimpse, the other one?  I think so.  Well, support for mini-profiler, let's build in.  Let's just leverage that.  And then I have my API host.  And then I'm going to push in an app host base.  That's quite easy, but I get some stuff I don't want.  That's a bit too much.  Let's see.  I have a...  Where did that go?  Yeah, in case you use another IOC, then the funk one that's built into Service Stack,  you give it an adapter.  So pretty much I'm getting my Windsor adapter.  I have somewhere else.  And I'm just going to say it was a container adapter, as far as I remember.  Yep, and as I said, a lot of misspelling.  Then we'll supply a service name.  Could be drain...  NDC, drink cart service.  And then I have once an assembly as well.  API host assembly.  And then we want to do some configuration.  That was pretty much most of the setup we need to do.  But since I decided to put stuff in a subfolder, I need to do some set config as well.  And I'm probably going to do this wrong.  Let's see if I can remember which one it is.  So much stuff to remember on this.  So pretty much what I've done here is just set to a service stack host that I'm actually  not hosting in the root directory.  I'm hosted in the API folder.  So the handle is set up for the API folder and service stack is now set for API folder  as well.  And that's pretty much it, except that it's not much fun doing web services without a  service.  So we're going to create a basic service as well.  Let's see.  We're going to create a drink service.  Here we are.  I could go for the iService if I wanted to.  It would look like that.  And I could say drink.  Then I will get this.  That's all nice.  And I've actually got some services I need to refactor because I did the iService before  actually read on upon the stuff, but legacy stuff, running in my private stuff so it doesn't  really matter.  If I wanted to expand this, I could actually do it.  If I just wanted to support the get keyword from REST, I could just add a partial interface  for it.  Now what would happen if I call the service, if I did a post or anything like it, it would  actually go for the execute method.  If I do a get, it hits the get method.  So you can actually have different flows in your service.  That's pretty cool, but I'm not going to use this.  This is just way too hard and I need to do error handling and so on.  So we're going to delete that.  And that's more fun.  And you might have noticed that this time it's a run instead of an execute.  Somehow I'm a bit split.  It could have been the same.  Just would have been easier to change it.  But well, who cares?  Now if I want to request a single drink, I could just do request drink ID.  That was different from my GUI.empty.  Then I could just, oh yeah, I know what I need.  I'm running a RavenDB so I might want to get hold of my document session.  And if somebody looks at my code later on and you see the registration for RavenDB, yes,  it is wrong.  I have the wrong lifestyles.  So I just want to grab that single drink.  So we'll do a drink.  It's pretty easy.  And then I can just return that drink if I want to.  Usually, you end up having a drink response.  Because wouldn't it be nice to just get the same response and if I get one in this list,  well, I have one drink.  If I have many, I have many.  It's just easier to pack stuff up and do batch loading.  So I'm going to return a new drink response.  Yeah, like this.  Go away.  So now we have actually done our first service, but we kind of want an option to get all the  drinks as well.  So we're going to just add drinks.  It's fun looking at me writing queries to RavenDB, right?  And misspelling.  So, a new drink response.  So that was pretty much it for our service.  As you can see, it's pretty easy to do a web service and service stack.  It doesn't really require much code of you, and that's pretty much it.  One thing you need to do before you get it up and running, you need to add a route as  well or route or however you want to say it today.  And that is most often for me done in the app host base.  You can decorate your DTOs, but I don't like decorating my DTOs for service stack when they're  in a different assembly.  That just seems so wrong for me, and somehow I don't like putting attributes everywhere.  So I'm going to add a drink, and that would be most likely be drinks.  So now we could get the drinks, but we kind of wanted the option to get a drink, a single  drink as well.  So we're going to add another one, and we can do drinks, and hit something wrong.  And do the ID.  Does that seem familiar when we're talking about RESTs?  I hope so.  And hopefully everything builds and runs.  Yep, it's succeeded.  That's fun.  One of the awesome things about service stack is that it's actually quite intelligent,  because it's going to look at my code now and generate a meta page for me at some point  if I did it right.  Oh, yeah.  It doesn't matter how many app hosts you do if you don't actually start it up.  Minor defect.  Yep.  So now we should have a service.  Except I come to stuff out in my installer as well.  Now this is fun.  How many did come to see me fail?  Awesome.  A few guys.  At least you're awake.  I'm going to put my container.  I'm going to eat the service.  Sorry for that.  We ever got the ES blown out.  Those familiar with Castle Winter would notice that I'm just pulling a lot of stuff in everything  that matches and I service will get into this and spun up.  So that's quite nice.  And it should be able to run now.  Anybody else have a laptop without an SSD?  This is quite nice page we got from service stack.  We can actually see we have operations on drinks.  And we can actually look at the bottom and see in case we want to hand this off to someone  else and they don't want to use service stack, we can supply them with SSDs and whistles.  It's quite easy.  I actually tried it the other night.  I don't know why but I did.  And then we have the options of the different formances up here.  So here you can see pretty much I registered for all works on drinks and drinks ID.  And you pretty much have a small example on how am I going to use this.  But there's another cool thing about it.  What if I try to go for that URL?  Awesome.  I have an empty database for some odd reason.  That's weird.  I should have some stuff.  Let's just take a peek at this.  If anybody spots my mistake please say so.  I would guess that I needed to do this to a list because I'm pretty sure that Revenby  doesn't like this.  Or service stack doesn't like this.  We'll see some drinks.  Nope.  Drinks are gone.  My if condition?  Is it the other way around?  No, I don't want to hit that one.  I pretty much want this.  And this one.  I'm actually doing the regular get.  So I just want to get all the drinks.  I didn't supply an ID.  This was fun.  Why did I decide to go for live coding?  Ah, no drinks.  Oh, I didn't do the app start because I didn't restart my application.  I decided to go and clear my complete Revenby database before I went in here.  So all the stuff being run from the server, it's pretty much not being run.  Let's move this.  And we should be able to season drinks, hopefully.  Nope.  Who ate my drinks?  Pretty sure that I added some drinks.  Hmm.  This is going to be fun showing off drinks when I have none.  Let's see.  Yeah, created my Revenby.  Should be okay.  Let's see.  Now, isn't it fun looking at people messing up?  Give me a break.  Yeah, yeah, I know.  So let's see if we're lucky this time.  We see a button in the database.  That's a good start.  That's actually quite a good question.  Hmm.  I'm pretty sure it wasn't this way last night.  Let's see.  So this is how to completely fail your demo.  Anybody remember if you can actually do breakpoints in global ASX?  Or did I just change the run code last night?  We might have done.  I think I know why.  So pretty much it should insert some drinks now.  Nope.  So who killed my code last night?  Is this in store?  So can anybody see any Revenby errors?  What?  Clever man.  I talked to the Revenby guys the other night and they pretty much convinced me that I should stop using repositories.  So this is what happens when you throw away your repositories.  So, well spotted.  I'm not just nerve-wracking anymore.  We might have drinks in a moment.  I just killed it.  It should be there now.  Yep, there it is.  Just going to remove that and that.  And we are going to get...  Yay!  Drinks for everyone.  So just to make sure that we could actually get a single drink.  I'm just going to paste that so it's as easy as that.  But that was drinks we were meant to do like a drink card.  And that should be fairly easy to do.  Since I'm a really lazy bastard, I'm going to take full advantage of using resharper.  And I'm going to do a wrist service base and drink card.  So that's fun.  If you get ticks from me tapping around, just raise your hand.  So, I only want to handle on git in the first run.  I might want to do some put as well.  It's going to be hard to get new cards into the system.  Post.  This is pretty much what we need to do.  As you can see, I don't have to set up all the different types of keywords or verbs.  I can just go along as I need to.  I could have done it the other way around as well with the eye service and just adding these separate words.  There's a lot of options and do whatever fits.  If we get a request with an ID, it's always nice doing ID stuff.  Go to empty.  Then I would like to get a drink card.  Somehow I have a tendency of missing Raven the Beast off today.  It's funny listening to me when I'm silent.  Just going to return the drink card.  That's fine. We want to just grab all drinks, cards, not crats.  Excuse me for my ADD. I can't do misspelled stuff and just doesn't work for me.  What the hell am I misspelling?  What? Oh, in.  I wouldn't think that you would remember that.  Card.  Select DC.  It's nice to have people correcting me.  Come on. Be nice.  Memorized clone. Why would I do that?  So everybody's heavy. We got drink cards as well.  It's not going to be much fun if we don't add them.  We're just going to grab and say decision store.  I'm pretty sure if I've done my fallback to my demo I had in my repo,  it would have been failing in the same places.  I could say return new HTTP request results.  I want to try that.  I can pretty much do like this and wrap it inside an HTTP result.  But if I wanted to give it a specific HTTP code, I could do that as well.  How is it? Status code.  And I could say create it.  That's some of the options.  But the client on the other side would actually accept this and just say,  oh, you just send me some extra stuff and I'm just going to grab the drink cards  or the single drink card I got.  So that's pretty much what we need to run our drink service.  And we need to, of course, add the routes as well.  So if we go to the card.  I wish we pretty much have everything.  And as we will see, it should just add another option to our major page in a moment.  And all of a sudden we got drink cards as well.  And if you look in the output you would see somewhere up here.  I think I forgot to add the log manager.  But actually when it starts hooking up the services you would get a log entry saying,  I just registered this service.  So you can actually just see that it does it correctly.  And of course we can do stuff like drink cards.  And nothing comes, of course.  As you see, the profile is running in the upper right corner.  It's nice to have.  I'm just going to add a logger.  So log manager.  It tends to be a bit confusing when you have two classes being the same thing.  I don't know how many times I've been adding the in-log instead of the actual service stack log manager.  And I could say, Nero, do I have an in-log?  Yeah, no, that's the wrong one.  I knew it in-log factory.  It's nice and confusing to have several stuff.  Really?  No.  Stop doing this to me.  Did I lose my logging?  Yeah, so apparently I forgot to pull my service stack in-log.  Oh well, who needs logging anyways?  So we could have had logging.  So I hope you're okay without logging.  And if we wanted to use this great API we just did for drinks,  I made a small really, really stupid console app.  Somehow everything should be in the terminal these days,  so why not do a drink cart manager in the terminal as well?  And as you can see, I'm setting up the URL for it.  That's quite simple.  Of course, we need to know where our API is.  And then you just can do a JSON service client.  If I go fastly to my slide.  Yep, let's see here.  So you have all sorts of clients.  You have the service client and you have the rest client  and the rest async client.  Of course, it doesn't really make sense to push the rest clients  on the service client,  but you can have a service client, rest client,  and rest client async for the rest of the stuff.  And as I said before, you can actually do the whistle way  if you want to do it.  We'll just go through this again.  The first thing I want to do is of course grab all my drinks.  How much fun is it creating a drink cart  if you don't know what the drinks are?  So I pretty much grabbed the list and I'll put it later on.  So this is just like basic crotch stuff, adding things.  And in the end, we're going to do a post to our drink cart service  and just say, hey, here's some drink carts.  Have fun. Get drunk.  And I'm just going to run this and create a short small drink cart.  Oh, Jesus Christ.  Somehow I managed to remember my fun sizes and so on,  but not in a nice way for you.  So new cart.  It's always nice to have new cart somewhere.  And it's the afternoon, right?  Or are we going for evening?  So we have the list of drinks.  We can see that pulled the drinks directly from the service.  We might want a white Russian.  We want a Long Island IST in Manhattan.  And somehow that didn't work.  We were supposed to see the right results,  but the quick reader might notice that I actually did this wrong  because I just returned the drink cart.  I didn't wrap it inside my drink cart response.  So actually I'm a bitch stuck right now  and I need to add my drink cart response,  which should be fairly fast to do.  Cards.  The way service stack handles this when it gets to the response,  I say I'm saying like, if you look at this right here,  I expected a drink cart response.  It will actually try to serialize the response into the drink cart response.  But if you try to use it, you would get an awful exception with like,  ah, I can't deserialize this.  It seems wrong.  It's just weird.  But it doesn't really just flip upside down and pukes all over the place.  It didn't have that many drinks.  Yeah, I don't care about the type.  How many is annoyed by the automatic typing stuff?  And we need to do this as well.  Cards, new.  Ah, both of them.  What am I missing?  Ah, yeah.  There we are.  Yeah, have fun with all the curly braces.  Let me just check everything works.  As you can see again, it's great not having an SSD.  So we actually did put the cart into the stomach of the RavenDB,  and we would have gotten this back again,  and I could have shown you the JSON.  I'm not going to create another one, just, it's just lame doing another one right now.  Then we have a lot of extension points for service stack,  which is actually quite fun.  I talked about the logging.  You pretty much set the log factory on it,  and how fun wouldn't it be if we could like, do our own custom format?  I have prepared a small custom format.  If you want your own content type,  why don't just do an x-drink card and say it's text.  I added the serialize to stream,  but I kind of skipped the deserialize,  because I don't really care about deserializing these.  Yeah.  Now you're reusing the types on the server and the file.  Yep.  Do you have to do that?  I would recommend that you reuse your types,  because it's just easier to maintain the types.  There's no need to have other types,  but you could have other types on the client,  as long as they serialize to something it matches in the other end.  It's possible.  You could send raw JSON as well if you want.  I just like working with objects.  We have a custom serializer here,  and the way you could add it was like this.  You can see the drink card formator.  What you can see is it's going to show up with another drink,  another formator in this list as well.  It's actually quite nice that it looks at which formators do I have,  and here are the options.  As you can see in the middle, right here,  we have the drink card now.  It's quite fancy.  We could actually use it right away.  If you want to see it drink card formatted in a really weird way.  Yes, I accepted.  This is our custom formatting.  It's really that easy.  Just go along, do your own business.  That was one of the fun parts doing.  What if I wanted to remove some stuff?  I could actually do that as well.  Let's see.  Pretty sure I'm grabbing the wrong thing here.  Yes, I thought so.  Wrong place.  Enable features.  They were so nice that they actually added features all.  When you want to remove stuff, you go features all,  and you pretty much just say that you want to remove a single thing.  That could be like whatever.  We could remove the XML.  If you're really quick, you could notice that it supports protocol buffers as well.  How many have ever heard about protocol buffers?  Nice.  It's a way, as far as I remember, it's optimizing the payload you send over the wire.  It's awesome if you need really, really small segments or a lot of compressed data.  Now we should see XML disappearing.  Hopefully.  Maybe.  Come on.  Faster.  Magic.  Yay.  That wasn't a good demo.  Ah, CSV.  Not XML.  Notice if CSV was gone.  Ah, this, yeah.  I don't know who uses CSV for serializing.  It seems weird.  We could do request filtering as well if we wanted to do statistics on our website.  We have the option of going to request filters and say just saying add,  and we could do requests, response.  And then we just go along and do whatever we wanted to do,  because we have access directly to the, we could like track the user agent.  We just grab it right off every request and we can do it the same on the response as well.  So there's a lot of hook points and you can actually just do whatever you like.  So it's nice that it's just plain simple when it comes out of the box,  but if you really want to do wicked stuff, you could just go do it.  I don't know if wicked is the right term to use, but that's how it is right now.  And then I have some more fantastic slides.  So we talked about the clients and you can pretty much switch to another client  if you just wanted to serialize the other way.  You don't have to do anything on the server.  If I wanted to change my JSON service client, I could just do it and say,  I want the GSV service client.  So that's pretty nice that I can just switch to whatever client I like.  I think it's pretty handy from time to time.  And then it's a freaking Swiss Army knife.  And why is it a Swiss Army knife?  Well, we have a lot of options.  Hmm, I think that's a bit like long list of SQL service supported,  but it's really, really nice that you can just grab another NuGet package  and you have it in the box.  So it supports all these.  And if you want authentication besides the built-in ones,  the built-in ones are, as far as I remember, basic and some other authorization stuff.  And they have Twitter and Facebook authentication.  Why would I need that on my web services?  I don't get it.  If somebody knows why, please come and tell me afterwards.  And I think it was Monday or last week,  they added the N-hybernate to the authentication plan.  And if you want to do caching in the box comes, of course, the RITIS.  And it has memory client, file client, file and XML disk written client,  whoever wants to use disk cache.  Or you can just grab Azure or memcached.  And of course, protocol officers support it.  It was in the list of options, but it's an add-on you grab on later.  And of course, it supports logging.  My favorite is N-Log, but if you want to run Log for NET,  and yes, it does exist in a strong signed and a non-strong signed for those who cares.  And you have Elma and EventLog, of course.  Yay, you can sleep in it and you can eat it.  And of course, as I said, if you have the need for speed, this is going to be awesome.  If we take a short look, we see Jason.net here.  He actually did a complete performance release, but apparently he didn't beat him.  And way over here, we have service stack doing this text.  And if you look at it, going from JROC or JavaScript serializer to this,  that's going to do a really, really huge impact on your serialization.  And imagine if they can cut even 25% more of it.  That's going to be awesome.  And it's cross-platform. There was a few Linux guys or Mac or whatever you're doing.  It supports asp.net, HTTP listener-based.  And as you can see, if you have a really, really old server, that's not a problem.  Just third-eyed.  I was running the demos of my IIS Express.  And in my production code, I actually have a Windows service hosting my API.  So there's a lot of options if you need it.  And that's all the... I was about to say weird Linux and OSX stuff, but I might sound wrong.  But if anybody knows about this stuff, I'm pretty sure you would not and say,  this is okay, this works, this is what we're doing.  And there's a small surprise in the end, because how many would like to see service stack running on an IOS device?  They actually did a demo where they ran Monotouch.  I don't know why on Earth I would host web services inside an IOS app,  but apparently somebody liked it.  So we can fly. Yay!  Where can you find more stuff about this?  If you go to the source, you can grab whatever you need.  It's right there on GitHub.  And you can find a lot of help in the Vika pages.  And you have a docs section as well.  It's a bit split.  I think the Vika pages are more up-to-date than the docs pages.  And the docs pages are mostly about extension points or other plugins they have.  And then we start wondering, would we actually use service stack in the production environment?  As I've already said, I'm running it as a Windows service.  And it's going to be quite good.  We're going to do a production release by the end of this month.  And it's not like some kid in Texas just sitting along,  drinking Coke, having a pizza and just doing some random stuff.  It's actually quite old.  As you can see, the first commit was done in 2008.  So it's not a new product.  It's actually quite old.  The first version didn't look like it at all.  And in case you didn't read it yet,  yes, DemiBillard works for Stack Exchange.  I'm pretty sure he's a valid guy for this stuff.  If you don't trust him, I'm willing to send him an email saying people don't trust him.  And it's quite well maintained.  Actually, when I did my code last week, I was running 3.7.9 or something like that.  And I did the, you're about to fail speaker because I updated my assemblies this morning.  And as you can see, there's coming a lot of commits and it's really nice.  There's always a new commit.  And that was pretty much everything I have to tell you today.  If anybody has questions, I'll try to answer them the best I can.  Also, I'll let you leave early for your flight or your train or your car or drinks or whatever you like to do.  And I would like to give a shout out to the Code 52 guys.  You should check out the projects.  It's a fun place. A lot of new stuff going on.  Anybody have any questions?  None?  It does support all weird kinds of authentication if you want to dig into that at some point.  You have a question? Awesome.  How does it handle SSL yet or no?  The question is if it handles SSL yet.  It was actually one of the first things I started looking at and it turns out a bit weird.  It's not in a box story because you need to do some registrations because it doesn't really handle SSL.  You do a lot of wicked, nasty command line tools and whoopty.  You have SSL support.  It is supported. You can do it.  But it's actually not something in service that handles it.  Anybody else?  I think we'll say that's it.  Thank you for coming.  It's quite nice to see so many people showing up even though it's the last session of the day.  Thank you very much for coming.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.
Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_0_6107.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_6108_11915.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_11916_11975.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_11976_12779.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_12780_14375.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_14376_14471.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_14472_15971.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_15972_16139.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_16140_16595.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_16596_16643.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_16644_16811.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_16812_16859.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_16860_18659.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_18660_18743.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_18744_18839.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_18840_23135.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_23136_28067.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_28068_31715.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_31716_31895.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_31896_32555.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_32556_33239.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_33240_34379.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_34380_35963.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_35964_36095.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_36096_36707.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_36708_36791.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_36792_37967.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_37968_38183.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_38184_38351.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_38352_39083.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_39084_39275.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_39276_39575.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_39576_40919.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_40920_42599.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_42600_45755.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_45756_48251.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_48252_49007.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_49008_50783.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_50784_52571.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_52572_55019.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_55020_57179.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_57180_58883.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_58884_59735.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_59736_59951.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_59952_60695.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_60696_62135.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_62136_62183.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_62184_62387.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_62388_66935.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_66936_77855.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_77856_78251.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_78252_79103.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_79104_79355.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_79356_80447.png Stefan_Daugaard_Poulsen_-_No_more_magical_webservices_feat_80448_80684.png
So, can anyone hear me? Yep. It's nice to see that more than two people turned up, so it's going to be fun. I'm here to talk about Service Stack and how many have heard about Service Stack or used Service Stack? So, around five or six people. That's great. I'm mostly doing this to inspire people and say there's other stuff than Web API or Nancy or whatever you want to use. So feel free to leave if you don't want to be inspired. Why I'm here? As you can see, I'm a developer at a company called Atia in Denmark and I'm pretty sure some of the Norwegian guys have heard about Atia, but it's an IT infrastructure and we're like four or five developers out of 1500 workers, so it's fun. I've done.NET development since 2002 and I think it was probably.NET 1 back then and did Silverlight last year with a lot of web services and as you can see, I kind of got caught in a discussion on Twitter around November. I might have made a mistake by saying that I didn't mind WCF. It was great. I had no problems with it. That pretty much went right back in my face later on. And I got annoyed by the RPC style you tend to do in WCF. And I assume you're all nerds, so you're probably going to like being here. It doesn't matter what you use or who you are. It's going to be fun. So what are the bad ideas for doing web services? If we look at the code generation, how many people have tried a WCF service adding it as a reference and the code just doesn't work? You get an external tool error, something, something, around half of you. And did it tell you how to solve it? No, absolutely not. And what happens when you change the service and update the reference, check in the code? What happens when the other developer actually did another method as well? Just blows right in your face and you have merge conflicts all over. That's some of the fun stuff. And then we have the archaic XML configuration. I think everybody can agree on that we should kill XML configurations as much as possible now. Yeah, as I said before with the mergers, I've actually seen a guy by mistake pushing stuff to a production server and it almost killed all the data in the server. So that was no fun. And then we have defaults. How many have been fighting defaults in WCF? Max objects and graph? Does it sound familiar? Or timeouts? And why do we have to go and set values? Why not use reasonable defaults? It's taken directly from Demi Bellard's words, the guy who primarily do all the coding on service stack, but have reasonable defaults. There's no need for us to go into these default configurations and overrides and so on. They should just be working. Fixed serialization. I haven't dug really deep into WCF if I could publish two serializations on the same endpoint, but wouldn't it be nice just to say, I want this to run JSON and by the way, if you can handle my XML and some other formats as well, that would be great. It would be awesome. I don't need to do new stuff if we get new developers. And the RPC style, it's a maintenance hell, as I said. And we have chatty services. It's not really a bad thing about WCF or any other framework. We should be bulking stuff instead of just pushing small method calls all the time. So that's some of the bad stuff. And as you can see, you've been burned before. Don't do it again. So what is this weird service stack thing? The official subtitle is, WebServices done right. Rest services done easy. Yeah, I remember that correctly. I'm not going to go into this huge rest debate today, hopefully not. But it's really, really easy to get up and running and do some rest services if you want. I'm going to show you how to later. Simple and model driven. If we put our models in a separate assembly, we can pretty much share it on the server and the client. We've done that in WCF as well. But this is the primary focus of service stack. Let's start with the model. Don't start off by generating weird stuff on the client side. End point ignorant. I was talking about these civilizations. You can pretty much get any format you like in service stack. It's IOC based. Everything should be IOC based these days. Easy access to HTTP. I'm going to share later on where we can pretty much just push HTTP codes or get stuff from the request and so on. It's in the box. Fast as lightning. I don't know if anybody heard about the Jason serializer from service stack. Yeah, a few of you have. At the moment, it's the fastest one. I'm going to come back with a graph later on so you can see the stats. It's amazing how fast it is. And I saw a guy called Mike Strobel the other night. He was tweeting to Demi Bill at about, I think I found a way to increase the speed by 25 to 33%. When you're the fastest and you're like somewhere between six and 30 times faster than the other ones, it's pretty impressive to find another 25%. Cross platform. Anybody running mono in here? A few guys. Awesome. You're going to like this. Oh, yeah, the clients are in the box. We don't generate any clients on the client side. We just use what's in service stack and use ways to grab data in that way. Yep. What's in the box? If you get the Nougat package called service stack, you're going to get the service stack text. You're going to get the common. That's pretty much what you need if you run on the client. And then you get the Redis and in a micro or M called or M light. That's in the box. I would have preferred this one. I don't see why I should get Redis and SQL light or the or M light into the default configuration. I really have no need for it. And it's just a pain to have assembly. You don't need. And then we're going to look at some code. That's going to be a lot of code. I hope you'll stay awake for it. And I'm probably going to do a lot of mistakes so you can point and laugh at me. Yep. We're going to start off by the eye service. Eye service is the basis of the service running in service stack. You can do your services directly from eye service. It's not recommended, but you can do it. If you go for the service basis that they've done some error handling for you, like wrapping it and putting it in a nice way and sending the right error codes from time to time. And you have the rest service base. It's pretty much which flavor do you like. Are you going to go for the single execute method or are you going to go for the rest way? And you can do other stuff as well. Yeah. And well, just in case you didn't notice, you can cut off an arm. It's really easy to do. But if you like your teddy bear like that, you can do it. But now let's look at some code. It's way more fun. I'm pretty sure. So I have my great solution here and I added some references. There's a lot of Winchester stuff and RavenDB, not important. But I pulled in service stack. And as you can see, it just pulled in the rest of it. That's actually quite easy to get going. As far as I remember, if you do it in an MBC project, it's going to set up some of the stuff I'm going to set up now automatically. But I decided to go on my own. So here we go. First of all, we need to register the correct handlers. As you can see, I have a location called API. And that's pretty much going to be a subfolder where I'm going to host my API. If you run the MBC project, it automatically puts it at an API. So I'm just going to create that, taking the slow road. So now we have the API folder. And that one should just go away. And then I have some stuff in my global ASACs. I'm going to come back in a minute when I've done the API host. You pretty much set up an app host space, as far as I remember, to run all this stuff in. You can hook up different stuff inside the app host. But just to tell you a short story, I've added some drinks to my RavenDB. I'm pretty sure everybody had a drink or two during the week. And what an obvious topic for the last session on a Friday. So it's going to push some drinks into my RavenDB. And then we'll be able to make some drink cards later on. Pretty much have a drink card with the name and type of drinks or the drinks. And then you'll find out if it's an evening card, noon card, or whatever it is. And there's a small trick you can do in Service Stack. How many know about the mini-profiler, Sam Saffron, and some other guy did? Or any other profiler you can run just pushing it? Or is it Glimpse, the other one? I think so. Well, support for mini-profiler, let's build in. Let's just leverage that. And then I have my API host. And then I'm going to push in an app host base. That's quite easy, but I get some stuff I don't want. That's a bit too much. Let's see. I have a... Where did that go? Yeah, in case you use another IOC, then the funk one that's built into Service Stack, you give it an adapter. So pretty much I'm getting my Windsor adapter. I have somewhere else. And I'm just going to say it was a container adapter, as far as I remember. Yep, and as I said, a lot of misspelling. Then we'll supply a service name. Could be drain... NDC, drink cart service. And then I have once an assembly as well. API host assembly. And then we want to do some configuration. That was pretty much most of the setup we need to do. But since I decided to put stuff in a subfolder, I need to do some set config as well. And I'm probably going to do this wrong. Let's see if I can remember which one it is. So much stuff to remember on this. So pretty much what I've done here is just set to a service stack host that I'm actually not hosting in the root directory. I'm hosted in the API folder. So the handle is set up for the API folder and service stack is now set for API folder as well. And that's pretty much it, except that it's not much fun doing web services without a service. So we're going to create a basic service as well. Let's see. We're going to create a drink service. Here we are. I could go for the iService if I wanted to. It would look like that. And I could say drink. Then I will get this. That's all nice. And I've actually got some services I need to refactor because I did the iService before actually read on upon the stuff, but legacy stuff, running in my private stuff so it doesn't really matter. If I wanted to expand this, I could actually do it. If I just wanted to support the get keyword from REST, I could just add a partial interface for it. Now what would happen if I call the service, if I did a post or anything like it, it would actually go for the execute method. If I do a get, it hits the get method. So you can actually have different flows in your service. That's pretty cool, but I'm not going to use this. This is just way too hard and I need to do error handling and so on. So we're going to delete that. And that's more fun. And you might have noticed that this time it's a run instead of an execute. Somehow I'm a bit split. It could have been the same. Just would have been easier to change it. But well, who cares? Now if I want to request a single drink, I could just do request drink ID. That was different from my GUI.empty. Then I could just, oh yeah, I know what I need. I'm running a RavenDB so I might want to get hold of my document session. And if somebody looks at my code later on and you see the registration for RavenDB, yes, it is wrong. I have the wrong lifestyles. So I just want to grab that single drink. So we'll do a drink. It's pretty easy. And then I can just return that drink if I want to. Usually, you end up having a drink response. Because wouldn't it be nice to just get the same response and if I get one in this list, well, I have one drink. If I have many, I have many. It's just easier to pack stuff up and do batch loading. So I'm going to return a new drink response. Yeah, like this. Go away. So now we have actually done our first service, but we kind of want an option to get all the drinks as well. So we're going to just add drinks. It's fun looking at me writing queries to RavenDB, right? And misspelling. So, a new drink response. So that was pretty much it for our service. As you can see, it's pretty easy to do a web service and service stack. It doesn't really require much code of you, and that's pretty much it. One thing you need to do before you get it up and running, you need to add a route as well or route or however you want to say it today. And that is most often for me done in the app host base. You can decorate your DTOs, but I don't like decorating my DTOs for service stack when they're in a different assembly. That just seems so wrong for me, and somehow I don't like putting attributes everywhere. So I'm going to add a drink, and that would be most likely be drinks. So now we could get the drinks, but we kind of wanted the option to get a drink, a single drink as well. So we're going to add another one, and we can do drinks, and hit something wrong. And do the ID. Does that seem familiar when we're talking about RESTs? I hope so. And hopefully everything builds and runs. Yep, it's succeeded. That's fun. One of the awesome things about service stack is that it's actually quite intelligent, because it's going to look at my code now and generate a meta page for me at some point if I did it right. Oh, yeah. It doesn't matter how many app hosts you do if you don't actually start it up. Minor defect. Yep. So now we should have a service. Except I come to stuff out in my installer as well. Now this is fun. How many did come to see me fail? Awesome. A few guys. At least you're awake. I'm going to put my container. I'm going to eat the service. Sorry for that. We ever got the ES blown out. Those familiar with Castle Winter would notice that I'm just pulling a lot of stuff in everything that matches and I service will get into this and spun up. So that's quite nice. And it should be able to run now. Anybody else have a laptop without an SSD? This is quite nice page we got from service stack. We can actually see we have operations on drinks. And we can actually look at the bottom and see in case we want to hand this off to someone else and they don't want to use service stack, we can supply them with SSDs and whistles. It's quite easy. I actually tried it the other night. I don't know why but I did. And then we have the options of the different formances up here. So here you can see pretty much I registered for all works on drinks and drinks ID. And you pretty much have a small example on how am I going to use this. But there's another cool thing about it. What if I try to go for that URL? Awesome. I have an empty database for some odd reason. That's weird. I should have some stuff. Let's just take a peek at this. If anybody spots my mistake please say so. I would guess that I needed to do this to a list because I'm pretty sure that Revenby doesn't like this. Or service stack doesn't like this. We'll see some drinks. Nope. Drinks are gone. My if condition? Is it the other way around? No, I don't want to hit that one. I pretty much want this. And this one. I'm actually doing the regular get. So I just want to get all the drinks. I didn't supply an ID. This was fun. Why did I decide to go for live coding? Ah, no drinks. Oh, I didn't do the app start because I didn't restart my application. I decided to go and clear my complete Revenby database before I went in here. So all the stuff being run from the server, it's pretty much not being run. Let's move this. And we should be able to season drinks, hopefully. Nope. Who ate my drinks? Pretty sure that I added some drinks. Hmm. This is going to be fun showing off drinks when I have none. Let's see. Yeah, created my Revenby. Should be okay. Let's see. Now, isn't it fun looking at people messing up? Give me a break. Yeah, yeah, I know. So let's see if we're lucky this time. We see a button in the database. That's a good start. That's actually quite a good question. Hmm. I'm pretty sure it wasn't this way last night. Let's see. So this is how to completely fail your demo. Anybody remember if you can actually do breakpoints in global ASX? Or did I just change the run code last night? We might have done. I think I know why. So pretty much it should insert some drinks now. Nope. So who killed my code last night? Is this in store? So can anybody see any Revenby errors? What? Clever man. I talked to the Revenby guys the other night and they pretty much convinced me that I should stop using repositories. So this is what happens when you throw away your repositories. So, well spotted. I'm not just nerve-wracking anymore. We might have drinks in a moment. I just killed it. It should be there now. Yep, there it is. Just going to remove that and that. And we are going to get... Yay! Drinks for everyone. So just to make sure that we could actually get a single drink. I'm just going to paste that so it's as easy as that. But that was drinks we were meant to do like a drink card. And that should be fairly easy to do. Since I'm a really lazy bastard, I'm going to take full advantage of using resharper. And I'm going to do a wrist service base and drink card. So that's fun. If you get ticks from me tapping around, just raise your hand. So, I only want to handle on git in the first run. I might want to do some put as well. It's going to be hard to get new cards into the system. Post. This is pretty much what we need to do. As you can see, I don't have to set up all the different types of keywords or verbs. I can just go along as I need to. I could have done it the other way around as well with the eye service and just adding these separate words. There's a lot of options and do whatever fits. If we get a request with an ID, it's always nice doing ID stuff. Go to empty. Then I would like to get a drink card. Somehow I have a tendency of missing Raven the Beast off today. It's funny listening to me when I'm silent. Just going to return the drink card. That's fine. We want to just grab all drinks, cards, not crats. Excuse me for my ADD. I can't do misspelled stuff and just doesn't work for me. What the hell am I misspelling? What? Oh, in. I wouldn't think that you would remember that. Card. Select DC. It's nice to have people correcting me. Come on. Be nice. Memorized clone. Why would I do that? So everybody's heavy. We got drink cards as well. It's not going to be much fun if we don't add them. We're just going to grab and say decision store. I'm pretty sure if I've done my fallback to my demo I had in my repo, it would have been failing in the same places. I could say return new HTTP request results. I want to try that. I can pretty much do like this and wrap it inside an HTTP result. But if I wanted to give it a specific HTTP code, I could do that as well. How is it? Status code. And I could say create it. That's some of the options. But the client on the other side would actually accept this and just say, oh, you just send me some extra stuff and I'm just going to grab the drink cards or the single drink card I got. So that's pretty much what we need to run our drink service. And we need to, of course, add the routes as well. So if we go to the card. I wish we pretty much have everything. And as we will see, it should just add another option to our major page in a moment. And all of a sudden we got drink cards as well. And if you look in the output you would see somewhere up here. I think I forgot to add the log manager. But actually when it starts hooking up the services you would get a log entry saying, I just registered this service. So you can actually just see that it does it correctly. And of course we can do stuff like drink cards. And nothing comes, of course. As you see, the profile is running in the upper right corner. It's nice to have. I'm just going to add a logger. So log manager. It tends to be a bit confusing when you have two classes being the same thing. I don't know how many times I've been adding the in-log instead of the actual service stack log manager. And I could say, Nero, do I have an in-log? Yeah, no, that's the wrong one. I knew it in-log factory. It's nice and confusing to have several stuff. Really? No. Stop doing this to me. Did I lose my logging? Yeah, so apparently I forgot to pull my service stack in-log. Oh well, who needs logging anyways? So we could have had logging. So I hope you're okay without logging. And if we wanted to use this great API we just did for drinks, I made a small really, really stupid console app. Somehow everything should be in the terminal these days, so why not do a drink cart manager in the terminal as well? And as you can see, I'm setting up the URL for it. That's quite simple. Of course, we need to know where our API is. And then you just can do a JSON service client. If I go fastly to my slide. Yep, let's see here. So you have all sorts of clients. You have the service client and you have the rest client and the rest async client. Of course, it doesn't really make sense to push the rest clients on the service client, but you can have a service client, rest client, and rest client async for the rest of the stuff. And as I said before, you can actually do the whistle way if you want to do it. We'll just go through this again. The first thing I want to do is of course grab all my drinks. How much fun is it creating a drink cart if you don't know what the drinks are? So I pretty much grabbed the list and I'll put it later on. So this is just like basic crotch stuff, adding things. And in the end, we're going to do a post to our drink cart service and just say, hey, here's some drink carts. Have fun. Get drunk. And I'm just going to run this and create a short small drink cart. Oh, Jesus Christ. Somehow I managed to remember my fun sizes and so on, but not in a nice way for you. So new cart. It's always nice to have new cart somewhere. And it's the afternoon, right? Or are we going for evening? So we have the list of drinks. We can see that pulled the drinks directly from the service. We might want a white Russian. We want a Long Island IST in Manhattan. And somehow that didn't work. We were supposed to see the right results, but the quick reader might notice that I actually did this wrong because I just returned the drink cart. I didn't wrap it inside my drink cart response. So actually I'm a bitch stuck right now and I need to add my drink cart response, which should be fairly fast to do. Cards. The way service stack handles this when it gets to the response, I say I'm saying like, if you look at this right here, I expected a drink cart response. It will actually try to serialize the response into the drink cart response. But if you try to use it, you would get an awful exception with like, ah, I can't deserialize this. It seems wrong. It's just weird. But it doesn't really just flip upside down and pukes all over the place. It didn't have that many drinks. Yeah, I don't care about the type. How many is annoyed by the automatic typing stuff? And we need to do this as well. Cards, new. Ah, both of them. What am I missing? Ah, yeah. There we are. Yeah, have fun with all the curly braces. Let me just check everything works. As you can see again, it's great not having an SSD. So we actually did put the cart into the stomach of the RavenDB, and we would have gotten this back again, and I could have shown you the JSON. I'm not going to create another one, just, it's just lame doing another one right now. Then we have a lot of extension points for service stack, which is actually quite fun. I talked about the logging. You pretty much set the log factory on it, and how fun wouldn't it be if we could like, do our own custom format? I have prepared a small custom format. If you want your own content type, why don't just do an x-drink card and say it's text. I added the serialize to stream, but I kind of skipped the deserialize, because I don't really care about deserializing these. Yeah. Now you're reusing the types on the server and the file. Yep. Do you have to do that? I would recommend that you reuse your types, because it's just easier to maintain the types. There's no need to have other types, but you could have other types on the client, as long as they serialize to something it matches in the other end. It's possible. You could send raw JSON as well if you want. I just like working with objects. We have a custom serializer here, and the way you could add it was like this. You can see the drink card formator. What you can see is it's going to show up with another drink, another formator in this list as well. It's actually quite nice that it looks at which formators do I have, and here are the options. As you can see in the middle, right here, we have the drink card now. It's quite fancy. We could actually use it right away. If you want to see it drink card formatted in a really weird way. Yes, I accepted. This is our custom formatting. It's really that easy. Just go along, do your own business. That was one of the fun parts doing. What if I wanted to remove some stuff? I could actually do that as well. Let's see. Pretty sure I'm grabbing the wrong thing here. Yes, I thought so. Wrong place. Enable features. They were so nice that they actually added features all. When you want to remove stuff, you go features all, and you pretty much just say that you want to remove a single thing. That could be like whatever. We could remove the XML. If you're really quick, you could notice that it supports protocol buffers as well. How many have ever heard about protocol buffers? Nice. It's a way, as far as I remember, it's optimizing the payload you send over the wire. It's awesome if you need really, really small segments or a lot of compressed data. Now we should see XML disappearing. Hopefully. Maybe. Come on. Faster. Magic. Yay. That wasn't a good demo. Ah, CSV. Not XML. Notice if CSV was gone. Ah, this, yeah. I don't know who uses CSV for serializing. It seems weird. We could do request filtering as well if we wanted to do statistics on our website. We have the option of going to request filters and say just saying add, and we could do requests, response. And then we just go along and do whatever we wanted to do, because we have access directly to the, we could like track the user agent. We just grab it right off every request and we can do it the same on the response as well. So there's a lot of hook points and you can actually just do whatever you like. So it's nice that it's just plain simple when it comes out of the box, but if you really want to do wicked stuff, you could just go do it. I don't know if wicked is the right term to use, but that's how it is right now. And then I have some more fantastic slides. So we talked about the clients and you can pretty much switch to another client if you just wanted to serialize the other way. You don't have to do anything on the server. If I wanted to change my JSON service client, I could just do it and say, I want the GSV service client. So that's pretty nice that I can just switch to whatever client I like. I think it's pretty handy from time to time. And then it's a freaking Swiss Army knife. And why is it a Swiss Army knife? Well, we have a lot of options. Hmm, I think that's a bit like long list of SQL service supported, but it's really, really nice that you can just grab another NuGet package and you have it in the box. So it supports all these. And if you want authentication besides the built-in ones, the built-in ones are, as far as I remember, basic and some other authorization stuff. And they have Twitter and Facebook authentication. Why would I need that on my web services? I don't get it. If somebody knows why, please come and tell me afterwards. And I think it was Monday or last week, they added the N-hybernate to the authentication plan. And if you want to do caching in the box comes, of course, the RITIS. And it has memory client, file client, file and XML disk written client, whoever wants to use disk cache. Or you can just grab Azure or memcached. And of course, protocol officers support it. It was in the list of options, but it's an add-on you grab on later. And of course, it supports logging. My favorite is N-Log, but if you want to run Log for NET, and yes, it does exist in a strong signed and a non-strong signed for those who cares. And you have Elma and EventLog, of course. Yay, you can sleep in it and you can eat it. And of course, as I said, if you have the need for speed, this is going to be awesome. If we take a short look, we see Jason.net here. He actually did a complete performance release, but apparently he didn't beat him. And way over here, we have service stack doing this text. And if you look at it, going from JROC or JavaScript serializer to this, that's going to do a really, really huge impact on your serialization. And imagine if they can cut even 25% more of it. That's going to be awesome. And it's cross-platform. There was a few Linux guys or Mac or whatever you're doing. It supports asp.net, HTTP listener-based. And as you can see, if you have a really, really old server, that's not a problem. Just third-eyed. I was running the demos of my IIS Express. And in my production code, I actually have a Windows service hosting my API. So there's a lot of options if you need it. And that's all the... I was about to say weird Linux and OSX stuff, but I might sound wrong. But if anybody knows about this stuff, I'm pretty sure you would not and say, this is okay, this works, this is what we're doing. And there's a small surprise in the end, because how many would like to see service stack running on an IOS device? They actually did a demo where they ran Monotouch. I don't know why on Earth I would host web services inside an IOS app, but apparently somebody liked it. So we can fly. Yay! Where can you find more stuff about this? If you go to the source, you can grab whatever you need. It's right there on GitHub. And you can find a lot of help in the Vika pages. And you have a docs section as well. It's a bit split. I think the Vika pages are more up-to-date than the docs pages. And the docs pages are mostly about extension points or other plugins they have. And then we start wondering, would we actually use service stack in the production environment? As I've already said, I'm running it as a Windows service. And it's going to be quite good. We're going to do a production release by the end of this month. And it's not like some kid in Texas just sitting along, drinking Coke, having a pizza and just doing some random stuff. It's actually quite old. As you can see, the first commit was done in 2008. So it's not a new product. It's actually quite old. The first version didn't look like it at all. And in case you didn't read it yet, yes, DemiBillard works for Stack Exchange. I'm pretty sure he's a valid guy for this stuff. If you don't trust him, I'm willing to send him an email saying people don't trust him. And it's quite well maintained. Actually, when I did my code last week, I was running 3.7.9 or something like that. And I did the, you're about to fail speaker because I updated my assemblies this morning. And as you can see, there's coming a lot of commits and it's really nice. There's always a new commit. And that was pretty much everything I have to tell you today. If anybody has questions, I'll try to answer them the best I can. Also, I'll let you leave early for your flight or your train or your car or drinks or whatever you like to do. And I would like to give a shout out to the Code 52 guys. You should check out the projects. It's a fun place. A lot of new stuff going on. Anybody have any questions? None? It does support all weird kinds of authentication if you want to dig into that at some point. You have a question? Awesome. How does it handle SSL yet or no? The question is if it handles SSL yet. It was actually one of the first things I started looking at and it turns out a bit weird. It's not in a box story because you need to do some registrations because it doesn't really handle SSL. You do a lot of wicked, nasty command line tools and whoopty. You have SSL support. It is supported. You can do it. But it's actually not something in service that handles it. Anybody else? I think we'll say that's it. Thank you for coming. It's quite nice to see so many people showing up even though it's the last session of the day. Thank you very much for coming. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
Stack and how many have heard about Service Stack year with a lot of web services and as you can a reference and the code just doesn't work? You get the common. That's pretty much what you need configuration. That was pretty much most of the could actually do it. If I just wanted to support in your service. That's pretty cool, but I'm not wanted the option to get a drink, a single drink that should be fairly easy to do. Since I'm a terminal these days, so why not do a drink cart doesn't really make sense to push the rest drink cart if you don't know what the drinks are? all over the place. It didn't have that many many is annoyed by the automatic typing stuff? need to have other types, but you could have segments or a lot of compressed data. Now we you have it in the box. So it supports all these.