500x500

I'm a software engineer, but I prefer to call myself Technology Bishop. Spreading knowledge through writing is my mission.

Software Engineer

Antonello Zanini

Let’s see everything you should know to start using Project Lombok. We will have a look at how to integrate it into your IDE and use it to avoid boilerplate code.

A Complete Guide to Lombok

Avoid boilerplate code by automatically mapping JPA entities into DTOs in Spring Boot and Java by harnessing MapStruct

Mapping JPA Entities into DTOs in Spring Boot Using MapStruct

sambiopic

I'm Director of Developer Relations and a Google Developer Expert for Angular and Web Technologies. I believe anyone who wants to learn to code should be able to learn code and I love teaching. When I'm not coding or writing, you'll find me outside hiking or camping in the beautiful Pacific Northwest.

Director of Developer Relations

Sam Julien

NgRx 8 features improved developer ergonomics, less boilerplate, runtime checks, and easier error handling.


**TL;DR:** NgRx 8 introduces a host of improvements, including `createAction`, `createReducer`, and `createEffect`. These helper functions drastically reduce (no pun intended) boilerplate, which boosts developer productivity.

## NgRx 8: A Massive Win
Shortly after the [release of Angular 8](https://auth0.com/blog/angular-8-differential-loading/), the NgRx team released their own version 8. It was a big release full of fantastic improvements to the library. While I'll let you read the [official release announcement](https://medium.com/ngrx/announcing-ngrx-version-8-ngrx-data-create-functions-runtime-checks-and-mock-selectors-a44fac112627) by [Tim Deschryver](https://twitter.com/tim_deschryver), here are the highlights:

- [`angular-ngrx-data`](https://github.com/johnpapa/angular-ngrx-data) by [John Papa](https://twitter.com/John_Papa) and [Ward Bell](https://twitter.com/wardbell) is now officially part of NgRx as [`@ngrx/data`](https://github.com/ngrx/platform/tree/master/modules/data)
- [Runtime checks](https://ngrx.io/guide/store/configuration/runtime-checks) are now available to check that state and actions aren't mutated and are serializable (these replace the `ngrx-store-freeze` package)
- Fully isolated unit tests are now available thanks to [mock selectors](https://ngrx.io/guide/store/testing#using-mock-selectors)
- There have been a couple of improvements to `@ngrx/router`, including a new [minimal `routerState` option](https://next.ngrx.io/guide/router-store/configuration)
- There are now NgRx snippets in John Papa's [Angular Snippets](https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular2) VS Code extension
-  [Alex Okrushko](https://twitter.com/AlexOkrushko) and [Wes Grimes](https://twitter.com/wesgrimes) have joined the NgRx team (well deserved!)
  
I've saved the best for last, though, and it's the subject of this article:

- `createAction`, `createReducer`, and `createEffect` helper methods *drastically* reduce boilerplate and improve development time

We're going to dig into what that means and how these functions will make your life better, but before we do that, we should make sure you know how to update to version 8 to take advantage of these new features.

<include src="TweetQuote" quoteText="NgRx 8 features improved developer ergonomics, less boilerplate, runtime checks, and easier error handling!"/>

## How to Update to NgRx 8
In order to update to NgRx 8, you'll need to be sure your project is updated to Angular 8. You can update your Angular CLI globally by running this command:

```bash
npm install -g @angular/cli
```

In a project that needs to be updated to Angular 8, you can run the following:

```bash
ng update @angular/cli @angular/core
```

You can then run the following to update to NgRx 8:

```bash
ng update @ngrx/store
```

When working on this article, I ran into a bit of a problem with the TypeScript version. It seems like there was a conflict between the required versions, so I had to manually lock in version `3.4.3`.

If you're using `ngrx-data`, you can easily migrate to `@ngrx/data` with this command:

```bash
ng add @ngrx/data --migrate
```

For a more thorough explanation of this process, Wes Grimes has written a great article on how to [upgrade to Angular 8 and NgRx 8](https://dev.to/angular/how-to-upgrade-your-angular-and-ngrx-apps-to-v8-4iip). For more specific details on migration to NgRx 8, check out the official [migration guide](https://ngrx.io/guide/migration/v8). Finally, don't forget that Angular has an [official update tool](https://update.angular.io) to help with moving to new versions of Angular.

With that out of the way, let's get to the fun stuff!

## createExcitement: The New NgRx 8 Helper Functions
One of the most common complaints about NgRx (and the Redux pattern in general) is that there is too much boilerplate. Once you dig into the library and the pattern, though, you start to understand that the initial setup is a completely worthwhile investment when you're managing state in large, complex applications (which is what NgRx is designed for!).

That being said, the NgRx team has listened to the developer community and made some huge improvements in "developer ergonomics" (a fancy way to say making it easier to write code) with version 8. Most of these improvements are due to a refactor of how actions, reducers, and effects are set up. There are now helper methods that are easy to understand and take less code to write. Let's take each of them in turn.

### createAction
As my friend [Mike Ryan](https://twitter.com/MikeRyanDev) says, "Actions are the gluten of the NgRx loaf." Indeed, they are the core of any NgRx application. Great care and attention are required in deciding what actions your app needs. Unfortunately, actions take a lot of code to set up. Just look at this excerpt from the application we built in my original [NgRx Authentication](https://auth0.com/blog/ngrx-authentication-tutorial/) tutorial:

```typescript
// src/auth/actions/auth.actions.ts (excerpt)
export enum AuthActionTypes {
  Login = '[Login Page] Login',
  LoginComplete = '[Login Page] Login Complete',
  LoginFailure = '[Auth API] Login Failure'
}

export class Login implements Action {
  readonly type = AuthActionTypes.Login;
}

export class LoginComplete implements Action {
  readonly type = AuthActionTypes.LoginComplete;
}

export class LoginFailure implements Action {
  readonly type = AuthActionTypes.LoginFailure;

  constructor(public payload: any) {}
}

export type AuthActions =
  | Login
  | LoginComplete
  | LoginFailure;
```

This excerpt only contains three of the eight actions in that application and it's a very small app! As Alex Okrushko points out in his excellent article on [the new action creators](https://blog.angularindepth.com/ngrx-action-creators-redesigned-d396960e46da), enums and strings also make it very difficult to see where actions are used. And don't get me started on those union types! You can see why a change was needed.

Enter the new `createAction` method. With `createAction`, you pass in the action name along with an optional `props` function with a specified argument type as a destructured object. 

Yikes, that's a lot of jargon. Let me explain that with an example. 

Let's say I have an action called `booksLoaded` that needs to receive an array of books (`books`) of type `Book[]` when created. My `props` function for `createAction` would be `props<{ books: Book[] }>()`. (With [destructuring](https://auth0.com/blog/a-rundown-of-es6-features/#ECMAScript-2015-Features), `{ books }` is the equivalent of `{ books: books }`.)  

```typescript
export const booksLoaded = createAction(
  '[Books API] Books Loaded', 
  props<{ books: Book[] }>()
  );
```

That way, when I create a new action of this type, I can directly pass the array of books into the constructor: `new booksLoaded({ booksFromServer })`.

So, the above authentication actions would be refactored like so:

```typescript
export const login = createAction('[Login Page] Login');

export const loginComplete = createAction('[Login Page] Login Complete');

export const loginFailure = createAction(
  '[Auth API] Login Failure', 
  props<{ error: any }>()
);
```

Mind-blowing, right?

There are two things to notice here. First, notice that the action constant names have gone from Pascal case (`LoginFailure`) to camel case (`loginFailure`). This is due to actions changing from classes to functions and is a standard JavaScript style convention. Don't let that trip you up, but be mindful of that in refactoring.

Second, notice that I renamed `payload` to `error` because it is more descriptive. (I could have also given it a new type like `Error`, but it doesn't matter much in this example). While this is a great new feature with the redesigned action creator function, be careful of doing this. Do a search through your code to avoid breaking other parts of the app relying on a `payload` property (a great reminder from [Gregor Woiwode](https://medium.com/@gregor.woiwode/ngrx-8-meet-the-new-upcoming-factory-methods-of-the-next-major-release-a97a079cc089)). If you rename `payload` in the action creator, be sure to change it everywhere.

There's one last great feature of the new action creators. You can now specify a default value of a `prop` argument. For example, in the above `loginFailure` action, I could provide a default error message:

```typescript
export const loginFailure = createAction(
  '[Auth API] Login Failure',
  (errorMessage = 'Error logging in') => ({ payload: { errorMessage }})
);
```

This would be a great backup in case the server fails to provide an error message for some reason.

To add one of these new action creators to your application, you can use the [updated action schematic](https://ngrx.io/guide/schematics/action):

```bash
ng generate @ngrx/schematics:action myNewAction --creators
```

This command will generate a new file called `my-new-action.actions.ts` containing a constant named `loadMyNewAction` using the `createAction` function.

<include src="TweetQuote" quoteText="The new action creators of NgRx 8 drastically reduce (no pun intended) development time when adding new features!"/>

### createReducer
The new way to create actions is incredible, but it doesn't stop there. Reducers are also now easier to write thanks to the `createReducer` method.

Here's a typical example of a reducer you might find in a burger restaurant app:

```typescript
export function reducer(
  state = initialState,
  action: BurgerApiActionsUnion
): State {
  switch (action.type) {
    case BurgerApiActionTypes.LoadBurgerCollection: {
      return { 
        ...state
        loading: true
      };
    }

    case BurgerApiActionTypes.LoadBurgersSuccess: {
      return { 
        loaded: true,
        loading: false,
        ids: action.payload.map(burger => burger.id)
      };
    }

    default: {
      return state;
    }
  }
}
```

This is a simple example, but as it scales up, you'll have a ton of case statements that will make understanding this code difficult. It gets messy fast (just like eating burgers, really).

With NgRx 8, you can use `createReducer` instead:

```typescript
const burgerReducer = createReducer(
  initialState,
  on(BurgerApiActionTypes.loadBurgerCollection, state => ({
    ...state,
    loading: true
  })),
  on(BurgerApiActionTypes.loadBurgersSuccess, (state, { burgers }) => ({
    loaded: true,
    loading: false,
    ids: burgers.map(burger => burger.id)
  }))
);
```

Much cleaner, isn't it? Each case uses the `on` function that receives the action and a function to modify state. 

The `on` function can also take multiple actions, making it easy to grow the reducer function. For example, it's common for the success of a record addition and the failure of a record deletion to result in the same state. An example of this is when an app state includes both a collection of data (which should match what's on the server) and an array of IDs for faster lookup (which is maintained in memory). In order to make sure the array of IDs always matches what's on the server, it's necessary to account for failures of adding or deleting records.

Here's an example of that with the burger application:

```typescript
const burgerReducer = createReducer(
  // ...other cases,
  on(
    CollectionApiActions.addBurgerSuccess,
    CollectionApiActions.removeBurgerFailure,
    (state, { burger }) => {
      if (state.ids.indexOf(burger.id) > -1) {
        return state;
      }
      return {
        ...state,
        ids: [...state.ids, burger.id],
      };
    }
  ),
  on(
    CollectionApiActions.removeBurgerSuccess,
    CollectionApiActions.addBurgerFailure,
    (state, { burger }) => ({
      ...state,
      ids: state.ids.filter(id => id !== burger.id),
    })
  )
);
```

Using the same reducer cases for multiple actions makes it easier to understand what's happening in this application in addition to ensuring the `ids` array doesn't get out of sync with the server.

One other important note on using `createReducer`. As of this writing, the Angular ahead-of-time (AOT) compiler (the compiler used for producing production builds) [does not support function expressions](https://angular.io/guide/aot-compiler#function-calls-are-not-supported). It's therefore necessary to wrap the `createReducer` function in an exported function like so:

```typescript
export function reducer(state: State | undefined, action: Action) {
  return burgerReducer(state, action);
}
```

Finally, as with `createAction`, there's a [schematic for the new reducer style](https://ngrx.io/guide/schematics/reducer):

```bash
ng generate @ngrx/schematics:reducer myNewReducer --creators
```

This schematic will generate a new file called `my-new-reducer.reducer.ts`. It will include both the `createReducer` constant and the exported `reducer` function for AOT.

### createEffect
Finally, `createEffect` is here to improve writing effects. Previously, effects used an `@Effect()` decorator. While this was fine, it was sort of the odd bird compared to all of the other more functional approaches NgRx takes.

Going back to the burger application, here's an example of the old style of effect: 

```ts
@Effect()
loadBurgerCollection$ = this.actions$.pipe(
  ofType(BurgerApiActionTypes.LoadBurgerCollection),
  switchMap(() =>
    this.burgerService.getAllBurgers().pipe(
      map((burgers: Burger[]) =>
        BurgerApiActions.LoadBurgersSuccess({ burgers })
      ),
      catchError(error =>
        of(BurgerApiActions.LoadBurgersFailure({ error }))
      )
    )
  )
);
```

The new `createEffect` helper simplifies this a bit and standardizes it to look more like creating actions, reducers, and selectors:

```typescript
loadBurgerCollection$ = createEffect(() =>
  this.actions$.pipe(
    ofType(BurgerApiActionTypes.loadBurgerCollection),
    switchMap(() =>
      this.burgerService.getCollection().pipe(
        map((burgers: Burger[]) =>
          BurgerApiActions.loadBooksSuccess({ burgers })
        ),
        catchError(error =>
          of(BurgerApiActions.loadBooksFailure({ error }))
        )
      )
    )
  )
);
```

> Remember, the actions have changed from Pascal case to camel case since they've changed from classes to functions.

There's also a small modification in effects that don't dispatch new actions. Here's an effect that fires after a burger is successfully ordered, which redirects back to the home page and doesn't dispatch a new action:

```typescript
@Effect({ dispatch: false })
orderBurgerSuccess$ = this.actions$.pipe(
  ofType(BurgerApiActions.OrderBurgerSuccess),
  tap(() => {
    this.router.navigate(['/']);
  })
);
```

Using the new `createEffect` function, you can refactor this code to the following:

```typescript
orderBurgerSuccess$ = createEffect(() => 
  this.actions$.pipe(
    ofType(BurgerApiActions.LoginSuccess),
    tap(() => this.router.navigate(['/']))
  ),
  { dispatch: false }
);
```

That second argument of the `createEffect` function is for passing in metadata to control how the effect operates.

One final word on effects in NgRx 8. Previously, the team found that developers were either forgetting to handle errors in their effects or handling them incorrectly. To help with this, effects now automatically resubscribe on errors (instead of completing) so they continue to listen to dispatched actions. This is extremely helpful but it can also be disabled if you start noticing weird behaviors. Simply pass `{ resubscribeOnError: false }` as the second argument of the `createEffect` function. 

As with the other two examples, there's a [schematic to add the new style of effect](https://ngrx.io/guide/schematics/effect) to your application:

```bash
ng generate @ngrx/schematics:effect myNewEffect --creators
```

This command will generate a new file called `my-new-effect.effects.ts` that imports `createEffect` and creates a class marked with the `Injectable` decorator.

## Aside: You Might Need Authentication (Even Though "You Might Not Need NgRx")
Most applications these days are going to need some sort of identity management to persist user profile information and handle authentication and authorization. To implement an identity management strategy in your NgRx application, some of the syntax has changed with version 8, but the core principles remain the same. You'll use actions for logging in and logging out and effects for calling your authentication service, while your reducer handles modifications to state like logged in status and profile attributes.

I cover this at length in my [NgRx authentication tutorial](https://auth0.com/blog/ngrx-authentication-tutorial/). Go ahead and <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account</a> and dig in to the tutorial to get started.

![Auth0's Lightweight Universal Login modal window](https://images.ctfassets.net/23aumh6u8s0i/54lZ5srDBAM0dqWSRkdxXk/f4260dcf2af6e7b5b4a52c62769e0745/lightweight-login)

By the way, I'd love to hear how it goes while using the new helper functions in version 8 of NgRx, so reach out on our [Community Forum](https://community.auth0.com/) any time.

## Conclusion
I don't know about you, but I couldn't be happier with NgRx 8. This is a team of volunteers who are making great software and even writing [phenomenal docs](https://ngrx.io/docs). With all of the improvements in this version, the future is looking bright. Give it a test drive and let me know how it goes!


Faster App Development with NgRx 8

30b8d1b7c0dab4bb311c121a47a6aae9?s=80 avatar

30b8d1b7c0dab4bb311c121a47a6aae9?s=80

Guest Author

Vladimir Fomene

This article demonstrates how you can use Project Lombok library to avoid boilerplate code from your Java projects.

Avoiding Java Boilerplate Code with Project Lombok

ryan-chenkie

Ryan is a full-stack JavaScript developer and trainer who mainly works with React, Angular, Node, and GraphQL. He runs a consultancy where he builds apps for companies and also helps established dev teams with their modern JavaScript challenges.<br /><br />Ryan is a Google Developer Expert, the host of the Entrepreneurial Coder Podcast, the author of Securing Angular Applications, and an all-around fanatic about application security.

Developer

Ryan Chenkie

JavaScript modules and build steps are getting more numerous and complicated, but what about boilerplate in new frameworks?



---
**TL;DR:** Frameworks like [Falcor](https://netflix.github.io/falcor/) and [Relay](https://facebook.github.io/relay/) solve some hard problems but come at the cost of requiring a lot of boilerplate. Perhaps the boilerplate is a necessity, but this likely has implications for developer uptake.

To get a sense of each, check out our getting started tutorials for both [Falcor](https://auth0.com/blog/2015/08/28/getting-started-with-falcor/) and [Relay](https://auth0.com/blog/2015/10/06/getting-started-with-relay/).

---

There’s been a lot of talk about JavaScript fatigue lately, and perhaps rightly so. It can be tough to keep up with all the new frameworks, modules, and libraries that pop up every day, and now that we’re in the era of next gen JavaScript and the build step, things can be even more difficult when we throw in transpilation and build tools.

We’ve even got people that are [really angry](https://medium.com/@wob/the-sad-state-of-web-development-1603a861d29f#.x1zwe3db2) about the current state of JavaScript and web development. Personally, I find this a kind of anger to be pretty odd. Everyone is entitled to their opinion of course, but getting mad about technology that is both **optional** and **free** just seems weird.

There’s no shortage of JavaScript fatigue articles of course.

<blockquote class="twitter-tweet" lang="en"><p lang="en" dir="ltr">I&#39;m fatigued by JavaScript fatigue articles</p>&mdash; James Kyle (@thejameskyle) <a href="https://twitter.com/thejameskyle/status/680949037516718085">December 27, 2015</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

A lot of these articles center around modules and build tools, but I’d like to explore something we haven’t heard as much about: **boilerplate**.

## Where are we Seeing Boilerplate?

One of the cool things about writing content at Auth0 is that I get to explore a lot of awesome new technologies every week. While doing this, it has become apparent that many of these technologies require a fair bit of boilerplate just to get going. Which ones exactly? I’m thinking specifically about frameworks like [Falcor](https://netflix.github.io/falcor/) and [Relay](https://facebook.github.io/relay/). I’ve also seen it with libraries like Flux and Redux, but I think in that case, it’s more of an ecosystem thing. Unidirectional data flow setups in general tend to have more boilerplate.

So let’s talk about Falcor and Relay. To start, what are they? In broad terms, both of them are used to help us with data interactions between the client and server sides of our apps. Falcor was created by Netflix and Relay by Facebook. With both, we set up a single endpoint on the server (virtual JSON model in Falcor and GraphQL endpoint in Relay), instead of sending data to and receiving it from multiple endpoints.

> **Note:** This article doesn't make a direct comparison between Falcor and Relay, but rather looks at the amount of code required to use them. It is recognized that while they have similarities, they don’t serve exactly the same purpose. Also, I know Falcor identifies as a library and Relay as a framework, but let’s keep things simple and just call them frameworks

Falcor gives us powerful features like data de-duping and Relay is great at providing only the data a given React component needs at the time it is needed. Both of the frameworks let us do things that would be really difficult to do manually. So what’s the catch?

> We’ve written full tutorials on these frameworks. Read more about [Falcor](https://auth0.com/blog/2015/08/28/getting-started-with-falcor/) and [Relay](https://auth0.com/blog/2015/10/06/getting-started-with-relay/).

## The High Boilerplate Framework

Looking at the getting started examples for [Falcor](https://netflix.github.io/falcor/) and [Relay](https://facebook.github.io/relay/), it’s easy to see that even a `Hello World` app requires quite a bit of code. That’s fine, a lot of it is just configuration to get the system wired up. Where I see the boilerplate really start to grow is when we get some actual routes set up.

Let’s look at what’s needed to set things up for a single data resource. From our previous tutorials, here’s a bit of what we need for a single route in **Falcor**:

```js
// 1. We needs some data, which is truncated for this example
var model = new falcor.Model({
  cache: {
    events: [
      {
        name: "ng-conf",
        description: "The worlds best Angular Conference",
        location: $ref('locationsById[1]')
      },
      ...
    ]
  }  
});

// 2. We need a data source route
app.use('/model.json', falcorExpress.dataSourceRoute(function(req, res) {
  return new Router([
    {
      // Our route needs to match a pattern of integers that
      // are used as eventIds
      route: "events[{integers:eventIds}]['name', 'description']",
      get: function(pathSet) {

        var results = [];

        // Above we specified an eventIds identifier that is an
        // array of ids which we can loop over
        pathSet.eventIds.forEach(function(eventId) {

          // Next, an array of key names that map is held at pathSet[2]
          pathSet[2].map(function(key) {

            // We find the event the cooresponds to the current eventId
            var eventRecord = eventsData.events[eventId];

            // Finally we push a path/value object onto
            // the results array
            results.push({
              path: ['events', eventId, key],
              value: eventRecord[key]
            });
          });          
        });

        return results;
      }      
    }
  ]);
}));
```

To call it from the front end:

```js
// front-end.js

...

.get(["events", {from: 0, to: 2}, ["name", "description"]]);

...
```

And here’s what we need for **Relay**:

```js
// 1. We need a schema
var userType = new GraphQL.GraphQLObjectType({
  name: 'User',
  description: 'A person who uses our app',
  isTypeOf: function(obj) { return obj instanceof db.User },

  fields: function() {
    return {
      id: GraphQLRelay.globalIdField('User'),
      name: {
        type: GraphQL.GraphQLString,
        description: 'The name of the user',
      },

      // We can set up a relationship between users and conferences here
      conferences: {
        description: 'A listing of the user\'s conferences',

        // Relay gives us helper functions to define the Connection and its args
        type: GraphQLRelay.connectionDefinitions({name: 'Conference', nodeType: conferenceType}).connectionType,

        // argument to tell GraphQL which user to pass back
        // in the resolve block
        args: {
          userToShow: { type: GraphQL.GraphQLInt }
        },

        // The resolve block will complete a query and pass back
        // data for the user id supplied by the arguments we pass in
        resolve: function(user, args) {
          return GraphQLRelay.connectionFromArray(db.getConferencesByUser(args.userToShow), args)
        },
      },
    }
  },
  interfaces: [nodeDefinitions.nodeInterface],
});

// 2. We need to export the schema
// Types and queries are exported with GraphQLSchema
module.exports = new GraphQL.GraphQLSchema({
  query: new GraphQL.GraphQLObjectType({
    name: 'Query',
    fields: {
      // Relay needs this to query Nodes using global IDs
      node: nodeDefinitions.nodeField,
      // Root queries
      user: {
        type: userType,
        resolve: function() {
          return db.getUser(1)
        },
      },
    },
  }),
});

// 3. We also need to export a container
exports.Container = Relay.createContainer(ConferenceApp, {
  // We initially want to get the first user's conferences
  initialVariables: {
    userToShow: 1
  },
  fragments: {
    // Results from this query will be placed on this.props for access in
    // our component
    user: () => Relay.QL`
      fragment on User {
        name,
        conferences(userToShow: $userToShow) {
          edges {
            node {
              id,
              name,
              description
            },
          },
        },
      }
    `
  },
});

```

Again, configuration is a big part of this, but there’s also a fair amount of logic just to gather and prepare our data to be sent back. Now I’m sure there are places where we could trim things up a bit, but even the official guides have a lot of code involved.

In this way, I’ve come to think of Falcor and Relay as High Boilerplate Frameworks. At the same time, they are inherently somewhat complex as well. While they are both great at doing what they do, I think this creates an unfortunate implication: **lots of boilerplate can be confused with complexity and people prefer simple to complex**.

## Approachability

When it comes down to it, most of us like things to be simple. It’s easy to get excited about a technology that makes quick work out of something that used to take a lot of time, effort, and code. I find that even if a framework or library has a learning curve and requires a lot of code for real-world use, I can get on board pretty easily if I can get *something* up and running quickly.

With all the configuration and boilerplate required to get going with Falcor and Relay, one of their downsides is that they are inherently less approachable. Some people haved [pushed for API changes](https://github.com/facebook/relay/issues/124), but I imagine more have abandoned their exploration altogether, which is unfortunate.

## Next Gen JavaScript Compounds the Issue

I recall watching a talk from ng-conf where the speaker said that a lot of the issues and questions the Angular team received were actually JavaScript related and didn’t have a lot to do with Angular. Language misunderstandings will likely always cause some trouble, sure, but I think we’re at a spot now where next gen JavaScript and the need for transpilation tools can easily be conflated with the complexities of a framework. Take this snippet of Relay from the docs for example:

```js
fragments: {
    game: () => Relay.QL`
      fragment on Game {
        scores(
          numToShow: $numToShow,
          sortDirection: $sortDirection
        ) {
          ${Score.getFragment('score')},
        },
      }
    `,
  }
```

If the developer isn’t yet familiar with arrow functions and template strings, even this simple example makes it look like the framework has a bunch of weird stuff when really this is just new JavaScript. If the developer is thrown off just by the language at this point, things don’t get much better when they eventually try to set up a [mutation](https://facebook.github.io/relay/docs/guides-mutations.html#content).

## What Does this Look Like in the Wild?

When setting up simple examples for Auth0’s tutorials I remember thinking that I can’t imagine building a full-fledged app in either of them. I’m curious about the experience of those who have and what their thoughts are about the boilerplate situation.

It would also be interesting to see how the companies that created Falcor and Relay (Netflix and Facebook respectively) make use of them. I wouldn’t be surprised if they have internal tools that provide some further abstraction which simplifies their use.

## Aside: Falcor and Relay Authentication is Easy with Auth0

Auth0 simplifies common authentication needs like social login, multi-factor authentication, and single sign-on. You can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for an account</a> and get 7,000 regular active users for free.

To add Authentication to Falcor, simply install and setup **express-jwt** and **jwks-rsa** with your Auth0 credentials and add the middleware to your route. Also set up an API like so:

1. Under your account name in the upper right corner of your [**Auth0 Dashboard**](https://manage.auth0.com/#/), choose **Account Settings** from the dropdown, then select the [**Advanced**](https://manage.auth0.com/#/account/advanced) tab. Scroll down to the **Settings** section and turn on the toggle for **Enable APIs Section**. Now you will have a link to manage [APIs](https://manage.auth0.com/#/apis) in your dashboard left sidebar navigation.
2. Go to [**APIs**](https://manage.auth0.com/#/apis) in your dashboard and click on the "Create API" button. Enter a name for the API. Set the **Identifier** to your API endpoint URL. In this example, this is `http://localhost:3001/api/`. The **Signing Algorithm** should be `RS256`.
3. You can consult the Node.js example under the **Quick Start** tab in your new API's settings.

```js
// server.js

...

var authenticate = jwt({
  secret: jwks.expressJwtSecret({
        cache: true,
        rateLimit: true,
        jwksRequestsPerMinute: 5,
        jwksUri: "https://{YOUR-AUTH0-DOMAIN}/.well-known/jwks.json"
    }),
    // This is the identifier we set when we created the API
    audience: '{YOUR-API-AUDIENCE-ATTRIBUTE}',
    issuer: "{YOUR-AUTH0-DOMAIN}",
    algorithms: ['RS256']
});


app.use('/api/model.json', authenticate, falcorExpress.dataSourceRoute(function(req, res)
  {
    return new Router([
      {...}
    ]);
  }
));

...
```

Then send an `Authorization` header with the requests to your model.

```js
// front-end.js

var token = localStorage.getItem('access_token');

var model = new falcor.Model({
  source: new falcor.HttpDataSource('/api/model.json', {
    // Send the token as an Authorization header
    headers: {
      'Authorization': 'Bearer ' + token
    }
  })
});
```

The steps for Relay are similar, but the endpoint is specific to GraphQL.

```js
// server.js

...

app.use('/graphql', authenticate, graphqlHttp({schema: schema}));

...
```

To add the `Authorization` header, use Relay’s network layer.

```js
// front-end.js

var token = localStorage.getItem('access_token');

Relay.injectNetworkLayer(
  new Relay.DefaultNetworkLayer('http://localhost:3000/graphql', {
    headers: {
      Authorization: 'Bearer ' + token
    }
  })
);
```

**Important API Security Note:** If you want to use Auth0 authentication to authorize _API requests_, note that you'll need to use [a different flow depending on your use case](https://auth0.com/docs/api-auth/which-oauth-flow-to-use). Auth0 `idToken` should only be used on the client-side. [Access tokens should be used to authorize APIs](https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/). You can read more about [making API calls with Auth0 here](https://auth0.com/docs/apis).


## A Final Word

Maybe the audience that frameworks like Falcor and Relay are intended for is one that itself is more advanced in terms of tech know-how. Perhaps this audience can see through the complexity and boilerplate requirements and look straight at the benefits that can be gained. Even if this is the case, I think there is a huge camp that understands and appreciates the problems that these frameworks are trying to solve, but are turned off by everything that is required to solve them.

I’m sure the newcomers aren’t alone. I doubt that seasoned developers like writing a lot of boilerplate and I have a feeling they have a special appreciation for simple and approachable APIs.

All this considered, I think High Boilerplate Frameworks like Falcor and Relay would do well to simplify their APIs and make themselves more approachable to noobs and veterans alike.

<include src="TweetQuote" quoteText="High Boilerplate Frameworks like Falcor and Relay would do well to simplify their APIs"/>

What do you think about the boilerplate required in frameworks like Falcor and Relay? Has this hindered you from getting started with them? If you’re working with them, is it hindering productivity, or do the benefits they bring outweigh the amount of boilerplate that is needed?


"boilerplate"