eaeac922b9f3cc9fd18cb9629b9e79f6?s=80 avatar

eaeac922b9f3cc9fd18cb9629b9e79f6?s=80

Guest Author

Daniel James

Learn how to use Auth0 Webtasks to build a twitter bot that pulls data from Data.gov and does sentiment analysis



# I built a Twitter bot using Auth0 Webtasks and Data.gov

I wanted to build something small, fun, and socially-engaging. I have been following [Darius Kazemi][kazemi-website] ([@TinySubversions][kazemi-twitter]) and the community of bot makers at [Botwiki][botwiki-website] ([@Botwikidotorg][botwiki-twitter]), and I decided a Twitter bot was the way to go. I have also been following the US Executive Order 13792 pretty closely. The order directs the US Department of Interior to review whether to downsize "certain national monuments" or sell their oil and mineral rights for profit. The Department has an open ["Opportunity for Public Comment."][docket] I thought this would be a good chance to tinker with lightweight sentiment analysis of the public comments.

I needed a good place to host my small project, and Auth0's free [Webtask.io][webtask-io] offering turned out to be a great fit! I didn't want to sacrifice my time on infrastructure and hosting when I wanted to focus on this bot idea. I got to attend Glenn Block's Auth0 Webtasks workshop at .NET Fringe this year, and he fired me up to do this.

The [Auth0 Webtask.io Editor][webtask-io-editor] is nice, but I have a set of development tools I like. I also wanted to import npm modules to handle the sentiment analysis and Twitter posting. The Auth0 Webtasks CLI is perfect for this.

```bash
# Install the CLI globally
npm i -g wt-cli
# Log in to my Webtask.io account
wt-init
```

Next, I needed to set up my project in a new folder

```bash
# Use source control always
git init
# Create a package.json and fill in the basics
npm init
# Install modules that I'll need for this bot
npm install --save twitter sentence-tokenizer sentiment md5 node-fetch
```

