We are soon reaching the testing phase for our little sport app athlyeti https://athlyeti.com/ I think it's time to write a few words about why we chose the stack we have.

The stack

Before jumping to reasons, I would like give you an introduction to the tech stack we currently have for athlyeti.

Expo + react native

That's for the client. The project is ejected meaning we need to reinstall after big changes. This is a bit unhandy but it was necessary when implementing google and apple auth. Expo is just such a great tool that comes with a build and delievery pipeline. With one button click, we deliever our code to the ios app store. (I love it)

express.js + postgresql (knex) + redis + directus

That's our backend stack. The biggest part is truly express.js and psql. Directus is what we just use to visualize and edit our backend data. It is a headless cms but we do no database changes there. All the migrations and schema is done in knex. Until now (no productive experience) I feel like directus is doing a great job. Check it out: https://directus.io/

Why react native and not swift?

That was such a hard question when starting to code. React native is discussed with many downsides, whom of which I feel only partially until now. One of them is performance. People say it can never be as performant as native code. Thats a fact, because react native works with a js bridge talking to native code. No matter what you do, there is always a layer above the native code. So yes, react native will always be slower no matter what you do. But do we feel it until now? Not really. And we render quite a large list or activites (yes, haven't optimized this until now. Its on the todo). But that's of course easy to say in the aftermath, now that we see it works with the stack we chose. But the main reason for choosing react native is really the conveniance. I think one should not care too much for online opinions and rely on the team's knoledge and experience. Would I choose RN if the team has lots of GO / Swift experience and no react experience? No, definitely not. But The team (well, me myself an I) have gained react experience so I chose it and I would do it again.

Why express.js and knex?

That's not such an easy one. This backend is pretty conservative. When looking at the options right now, one could choose modern and sexy stacks like firebase, amplify, mongodb, rust (maybe?), nest.js and the list goes on. For me, firebase and amplify didn't come into question because I feel like giving too much control to clouds. If choosing one of them, one is so much locked in. And the price is quite intransparent imo. (See my last article where I exagerate in how evil clouds are). I was honestly very indecisive about whether to choose a JS framework like nest or express or use GO. The main reason in the end was that JS is just so much more common at the moment. If ever in the future someone would have to touch the code I've written, I would much easier find someone who knows JS rather than GO. That's basically the reason. Next on, why not using an ORM? That's a thaugh one. In the aftermath, I think it would have been easier. But I was afraid of the database growing and me losing control over it. But that just didn't happen. I have 3 operative tables at the moment. But why not nest? I used it once and I felt like I had not enough control. I spend half a day finding out how to do socket.io whereas with express.js it would have cost me one single chatgpt prompt.

So that's the reason for all of it. Was it the right choice? Until now yes, but we are only in beta phase until now. Maybe, if we ever make it to production, I will change my opinion and curse my past-self for chosing it.

But in the end, does it really matter? I don't think so. In the beginning, when having zero.zero users, it's so much more important to get somewhere than to wrap your head around having the perfect stack. Also, it's always a bad sign if a company has more microservices than users..

I write this post because I am concerned about the development that we have seen in the last years regarding server infrastructure and clouds. I wonna write down my perspective of how things have developed and what makes sense for the future.

The beginning

At the starting phase, cloud hosts like gcloud or aws consisted of remote machines that one could start in one click and log into per ssh. That was a really handy feature and just so much better than managing your own machine. Someone on the other side managed the resources, the hardware, the internet connection and so on. You could just have your machine located in san francisco or whatever, start it, stop it, kill it and so on. Things were cool back then. I once installed a devops pipeline jst

Where things got out of hand

Later on, I guess it was Heroku who was leading in the deployment of pre-defined servers like databases, search services, frontends, minecraft servers and so on. That's where things started to get out of hand. The idea is not bad: You have your database up within seconds. You can connect your app to it within minutes. The cloud manages your backup if you want to. This is really nice. But everything comes at a cost. From now on, clouds started charging their customers for database reads and for the amount of database entries. This idea is just wild. You need to have some shitty code in your software that decides to go wild and you have as many reads as your engine can handle. Or you can get a DDos and your bill is just crazy. As a product owner of a serious app launched on the web somewhere, I would never trust such a payment option. Because internet is just wild and so is pretty much every source code.

Today's debacle

The thing is, modern billing is not even the worst part of clouds. A standard website that's proposed by those providers may look like that:

• A PostgreSQL Database for your data
• A Redis Database for caching
• A Frontend server with a CDN to be on the edge
• 2 Microservices for the backend (Or even worse, cloud functions)
• Maybe one ElasticSearch service to find some data because your database is shitty
• An Authentication service

And the list goes on. This is a classic example of an overengineered website. If you want to spin up something like that on AWS, you would need users setup for the services, users setup for the teams, have permissions set right, setup backup for everything, make sure communication is working, have separate logfiles and the list goes on and on. That is just so much to manage. I mean, some companies with huge traffic may need that but here is the point. The argument for clouds in the early days was their flexibility and easy setup. A system like the above on AWS may need several teams to manage. The bill would be all over the place and hard to decode. The cloud provider has all the power over the product. A small rise in the price and you cannot go away because you are just locked into the cloud with not just the system but also the people you have hired. This lock is just so scary. In the end, it means the cloud IS the product you make and the cloud makes the most profit of it as well. The engineering force spent into cloud providers could just as well be spent into a good docker setup with just plain old linux machines.

The alternative

That's where we arrive. I wonna provide some things to consider BEFORE deciding for a cloud architecture.

1. How much do you NEED to engineer your app? This is the first thing to look at. If you are a startup, just create a monolite and write shitty but fast code. May it be next.js, rails, node.js or whatever. Keep the code in one place and don't worry about performance because mostly, you have very few users in the beginning. If you grow, so does the income and that puts you in good places. But even there, you can scale with monolithic Opimizations and just more hardware as well. No need for crazy architectures in first place. Simplicity always comes first.
2. Dockerize everything. Docker is a great technology and instead of making GCloud or AWS Certificates, invest into being good at docker. Not even kubernetes but docker in first place. Once you have your app dockerized or all your app parts in a docker compose, you can spin it up on any machine you just want. You can have a GCloud compute instance. Google decides to mess up and all you need to do is spin up a Digitalocean droplet, start it with docker compose, migrate data and change the DNS entry and you are gone.
3. Keep it simple and handy I have made a great experience by hosting an app just using traefik and docker. For small apps, all you need is a proxy and docker. Traefik is a proxy that works with labelled docker containers. You label them with your subdomain and, once setup, traefik is handling the rest. I think coolify is using traefik as well and its my favorite hosting service. Check traefik out here: https://doc.traefik.io/traefik/ (No, I am not paid but it is a cool product).

I really wish we had more docker engineers than AWS experts in the industry. Another advantage: If you are dealing with sensitive data, just host it in your country or even just locally: Possible when you just know docker.

Sidenote: I like Digitalocean

I am not paid by the company, but I think digitalocean has managed to keep its cloud simple and easy. Make droplets, make sql services, connect them and there you are. They have just few products but document them really well. I have used digitalocean app machine as well with an SQL Database. As far as I remember, they don't charge by reads or something wild. It is still a cloud for users and devs and not for management.

I have most experience in frontend with technologies like react, next.js and angular. But since I am always curious about different technologies and solutions, I tend to try new things. The first time I heard of ruby on rails was 3 years ago when I gave it a try. but didn't come so far and didn't have the endurance or a project to keep going. But I stayed curious because the usp of the framework (according to the community) is its develpment pace. That's what I like so I tried again and here's a first summary of my experience.

The Object oriented world

Neither js nor go are really object oriented languages. They are mostly procedural and I got so used to this procedural world that I had a really hard time going back to ruby and write everything in classes. I admit I have a hard time switching "back" to thinking in objects. I think debugging and coding was easier when I had my variables and methods in place instead of abstractions like objects and inheritance.

The LSP

One of the ugly things in ruby on rails is the LSP imo. For react and go, I have setup my editor in a way that I can jump to definition, go back and forth, have suggestions, autocomplete usw in such a way that I feel like an AI copilot is not necessary. For ruby on rails, on the other hand, I cannot jump to definition. I have some suggetions but not all of them. That is a real pitfall. Having a good language server is god for both development speed and security. Potential bugs are just caught before you even compile the code. So for ruby on rails, that's missing and a minus point. It might be because rails is doing so much magic, which leads me to the next point

The magic

Rails is a very accelerated framework. You can scaffold your stuff together, spice it with some code here and there and your app is done. That's cool, but just like in harry potter there's a dark side to this magic as well. As a junior rails dev, I spend so much time just figuring out why my form isn't working, why I cannot do this in that controller, why I get this error and so on. I know I have some learning to do still but that's the experience. With go, for example, things just worked and most of my time went into thinking about the best way to write this form or this code and that's just a huge as developer. Also, I think if a rails project grows, the problem of the magic, the unseen stuff happening might just lead to really long debugging sessions. Whereas with an easy and straightforward framework, you just trace throught your code, from method to method and find your bug.

The good things

This text has become too negative so I would like to bring some positive vibes into rails as well. I really like the idea of conventin before configuration. I may not yet have that powerfull feeling, but I can imagine that with growing experience in this framework, One can become really powerful and fast. That's why I keep going with my rails project. Even just the fact how easy it is to create and edit data, to configure my routes is really a bless. Compared to like go where I sql-ed so much stuff and wrote so many time consuming migrations to get where I wanted. (note: haven't tried a go orm yet. Might be sth for the future). That's why I don't give up and maybe in the future I write about how I became a rails champion ;)

