With the craze over building Single Page Applications (SPAs), companies have joined the movement and hired armies of front-end engineers with/without experience in back-end technologies. These new engineers that have brought about refreshing talent and new ideas to spur the growth. To accommodate the new talent, many of these companies have built what is known as “cross-functional” teams. Simply put, it’s a team of developers both front-end, back-end engineers, and other disciplines working together to deliver a product. In general, front-end engineers work on the SPA features while the back-end engineer develop the supporting Web APIs.

The Challenges

Although products are higher quality and teams more Agile, productivity sometimes grinds to a halt. An issue in the development server hosting the back-end APIs could be a showstopper for front-end productivity. Updates to back-end services have long turn-around because the developers have to deploy their own code to the test environments. Lastly, sometimes front-end developers have to dig through unfamiliar code to how an API works. So, it is evident that feedback loops could be shortened, human factor could be removed, and better tools could be chosen.

5 Ways to Increasing Productivity

1. Continuous Deployment

Although deploying code to a test environment might not take a long time, 5-10 minutes and 2 or 3 times a day adds up. This doesn’t take into account the context switching the developers have to do in order to deploy the application. Mistakes happen and manual deployments don’t always go smoothly.

One way to effectively increase productivity in a cross-functional team is to automate deployments. Having a deployment pipeline that builds and deploys the code after it is checked in to the source control system. By having this level of automation, any member of the team could request deployments of their features without having to bother a fellow teammate to deploy the application.

There are various tools out there to do continuous integration and deployment. At Nebbia, we like to use VSTS to build, deploy, and manage our release pipelines. For most projects, we have our applications be deployed automatically to a development environment soon after the code is committed to the repository and reviewed by others.

A healthy release pipelines helps automate some of the mundane tasks some developers have to do

2. Self-Documenting Web APIs

Engineers often lose track of what endpoints are available. Especially if this is a large applications, there are other team members interested in how an API is defined including: QA analysts, Security Engineers, and even Stakeholders. One way to communicate to everyone how these APIs are defined is through documentation. But, having to do this whilst in the development cycle can quickly become counter-productive.

There are several packages that automatically document an API with minimal developer involvement. Swagger UI is a very popular open source project that lets anyone visualize your API and its resources. There are endless integrations with Swagger with numerous programming languages. A live example of Swagger documenting a sample API can be found here.

Swagger will document your API endpoints and its resources

3. Create Front-End Prototypes with Mocked Data

Like mentioned earlier, Swagger can help expedite some of the guesswork in how an API works without digging into the code. However, there will be times where fellow teammates responsible for back-end work are busy working on something else.

There are numerous JavaScript playground sites out there like JS Bin, CodePen, JS Fiddle, and Plunker. These sites host and run front-end code so that engineers can develop iteratively. They are great for figuring out how a feature might work and get feedback from fellow developers or even stakeholders.

By using good design principles and abstracting away API calls into their own components, front-end prototypes can be developed against mocked data that resides in JSON files. For instance, if your app needs an API endpoint to manage customers, you could abstract API calls to instead return data from a customer JSON file. Frameworks like Angular make this abstraction particularly easy.

There are number of data mocking tools out there. For generating raw JSON files with some context on the type of data (e.g. first name, last name) there’s a useful site called Mockaroo that will generate this for you.

Plunker for an AngularJS app with data mocked Mockaroo

4. Effortlessly Run APIs on Any Environment

Today, SPA development is quick and iterative when developing against a hosted API. However, there might be situations where the development environment cannot be updated or it might conflict with other features being developed. So, it’s a good idea to have the back-end be executable on any OS so that front-end engineers can develop locally. Especially with the micro-services movement, back-end stacks can be written in many languages (.NET, Java, JavaScript, Ruby) and it could be problematic to set up complicated development environments.

New container technologies also make cross-sharing code especially easy but it can be expensive to implement in the beginning. Therefore, it’s important to find out what works best for your team and your organization: container technology or tool standardization.

For .NET stacks, until recently they were limited to only Windows Environment. With the new-coming of ASP.NET Core and Kestrel, ASP.NET APIs can be run on any OS with very little effort. With the craze over VS Code as a lightweight IDE, it can quickly be tailored to run front-end or back-end code on any OS.

5. Use a Feature Branch Strategy

A “feature branch” strategy can be used against many source control systems to manage code checked in against a feature with having less impact on other features being developed. Meaning, a developer will create a branch of the source code repository whenever he/she starts working on a feature. Using this strategy, a subset of the development team can work together to complete a feature without impacting the other development efforts.

Martin Fowler gives a high-level explanation on this strategy on his blog. At Nebbia, we like to follow the feature branch strategy using Git. Lastly, Atlassian gives a little more detail on how to implement this strategy using Git as the version control system in this article.


At Nebbia, we like to implement these strategies to develop meaningful applications for our clients. Feel free to reach out to us for help in setting up your deployment pipeline with some other DevOps practices or if you simply need some guidance on how to streamline the development process for your own application.