Launching New Products That Are Built to Last

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:

• 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.
• 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.
• 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.
• 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.

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.

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.