🇬🇧🇺🇸 Amethyst Platform - DevLog 1

What is Amethyst Platform?

Amethyst Platform strives to be a one-stop platform for the complete application lifecycle. As soon as you push some changes to your code, we test, build, configure and deploy it so that you don't have to worry about that. Everything is managed through an amethyst.yaml file in your project, and we do the rest. You can read more on the Amethyst Platform website or on the Amethyst Platform project page .

On marketing and promotion

In the early days, I set up the website, from which I was planning to collect some email addresses to validate the idea. But it didn't go so well, I only got a few (way less that the amount I targeted), but to be fair, I didn't spend too much effort to promote it either.

Right now I put most of the effort into building the MVP, because (at least from my point of view) the nature of the product doesn't really allow for validation without a working prototype/MVP.

It's not the usual kind of SaaS product where people could join and leave in the span of a few months. Being more in the hosting and infrastructure space, it aims to create long-term relationships with the people that use it: you can't switch hosting every few months. Once you find a good hosting option, you tend to stick with it for as long as possible.

On tech

The platform is being built on top of Kubernetes, so I am coding and testing the results live on a mini-cluster managed by Scaleway .

Right now, the flow of connecting a Gitlab account, connecting repositories and running the test, build and deploy functionality is done. I am still spending some time testing various edge cases, but this part seems pretty stable so far. For the deployment part the following features are done: generating SSL certificates, exposing services on the public internet on specific URL (specified in the amethyst.yaml config file), updating with a newer version when a push is being made.

Logging

I am currently integrating ElasticSearch for log storage for everything that emits logs (running steps and services). The first iteration I did on that was pretty limited: I was relying on Kubernetes to serve the logs from the pods, but that came with some limitations:

• being unable to log extra events from inside the code, for debugging purposes. I was able to only see the standard output and error emitted by the running containers. Because of that, the deployment step had no logs at all, because it relies on creating/updating/deleting various Kubernetes resources, not running containers at all!
• having to keep around all the finished step containers (test, build, deploy) to be able to access the logs. I did an initial "hack" to circumvent this, but it wasn't enough (moving the logs to long-term storage such as an S3 compatible object storage as soon as the job completed).

Tooling

At first, I was developing the services directly on my laptop, running them locally and having the Django backend use a SQLite database. As soon as I needed to add more auxiliary services (Redis, ElasticSearch, Celery beat), this approach became inefficient because I had to manage all that somewhat manually.

First step for improving the development workflow was to move everything into Docker containers, and manage the development environment using docker-compose.

I created some tooling to help speed up the whole development process. A dedicated CLI that bootstraps all the development processes that I needed: starting the whole project, cleaning up all the environment when I am done for the day, debugging various Kubernetes resources created in the cluster and others.

Fighting Next.Js and Relay

On the frontend side, I initially started with Next.Js, being the hottest new trend in the frontend space. I was eager to try it out, but by doing so, I committed the ultimate sin of the startup world: succumbing to the shiny object syndrome instead of focusing on building. Being a developer, I tend to do that from time to time, it's an urge I am still fighting, but fortunately I am making progress.

I started with Next.Js and Relay 10.x (pre-hooks), but the Server Side Rendering was causing quite some issues. I found myself having to do weird hacks to be able to do the GraphQL requests properly from the server side. After all, for this kind of application, where all the content besides the login and register pages are locked behind authentication, it didn't make sense to endure all this pain for the sake of SSR. It just didn't have any advantage over the "classic" client-side only rendering.

So I switched to the old plain React based approach and ditched Next.Js altogether. I removed the parts that were provided by Next.Js out of the box such as routing, and I switched to other open source tools to get the same behavior. It wasn't as painful as I expected, but it involved extra work nonetheless, which would further delay the MVP. After all, no bad decision comes for free.

Then, I did something else (again succumbing to the shiny object syndrome, more or less): I upgraded Relay to the 11.x version (with hooks), and thought to migrate all the QueryRenderer , createFragmentContainer and mutations to use the new Relay hooks.

Again, I fought with it more that it was worth, and after a day of pure pain, I decided to stick with the "old" way of doing things. The new way, with hooks, just adds more complexity, and I can't fathom the reason why the Relay team decided to design the API the way they did.

It seemed that instead of going the ideal flow: from problem ( "we have this problem with the old way" ) to solution ( "Using hooks helps us with that" ), they seem to have gone the other way around: They had the requirement to use hooks, and fiddled with the API so that it fits the design paradigm. There are some new features, that's true, but honestly it feels just like added complexity with not enough upside to justify the migration.

/ rant over

Organization

I systematized my work more by creating tasks and using a proper project management tool. I started using the kanban boards from Notion.so but I found them to be pretty limited. I switched to using ClickUp because I am already somewhat familiar with it from using it at my current job at Vuuh .

Next steps

During the next two weeks, I plan to use ElasticSearch for log storage and retrieval, start working on a dashboard admin to help me with debugging and future customer support and interpolate values from AppConfigs and AppSecrets into the services, when needed (+ being able to store/retrieve docker images to/from a private registry).

For the marketing and promotion part, I don't really have a very well-defined plan, but I want to start posting content for the Amethyst Platform Blog in order to increase the domain authority and target some organic traffic for some relevant keywords. Because SEO is a slow and long game (6+ months from when you start doing it for a new website until you start seeing results), I need to get on it early on.