# FY1 S0 Technology Plan

Dream a federated infrastructure for apps. Instead of each developer wasting duplicate cost to keep their apps simply standing, each developer will get to focus on what their apps stand for. This is the promise of Junwon App Platform that we made in [FY1 S0 Product Plan](FY1%20S0%20Product%20Plan%2045538c034c4e4b929144aca78a124dc2.md). 

On Junwon App Platform, apps will run in 2 modes: 

- Independence Mode will run an app, in isolation from all the other apps on Junwon App Platform, on the 3P developer’s servers hosted on 3P developer’s accounts on cloud service platforms.
- Federation Mode will run an app on our 1P servers.

We will first develop and publish Independence Mode to immediately unblock developers to make their dreams a reality. After Federation Mode is made, apps in production will run on Federation Mode, and apps in development will run on Independence Mode. Federation will let us improve the experience of developers and users over time at our own effort. 

# Specification

We must make it possible for developers to deliver an online app with original features to users within a day. While we are developing Independence Mode, we must make it possible for us to grow the codebase to support Federation Mode. All other features, even if we can add them with trivial effort, or even if customers explicitly ask for the features, unless we pivot the Product Plan, are mere distractions. 

## Must Support

Junwon App Platform Independence Mode must make it possible for developers to launch an online app within a day. Within a day, users must be able to hold and touch the app working the way developers dreamed on a drawing canvas. 

To minimize time to launch for developers, we will develop Cross Repository and Auto Deploy. Developers will interface with Cross Repository and Auto Deploy using Junwon CLI (See ‣). 

### Cross Repository

**Cross Repository** separates out app-level code from platform-level code. 

When a developer creates a local Junwon App Platform workspace, the root level directory will have 2 directories: /platform and /app. Developer will only work in the /app directory. 

| Optimize | Metric | Target |
| --- | --- | --- |
| Minimize | Number of files in the “/app” directory at creation. 
* Include configuration file. 
* Include sample app.  | 3 |

### Auto Deploy

**Auto Deploy** configures, deploys, and integrates multiple servers and databases for the developer to create one coherent system for an online app. 

| Optimize | Metric | Target |
| --- | --- | --- |
| Minimize | Number of inputs needed before each deployment. 
* Include the initial command to call Auto Deploy. 
* Include the configuration file as one input. 
* Ignore the number of steps outside of CLI (e.g. on CSP websites) and the number of lines in the configuration file. These will be tracked as Product Metrics.  | 3 |

## Will Later Support

To let developers focus on dreaming up new features, we will take over improving the infrastructure of their apps. Developers will wake up to find that their apps were made faster, more secure, and more pleasant to their users, by us. We will also drive down the cost of infrastructure to let them get more done with less. For all these to come true, we need to make Federation Mode as soon as Independence Mode is made. 

While we are making Independence Mode, we need to make it possible and easy to grow the codebase to support the following features which will be important to driving down the cost and creating a great experience for developers and users in Federation Mode: 

- **Federation of multiple 3P apps in a single 1P shell**
    - Developers must be able to update apps live in production.
    - We must be able to update the shell live in production.
    - We must be able to provide tools for monetization.
- **Federation of accounts and profiles in a 1P database**
    - Users must be able to have multiple profiles in a single account.
    - Users must be able to use one profile on multiple apps, not only to authenticate, but also to carry over information such as their interests.
    - We must be able to provide tools for moderation.
- **Federation of event logs in a 1P database**
    - We must be able to report accurate metrics to developers for monitoring and experimenting.
    - Accuracy and standardization of the metrics we report must be able to support financial institutions to make informed investment decisions on specific apps.
- **Federation of contents in a 1P database**
    - Users must be able to discover contents via search and recommendations.
    - Developers must be able to deduplicate cost of saving duplicate contents with other developers.
    - We must be able to provide tools for moderation.

See how much more utility we may be able to provide to developers, and to businesses working with the developers, by federating and standardizing. Write each line of code with this plan in mind. 

## Will Not Support

If we spend one unnecessary day developing a feature that is not strictly necessary, then developers lose another day without seeing their dreams come true, and their users lose another day without seeing what could be. We must fight distractions. 

We will not support the following features, and we will not set up the codebase to be able to support the following features later: 

- Horizontal Scalability
- Mobile Apps
- Offline Mode
- Search Engine Optimization

But what if we find out later that we need to support the above features and that we cannot support the above features without rewriting the codebase? Here is the solution: rewrite the codebase. Do not let the fear of what has not happened stop us from making anything happen at all. Such fear too is a distraction that we must fight. 

# Architecture

## Independence Mode

In Independence Mode, developers will host all programs in the full stack on their own accounts. If we find it viable to do so, we will consider providing 1P server capacity for Independence Mode later. 

![IndependenceMode.png](FY1%20S0%20Technology%20Plan/IndependenceMode.png)

We will try the following technology choices:

- Webpack Module Federation for combining 1P shell and 3P app.
- Next.js in TypeScript hosted on Vercel for frontend components.
- Supabase for accounts, database, storage, and backend logic.

We will test and document the developer workflow using the following developer tools:

- GitHub for source control.
- Visual Studio Code on GitHub Codespaces for code editing.

We expect this architecture will sufficiently support each app developer to scale to 10K daily active users. We expect to keep this architecture for Independence Mode even after transitioning Independence Mode from production mode to testing mode. 

## Federation Mode

In Federation Mode, we will host all programs in the full stack for live production user traffic on 1P server. 

![FederationMode.png](FY1%20S0%20Technology%20Plan/FederationMode.png)

If a developer chooses to host any server-side code on their own server, they will be maintaining that server. Otherwise, it will be possible for the developer to focus on writing the app-level code (”3P Apps”), and delegate all infrastructure work and platform-level code to us. 

We plan to transition to Federation Mode gradually by moving services one by one in the following order: Accounts, 1P Frontend (Shell and Apps), Database, 3P Backend Logic, 3P Frontend. 

When we are ready to start working on Federation Mode, we will write a new technology plan and propose the technology choices.