Today, we want to share how Remoter serve thousand of traffic every day since we launch Remoter at the beginning of this year. We build Remoter at the top of AWS infrastructure because we already use AWS in our previous startup last time so we already have experience handling things in AWS.

Remoter.id is a platform to help digital talents get full-time, part-time, or freelance jobs remotely from within and outside the country. Digital talents can build their own website portfolio and can be easily found by thousands of service users from home and abroad.

Frontend

The main website Remoter.id

Frontend Repo is hosted in the GitHub private repository. We used NextJS as our frontend application and using AWS EKS for the Kubernetes to give our site the best possible scalability and security that we can think of.

The main frontend repo is built using Circle CI since they provide a generous free plan and the performance is better than our previously built docker as well and it does support ARM machine which is needed by our AWS EKS for more efficient performance in the machine levels.

Customer Relationship Management (CRM)

The CRM frontend is also hosted in the GitHub private repository. It is being published to Netlify because it is a pretty simple Single Page Application (SPA) where our operational team can update our data and keep our site data updated with our users.

Since the site is published in Netlify, we just use AWS Route53 to point the CNAME as our CRM subdomain to the Netlify URL.

API & Microservice

For the backbone of the Remoter backend, we use node js with nest js as our framework. We expose our API using GraphQL as our gateway. Why do we choose GraphQL instead of rest? We believe it's quite hard to make frontend and backend talk together in terms of API communication. With GraphQL, the frontend can take whatever data they need and don't need to fetch unused data in the frontend.

From our previous experience, we already know how hard to maintain 1 big service in 1 repo with multiple hands on it, quite scary and messy when someone doing changes on it. We believe microservice with multiple repo concepts suits us in our development method. We separate our service based on the business requirement and use GRPC as our internal service communication. Now everyone is happy because each service has its boss.

KUBERNETES

Why? why? why? That's the question from people around us. Many people hate Kubernetes because of its complexity and price. Trust me, it will be cheap if you know what's Kubernetes can do to help you maintain whole architecture and deployment. Currently, our Remoter can serve a thousand users every day (and keep going up) without the worried the server will down. Kubernetes can scale our service automatically. We will put this section and explain it in the next part.

So, If you still want to know the next chapter of our story, follow us and we will back with a more interesting story within our tech.

Unicorn soon 🦄