Defining the general vision for what Cardinal is

[ernestoresende]

This project is the answer to years of having to deal with boilerplate work and making the different pieces that compose a full-stack application project actually work together.

On a modern full-stack application, there are a ton of moving pieces that need to be considered:

• What is the framework where the client app is going to be built?
• What will be the backend type?
• Is that backend type gonna be served by some kind of framework?
• What styling solution is going to be used on the client app?
• Where is the app being deployed? How does that deployment happen?
• If my client app's framework supports writing backend code, will I serve my backend from there, or as an separate thing?

Piecing all these questions together into a cohesive "thing" is not easy. Some technologies don't exactly talk well with each other, and deployment path is often obscure when you go outside of self managed solutions.

Cardinal aims to bring some ease to that problem by putting together predefined libraries, project structures and configurations that work the entire way for a given combination. We can think of it as the developer, asking from the machine:

"I want to create a new project using [frontendFramework] on the client, fetching data from a [backendType] API, and I want to be able to deploy it on [deployProvider]."

Is it a template?

By definition, yes. We could define it as multi-template given that the choices made during installation can change how your specific template is scaffolded, but that’s just a matter of semantics. It will be marketed as a "monorepo project starter".

Core principles

It is important to keep in mind that it isn't trying to solve all problems, only the most pressing ones faced by me, and — hopefully, in the near future — by the community that adopts it:

• It isn't trying to serve all languages. It keeps TypeScript as core foundation, and that is the only language it will support.
• It isn't trying to prescribe how you should write your applications. While we do have to make some choices on regards to what libraries to use in order to enable some of the chosen paths (eg. data-fetching), we try not to prescribe the things you can bring in yourself (components, state management, etc...).
• It isn't trying to cover every deployment path under the sun. This is because the cloud infrastructure we decide to support has either to be popular enough to warrant it being supported, or have easy enough solution for deployment in IaC manner (eg. SST for AWS).

Another core principle is that it bets really heavily on serverless architectures; All deployment paths take a "serverless-first approach". Vercel is a serverless platform by default, and while traditional deployments are possible in AWS, relying on SST to setup the infrastructure and deployment pipeline means AWS deployment path is also going to bee completely serverless (Lambda, Lambda@Edge, RDS, etc).

The diagram bellow gives an top-level idea of how the CLI will behave:

For the initial launch, it seems like a sensible enough idea to support Vercel and AWS deployments, and incrementally add support for more deployment paths in the near future (initial planned support for Google Cloud Platform and Cloudflare Workers).

Warning
Still trying to define how to handle authentication for everything that is not Next.js. NextAuth is in the process of becoming an agnostic solution for authentication, but it's not there yet, and there are several things to be considered about rolling out our own auth implementation with something like Passport. SST Auth works like a good second options, but it's directly tied to an AWS Lambda, which leaves us without authentication options for cases are none of the conditions are met.

Next steps

• Draft out project items and a implementation roadmap;
• Setup discussion topics for the CLI overview (this will help us have proper documentation about how the installers are going to work, and with the addition of more templates in the future);