Finding application solutions.

Example common Ruby on Rails application challenges and the solutions provided.

Upgrading Ruby on Rails.

Upgrading a Ruby on Rails monolithic application from version 4.3 to 6.0 posed challenges, with rising support issues and hindrance to a front-end overhaul.

Maintaining an up-to-date application is crucial, since it otherwise comes with challenges such as inefficient development time and escalating support costs due to persistent bugs. The need for upgrading was evident, considering the continuous improvements in Ruby on Rails from version 4.3 to, at the time, the most current version of 6.0.

To address this challenge, the strategy involved a step-wise approach. The initial phase focused on refactoring the application, removing less-utilized older gems to reduce potential issues during the upgrade. Subsequently, attention shifted to upgrading remaining gems incrementally, addressing test issues along the way, and finally reaching the desired Rails version. This method aimed to ensure a successful upgrade while prioritizing safety and minimizing adverse impacts on the core business.

Time to completion
1-6 months
4.3 ==> 7.1

White labeling a SaaS offering.

The task involves hosting multiple domains, potentially numbering in the hundreds or thousands, all pointing to a multi-tenant application. The challenge is to automate client configuration and accomplish the implementation within minutes.

Domain SaaS white labeling is increasingly being utilized where clients are reselling or offering a service provided by the SaaS. Rather than host as a subdomain and further advertise the SaaS product, they want to use their own domain.

Depending on the number of expected SaaS clients, automated domain registration can be handled by a local NGINX service acting as the domain endpoint, that routes to the intended service, or you can use an external service such as Cloudflare, or with fewer domains, Heroku. All are solutions that can be fully automated and with implementation occuring within minutes. It is important to do this correctly as reversing course in the future can be extrememly difficult and distruptive for clients.

Time to completion
1 month
mydomain.someonelsesdomain.com
↓ ↓
mydomain.com

Offering a RESTful API.

There is a growing demand from clients for API access to integrate your services into their own systems. This presents a significant opportunity as your service stands to be remarketed by clients, thereby significantly expanding the reach of your offering.

API's are important nowadays as client often want to integrate data from third parties and to do so require access to an API. Having an API, and particularly a RESTful one, is important, because it expands the accessibility of your application, and potentially greatly expands the market of your service, particulary if your clients remarket your service.

A solution is to design the API concurrently with new application development, minimizing future rework. Ensure user-friendly API design with clear, intuitive queryable objects to reduce confusion and support demands. In cases of existing applications adding APIs, use a translator for ideal object naming. Prioritize comprehensive documentation to decrease reliance on customer support resources, considering third-party services or internal solutions like Yalit, an open-source application that I open-sourced for white-labeling API documentation on a custom domain.

Time to completion
1-3 weeks

Recurring charges and billing.

Billing needs to be fixed to handle recurring charges, special offerings, and to reduce interchange and merchant fees.

Billing represents your brand and should allow for customized approaches and flexibility, while being cost-effective. Often, its implementation was years ago, and now shows its age, but overhauling it could pose significant challenges with disruptions and inconvenience, requiring it to be done thoughtfully and in conjunction with all stakeholders.

The solutions include third-party providers, such as Chargebee or Recurly, which can be implemented quickly and has the lowest upfront cost, however this the most long-term expensive and least flexible. Alternatively, you can roll your own service utilizing Stripe, and this would be the least expensive, however it will have a higher upfront and ongoing development cost, but it does offer the most flexibility in offering recurring and customized charges.

Time to completion
1-2 months

Monolith to microservice.

Your Ruby on Rails has grown into a large monothithic application, with performance lagging on certain features, bringing down the overall appliation's response times.

The benefits of a monolithic application are numerous, particularly for smaller development teams where overlapping work is minimized and deploys can be easily coordinated. There are cost benefits due to fewer instances deployed as well as development time necessary to manage multiple codebases. Microservices have the benefits of simplicity, in that each code base can have a narrow set of functions, as well minimized required deployment coordination, as each service can be separately deployed.

The solution in one particular case I faced was a substantial AWS-hosted monolith that had multiple functions, that were expected to continue to grow, and there were concerns that deployments would impact service levels. In addition, there was a desire to migrate from AWS, so it was a perfect opportunity to launch new microservices at the new provider, whilst integrating API calls and disabling the same service in the monolith. Overtime, the original monolith had been disassembled, with the individual microservices launched at the new cloud provider.

Time to completion
1-2 months
→

Leveraging Heroku with devops.

You use Heroku, but don't have a CI/CD platform to automate the deployment process.

Heroku is an excellent choice for Ruby on Rails application hosting. From its inception, they have focused on Rails applications with a tailored build process that is extremely reliable and comes with great support. It is not the cheapest hosting service, but it makes that up with automated CI/CD deployment tools, and negating the need for dedicated devops and database personnel.

The solution is provided by Heroku through their Review Apps and stage Pipelines, which once configured, provides automated testing, deployment and rollover. In addition, Review Apps provide dedicated exclusive deployments off branch commits for developers, allowing for complete end-to-end testing prior to merging into production. Its a great solution.

Time to completion
1-2 weeks

Scraping for data.

Your site could benefit from third-party data where no open API exists.

APIs have exploded in availability in the last 10 years, but many sites still lack accessibility, so web scraping remains an important tool. The challenges are how to implement those tools in way that you can monitor their ongoing operation, as breakage will likely occur, and frequently. Depending on the number of different sites you'll target, this can be a big challenge.

In an example situation, we were faced with tracking nearly 200 different websites that required daily scraping. Over time, the scraping component of this monolithic application was overwhelming our instances leading to increase web response times for clients. The solution was to extract the scraping into a microservice, that could easily be scaled up or down, using such tools as ScraperAPI, HTTParty, and Selenium.

Time to completion
1-2 months
→

From single to multi-tenancy.

Transitioning from single to multi-tenancy poses challenges. Initially, a single-tenant SaaS application was deployed for various clients in individual instances. However, this approach led to escalating support costs due to misalignment in code and database structures across instances. As the number of clients grew, managing this fragmented system became increasingly difficult and costly.

Opting for multi-tenancy is the intelligent choice when designing a SaaS application, as handling numerous single-tenant installations entails significantly greater overhead, given the management of multiple data and code bases.

In this chalenging project, the approach taken was to first refactor the codebase for multitenancy and launch a new master application. Each client instance then had its database migrated and data massaged, and then within a tight timeframe, merging it into the master database, and resetting its DNS to seemlessly direct to the new application.

Time to completion
1-6 months
→
→
→