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 the brand to attract its mobile users, who can help them build high-value relationships with the company after customers have downloaded their apps.

For now, Urban Airship has a large customer base, covering areas such as retailing, media and entertainment, sports and tourism, and healthcare. These companies are using urban airship to enhance their connectivity to their customers. Recently. Developers from urban airship open up a development tool they use: frock. The framework is designed to simplify the management of analog service suites.

Assuming you're using 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 common pattern for a SaaS company: We have a number of services, each of which is packaged with a small amount of functionality, and every 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, including a number of features: message generation and reporting, billing and usage reporting. and service management (for example, urban Airship Connect, announced shortly ago).

Go will invoke a large number of services. This has led to many problems with the team's development environment. Previously, our environment consisted of a single, virtual machine that was executed on top of the vagrant. It relies on the full service of the dashboard. There are many problems in doing so:

• The speed is very slow.

  There are a number of services and dependencies, including several different databases that need to be kept in the execution state.

• Very fragile. Our team lacks a JVM expert.

  Upstream changes to services can undermine our development environment, which many of us are afraid to update.

• Cause the developer to be unable to continue working. When the developer's environment is compromised, they often cannot continue to work.

  The complexity of the environment means that such destruction can occur frequently. This will waste a lot of time. and cause developers to be frustrated.

• It is difficult to import data into the environment.

  During the development phase. You need a variety of data to test the code.

  The previous environment usually requires you to perform the test data manually. This is done by 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 and execution of the team's habits to write simulation services: JavaScript and node. js.

The core of frock only provides some features such as the following:

• Highly configurable routing, which allows us to easily intercept calls to the service.
• The plugin-based architecture does not impose a mandatory constraint on how to write a simulation service.

• Out-of-the-box generic plug-ins for common tasks. That is, a static file server with a proxy server.

• Supports HTTP and socket services.

• HTTP middleware supports the ability to define the behavior of a service or route itself. 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 (the file name is Frockfile.json, according to the contract). It is also shared through warehouses that include all of their own defined simulation services. Frock has been inspired by grunt and gulp, and its configuration is in your project. For HTTP impersonation, a frockfile will include a simple service and routing definition. Say:

{"  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 number for the service definition in our frockfile. When visiting the Go dashboard. You'll actually hit a highly available proxy: The agent internally directs traffic to different services, where the main service is go. Just some API routing is handled by a level two service.

Compared to performing this level two service locally, we were able to select this route via frock and replace it with the simulated version number. In the preceding code demonstration sample, the simulation is just a static file, which is handled by the frock-static Universal static server plug-in. All other requests will be directed to the locally executed go development server,server port is 8052.

Writing frock plugins

As a matter of fact. Frock is our 2nd platform for solving this problem, and the 1th platform is a tool called "Multimock". It is a single Python application that can create multiple service threads and pass them to some common conversion functions before reaching their own definition of the processor. It can solve a lot of problems, but we still rewrite it, and finally have the frock. Why did you do it? This is because it is very difficult to write plugins in Multimock. 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. For example, the following code shows the simplest of a frock HTTP plug-in, which simply responds to a "Hello world!" to a hit route, regardless of the request. Only:

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

Assume that you have previously written a request processor for node. js. Then the above code is easy to understand; the frock plugin only includes a factory function that returns a route processor.

In the Frockfile Demo sample above. We will replace this plugin 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 "          }      ]}  ]}

Today, any request to Http://localhost:8080/api/devices will return "Hello world!".

Frock's help to our role

Large feature announcements are often complex: you often have to wait for a dependent service to be ready. Also read how to use the specifications for these services. In a fast-paced project, this means you have to keep chasing integration dates. When all the components are finally 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 makes us confident and integrates well.

In fact. None of the frock described above is revolutionary, but frock can help us do it in a simpler way.

It is recommended that you try it out and you will find it useful in your development environment. Frock Readme includes a high-speed start-up guide, and another rich documentation and demo sample code to help you get started at a high speed. Use frock in your project and implement your own plug-in.

Micro-Service API simulation framework frock Introduction