I prefer writing ES6, so I'll be adding `'use latest'` to the top of my scripts. I want to split my logic into a couple of different modules, so I'll use the CLI to bundle my scripts (`-b`). While I'm hacking, I also want to have automatically update my webtask when I save, so I'll have the CLI watch for changes (`-w`). Finally, I have some API keys that I don't want to hard-code, so I'll create a file called `.secrets` to hold on to those for me. (And add `.secrets` to `.gitignore` so it doesn't accidentally get committed!)

```bash
wt create -b -w --secrets-file .secrets .
```

The first of my secrets to go in the `.secrets` file is my Data.gov API key. (It's free and [easy to sign up][data-gov] for, and provides access to other US government data besides Regulations.gov.) Next, I created a new Twitter account called [@EO13792Bot][eo13792bot-twitter] and created a [Twitter app][twitter-apps] for it. I copied the Consumer Key and Secret, and the Access Token and Secret into the `.secrets` file.

There are four distinct parts to this webtask:

* [Regulations.gov API client][regulations-gov-api-client]
* [Text analyzer][text-analyzer]
* [Comment selector and formatter][comment-selector-and-formatter]
* [Tweeter][tweeter]

The Regulations.gov API client exports a function to get the latest comments for a given docket. ([DOI-2017-0002][docket], in this case.) After testing requests against the API, it was necessary to add a timeout to `fetch`.

Source: [quoter/src/regulations-gov-api.js][regulations-gov-api-client]

```javascript
export default (apiKey, docketId, count) => new Promise((resolve, reject) => {
    fetch(`${baseUrl}/documents.json?api_key=${apiKey}&dktid=${docketId}&dct=PS&sb=postedDate&so=DESC&rpp=${count}`)
        .then(response => response.json())
        .then(page => page.documents)
        .then(resolve);

    setTimeout(reject.bind(null, {
        type: 'source-api-timeout'
    }), 25000);
})
```

The text analyzer exports a function to analyze a single comment. I found sentences with the most "negative" sentiment analysis score were [subjectively] the most interesting. I decided to use the most "negative" sentence from a comment as its "pull quote" candidate for tweeting. The text analyzer also hashes the comment to only consider identical "form letter" comments once.

Source: [quoter/src/analyzer.js][text-analyzer]

```javascript
export default (commentText) => {
  // The Tokenizer has a notion of words describing itself. Not used here.
  const tokenizer = new Tokenizer('unused', 'unused');
  tokenizer.setEntry(commentText);

  const pullQuote = tokenizer.getSentences()
    // Score each sentence
    .map(sentence => ({
      sentence,
      score: sentiment(sentence).score,
    }))
    // Select a single sentence with the most negative score and the longest character length
    .reduce((min, curr) => {
      const last = min || curr;
      return last.score < curr.score
        ? last
        : (
          last.sentence.length < curr.sentence.length ? curr : last
        );
    });
  
  // Hash the comment for duplication checks
  const hash = md5(tokenizer.getTokens().join(' '));

  return {
    pullQuote,
    hash,
  };
};
```

The [comment selector and formatter][comment-selector-and-formatter] exports a function that ultimately returns a single comment to tweet. It gets the comments from the Regulations.gov API client and maps each comment through the text analyzer. It takes in a list of hashes from previous tweets to exclude those comments. It also ensures that the pull quote can fit into a tweet.

The tweeter is the main body of the webtask. It initializes the Twitter client, gets the list of hashes out of the webtask context storage, and calls the comment selector and formatter to pick its tweet. Once it successfully tweets, the hash is added to the list in context storage.

Source: [quoter/src/index.js][tweeter]

```javascript
module.exports = (ctx, cb) => {
  const docketId = 'DOI-2017-0002';
  const apiKey = ctx.secrets.REGULATIONS_GOV_API_KEY;
  const backlogCount = 500;

  // Set up Twitter API client
  const client = new Twitter({
    consumer_key: ctx.secrets.TWITTER_CONSUMER_KEY,
    consumer_secret: ctx.secrets.TWITTER_CONSUMER_SECRET,
    access_token_key: ctx.secrets.TWITTER_ACCESS_TOKEN_KEY,
    access_token_secret: ctx.secrets.TWITTER_ACCESS_TOKEN_SECRET
  });

  // Get the context storage into `data`
  ctx.storage.get((error, data) => {
    const backlog = data || {};

    if (ctx.data.dump) {
      cb(null, backlog);
      return;
    }

    // Get a single comment to tweet
    getSingleComment(apiKey, docketId, backlogCount, backlog)
      // Then tweet it
      .then(document => {
        const status = `${document.tweet} ${document.targetUrl}`;
        return client.post('statuses/update', { status }).then(() => document);
      })
      // Then add the comment's hash to the context storage 
      .then(document => {
        backlog[document.hash] = true;
        backlog.lastError = null;
        // If something bad happened while saving to context storage, log it to STDERR and move on. No big deal.
        ctx.storage.set(backlog, console.error);
        return document;
      })
      // Then hit the webtask's callback and end this request
      .then(cb.bind(null, null))
      // If anything went wrong with the above, handle it
      .catch(err => {
        console.error('error', err);
        /* snip; Do some handling of specific errors */
      });
  })
}
```

Testing this work is as simple as hitting the webtask's endpoint in a browser. However, I wanted this to run on its own, checking for comments and tweeting every 10 minutes. I set up the webtask on a schedule with a simple change to the CLI command:

```bash
wt cron schedule -b --secrets-file .secrets 10m .
```

In order to make my code a little more usable by other developers and to save myself from having to remember all the switches for the CLI, I added two scripts to my `package.json` file. Also, I added `wt-cli` as a dev dependency.

Source: [quoter/package.json][package-file]

```json
"scripts": {
    "start": "wt create -w -b --secrets-file ../.secrets .",
    "publish": "wt cron schedule -b --secrets-file ../.secrets 10m ."
},
```

Now [@EO13792Bot][eo13792bot-twitter] is tweeting on its own! Following the bot has given me an insight into some of the 300,000 comments that people have made. And I'm ecstatic to spend my time hacking on my bot ideas and trust the infrastructure and hosting to Auth0!

I've made the source for [@EO13792Bot][eo13792bot-twitter] available on [GitHub][eo13792bot-website]. Take a peek!

[kazemi-website]: http://tinysubversions.com/
[kazemi-twitter]: https://twitter.com/tinysubversions
[botwiki-website]: https://botwiki.org/
[botwiki-twitter]: https://twitter.com/botwikidotorg
[docket]: https://www.regulations.gov/document?D=DOI-2017-0002-0001
[eo13792bot-website]: https://github.com/thzinc/eo13792bot
[eo13792bot-twitter]: https://twitter.com/eo13792bot
[twitter-apps]: https://apps.twitter.com/
[data-gov]: https://api.data.gov/signup/
[regulations-gov-api-client]: https://github.com/thzinc/eo13792bot/blob/master/quoter/src/regulations-gov-api.js
[text-analyzer]: https://github.com/thzinc/eo13792bot/blob/master/quoter/src/analyzer.js
[comment-selector-and-formatter]: https://github.com/thzinc/eo13792bot/blob/master/quoter/src/tweetUtils.js
[tweeter]: https://github.com/thzinc/eo13792bot/blob/master/quoter/src/index.js
[package-file]: https://github.com/thzinc/eo13792bot/blob/master/quoter/package.json
[webtask-io]: https://webtask.io/
[webtask-io-editor]: https://webtask.io/make


How I Built a Twitter Bot Using Auth0 Webtasks and Data.gov

53f70144dc9d7c76455fa91f858d4cec?s=200 avatar

53f70144dc9d7c76455fa91f858d4cec?s=200

Tomasz Janczuk

Customize Auth0 platform with Node.js using Auth0 Hooks, a new extensibility mechanism powered by Webtasks.

<div class="alert alert-danger alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>We are deprecating Auth0 Rules and Hooks by November 18, 2024. To learn more about what's changing, check out the <a href="https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/">deprecation announcement blog post</a>.</strong>
</div>

Auth0 Hooks are a new extensibility mechanism in Auth0 that allows you to customize the behavior of our platform using Node.js.

-----

## Developers love code and extensibility

Customization flexibility has always been an integral part of the Auth0 platform. Until now, you could use [Auth0 Rules](https://auth0.com/docs/rules) to execute arbitrary Node.js code during an authorization transaction. Today, we are introducing [Auth0 Hooks](https://auth0.com/docs/auth0-hooks), a new and improved mechanism to extend the Auth0 platform using code.

![Auth0 Hooks in Webtask Editor](https://images.ctfassets.net/23aumh6u8s0i/7AhEd6rE5LSLZ32DLUJ3Ax/15c33539f6464608a138ce0e499bee8c/wt-editor-auth0-hooks)  

## Better developer experience

While Auth0 Hooks are building on the same underlying [Webtask](https://webtask.io) technology we have developed to run Auth0 Rules, several aspects of the developer experience are improved:

* Using the [management dashboard](https://auth0.com/docs/auth0-hooks/dashboard) you can create, move in and out of production, and edit hooks for selected extensibility points in the Auth0 platform.

![Auth0 Hooks dashboard](https://images.ctfassets.net/23aumh6u8s0i/5kHLjW7V9ovSFHxRAXhxxC/2dbccc8615c5308bb6c2adc7860f7ca4/manage-hooks)  

* You edit hooks in the Webtask Editor, which offers a much richer featureset compared to the experience you are used to with Auth0 rules.  
* Syntax completion allows you write the code faster without referring to documentation.  
* Integrated secret management improves the security of your code by providing a mechanism to securely store secrets while making them conveniently available in code.  
* Integrated runner allows you to test your code without leaving the webtask editor.  
* Real-time logs simplify debugging by streaming the output generated by your code.  
* GitHub integration allows you synchronize your hook with code stored in a github repository. Updating your hook is as simple as pushing to GitHub.  

## What can you do today

The initial release of Auth0 Hooks supports customizing the behavior of Auth0 at three new extensibility points:  

* [Client Credentials Exchange](https://auth0.com/docs/hooks/extensibility-points/credentials-exchange) allows you to change the scopes and add custom claims to issued access tokens.  
* [Pre User Registration](https://auth0.com/docs/auth0-hooks/extensibility-points/pre-user-registration) allows you to intercept creation of a new database user to enforce custom password policy, or employ application specific logic to prevent the signup.  
* [Post User Registration](https://auth0.com/docs/auth0-hooks/extensibility-points/post-user-registration) allows you to perform any actions as a result of a succcessful creation of a new database user, e.g. send a message to Slack, or create a record in your CRM system.  

This is just the beginning. We are going to be adding many more extensibility points in the Auth0 platform using the Auth0 Hooks mechanism in the future.   

## Auth0 Hooks vs Auth0 Rules

Introduction of Auth0 Hooks does not affect any existing Auth0 Rules. Your rules continue to work unchanged.

Auth0 Hooks provide a foundation for a new extensibility mechanism in Auth0. All future extensibility points in the platform will build on top of Auth0 Hooks. We are also planning to add support in Auth0 Hooks for the same things you use Auth0 Rules for today.   

## Differences with Auth0 Rules

If you have been using Auth0 Rules before, these are some of the key differences in the development experience when moving on to Auth0 Hooks:

* In Auth0 Rules, you are editing code on the Auth0 management dashboard. When using Auth0 Hooks, you edit code in the Webtask Editor.  
* When using Auth0 Rules, you are specifying rule configuration common to all rules on the Auth0 management dashboard. Auth0 Hooks allow you to specify secret configuration directly in the Webtask Editor, and separately for each hook.  
* When developing Auth0 Rules, you can dry run a rule from within the Auth0 management dashboard. Auth0 Hooks can be tested from within the Webtask Editor using the integrated runner and access to real-time logs. 
* Auth0 management HTTP APIs offer a way to manipulate Auth0 Rules using any HTTP client. Auth0 Hooks are managed using [Webtask management APIs](https://webtask.io/docs/101).  

## Aside: Auth0 Extend

We have recently released a product called [Auth0 Extend](https://auth0.com/extend/). This product enables companies to provide an easy extension point where customers can run arbitrary JavaScript code. With [Auth0 Extend](https://auth0.com/extend/), customers can create custom business rules, scheduled jobs, or connect to the ecosystem by integrating with other SaaS systems, like Marketo, Salesforce, and Concur. All using plain JavaScript and NPM modules.

## Learn more

> Give your customers enterprise identity integration, frictionless SSO across your products and adaptive authentication with MFA and Anomaly Detection. [All of this with a flip of a switch](https://auth0.com/b2b-enterprise-identity-management).

Check out the [Auth0 Hooks documentation](https://auth0.com/docs/auth0-hooks) or head over directly to the [Auth0 Hooks management dashboard](https://manage.auth0.com/#/hooks) to create your first hook.  


Introducing Auth0 Hooks

001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

Learn how to fix your Twitter share count with a simple HTTP proxy without a server using Webtasks



Recently Twitter decided to [shutdown](https://blog.twitter.com/2015/hard-decisions-for-a-sustainable-platform) one of its unofficial API endpoints: the URL share count. In this post we will show you how to get that functionality back with a simple [Webtask](https://webtask.io) acting as a proxy to a different counts provider.

-----

## The problem
Twitter used to provide a *non-public* API endpoint for URL share counts:

```
$ curl http://cdn.api.twitter.com/1/urls/count.json?url=http://my.url.com
{"count":27438,"url":"http:\/\/my.url.com\/"}
```

![Twitter share count](https://images.ctfassets.net/23aumh6u8s0i/4m43U8hB07Ec0PsCc2RrGu/2aea8f8a6794a65f6ff7200ee93c9a85/twittercount)

Although this endpoint was not public (and therefore Twitter never committed to supporting it), it stayed available for a long time and people started using it. Unfortunately this [changed recently](https://blog.twitter.com/2015/hard-decisions-for-a-sustainable-platform). However the need for a Twitter URL share count remained. At Auth0 we use URL share counts in our [blog](https://blog.auth0.com), so we had to find a way to fix this.

> It should be noted that as the endpoint was not public Twitter really can't be blamed for removing it.

## The alternative
So we set out to find an alternative service providing link counts on Twitter. We found [OpenShareCount](http://opensharecount.com/). The service basically works by performing periodic searches using the official Twitter search API, then counting the results and storing them for quick retrieval. If you are familiar with the Twitter API, then this should trigger an alarm: Twitter searches only go back a few days, so count results are not absolute. OpenShareCount resolves this by running the search periodically and adding up newer results. Good enough.

After signing up and setting up your domain for counts, a simple call to OpenShareCount's API will do the thing:

```
$ curl http://opensharecount.com/count.json?url=http://my.url.com
{"count":27438,"url":"http:\/\/my.url.com\/"}
```

> It should be noted that OpenShareCount does not support JSONP (using the callback parameter) as the old Twitter API did, so further changes to your site might be needed.

Looking good. However we still have one problem to solve: cross site requests.

## Another problem: the same origin policy
Our blog is hosted at [https://blog.auth0.com](https://blog.auth0.com) and OpenShareCount provides the API endpoint at `http://opensharecount.com/count.json?url=http://my.url.com`. There are two things we need to take into account:

1. The `Access-Control-Allow-Origin` header.
2. The use of the same communications protocol (HTTP or HTTPS).

By running a simple cURL test to the URL we see the `Access-Control-Allow-Origin` header is correctly set:

```
curl -v http://opensharecount.com/count.json\?url\=http://my.url.com
*   Trying 104.27.164.180...
* Connected to opensharecount.com (104.27.164.180) port 80 (#0)
> GET /count.json?url=http://my.url.com HTTP/1.1
> Host: opensharecount.com
> User-Agent: curl/7.45.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 10 Dec 2015 17:07:23 GMT
< Content-Type: text/html; charset=ISO-8859-1
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=d953733a4896a8010a92b07f02928451f1449767243; expires=Fri, 09-Dec-16 17:07:23 GMT; path=/; domain=.opensharecount.com; HttpOnly
< Vary: Accept-Encoding
< Access-Control-Allow-Origin: *
< CF-Cache-Status: MISS
< Expires: Thu, 10 Dec 2015 17:37:23 GMT
< Cache-Control: public, max-age=1800
< Server: cloudflare-nginx
< CF-RAY: 252a8bb960980320-MIA
<
* Connection #0 to host opensharecount.com left intact
{"url":"http://my.url.com","error":"Domain my.url.com not authorised, register for free at http://opensharecount.com first","count":0}
```

So the `Access-Control-Allow-Origin` header is not a problem. However the difference between HTTPS and HTTP *is*. Browsers forbid AJAX requests to non-TLS resources from a TLS-secured page.

### A Webtasks Proxy
The obvious solution to the problem above is a *proxy*. This proxy will simply provide a HTTPS frontend for the HTTP OpenShareCount API. This is a simple matter, but forces us to think about hosting, load-balancing and other stuff related to setting up a new service. As we face these problems daily, at Auth0 we developed [webtasks](https://webtask.io), which fit this problem domain perfectly.

Here's our simple HTTP to HTTPS proxy:

```
var url = require('url');
var request = require('request');

module.exports = function (ctx, cb) {
  var whitelist = ['metrics.it.auth0.com', 'opensharecount.com'];

  var targetUrl = ctx.data.url;
  var target = url.parse(targetUrl).hostname;
  var ok = whitelist.some(function (host) {
    return target === host;
  });

  if (!ok) {
    return cb(new Error('no way'));
  }

  request.get({url: targetUrl}, function(err, resp, body) {
     if (err) return cb(err);
     cb(null, JSON.parse(body));
  });
};
```

And this is our endpoint with parameters: `https://webtask.it.auth0.com/api/run/auth0/proxy?webtask_no_cache=1&url=http://opensharecount.com/count.json?url=LINK_COUNT_URL`

The proxy has a simple embedded whitelist to prevent misuse by third-parties. After running the whitelist filter, it performs an HTTP request and sends back the result to the original caller.

> Please note that browser restrictions with regards to access to unprotected resources from a TLS secured page are in place for a reason. Study carefully if the unprotected resource can be handled this way before doing something like this.

## Get Your Twitter Share Counts Back: Create Your Own Webtask!
If you are interested in learning more about webtasks or creating your own, head over to [https://webtask.io](https://webtask.io) and get started. With the webtasks command line interface, creating your first script is a matter of running a few commands:

<include src="TweetQuote" quoteText="With the webtasks command line interface, creating your first script is a matter of running a few commands."/>

```
npm install wt-cli -g
wt init your@email.com
echo "module.exports = function (cb) {cb(null, 'Hello');}" > hello.js
wt create hello.js
```

You can then run the webtask:

```
curl https://webtask.it.auth0.com/api/run/wt-sebastian_peyrott-auth0_com-0/hello?webtask_no_cache=1
```

Replace your webtask URL by the one returned by `wt create`.

## Conclusion
The decision to remove the link counts API by Twitter was unfortunate but perfectly understandable. It was never meant for public use. Fortunately OpenShareCount and Webtasks make a perfect fit for solving this issue as soon as possible and in a convenient manner. If you decide to use or extend our simple proxy sample, let us know in the comments. Good luck!


Get Your Twitter Share Count Back with a Webtask

Learn what are microservices and how they are used in the industry



Everybody is talking about microservices. Industry veterans may remember monolithic or SOA-based solutions being *the way* of doing things. Times have changed. New tools have allowed developers to focus on specific problems without adding excessive complexity to deployment or other administrative tasks that are usually associated with isolated services. It has become increasingly easy to choose to work with the right tool for the right problem.

In this **post series**, we will explore the world of microservices, how it can help solve real world problems, and why the industry is increasingly picking it as the standard way of doing things. In this series, we will attempt to tackle common problems related to this approach, and provide convenient and simple examples. By the end of the series, we should have a skeleton implementation of a full microservice-based architecture. Today, we will focus on what microservices are and how they compare to the alternatives. We will also list the problems we plan to discuss in the following posts.

**Update:** in [part 2](https://auth0.com/blog/2015/09/13/an-introduction-to-microservices-part-2-API-gateway/) we talk about the *API gateway*.

-----

## What is a microservice?
A microservice is an **isolated**, **loosely-coupled** unit of development that works on a **single concern**. This is similar to the old "Unix" way of doing things: do one thing, and do it well. Matters such as how to "combine" whatever is provided by the service are left to higher layers or to policy. This usually means that microservices tend to avoid interdependencies: if one microservice has a hard requirement for other microservices, then you should ask yourself if it makes sense to make them all part of the same unit.

<include src="TweetQuote" quoteText="A microservice is an isolated, loosely-coupled unit of development that works on a single concern."/>

![Typical microservices diagram](https://images.ctfassets.net/23aumh6u8s0i/7m1asvRD6piucFe4KV8F0M/c029abc6718f31599e602fdd133c057d/Microservices2)

What makes microservices particularly attractive to development teams is their **independence**. Teams can work on a problem or group of problems on their own. This creates several attractive qualities favored by many developers:

- **Freedom to pick the right tool**: Is that new library or development platform something you always wanted to use? You can (if it's the right tool for the job).
- **Quick iteration**: Was the first version suboptimal? No problem, version 2 can be out the door in no time. Because microservices tend to be small, changes can be implemented relatively quickly.
- **Rewrites are a possibility**: In contrast with monolithic solutions, since microservices are small, rewrites are a possibility. Was the technology stack the wrong pick? No problem, switch to the right alternative.
- **Code quality and readability**: Isolated development units tend to be of higher quality and new developers can get up to speed with the existing code fairly easily.

## Production-quality microservices
Now that we know what microservices are, here is a list of things we need to keep in mind when designing our microservice-based architecture. Don't worry if this seems too abstract; we will deal with all these concerns in a systematic way throughout this series of posts.

- **Cross-cutting concerns** must be implemented in a way such that microservices need not deal with details regarding problems outside their specific scope. For instance, authentication can be implemented as part of any API gateway or proxy.
- **Data sharing** is hard. Microservices tend to favor per-service or per-group databases that can be updated directly. When doing data modeling for your application, notice whether this way of doing things fits your application. For sharing data between databases, it may be necessary to implement an internal process that handles internal updates and transactions between databases. It is possible to share a single database between many microservices; just keep in mind that this may limit your options when and if you need to scale in the future.
- **Availability**: Microservices, by virtue of being isolated and independent, need to be monitored to detect failures as early as possible. In a big software stack, one service that goes down may go unnoticed for some time. Account for this when picking your software stack for managing services.
- **Evolution**: Microservices tend to evolve fast. When dedicated teams deal with specific concerns, new and better solutions are found quickly. Therefore, it is necessary to account for versioning of services. Old versions are usually available as long as there are clients who need to consume data from them. Newer versions are exposed in an application-specific way. For instance, with an HTTP/REST API, the version of the microservice may be part of a custom header, or be embedded in the returned data. Account for this.
- **Automated deployment**: The whole reason that microservices are so convenient nowadays is that it is so easy to deploy a new service from a completely clean environment. See Heroku, Amazon Web Services, [Webtask.io](https://webtask.io) or other PaaS providers. If you are going for your own in-house approach, keep in mind that the complexity of deploying new services or versions of preexisting services is critical to the success of your solution. If deployment is not handled in a convenient, automated way, you risk eventually reaching a level of complexity that outweighs the benefits originally brought about by the approach.
- **Interdependencies**: Keep them to a minimum. There are different ways of dealing with dependencies between services. We will explore them further later in this blog post series. For now, just keep in mind that dependencies are one of the biggest problems with this approach, so seek ways to keep them to a minimum.
- **Transport and data format**: Microservices are fit for any transport and data format; however, they are usually exposed publicly through a RESTful API over HTTP. Any data format fit for your information works. HTTP + JSON is very popular these days, but there is nothing stopping you from using protocol-buffers over AMQP, for instance.

### Doing things right
All of these concerns can be dealt with in a systematic way. We will explore techniques and patterns in this post series to deal with them. Here is what we will be talking about in future posts:

- **API proxying**
- **Logging**
- **Service discovery and registration**
- **Service dependencies**
- **Data sharing and synchronization**
- **Graceful failure**
- **Automated deployment and instantiation**

## Keeping it real: a sample microservice

Now, this should be easy. If microservices take so much baggage off the development team's mind, writing one should be a piece of cake, right? Yes, in a way. While we could write a simple RESTful HTTP service and call that a microservice, in this post we will do it by taking into account some of the things we have listed above (don't worry: in the following posts, we will expand this example to include solutions for ALL the concerns listed above).

For our example, we will pick the backend code from Sandrino Di Mattia's excellent [post](https://auth0.com/blog/2015/08/25/logging-and-debugging-in-react-with-flux-replaying-your-users-actions/) about using Flux for debugging. In Sandrino's post, a simple express.js app makes the backend for a React.js app. We will take that backend and adapt it. You can see the original backend code [here](https://github.com/auth0/react-flux-debug-actions-sample/blob/master/server.js).

The backend in Sandrino's example handles many different concerns: login, authentication, [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing), update operations over tickets, and queries. For our microservice we will focus on one task: querying tickets. Check it out:

```javascript
var express = require('express');
var morgan = require('morgan');
var http = require('http');
var mongo = require('mongodb').MongoClient;
var winston = require('winston');

// Logging
winston.emitErrs = true;
var logger = new winston.Logger({
    transports: [
        new winston.transports.Console({
            timestamp: true,
            level: 'debug',
            handleExceptions: true,
            json: false,
            colorize: true
        })
    ],
    exitOnError: false
});

logger.stream = {
    write: function(message, encoding){
        logger.debug(message.replace(/\n$/, ''));
    }
};

// Express and middlewares
var app = express();
app.use(
    //Log requests
    morgan(':method :url :status :response-time ms - :res[content-length]', {
        stream: logger.stream
    })
);

var db;
if(process.env.MONGO_URL) {
    mongo.connect(process.env.MONGO_URL, null, function(err, db_) {
        if(err) {
            logger.error(err);
        } else {
            db = db_;
        }
    });
}

app.use(function(req, res, next) {    
    if(!db) {
        //Database not connected
        mongo.connect(process.env.MONGO_URL, null, function(err, db_) {
            if(err) {
                logger.error(err);
                res.sendStatus(500);                
            } else {
                db = db_;
                next();
            }
        });
    } else {
        next();
    }    
});

// Actual query
app.get('/tickets', function(req, res, next) {
    var collection = db.collection('tickets');
    collection.find().toArray(function(err, result) {
        if(err) {
            logger.error(err);
            res.sendStatus(500);
            return;
        }
        res.json(result);
    });   
});

// Standalone server setup
var port = process.env.PORT || 3001;
http.createServer(app).listen(port, function (err) {
  if (err) {
    logger.error(err);
  } else {
    logger.info('Listening on http://localhost:' + port);
  }
});
```

- **One thing and one thing only**: Our microservice's single concern is querying for the full list of tickets. Nothing more. Authentication, CORS and other concerns are to be handled by upper layers in our architecture.
- **Logging**: We have kept logging using the 'winston' library. For now we will just log to the console, but in later versions we will push logs in a predefined format to a centralized location for analysis.
- **No dependencies**: Our microservice has no dependencies on other microservices.
- **Easily scaled**: With no dependencies, a separate process, and operating on a single concern our microservice can easily be scaled.
- **Small and readable**: Our microservice is small and readable. New developers can modify or rewrite it in no time.
- **Data sharing**: For now our microservice reads data from its own database. We will explore in future posts what happens when other microservices need to update or create tickets.
- **Registration and failure**: Our microservice stands on its own. In future posts we will explore how to manage service discovery and what you can do in case microservices fail.

Get the [code](https://github.com/sebadoom/auth0/tree/master/microservices/microservice-1).

## Conclusion
Microservices are the new way of doing distributed computing. Advances in deployment and monitoring tools have eased the pain involved in managing many independent services. The benefits are clear: using the right tool for the right problem, and letting teams use their specific know-how to tackle each problem. The hard part is dealing with shared data. Special considerations must be taken into account when dealing with shared data and inter-service dependencies. Data modeling is an essential step in any design, and is even more so in the case of a microservices-based architecture. We will explore other common patterns and practices in detail in the following articles.


"webtasks"