Why we chose react native and express.js

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..