• Skip to primary navigation
  • Skip to main content
  • Skip to footer

Codemotion Magazine

We code the future. Together

  • Discover
    • Events
    • Community
    • Partners
    • Become a partner
    • Hackathons
  • Magazine
    • Backend
    • Frontend
    • AI/ML
    • DevOps
    • Dev Life
    • Soft Skills
    • Infographics
  • Talent
    • Discover Talent
    • Jobs
    • Manifesto
  • Companies
  • For Business
    • EN
    • IT
    • ES
  • Sign in
ads

Leo SorgeNovember 15, 2021

Back-end Refactoring: The Sailogy Case Study

Backend
facebooktwitterlinkedinreddit
Table Of Contents
  1. What is Sailogy?
  2. A complete separation of back- and front-end
  3. Starting from a monolithic blob
  4. The goal in nine points
  5. Three different paths
  6. The five steps of the back-end refactoring process
    • # 01
    • # 02
    • # 03
    • # 04
    • # 05
  7. Main services, now parallelized, upgraded by order of magnitude
  8. Next steps: the future is coming!
  9. Conclusions

What is Sailogy?

Sailing is a wonderful activity that many people would like to enjoy more often. The demand for simpler booking tools indicates that there is a large market to serve. The Sailogy platform currently offers 22,375 certified boats and over 800 destinations, from the Mediterranean to the Caribbean – enough options for everyone to make a great choice!

A complete separation of back- and front-end

The website needed to be completely refactored. The end goal was a complete separation of the back-end and front-end, using the most appropriate modern technologies. The process started with a migration operation, with refactoring worked on in a subsequent phase. The work that produced the brand-new front-end has been fully described in a case study in a previous article.

Recommended article
June 10, 2025

VanillaCreamJS: Superpowers for Native JavaScript

Riccardo Degni

Riccardo Degni

Backend

Starting from a monolithic blob

The situation at the start used Django 1.11 and Python 2.7 as basic programming tools. From a development point of view it was necessary to parallelize the database access, separate the front-end from the back-end, and introduce a microservices approach to be orchestrated through Kubernetes.

The existing monolithic architecture was based on very complex logic structures that connected the end user and the company personnel. A large blob with many hundred thousand lines of code, the architecture interacted with custom-made management software. Its integrated front-end used the Django template, written in jQuery language.

The release process was based on a CI/CD pipeline that needed significant improvement to meet today’s requirements. The production process was slow, requiring up to 60 minutes to complete. Moreover, any change to the code afflicted the entire codebase in the previous pipeline.

The goal in nine points

The overall result was structured according to nine important points, following the same plan used for front-end refactoring. 

Performances, front/back separation, a CI/CD production pipeline, and the introduction of microservices were the key principles behind the nine points listed below.

– Improve performances;

– Reduce the consumption of resources, and consequently, infrastructure costs;

– Improve the maintainability of the code;

– Separate the front-end from the back-end, and switch to the React library;

– Communication between front-end and back-end to be dealt with via REST APIs;

– Implement a CI/CD pipeline to decrease production release times for the code 

– Isolate business logic from the overall codebase;

– Reduce the development time of a new feature or a feature fix;

– Significantly increase code coverage.

Three different paths

A complete assessment of the overall scenario, when analyzed with in relation to the nine points above, allowed for a clear identification of three different paths:

Path A

Writing microservices from scratch; releasing everything once the work is done.

Path B

Removing the business logic from the old monolith, then creating the necessary microservices fabric.

Path C

Creating the first REST APIs, accessing the monolith to separate the front-end from the back-end immediately, and – with the experience gained from their implementation – designing the porting of each business function to microservices.

A number of subsequent analyses contributed to the establishment of a well-defined brief. If Choosing Path A, apart from any other architectural consideration, would mean a delay of several years before any results could be seen, so it was the first to be discarded. 

Path B presented some advantages from a theoretical point of view, but would not have permitted the release of the front-end in a short timeframe. Moreover, it would have required the termination of all microservices before seeing any results, taking the development phase into a situation similar to that of Path A. Path B was also not the right choice.

With these considerations in mind, Path C emerged as the best process to meet Sailogy’s needs. The front-end team could start with development in React immediately. At the same time, various issues could be thoroughly analysed before moving on to the development of each specific microservice. In addition, whenever a microservice was complete, it could be released immediately, rather than having to wait for the other services to develop, slowly but relentlessly composing the threads required by the brand-new fabric for the end goal – a tailored back-end.

