tabi-memo / backend

0 stars 0 forks source link

GraphQL API Design #3

Open samuraikun opened 1 year ago

samuraikun commented 1 year ago

GraphQL API

The Supabase GraphQL API is automatically reflected from your database's schema using pg_graphql. https://supabase.com/docs/guides/graphql

It's amazing!! :tada: (If we use Supabase, we wouldn't need to implement GrapQL resolvers by ourselves.)

Infra

※ If we need to develop our own...

Comparison Table

Feature / Platform Google Cloud Run AWS ECS Fargate AWS App Runner AWS Lambda Supabase Function
Ease of Management High Moderate High High Moderate
Scalability Automatic Automatic Automatic Automatic Limited
Cost Usage-based Usage-based Usage-based Usage-based Usage-based
Startup Time Fast Fast Fast Very Fast Fast
Customizability Moderate High Moderate Low Low
Database Connection Supported Supported Supported Supported Supported (with limitations)
Long-running Tasks Supported Supported Supported Limited Limited
Docker Support Yes Yes Yes Yes No
Network Configuration Requirement Not required Required Not required Not required Not required
Terraform Configurability Yes Yes Yes Yes Limited

Explanation

This table can help you choose the most suitable environment for a GraphQL API Nest.js application, taking into account Docker container support, network configuration needs, and Terraform configurability.

Yo-mah-Ya commented 1 year ago

No suggestion or preferable but just simple question: As long as I google GraphQL servers, Apollo server is also popular and reliable. And I've used this before. And Nest.js seems to use it within it. It might be useful and simplified, but when some problems happens, it's going to be more difficult to fix it, for sure. What do you think about the pros and cons of them ?

samuraikun commented 1 year ago

@Yo-mah-Ya

No suggestion or preferable but just simple question: As long as I google GraphQL servers, Apollo server is also popular and reliable. And I've used this before. And Nest.js seems to use it within it. It might be useful and simplified, but when some problems happens, it's going to be more difficult to fix it, for sure. What do you think about the pros and cons of them ?

You are right! I prefer "convention over configuration" like Ruby on Rails, So I suggested Nest.js. But in this project, we should choose an approach easy to get started. Thk!

Yo-mah-Ya commented 1 year ago

Wow sorry ! Either Apollo or Nest we choose is out of scope in this issue.. Just copy and pasted from parent issue.... Then got it, Apollo sounds better !


First of all, Cloud Run looks nice ! But I'd say it's not going to be the reason that we'll choose it as a server with above investigation.

Somewhat it looks docker is considered that important though, is it really necessary in this project first of all? From where I sit, it'd be rather inconvenient when we can prepare particular environment, which are like exact version of nodejs run time, OS and whatnot. My concern is building time of container image and how we manage.

And AWS says it officially supports Docker with Lambda

samuraikun commented 1 year ago

Wow sorry ! Either Apollo or Nest we choose is out of scope in this issue.. Just copy and pasted from parent issue.... Then got it, Apollo sounds better !

First of all, Cloud Run looks nice ! But I'd say it's not going to be the reason that we'll choose it as a server with above investigation.

Somewhat it looks docker is considered that important though, is it really necessary in this project first of all? From where I sit, it'd be rather inconvenient when we can prepare particular environment, which are like exact version of nodejs run time, OS and whatnot. My concern is building time of container image and how we manage.

And AWS says it officially supports Docker with Lambda

Agreeing with your perspective 👍 We indeed don't need to focus on Cloud Run or Docker for this project. Supabase's managed GraphQL API already handles much of what we'd need without the extra work of setting up and managing containers. This keeps things simpler and lets us concentrate on the actual app development, without worrying about the infrastructure side of things.