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