What Battlefront II Means for Game Monetization - by Daniel Chamberlin Blogs - 29 November 2017 - 7:19am
A reflective look on Battlefront II's tumultuous launch and what impact this will have (if any) on game monetization in the future.
Categories: Game Theory & Design

The Risky Nature of the Game Industry - by Josh Bycer Blogs - 29 November 2017 - 7:19am
This recent Black Friday was a great time for consumers, but highlights some major problems with making a living off of video games.
Categories: Game Theory & Design

So you’ve got an email sign-up button on your site, now what? - by Megan Carriker Blogs - 29 November 2017 - 7:17am
Here are a few tips to get your company to send emails on a regular basis, even if you’re on the fence about doing so, so that when you need to email people you've already got a good system in place.
Categories: Game Theory & Design

Email Marketing 101: How To Actually Use Your Mailing List - by Chris Zukowski Blogs - 29 November 2017 - 7:16am
If you are confused about the differences between social media and email marketing, read this guide. I will teach you what you need to send your email list.
Categories: Game Theory & Design

Why Most Modern Game Soundtracks Are Lifeless and Boring(Inspired by the Marvel Symphonic Universe Video) - by Kian How Yoa Blogs - 29 November 2017 - 7:05am
These days, most games across the range of indie, console, mobile are suffering from a very cancerous disease - Lack Of Originality aka "everything sounds the same" and/or "the music is there for the sake of being there". Read on to find out why.
Categories: Game Theory & Design

A few ideas when pricing your indie game - by Nazgum Darktooth Blogs - 29 November 2017 - 7:05am
If you were to launch your indie game today, how would you price it? Probably one of the more stress-inducing questions you will need an answer for. So how do you choose?
Categories: Game Theory & Design

Random Coping Chess Up On Kickstarter

Tabletop Gaming News - 29 November 2017 - 7:00am
I enjoy a good game of Chess. It’s been a while since I played, but I used to get in a game just about every day during lunch. I like the game just fine, but occasionally I wish there was a bit… more to it. Well, that’s what you get in Random Coping Chess. It […]
Categories: Game Theory & Design

Lullabot: Decoupled Drupal Hard Problems: Routing

Planet Drupal - 29 November 2017 - 7:00am

As part of the Decoupled Hard Problems series, in this fourth article, I'll discuss some of the challenges surrounding routing, custom paths and URL aliases in decoupled projects. 

Decoupled Routing

It's a Wednesday afternoon, and I'm using the time that Lullabot gives me for professional development to contribute to Contenta CMS. Someone asks me a question about routing for a React application with a decoupled Drupal back-end, so I decide to share it with the rest of the Contenta Slack community and a lengthy conversation ensues. I realize the many tendrils that begin when we separate our routes and paths from a more traditional Drupal setup, especially if we need to think about routing across multiple different consumers. 

It's tempting to think about decoupled Drupal as a back-end plus a JS front-end application. In other words, a website. That is a common use case, probably the most common. Indeed, if we can restrict our decoupled architecture to a single consumer, we can move as many features as we want to the server side. Fantastic, now the editors who use the CMS have many routing tools at their disposal. They can, for instance, configure the URL alias for a given node. URL aliases allow content editors to specify the route of a web page that displays a piece of content. As Drupal developers, we tend to make no distinction between such pieces of content and the web page that Drupal automatically generates for it. That's because Drupal hides the complexity involved by making reasonable assumptions:

  •  It assumes that we need a web page for each node. Each of those has a route node/<nid> and they can have a custom route (aka URL alias).
  •  It means that it is okay to add presentation information in the content model. This makes it easy to tell the Twig template how to display the content (like field_position = 'top-left') in order to render it as the editor intended.

Unfortunately, when we are building a decoupled back-end, we cannot assume that our pieces of content will be displayed in a web page, even if our initial project is a website. That is because when we eventually need a second consumer, we will need to make amends all over the project to undo those assumptions before adding the new consumer.

Understand the hidden costs of decoupling in full. If those costs are acceptable—because we will take advantage of other aspects of decoupling—then a rigorous separation of concerns that assigns all the presentation logic to the front-end will pay off. It takes more time to implement, but it will be worth it when the time comes to add new consumers. While it may save time to use the server side to deal with routing on the assumption that our consumer will be a single website,  as soon as a new consumer gets added those savings turn into losses. And, after all, if there is only a website, we should strongly consider a monolithic Drupal site.


After working with Drupal or other modern CMSes, it's easy to assume that content editors can just input what they need for SEO purposes and all the front-ends will follow. But let's take a step back to think about routes:

  • Routes are critical only for website clients. Native applications can also benefit from them, but they can function with just the resource IDs on the API.
  • Routes are important for deep linking in web and native applications. When we use a web search engine in our phone and click a link, we expect the native app to open on that particular content if we have it installed. That is done by mapping the web URL to the app link.
  • Links are a great way to share content. We want users to share links, and then let the appropriate app on the recipient's mobile device open if they have it installed.