A parallel approach was chosen for database accessing in Python, alongside Kubernetes microservices orchestration, to improve both performances and pipeline management.

The five steps of the back-end refactoring process

How were the project points addressed during the refactoring process? The development phase was split into five sub-phases:

# 01

The preliminary phase analyzed the monolith in order to isolate all the business logic necessary to proceed with the chosen path.

# 02

Path C could then be exploited. Work began on the monolith, with the implementation of the REST APIs at this point. The Django REST framework was the chosen development tool.
The first sub-goal – the separation of the front-end from the back-end – was achieved in a few months.

# 03

Building the APIs on the monolith produced clear ideas about how the microservices should work and how the logics should be divided. This allowed for the design and creation of templates that would permit the skeleton of a new microservice to be set up with one click, and an overall reduction in development time.

# 04

Microservices now came to the fore. One by one, starting with the most important services, such as researching a destination or fleet management, construction of the various microservices began.

# 05

A tuning process was initiated to increase performance, and decrease the consumption of resources at the end of the realization of each microservice. In addition, at this point the front-end was completely disconnected from the monolith’s endpoints and immediately interfaced with the new microservices, taking advantage immediately of the performance improvements offered by the new fabric being realized. 

Main services, now parallelized, upgraded by order of magnitude

The process is still in progress at this time. The excellent results achieved so far can be shown by a few figures:

– Production release time reduced by 80%

– Response times reduced by 45%

– Ability to serve requests in 30 seconds increased by 23,000% 

– Hardware resources required by microservices reduced by 80%

– Code coverage: 100% on all microservices

– Parallelization of work between team members: much higher efficency.

The microservices are now in line with Python version 3.9. The new development phase started with Python 3.8 to accommodate any necessary subsequent update. All new microservices are based on the brand new FastAPI asynchronous web framework.

Next steps: the future is coming!

The development of the consumer microservices fabric should be complete within the first half of 2022. Thanks to the robust foundation built by a complete refactoring effort, Sailogy is already moving towards the future. 

The company now aims to:

– significantly improve workflow, implementing the same procedure for the internal management system as seen on the consumer side, entirely created and designed for the business’ unique needs;

– significantly improve the user experience, integrating new services such as a recommendation engine system based on machine learning algorithms, for example.

Conclusions

Writing websites is not the easy task many believe it to be. Choosing the right stack, the right toolset, and the right people to start a new page using up-to-date development tools is not as simple as choosing just any stack or any programmer. 

Sailogy has proven to be a challenging place for cool developers, separating the back-end and front-end completely, then refactoring both sections. Take a look at the first story, “Front-end refactoring for performance improvement”, to understand the complete scope of the full process improvement Sailogy has completed. Sailogy rewrote their software to effect a transformation, separating front-end and back-end completely.

If this sounds like somewhere you might want to work, try their Coding Challenge to have the chance to apply for a Back-End Developer position and become part of their team.

Related Posts

Start building REST APIs with Django REST Framework

raffaelegrieco.it
May 13, 2025

Top 10 online platforms to practice Python every dev should know

Lucilla Tomassi
May 13, 2025

.NET Refactoring Series: Episode 1 — How to Approach Service Refactoring

giovanni-ferrari
April 2, 2025

Queueing Without a Queue: The PostgreSQL Hack

Puppo92
March 13, 2025
Share on:facebooktwitterlinkedinreddit

Tagged as:CI/CD Microservices

Leo Sorge
I hold a degree in electronics. I talk and write about science and technology in both real and close-to-real worlds since 1976. I frankly believe that business plan and singularity are excellent starts for science-fiction stories.
5 Key Strategies to Streamline Team Velocity
Previous Post
Top 7 QA Testing Best Practices to Ensure Overall Software Quality
Next Post

Footer

Discover

  • Events
  • Community
  • Partners
  • Become a partner
  • Hackathons

Magazine

  • Tech articles

Talent

  • Discover talent
  • Jobs

Companies

  • Discover companies

For Business

  • Codemotion for companies

About

  • About us
  • Become a contributor
  • Work with us
  • Contact us

Follow Us

© Copyright Codemotion srl Via Marsala, 29/H, 00185 Roma P.IVA 12392791005 | Privacy policy | Terms and conditions