Iguana Solutions DevOps platform#

From 2021 to 2024 I joined the hosting provider Iguana Solutions as a frontend engineer to help build a DevOps platform. The project started with a technical prototype aimed at proving our team could deliver what was expected, and to raise funds from investors to scale up fast, and go to market as soon as possible.

The frontend stack#

My directives from the CTO for the frontend technical stack were:

Cloud compatible and hosted on AWS, with the rest of the project.
Client side application to avoid managing a web server.
Easy to understand, onboarding should be fast.
Performant and batteries included to avoid wasting time assembling a NPM puzzle.

I had worked with React (pre hooks era), Vue 2 and Angular 1 in the past, but wasn't very interested in them or their more recent versions for different reasons:

React is notoriously difficult to understand and use. And it has huge performant issues. Of course React has a massive ecosystem of plugins, but that's because it's actually so hard to do some things in React that people outsource their difficulties to them.
Angular is a complete package, but it felt too much to handle for a single person. It is very opiniated and from what I could tell, lacked in performance at the time (but they are working on it).
Vue was stable, but I needed a complete package with styling, routing, state management, and more. Nuxt could have helped, but at the time they just were just starting the beta of their V3, which wasn't ideal for me.

In the end I picked Svelte, for the followintg reasons:

It was easy and fast to learn as it benefits from HTML/CSS/JS fundamentals.
It's compatible with almost all the native JavaScript ecosystem of plugins and libraries.
It's a complete package: scoped styling, simple reusable data stores, transitions and animations, are all baked in.
It does a lot of things for you, among them automatic reactivity to changes without a virtual dom. It's still performant as Svelte is a compiler that strips what isn't used and optimizes code.
It had a framework (SvelteKit) that was near its V1, so I could easily migrate the project to standardize our code and reduce our third party dependencies.

In the end Svelte proved to be a good pick and was never a hindrance in the project. Its data stores were particularly suited for the job.

As for styling, I followed the methodology pionereed by Andy Bell in its Build Excellent Websites talk. It allowed me to create a small base design system I could expand on the component level. It's the right mix of enough rules to keep a standardized look, and enough freedom to improvise.

Visual Design#

From a user experience POV, the directive from the the CTO was to take inspiration from the modeling application Cloudcraft, to allow investors in the field to directly understand what we were going for.

Initial design#

I created a temporary design inspired by the AWS icons system, and went for a scrollable and interactive isometric grid.

A global view of the grid with icons and arrows figcaption — The temporary design of the prototype. Not pictured: hovers to show names and states. | Full size

Same view as before but with a side panel for editing figcaption — Each node was clickable, with a side panel allowing to customize its size, position, and AWS parameters. | Full size

The different nodes of the graph had several states (idle, in deployment, delete in progress, changes not saved) that were all conveyed by small design changes and animations done in SVG.

Deployment turned every icon into a small animated box.

Final design#

A new design was comissioned to The Skin Factory agency to give a sleeker and more Apple style to the app.

A sleeker design figcaption — This new design removed the direct reference to Cloudcraft and aimed at convincing investors and clients by presenting a more finished look. | Full size

I implemented this new design and reduced the animations to more subtle affordances, the kind your barely notice but give a nice feeling to the app.

A demonstration of the infrastructure editing screen, with subtle animations on the click and drag & drop.

Deploy in progress animations

Overall the design documents lacked some informations and components, that I had to create to finish the redesign.

The agency only delivered a desktop design. I created the responsive version to allow potential demonstrations to investors when a computer wasn't available.

Routing and data fetching#

Routing followed Sveltekit's conventions, one folder = one route. Even if the project was a SPA, I still followed the convention of using a layout.ts or page.ts file in each route to fetch data before rendering (this is usually used for server side rendering).

I decided to use this to simplify the application UI rendering. You can use an onMount() life cycle method in svelte pages and components, but it would have resulted in a lot of loading spinners, a spread of the API calls, and a harder management of state. Using the sveltekit convention also allow to recover the upper level fetched data in lower pages, using the parent fonction.

For example:

/ will check the session and make it available to subpages
/org_id will fetch a list of projects linked to the org and make it available to subpages
/org_id/project_id will fetch project details and make it available to subpages

State management#

The state of the application is stored in memory, a hard refresh resets it, so it needs to be reproductable from the APIs.

The project' states were thought as state machines. A change of state from one of the API endpoint, or from the user, created a chain reaction that would change other states, allowing the app to show what is necessary in each page (texts, popups, images, redirects, etc.).

Stores were organized this way:

Writable stores were a mirror of each API endpoint. They served as a source of truth, and were updated when the user changed something (a copy was stored to compare changes and indicate undeployed changes). Their content could directly be sent through a POST/PUT call. They were called core stores.
Derived stores subscribed to one or several core stores, modified their data to match the needs of the user interface, and sent it to the view. Svelte automatically updated the derived stores when a core store changed.

a diagram figcaption — An early diagram of the state of the infrastructure page, representing how data is stored in core stores and used by derived stores. | Full size

This way, I achieved a one-way data flow: core reflects data, derived transforms core, the UI presents derived, the user modifies the UI, which updates the core, and repeat.

Final Words#

This is just a surface level explanation of multiple things I had to do for this project. I hope this page allowed you to grasp the variety of tasks I worked on this mission. If you need more context or information, you can contact me by email.

Thank you for reading!