Slide 1

Slide 1 text

Backend Technology Selection

Slide 2

Slide 2 text

自己紹介 Self introduction

Slide 3

Slide 3 text

RODRIGO RAMIREZ / ロドリゴ ラミレス @xpromx Argentinian Spanish: Native | English: Business | 日本語: 勉強中! https://xpromx.me Career ● 2006~2008: Freelance Developer ● 2008~2015: CEO/CTO - PowerSite (SaaS: NewsMaker, SocialHint) ● 2015-2021: CTO - Travelience (GoWithGuide: Tour Guide Marketplace) ● 2021~: Full-Stack Developer at ReiwaTravel (NEWT: Abroad Tour Package) ( + 10 years ) Self introduction Full-Stack Developer

Slide 4

Slide 4 text

NEWTとは About NEWT

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

Backend Stack

Slide 9

Slide 9 text

Backend Stack

Slide 10

Slide 10 text

Choosing the right technology stack

Slide 11

Slide 11 text

Choosing the right technology stack

Slide 12

Slide 12 text

Choosing the right technology stack Current team knowledge + Scope of the project your are trying to build

Slide 13

Slide 13 text

Choosing the right technology stack Developers available using that technology + Future proof

Slide 14

Slide 14 text

Choosing the right technology stack Development Speed + Scalability & Maintainability

Slide 15

Slide 15 text

Choosing the right technology stack Development Speed + Scalability & Maintainability Developers available using that technology + Future proof Current team knowledge + Scope of the project your are trying to build

Slide 16

Slide 16 text

Backend Stack

Slide 17

Slide 17 text

API Layer

Slide 18

Slide 18 text

API Layer Selection Criteria ● One way to request information from our Web and Mobile apps. ● It should be easy to maintain and scale

Slide 19

Slide 19 text

API Layer Candidates Criteria REST GraphQL gRPC It should work for our Webs & Mobile Apps ✅ ✅ ⚠ Schema-based request ❌ ✅ ✅ Easy to maintain & test ⚠ ✅ ✅ Speed & Smaller payloads ⚠ ✅ ✅

Slide 20

Slide 20 text

API Layer Conclusion GraphQL was the best option to cover all the uses cases we needed gRPC is more performant for internal communication between our apps, but it's not supported completed over HTTP.

Slide 21

Slide 21 text

GraphQL

Slide 22

Slide 22 text

GraphQL What is GraphQL? ● GraphQL is a query language for your API ● It was created by Facebook (meta) ● It gives the client the power to ask exactly what they need ● It prevents Over and Under fetching of data ● GraphQL has a strongly typed schema ● Developers can easily check the GraphQL documentation schema ● Big companies are using it: Facebook, Twitter, Netflix, Airbnb, etc

Slide 23

Slide 23 text

GraphQL Libraries and Services used by NEWT Backend ● Apollo Server ● TypeGraphQL: Code First Approach ● Apollo Studio : Schema Validation & Performance Monitoring

Slide 24

Slide 24 text

GraphQL Schema First (SDL-First) Code First

Slide 25

Slide 25 text

GraphQL vs REST

Slide 26

Slide 26 text

GraphQL Vs REST HTTP Methods REST ● GET ● POST ● PUT ● PATCH ● DELETE GraphQL POST → operation types ● Queries → get data ● Mutations → change data ● Subscriptions → get real time data

Slide 27

Slide 27 text

GraphQL Vs REST API Documentation REST GraphQL Open API (Swagger, etc.) Schema Introspection out of the box.

Slide 28

Slide 28 text

GraphQL Vs REST Over-fetching and Under-fetching of data REST GraphQL

Slide 29

Slide 29 text

Programming Language

Slide 30

Slide 30 text

Programming Language Selection Criteria ● Current team knowledge ● We decided to use GraphQL, so we need a language that fits well with that. ● Easy to Develop and Deploy

Slide 31

Slide 31 text

Programming Language Conclusion We decided select TypeScript, and the reasons are: ● Our team members already had production experience with TypeScript and GraphQL ● Our frontend team also use React and Typescript ● Node.JS/Typescript is the most popular option for implementing GraphQL servers. ● Node.JS/Typescript apps can be deployed anywhere.

Slide 32

Slide 32 text

Infra / Cloud Providers

Slide 33

Slide 33 text

Infra / Cloud Providers Selection Criteria ● Managed solutions ● Easy to deploy our code, scale, and monitor.

Slide 34

Slide 34 text

Infra / Cloud Providers Candidates We compared various solutions offered by GCP and AWS based on our selection criteria. We reduced it to two options. ● GCP Cloud Run Managed Serverless Containers https://cloud.google.com/run ● AWS Elastic Beanstalk Managed Services to Deploy and Scale EC2 instances https://aws.amazon.com/elasticbeanstalk/

Slide 35

Slide 35 text

Infra / Cloud Providers Candidates Feature Cloud Run Elastic Beanstalk Cloud Provider GCP AWS Description Managed Serverless Container Managed EC2 instances Price ✅ (pay per second) ✅(pay per hour) Scalability ✅Automatically ✅Automatically Full Managed ✅YES ✅YES Deploy Method Docker Source Code, Docker DX ✅Very Good ✅Good Vendor Lock-in ✅ NO ✅ NO Integration with DB ✅ YES ✅ YES

Slide 36

Slide 36 text

Infra / Cloud Providers Conclusion Both options were good enough, but we decided to go with GCP because: ● GCP interface was easier to understand ● Cloud run was easy to deploy and setup compared with Elastic Beanstalk. ● We planned to use Firebase Auth and BigQuery. So keeping all in the same place will simplify the infra maintenance.

Slide 37

Slide 37 text

Bonus: Vercel & Testing Environments

Slide 38

Slide 38 text

Vercel & Testing Env. ● Vercel automatically generates testing environments for each PR. ● We use GitHub Action to create a DB based on the branch name. ● After a branch is deleted, the DB is also destroyed. ● Vercel also generates our testing environment for our Admin and Web apps

Slide 39

Slide 39 text

Backend Stack Choosing the right technology stack https://engineering.reiwatravel.co.jp/blog/ choosing-the-right-technoloy-stack Backend Technology Selection for Building a digital travel agency. https://engineering.reiwatravel.co.jp/blog/newt-b ackend-stack

Slide 40

Slide 40 text

Thank You! @xpromx https://www.reiwatravel.co.jp/recruit We are hiring! All positions open! ありがとうございます! Muchas Gracias!