1. Introduction

1.1 Introduction

When developing a front-end application, you would normally need a back-end as well. If this isn't something you are providing or if it is rather complex, you might consider simulating this. With Ember CLI Mirage you can do exactly that. Welcome to this and other Tuts+ course. I'm Markus Muhlberger and this is Simulate a Server With Ember CLI Mirage. In this course, I will show you how you can use Ember CLI Mirage in development and during testing. We will look at static data using fixtures as well as dynamic data with factories. we will also have a look at acceptance tests and the way you would use Ember CLI Mirage there. Are you ready to speed up your Ember development by eliminating the need for a server? Then, I will see you in the first lesson.

2. Ember Cli Mirage

2.1 Installation and Getting Started

Hi and welcome to Simulate a Server With Ember CLI Mirage. In this lesson, we will install the atom and experiment with the first route. Before we start, let me introduce you to Mirage properly. When you create an ember, you normally also have a back-end component. This component can either be from a third party like Twitter, or owned by you, meaning you're in charge of creating it. Let's look at the first case. When you are developing against a third party API, you might want to avoid calling it everytime, especially when it is over a network, it can take some time to respond. When you run automated tests, you also don't want to hit the network because it can substantially slow down the execution and is bad manners. When you have your own API, it makes it a bit easier, but it also isn't ideal. Let's imagine you were gonna break project with a lot of dependencies. It would be overly complicated for the front-end developer to spin up the whole project just to develop against an API. Or the API is worked on by a separate team and not yet completed. Ember CLI Mirage solves that problem problem by simulating a back-end server and rerouting your network requests to itself. Enough talking, let's get started with the installation. It is very simple with Ember add-ons these days. Typing ember install ember-cli-mirage in your shell will do the trick. As you can see during installation, it will create some files under the Mirage folder. Let's have a look at them. Mirage keeps everything in this folder. The heart of the add-on is the config.js file. You will set all options and also define your routes. This sounds familiar? It should. Ember CLI Mirage tries to use the same concepts you most commonly find in a back-end system. It has routes, models, and in-memory database, factories, mixtures, and even serializers. You will learn about all those things during this course. Okay, before we can create our first mock route, we need to do a little investigating since we don't know anything about the project yet. The project was taken from the Get Started of Ember 2.0 course by Andrew Vargas. He created a back-end for his course, which I'm going to simulate with Ember CLI Mirage in mind. To be able to explore the project, we need to start the Ember development server first. Loading it up in the browser, it prompts me to log in. This is our first hurdle. However, it is an easy one. When you have a look at the source code, you will see an authenticators and an authorizers folder. This screams ember-simple-auth, and when you reopen one of those files, it sure enough is what we expected. As you can also see, Andrew used the oauth2-password-grant authentication flow. This is great for us because it's a formal standard and we know what we will receive from the server. I also noticed that the Endpoint is on the /api/token. Let's have a look at the application adapter, that's what I thought. The whole API is namespace and a slash API. Let's get back to their Mirage config file. Since everything falls under a common namespace, we can use the namespace option to prefix all of our end points. Now, the token endpoint is on a /token and it expects us to return an excess token object. This is defined in the standard and you can also find out about it in the Ember Simple Auth Test suite. Okay, so, how is the route defined with Mirage? Just very easy. Ember CLI Mirage implements all HTTP routes as functions. You will then have an endpoint POV and a function that returns data. In our case, a hash with an access token key. Let's try it out. We can enter any data we want here because Mirage doesn't check for credentials. Let me log out again and have a look at the network inspector during the login. I'm typing in a user and password again. And after I'm logged in, you can see, there was no request log. If you have experimented with a built-in server mock functionality of Ember CLI, you would expect to see a request being made that will get intercepted by Ember CLI, but not so in Mirage. Ember CLI Mirage rocks as an add-on that runs in the browser, not as part of the development server. When we have a look at the console output, we can see Ember CLI Mirage was logging the post requests to /api/token and also showing the response. Completely bypassing the network this way makes it very fast, but also unrealistic. This is why Ember CLI Mirage has a timing option that is set to 400 milliseconds by default to simulate a real network. You can change that setting, of course. During testing, it is set to zero, since we want our tests to run fast. Okay, so, in this lesson, we have made our first successful mock endpoint with Ember CLI Mirage. And learned more about what it is aiming to do. In the next lesson, we are going to simulate the calendar's endpoint, with static data by using fixtures. See you there.