Three strategies for enabling flexible, rapid application development.

pattern-1440x552

Pattern- 1440x552

Launching New Products That Are Built to Last

Even in this age of exponential speed-to-market, most software projects are burdened by pre-existing codebases and legacy back-end systems. A purely greenfield product is the dream of most application developers. But what often spoils this dream is the very delivery speed developers and business stakeholders crave. With a short runway to get a product to launch, how does a team chart a course that will not only ensure project deadlines are met, but will also ensure long-term stability? To be successful, you’re going to want to ensure that you focus on flexibility, on ease and speed of development, and on future scalability needs.
&nbsp;
<h2>From ‘greenfield’ to ‘evergreen’</h2>
To enable rapid greenfield development, the product architecture must be easy to update and maintain by a small team (or even a single developer) as new requirements and use cases emerge, it must not create bottlenecks for the front-end developers, and it must remain flexible enough for at least near-term scalability. The approach frog has developed and successfully implemented for many companies, including the ride hail startup Alto, has three main features to ensure flexible, rapid application development:
<ul>
<li>Decoupled back-end services: Centralize all business logic and all possible third-party integrations on the back end, behind services designed around the schema you have defined.</li>
<li>Decomposable Monolith architecture: Make use of a monolithic codebase for efficiency but strictly enforce loose coupling so that adapting to micro services is easy once scale calls for them.</li>
<li>GraphQL front-end: Make use of GraphQL for its speed of development and ability to reduce bottlenecks between the front end and the back end.</li>
</ul>
This approach puts and emphasis on the back-end as a foundation upon which to build, and partially reverses two architectural choices that have become gospel in recent years: REST-based APIs and micro services architectures. Below, we’ll dive deeper into each strategy to better understand how to get products from concept to launch and beyond.

With applications needing to be available across multiple channels—and with various potential applications needing to utilize much of the same logic—the need to have a well-considered back end has become critical to getting applications off the ground with minimal headache. In very broad strokes, there are a handful of principles one should apply to back-end services to ensure the necessary flexibility:
<ul>
<li>The back end should be responsible for as many third-party integrations as possible. This not only gives application developers one single, central integration point to use, but it also enables the business to manipulate responses from third parties, to store any necessary data from these third parties, and to make any necessary adjustments to these integrations in one place without requiring the rebuilding of applications.</li>
<li>All business logic should be consolidated on the server for the same reasons. Ideally, this takes the form of a dedicated business logic layer used by various services. Having all such logic and rules in one location ensures that any updates are applied universally and only need to be made once.</li>
<li>Communication between services, utilities and other components of the back end should be event-based. Whatever architecture is chosen for the back end should be as decoupled as possible. Not only does this make long-term maintenance much easier but it also allows for far more nimble adjustments to be made during principal development.</li>
<li>A robust logging mechanism should be put into place. While logging is frequently an afterthought, it is in fact vital for timely debugging of any issues that should arise.</li>
</ul>
<h2></h2>

A flexible foundation upon which to build

Right now, microservice architectures are having their moment in the sun, and for good reason—this degree of decomposition allows tremendous flexibility for large teams. As with any pattern, however, there are also disadvantages to microservices. Deployment can be complex, there is higher operational overhead with regards to infrastructure, and a decomposed codebase can be an impediment for shoestring development teams.
An approach that has proven useful when frog has been required to rapidly stand up services is to split the difference and build a decomposable monolith. We begin with a monolithic back end, but keep everything as decoupled and event-based as possible to ensure an easy transition to a microservice architecture once the needs of the business reach that point. Each service is developed as its own set of files that are themselves incorporated into the main structure, enabling the service to become in essence a removable component of the monolith. This approach combines the better parts of both monolithic and microservice architectures, at the time when the advantage of each approach makes the most sense. Then, during principal development, when there may be only one or two development resources allocated to creating services, there is only one codebase to manage, one deployment pipeline, one logging channel to set up and monitor, likely no need for synchronization and management of multiple databases, and no need for cloud-based messaging and event queue management, as the monolith can make use of your chosen framework’s internal event bus.

Microservices vs. Monolith

Another way to turbocharge development is to discard the standard REST-based paradigm of API contracts in favor of graph-based queries. When it comes to API design architectures, it is difficult to overstate the advantage of GraphQL when developing your back end concurrently with front-end development. While there are compelling arguments for and against both GraphQL and REST, developer productivity is one of the primary reasons for GraphQL’s inception. GraphQL virtually eliminates back-and-forth communication between front- and back-end developers, enables client applications to dictate the data they need, facilitates rapid iteration on services, and goes a long way towards mitigating API development as a bottleneck.
With this holistic approach, we’ve been able to shepherd full-stack, omnichannel applications form nascent ideation to polished, public releases in just a few months’ time with a team that fluctuates between 2-6 developers only—all while managing fluctuating functional requirements and design iterations. This approach was especially successful when working on developing Alto, which we saw grow from a napkin-sketch idea to a fully operational pilot in the market in just 12 months.
When standing up any new product, it’s important to remember that the priorities are not based around early optimization, but rather on getting stood up quickly, on maintaining flexibility, and on being able to rapidly iterate without creating bottlenecks for concurrent front end application development. This will set your team up for a relatively painless future optimization once things have stabilized a bit, and ultimately lead to ensuring that the greenfield products you launch stay evergreen in the market.

Down with REST-based APIs

David Hezlep

David is a senior solutions architect and passionate tinkerer with 20 years&#8217; experience in advertising and marketing, specifically in the interactive arena. From creative through to implementation and technical architecture, David has experience in almost every phase of interactive work.

David Hezlep

Featured

Launching New Products That Are Built to Last

Articles

	Global		EN
	France		FR

	Global		EN
	France		FR