It seems clear that even non-browser-centric applications care about the routes of our consumers. Luckily, Drupal considers the URL alias to be part of the content, so it's available to the consumers. But our consumers' routing needs may vary significantly.

Routing From a Web Consumer

Let's imagine that a request to hits our React application. The routing component will know that it needs to use the recipes resource and find the node that has a URL alias of /4-hour-lamb-stew. Contenta can handle this request with JSON API and Fieldable Path—both part of the distribution. With the response to that query, the React app builds all the components and displays the results to the user.

It is important to note the two implicit assumptions in this scenario. The first is that the inbound URL can be tokenized to extract the resource to query. In our case, the URL tells us that we want to query the /api/recipes resource to find a single item that has a particular URL alias. We know that because the URL in the React side contains /recipes/... What happens if the SEO team decides that the content should be under How will React know that it needs to query the /api/recipes resource and not /api/articles?

The second assumption is that there is a web page that represents a node. When we have a decoupled architecture, we cannot guarantee a one-to-one mapping between nodes and pages. Though it's common to have the content model aligned with the routes, let's explore an example where that's not the case. Suppose we have a seasonal page in our food magazine for the summer season (accessible under /summer). It consists of two recipes, and an article, and a manually selected hero image. We can build that easily in our React application by querying and rendering the content. However, everything—except for the data in the nodes and images—lives in the react application. Where does the editor go to change the route for that page?

On top of that, SEO will want it so that when a URL alias changes (either editorially or in the front-end code) a redirect occurs, so people using the old URL can still access the content. Note that a change in the node title could trigger a change in the URL alias via Pathauto. That is a problem even in the "easy" situation. If the alias changes to, we need our React application to still respond to the old The old link may have been shared in social networks, linked to from other sites, etc. The problem is that there is no recipe with an alias of /recipes/4-hour-lamb-stew anymore, so the Fieldable Path solution will not cover all cases.

Possible Solutions

In monolithic Drupal, we'd solve the aforementioned SEO issue by using the Redirect module, which keeps track of old path aliases and can respond to them with a redirect to the new one. In decoupled Drupal, we can use that same module along with the new Decoupled Router module (created as part of the research for this article).

The Contenta CMS distribution already includes the Decoupled Router module for routing as we recommend this pattern for decoupled routing.

Pages—or visualizations—that comprise a disconnected selection of entities—our /summer page example—are hard to manage from the back-end. A possible solution could be to use JSON API to query the entities generated by Page Manager. Another possible solution would be to create a content type, with its corresponding resource, specific for that presentation in that particular consumer. Depending on how specific that content type is for the consumer, that will take us to the Back-end For Front-end pattern, which incurs other considerations and maintenance costs.

For the case where multiple consumers claim the same route but have that route resolve to different nodes, we can try the Contextual Aliases module.

The Decoupled Router

Decoupled Router is an endpoint that receives a front-end path and tries to resolve it to an entity. To do so it follows as many redirects and URL aliases as necessary. In the example of /recipes/four-hour-stewed-lamb it would follow the redirect down to /recipes/4-hour-lamb-stew and resolve that URL alias to node:1234. The endpoint provides some interesting information about the route and the underlying entity.


In a previous post, we discussed how multiple requests degrade performance significantly. With that in mind, making an extra request to resolve the redirects and aliases seems less attractive. We can solve this problem using the Subrequests module. Like we discussed in detail, we can use response tokens to combine several requests in one.

Imagine that we want to resolve /bread and display the title and image. However, we don’t know if /bread will resolve into an article or a recipe. We could use Subrequests to resolve the path and the JSON API entity in a single request.


In the request above, we provide the path we want to resolve. Then we get the following response.


To summarize, we can use Decoupled Router in combination with Subrequests to resolve multiple levels of redirects and URL aliases and get the JSON API data all in a single request. This solution is generic enough that it serves in almost all cases.


Routing in decoupled applications becomes challenging because of three factors:

  • Instead of one route, we have to think about (at least) two, one for the front-end and one for the back-end. We can mitigate this by keeping them both in sync.
  • Multiple consumers may decide different routing patterns. This can be mitigated by reaching an agreement among consumers. Another alternative is to use Contextual Aliases along with Consumers. When we want back-end changes that only affect a particular consumer, we can use the Consumers module to make that dependency explicit. See the Consumer Image Styles module—explained in a previous article—for an example on how to do this.
  • Some visualizations in some of the consumers don’t have a one-to-one correspondence with an entity in the data model. This is solved by introducing dedicated content types for those visualizations. That implies that we have access to both back-end and front-end. A custom resource based on Page Manager could work as well.

