Conclusion

• ServerlessFramework is great
• S3 hosting + CloudFront for the front end and Lambda@Edge for the SSR
• Don't use RDS but DynamoDB as a database.
• API is basically GraphQL, and you can easily add REST if you need it.

There is no absolute right answer to the architecture.

There is no absolute right answer for architecture.
This is because different products and phases have different requirements, and it is necessary to consider the appropriate architecture for them.

For example, the Tokyo Stock Exchange's high-speed trading system, which was recently closed for a day due to a failure, is an architecture that is fully allocated to stability and reliability requirements, distributing the load across 400 servers and localizing the impact of the failure by dividing the network.
Growth companies such as AWS have high scalability requirements and adopt a microservices architecture so that they can deploy new services without impacting the current application to keep innovating.

So let's consider what requirements are more important for startups.
Here is a ranking of the reasons why startups fail.

No. 1: there was no market need.
No. 2: Depletion of funds
No. 3: Inappropriate team composition
No. 4: Lost to the competition.
No. 5: Hard-to-use product

These are not all problems that can be solved by architecture, but you can see what requirements are needed.

No. 1: → Agility to change the specifications to meet customer feedback.
No. 2: → Cost optimization
No. 3: → Small team structure with as few specialists as possible
No. 4: → Increasing the speed of development to overtake the competition
No. 5: → Agility to increase the improvement cycle

We hypothesize that the requirements for startups are agility, cost optimization, small team, and speed of development.
We have examined the technical elements in this regard.

Technology Components

I've discussed how startups should adopt technology elements that excel in agility, cost optimization, small team, and speed of development.
I'm going to introduce the technology components that I think are superior in this regard.
I will explain in three stages: "front end", "database" and "back end (API)".

Frontend

Framework

There are three major front-end frameworks: React, Vue, and Angular.
In terms of "development speed" and "agility," I think typing in TypeScript is a must. The reason is that you can benefit from the completion and improve development efficiency by knowing what data to pass, and you can check for errors at compile time when you change the code due to specification changes.
In terms of compatibility with TypeScript, I think React is superior to the other two frameworks, and I think React should be adopted as a front-end framework.
Also, from the point of view of "speed of development" and "small team", I would recommend using Next.js rather than using bare React. This is because with Next.js, you can do things that are necessary but troublesome to implement with No Config. Specifically, routing and SSR (for SEO and SNS OGP).
From the above, Next.js (TypeScript) is recommended as a front-end framework.

Where to deploy the front end

The first places that come to mind for Next.js deployment are vercel, Netlify and Heroku.
These are good options because they are very easy to deploy and basically free to use.
However, there are always some functional limitations to the free quota, so if you're looking to scale, you'll want to build on AWS if possible.
With S3 hosting + CloudFront, you can use AWS free quota, and even if the free quota runs out, it's almost free (0.025 USD/GB for S3, 0.114 USD/10TB for CloudFront).
If you become a paid account for services such as vercel, you will have to pay a fixed cost, but with this configuration of AWS, it will be an on-demand billing, so we recommend S3 hosting + CloudFront in terms of "cost optimization".
By the way, since the free quota of vercel is also almost like unlimited, if you do not assume extreme scale, vercel is also totally good option.
I think that using a server such as EC2 or ECS as the deployment destination of the front end is out of the question from the point of view of "development speed" and "cost optimization".

Next.js SSR is done with Lambda@Edge.
Deploying this configuration is easy with ServerlessFramework with No Config.
https://github.com/serverless-nextjs/serverless-next.js

Database

RDS vs DynamoDB

In conclusion, I recommend you to choose DynamoDB without question.
To be more precise, RDS has to be used for complex data structures and access patterns, but in the initial phase, it is better to use DynamoDB and if it becomes complex, consider using RDS together.
From the point of view of cost optimization, Dynamo has a on-Demand option, while RDS charges by instance start-up time. Also, RDS+Lambda requires you to install RDS Proxy. There is also Aurora Serverless, but its cold start is critical.
Also, RDB has a dependency between tables, which makes it difficult to discard tables and causes migration and remaking of SQL.
In terms of development speed, Dynamo does not require management of database and is compatible with GraphQL, making it possible to increase development efficiency.

Designing DynamoDB

DynamoDB is recommended, but if you design DynamoDB like an RDB, you will get stuck, because DynamoDB doesn't allow joins, so you need to design your tables so that joins are not necessary.
RDB and NoSQL have completely different table design practices, so be sure to apply the initial learning curve here.

Backend(API)

REST vs GraphQL

We recommend GraphQL for agility, small team, and speed of development.
GraphQL transfers responsibility from the back end to the front end. It increases agility by not having to modify the API every time the UI is changed.
Also, if you write a REST API in Lambda, you will have to create as many Lambdas as there are endpoints (although there are ways not to do so), but GraphQL is a single endpoint, so you can keep it "small".
GraphQL is very easy to handle when using it from the front end, and although this is an experience, I feel that the front end development speed is higher than REST.

However, there are certain usecase for which REST is better suited. For example, file uploads require a little bit of work when using GraphQL. You can use REST endpoints in conjunction with an API Gateway in the same domain.

Deployment

Deploying the API Gateway + Lambda(GraphQL) + Lambda(REST) + DynamoDB configuration is easy with ServerlessFramework.
You can find templates for each language on here and try deploying it all the way through. You'll be surprised at how easy it is.
By the way, I use here after customizing it to make it easier to use.

About Certification Authorization

We use Cognito for authentication and authorization to implement login functions. If you are conscious of development speed, it may be faster to implement it yourself, but it's better to use a managed service because of the security implications.
This can also be added with ServerlessFramework.

Final Form.

In summary, the architecture is as shown in the above figure.

• Using ServerlessFramework
• S3 hosting + CloudFront for the front end and Lambda@Edge for the SSR
• The database is DynamoDB, not RDS.
• The API is basically GraphQL, you can easily add REST if needed.

I hope this will be helpful to those involved in startups.
Thank you.