As a passionate developer, I wonna write code of course. I was always developing and then crashing my head about how to deploy my application. Like 5-6 years ago, what I had was a linux node setup somewhere then starting docker containers with it via ssh. I once even wrote a bash deploy script that was deploying right after my code was updated on github. But it was messy tbh.

After I spend ways too much time thinking about my linux node, I discovered those fancy apps like firebase and aws amplify (Later on vercel). I tried out both of them and it was so easy. But of course I thaught all my apps would go though the so-called roof and sooner or later I need to give money to those platforms, which I disliked. Also, I think it is just crazy to charge me for every request on a database. I simply didn't have enough trust in my skills to not have a bug that just penetrates that database and leaves me back giving all my money to aws.

That's why I used heroku. It had free tiers back then. Now it doesn't anymore and since I have not made one single dollar with any of my apps I didn't want to pay something. That's when I discovered coolify in the end. It was a simple setup on a plain old linux server and everything just worked. I can create databases, services, deploy my dockerized github apps in less than 1 minute. Everytime I do it I am just amazed by its ease. I sometimes just create and kill services for fun. When my 5-yrs-ago me would see me now, it would be so proud.

Coolify is an open source platform to basically host and manage docker containers and networks. There are database templates like psql, mongodb, mysql which really are just a one-click-deploy. There are complete application templates as well for cms, wikis, chats and so on. One day if I have time, I will setup my whole open source wold with it and it is gonna take me like one afternoon. I connected my github account as well and I can deploy from a branch of my code. It as to be dockerized then everything is set for deployment.

What makes it so nice for me is the UI to be honest. Compared to like dokku, I can see stuff. And I need to see stuff and click around when it comes to infrastructure because I am simply not as used to it. The simplicity that comes with the UI is really good. And I think it has an unused potential in industry. If I were a samll business, I would definitely had a coolify instance to host some tools we want. It is simply cheaper and easier than paying all the monthly fees to some big company in my opinion.

I know this is like an advertisement for coolify, but I do not get anything from them. I just use the tool. If I would make my first euro on the internet, I would definitely donate some 10 cents to the devs from coolify.

Check it out: https://coolify.io/