by Marie Morisi
ImVitro’s product, EMBRYOLY, is a SaaS platform that assists embryologists in their embryo evaluations and helps manage the embryo management needs of IVF centers. With infertility on the rise coupled with the increasing challenges and expectations embryologists face in the lab, we have created a product that fits seamlessly in their workflow.
While this post can be read by any audience, it is most relevant for fellow web developers, including those who might be interested to join us at ImVitro. I am Marie, the lead frontend developer, and in this post I will take you through our product’s application and how it helps us achieve our goals at ImVitro.
What is a Single Page Application?
Single-page applications (SPAs) are web applications that load a single HTML page and dynamically update the body content of that page as the user interacts with the application. In other words, new pages won’t need to be completely reloaded from the server, and only new content has to be loaded.
Considering that many websites frequently display certain elements on every page, such as the header, footer, or menu, having an SPA is useful because it removes the need to reload this content on every page. The first page load may take a little longer than other pages since the browser must download and run the entire application code before the content is displayed, but after the application has fully loaded, no further loading will be necessary.
With SPAs, the browsing experience is fast, helping us gain in our performances, and deliver a smoother and more dynamic user experience.
Many big tech companies like Google (Gmail, Google Maps), Netflix, Airbnb, and many more choose to use SPA to build their applications. While there are many advantages for developing a SPA, it can not be the right fit for every project. Especially in the medtech sector, SPAs might be particularly beneficial in improving user experience by increasing speed and responsiveness, and enabling real-time updates without reloading the page. Let’s explore the differences between SPAs and Server-Side Rendering (SSR) below:
Differences between SPA and SSR
The key difference between SSR and SPA is that the former is getting the HTML from the server for every page. When a new URL is requested, the server creates a new HTML page and sends it back to the user’s browser which then displays the corresponding HTML page. If the user clicks on a link, it will call the server again to get the new HTML for the full page, and so on.
SSR was a standard way for producing web pages, since early web browsers acted mainly as document viewers and was easily indexed by search engines. When using SSR, the initial page loading may be quicker because the static content is actually what loads first. However, the JavaScript file then needs to be downloaded by the browser in order to provide interaction to the page. Users will have to wait longer before interacting with the application. As applications have become more complex and interactive, SSR is no longer favoured for such projects.
This is not to say that SSR is obsolete. In specific use cases, SSR would be a better option for a website that wants to rank highly for Search Engine Optimization (SEO). In our case, we didn’t need to take SEO into account because we are developing a SaaS platform that is only accessible to our customers. To emphasise, this is, of course, separate from the SEO strategy and web development of our company’s website https://im-vitro.com/ where this post is being read.
How does our SPA work?
- On the browser side
In EMBRYOLY, the application and necessary resources, such as HTML, CSS, and JavaScript, are loaded as soon as customers arrive on the login page. A JavaScript engine generates the HTML for the page, and the user’s browser uses the HTML to create the full app and visually render the page.
Then, if the user navigates from one page to another, only the body of the new page page will be loaded since we have the same layout on every page. We will only fetch the data that we want to show from the database and display it.
- On the coding side
SPAs must be created using JavaScript and we chose to use a Javascript framework named Vue.js. This framework has many advantages in that it is lightweight, has many powerful features for the developers to work with, and makes the code easy to maintain and debug.
All of these advantages allow us to frequently build and ship new features on EMBRYOLY for embryologists to have a dynamic user experience.
Additional benefits of SPAs
There are many other advantages of SPAs in addition to loading speed, such as:
- Better caching capabilities: in case of bad internet connection, we can cache data retrieved from the server and use it.
- Mobile-friendly: we can use SPAs to build a mobile application while still using the backend of the web application.
- Fast development: when building an SPA, the frontend and backend code are separated, meaning multiple developers can work on different aspects of the same feature at the same time.
Conclusion
At ImVitro, we want to give embryologists the best user experience to support them in their daily tasks. This is why we chose to build an SPA: an application that is easily deployable and scalable, allowing us to frequently introduce new features on our application and consistently meet the needs of IVF centers.