Micro-Service API simulation Framework frock Introduction

This article is from my translation of the Infoq Chinese station, the original address is: Http://www.infoq.com/cn/news/2016/02/introducing-frock

Urban Airship is a company that helps lead brands to attract their mobile users, and they can help companies build high-value relationships with their customers after they have downloaded their apps. At present, Urban airship already has a large number of customer base, covering the areas of retail, media and entertainment, sports and tourism, medical and so on. These companies are using urban airship to enhance their connectivity to their customers. Recently, developers from urban airship open-source a development tool they used: frock, a framework that simplifies the management of analog service suites. If you use a service-oriented architecture at work, frock is a tool worth trying.

Addressing the complexity of the development environment

Urban airship uses microservices, which is a very common pattern for a SaaS company: We have a lot of services, each of which is packaged with a small amount of functionality, and each service can be requested by a well-defined protocol for other services. This is great for scalability and stability, but it's a problem for developers and their environment. Our team engaged in GO development work (GO is the urban Airship Engagement Dashboard product), which is one of the earliest urban Airship code bases and contains a number of features: message generation and reporting, billing and usage reporting, and service management (for example, Urban Airship Connect, released shortly ago). Go calls a lot of services, which leads to a lot of problems with the team's development environment. Previously, our environment contained a single, virtual machine running on vagrant, which relied on all the services of the dashboard, and there were many problems:

• The speed is very slow. There is a very large number of services and dependencies, including several different databases that need to be kept in a running state.
• Very fragile. Our team lacks a JVM expert. Upstream modification of the service will undermine our development environment, which many of us are afraid to update.
• Cause developers to be unable to continue working. When the developer's environment is compromised, they often can't continue to work. The complexity of the environment means that this kind of destruction can happen often. This can waste a lot of time and cause developers to be very frustrated.
• It is difficult to import data into the environment. In the development phase, you need a variety of data to test your code. The previous environment usually requires you to run the test data manually, which is done through direct communication with the service that holds the data.

Frock is a great tool to help us solve all of these problems.

What is frock?

We can use our own defined data to simulate services by frock, using the language of the team and the runtime to write simulation services: JavaScript and node. js. The core of frock provides only the following features:

• Highly configurable routing, which allows us to easily intercept calls to the service.
• A plug-in-based architecture that does not impose a mandatory constraint on how to write a mock service.
• An out-of-the-box Universal plug-in for common tasks, a static file server and a proxy server.
• Supports HTTP and socket services.
• HTTP middleware support, you can customize the behavior of a service or route, for example, it provides a deferred middleware that can delay the time of the request.

All of this is configured through a JSON configuration file (which is named Frockfile.json according to the Convention) and is shared through a warehouse that contains all the custom impersonation services. Frock has been inspired by grunt and gulp, and its configuration is in your project. For HTTP impersonation, a frockfile contains a simple service and routing definition, such as:

{"  Servers": [    {      "port": 8080,      "routes": [        {          "path": "/api/devices",          "Methods": ["GET"] ,          "handler": "Frock-static",          "Options": {            "file": "./fixtures/devices.json",            "ContentType": " Application/json "          }        },        {          " path ":" * ",          " methods ":" Any ",          " handler ":" Frock-proxy ",          "Options": {            "url": "http://localhost:8052"          }      ]}  ]}

This is a highly simplified version of the service definition in our frockfile. When you access the Go dashboard, you actually hit a highly available proxy: The agent internally directs traffic to different services, where the main service is go, but some API routes are handled by level two services. Instead of running this level two service locally, we can select this route via frock and replace it with a simulated version. In the above code example, the simulation is just a static file, which is handled by the frock-static Universal static server plug-in. All other requests are directed directly to the Go Development server running locally, and the server port is 8052.

Writing frock plugins

In fact, frock is our 2nd platform for solving this problem, and the 1th platform is a tool called "Multimock", a single Python application that can create multiple service threads and pass them to some common conversion functions before reaching a custom processor. It can solve a lot of problems, but we rewrite it, and finally we have the frock. Why did you do it? This is because writing plugins in Multimock is a very difficult task. In writing frock, our core principle is that "plugins should be written in a simple and built-in hypothesis as little as possible." Frock achieves this by imposing minimal restrictions on the plug-ins, and applies the simplicity of the node. JS HTTP module directly to the implementation. The following code shows the simplest of a frock HTTP plug-in, which responds to "Hello world!" only to any request that hits a route. Only:

file./hello-world.jsmodule.exports = Createpluginfunction Createplugin (frock, logger, options) {  return handler  function Handler (req, res) {    res.end (' Hello world! ')  }}

If you have previously written node. JS's request processor, the above code is easy to understand; the frock plugin contains only a factory function that returns a route processor. In the Frockfile example above, we replace this plug-in with a static file server:

{"  Servers": [    {      "port": 8080,      "routes": [        {          "path": "/api/devices",          "Methods": ["GET"] ,          "handler": "./hello-world"        },        {          "path": "*",          "methods": "Any",          "handler": " Frock-proxy ",          " Options ": {            " url ":" http://localhost:8052 "          }      ]}  ]}

Any request to Http://localhost:8080/api/devices will now return "Hello world!".

Frock's help to our role

Large feature releases are often very complex: you often wait for dependent services to be ready, and to read the specifications for how to use those services. In a fast-paced project, this means that you have to keep catching up to the integration date, and when eventually all components are in place, you want them to be able to invoke each other successfully. Connect is such a project that frock can help the Web Team build a project that gives us confidence and integrates well.

In fact, none of the above-mentioned frock is revolutionary, but frock can help us do it in a much simpler way. It is recommended that you try it out and you will find it very useful in your development environment. Frock Readme includes a quick start guide and a rich documentation and sample code to help you get started quickly, use frock in your projects, and implement your own plugins.

Micro-Service API simulation Framework frock Introduction