In general, whenever we need editorial control we'll have to turn to the back-end CMS. Unfortunately, the back-end affects all consumers, not just one. That may or may not be acceptable, depending on each project. We will need to make sure to consider this when thinking through paths and aliases on our next decoupled Drupal project.

Lucky for us, every project has constraints we can leverage. That is true even when working on the most challenging back-end of all—a public API that powers an unknown number of 3rd-party consumers. For the problem of routing we can leverage these constraints to use the mitigations listed above.

Hopefully, this article will give you some solutions for your Decoupled Drupal Hard Problems.

Photo by William Bout on Unsplash.

Categories: Drupal

Mediacurrent: Diversity at Mediacurrent: A Path Forward

Planet Drupal - 29 November 2017 - 6:53am

The issue of workforce diversity has been in the news a lot lately, and rightfully so. Diversity data is pretty dismal, particularly in the technology industry. Essentially, there is a long history of white males disproportionately holding leadership roles and minorities being immensely underrepresented. You already knew that though.

Categories: Drupal

Whatever Party Card Game Up On Kickstarter

Tabletop Gaming News - 29 November 2017 - 6:00am
What do you want to play? I dunno. I’m up for playing whatever. *gets out a copy of Whatever, the party card game* Gotcha! Whatever is a new party card game that’s up on Kickstarter. Participate in truth-or-dare style dares or compete in competitions with another player. Can’t handle the heat? Draw a penalty card […]
Categories: Game Theory & Design

CMON Partners with Steve Jackson Games to Make Munchkin Board Games

Tabletop Gaming News - 29 November 2017 - 3:05am
Just about all of us have played some version of Munchkin in our time as gamers. It’s a fun, little card game from Steve Jackson that takes the usual tropes of dungeon delving (or going into space, or pirates, or faeries, or a hundred other things it’s spun off into) and turns them on their […]
Categories: Game Theory & Design

Colorfield: Drupal 8, React, Vue, JSON API and ES6 learning resources

Planet Drupal - 29 November 2017 - 1:24am
Drupal 8, React, Vue, JSON API and ES6 learning resources christophe Wed, 29/11/2017 - 10:24

Start by Contenta or Reservoir and if you are still hungry, here are some clues.

Categories: Drupal

The RPGnet Interview: Russell Morrissey, What is Old is New

RPGNet - 29 November 2017 - 12:00am
A look at the WOIN system and Xenomorphs.
Categories: Game Theory & Design

Drutopia Resource

New Drupal Modules - 28 November 2017 - 7:38pm

A base feature providing a resource content type and related configuration.

Development is on GitLab and mirrored here.

Categories: Drupal

Discount code

New Drupal Modules - 28 November 2017 - 6:43pm

Discount code for your site. Add useres code when they register.

Categories: Drupal

Entity Reference, Flexiform Connect

New Drupal Modules - 28 November 2017 - 5:12pm
Categories: Drupal

Tag1 Consulting: Background Image - A New Drupal 8 Module

Planet Drupal - 28 November 2017 - 5:00pm
Introducing a new, easy to use, Drupal 8 module for background images: If your site is designed around utilizing background images, then this module is for you! Whether you need a surgical implementation that only administrators/developers can implement or provide the ability to allow users to attach their own background images to entities, this module has you covered.Read more markcarver Tue, 11/28/2017 - 17:00
Categories: Drupal Blog: AGILEDROP: Drupal meetup with two great sessions

Planet Drupal - 28 November 2017 - 4:51pm
In the middle of November, we organized a Drupal meetup. Meetup is a great way to connect web developers, designers, and other web enthusiasts. We were hosting two lecturers, David Ličen from Slovenia and Philipp Melab from Austria. In this blog post, you can learn, what they shared with us.   David Ličen, Slovenia: “Drupal point of Vue” The Drupal point of Vue session, led by David Ličen, was a very good introduction to the decoupled Drupal, where the web application and server are separated. Session attendees were acquainted with the basics of a very simple yet powerful JavaScript… READ MORE
Categories: Drupal

Configuration Read-only Filter

New Drupal Modules - 28 November 2017 - 4:40pm

Allows to exclude certain configuration forms to be editable, when the site is on configuration read-only mode.
Filters can be created with set of form id or route name. Since filters are config entities, can be exported/imported like any other configuration.


1. Filter by Form ID
2. Filter by Route name - This is not supported yet.

  1. Configuration Read-only mode
Categories: Drupal

Inside the PUBG-fueled rise of 'chicken eating games' in China

Social/Online Games - Gamasutra - 28 November 2017 - 4:30pm

The latest issue of the Magpie Kingdom newsletter explores how quickly Chinese hacking and cloning industries seem to have sprung up around PUBG, and it makes for fascinating reading. ...

Categories: Game Theory & Design


Subscribe to As If Productions aggregator