Skip to content

codinsonn/green-stack-demo

Repository files navigation

Move fast and Build things

Supports Next.js Supports Vercel Deployments Supports Netlify Deployments Test in Expo GO Supports Expo iOS Supports Expo Android Docs with Storybook

This project was bootstrapped with Aetherspace, the Evergreen repo setup for all your full-stack cross platform app development needs {...πŸ’š} Enabling the project to be built for Web, iOS, Android, PWA, Static, SSR, API routes and GraphQL all at once πŸ‘‡ ... while also documenting your code automatically with Storybook.

Getting started ⚑️

Install packages: yarn install

Run on web & mobile: yarn dev

Run with Storybook docs: yarn dev:docs


βœ… Aetherspace, GREEN stack & template benefits? πŸš€

Aetherspace - GREEN stack starter template for cross platform React app development

🐦 Anouncement post
⚑️ Quickstart example
πŸ“š Core Concepts

Table of contents

πŸ’š - What is the GREEN stack?
πŸš€ - What is Aetherspace?
πŸ€– - Why start with a turbo/monorepo?
πŸ“ - File structure and installing new packages.
πŸ‘Ύ - Benefits and next steps.
πŸ€·β€β™‚οΈ - When not to use the GREEN stack.
πŸ“š - Relevant Docs.

What the hell is the GREEN stack? πŸ’š

In short GREEN stands for these 5 core technologies:

  • GraphQL for typed and self documenting APIs
  • React & React-Native for write-once UI
  • Evergreen components (extendable, themable, with docs & types)
  • Expo for easy mobile development, deployment and testing
  • Next.js for web, SEO, Static & Server rendering, API & Web-Vitals

The core idea is writing your app code or features just once with Typescript and React-Native, yet make it available on any platform or device without double implementations or the need for different development teams.

How does 'Aetherspace' help, exactly? πŸš€

Think of it as Unity for React Apps. Just like Unity aims to make cross console game development a lot easier for (indie) game devs, Aetherspace's setup for the GREEN stack aims to do the same for cross-platform app development.

Core concepts

  • Cross-platform from the start
  • Take what works, make it better
  • Single sources of truth
  • Write once, use anywhere
  • Documentation drives adoption

It helps you move fast, save time and deliver more

Aetherspace is an opinionated framework that fills in the gaps of working and building with the GREEN stack:

  • How should I handle responsive design?
  • How do I avoid web layout shift when react-native styling does not support media queries or classnames?
  • How can I expose / read public env vars across multiple platforms?
  • How do I take advantage of optimisations like next/image on web when that's not available in React-Native?
  • What's the best way to style and animate my UI elements for both web and mobile?

Just to name a few.

While the stack itself is very powerful, figuring out how to get set up and do certain things in a write-once way can be frustrating and time consuming. To save you time figuring it all out on your own, Aetherspace contains a bunch of packages, utils and best-practices to set you up for a quick and easy ride to cross-platform success.

But why start with a turbo/monorepo? πŸ€–

One annoying thing about figuring this stack out on your own is when packages you're using require custom configs for babel, webpack or otherwise. With Expo and Next.js, it often happens that updating e.g. a single babel.config.js used for both Expo and Next.js will fix usage on either, but then break the other.

Using a monorepo with different entry points for Next.js and Expo allows us to keep configs more separate, and therefore allow more confident updating of packages and configs without accidentally breaking other platforms.

In this starter template, we've opted to use turborepo with yarn workspaces. We'll list some basics in the next section, but for a deeper understanding please refer to their documentation for more info.

πŸ“ File structure and package management πŸ“¦

This starter monorepo has three types of workspaces:

  • /apps/* for all expo & next.js versions of your apps (consumes 'features' πŸ‘‡)
  • /features/* features of your app, grouped together by feature name (consumes 'packages' πŸ‘‡)
  • /packages/* for all shared dependencies / library code used in multiple apps or features
β”œβ”€β”€ apps/
β”‚   └── expo/ πŸ‘‰ Where all Expo & mobile specific config for {app-name} lives
β”‚       └── app.json ➑️ Expo app config (e.g. App name, icon, landscape / tablet support)
β”‚       └── app/ ➑️ File-based Routing & Navigation Setup for mobile (using 'app-core/screens/')
β”‚           └── (generated)/ ➑️ File based routing generated from `routes/` in features or packages
β”‚               └── _layout.tsx ➑️ Root layout for all app screens (e.g. tab bar, drawer, etc.)
β”‚               └── index.tsx ➑️ Home & starting screen for the app
β”‚       └── babel.config.js ➑️ Babel transpilation config for Expo
β”‚       └── index.js ➑️ Mobile entrypoint loader for App.tsx
β”‚       └── metro.config.js ➑️ Metro bundler config for react-native
β”‚       └── package.json ➑️ yarn-workspace config, lists core expo & react-native dependencies
β”‚       └── tsconfig.json ➑️ Typescript config for Expo
β”‚       └── webpack.config.js ➑️ Enables PWA browser testing with Expo (no SSR)
β”‚
β”‚   └── next/ πŸ‘‰ Where all Next.js, Server & API config for {app-name} lives
β”‚       └── public/ ➑️ favicon, app icons & other static assets (e.g. images & fonts)
β”‚       └── app/ ➑️ File-based Routing & Navigation Setup for Web (using 'app-core/screens/')
β”‚           └── (generated)/ ➑️ File based routing generated from `routes/` in features or packages
β”‚               └── head.tsx ➑️ HTML wrapper for head & meta tags (+ SSR styles)
β”‚               └── layout.tsx ➑️ Root layout for all web pages (e.g. headers / footers / nav)
β”‚               └── page.tsx ➑️ Web Homepage (e.g. using 'app-core/screens/HomeScreen.tsx')
β”‚               └── api/ ➑️ directory based api routes (using 'app-core/resolvers/')
β”‚                   └── graphql.ts ➑️ GraphQL client from 'app-core/graphql/'
β”‚       └── babel.config.js ➑️ Babel transpilation config for Next.js
β”‚       └── next.config.js ➑️ Next.js config, modules to transpile & plugins to support
β”‚       └── package.json ➑️ yarn-workspaces config, lists core next.js dependencies
β”‚       └── tsconfig.json ➑️ Typescript config for Next.js
|
|── features/
β”‚   └── app-core/ πŸ‘‰ Where all core cross-platform code for {app-name} lives
β”‚       └── components/ ➑️ Molecules / Atoms / Common UI used in 'screens/'
β”‚       └── graphql/ ➑️ Shared code for the GraphQL API client (optional)
β”‚       └── resolvers/ ➑️ Shared resolvers used in both in API routes or GraphQL API
β”‚       └── screens/ ➑️ Page templates used in App.tsx and next.js's 'app/' directory
β”‚       └── routes/ ➑️ Write-once routing for both web & mobile (see 'app/(generated)/' in expo & next)
β”‚       └── package.json ➑️ config required by yarn-workspaces, lists dependencies that don't fit anywhere else
β”‚   └── {app-feature}/ πŸ‘‰ Code shared across apps, ideally same structure as 'features/app-core'
β”‚       └── package.json ➑️ config required by yarn-workspaces, list dependencies specific to this feature
β”‚
β”œβ”€β”€ packages/
β”‚   └── @aetherspace/ ➑️ Primitives, utils & helpers for working with the GREEN stack
β”‚       └── schemas/ ➑️ A set of Zod powered schema utils for building single sources of truth
β”‚   └── @config/ ➑️ list of ts & other configs to use / extend from in next or expo apps
β”‚   └── {comp-lib}/ πŸ‘‰ Code shared across apps, ideally same structure as 'features/app-core'
β”‚       └── package.json ➑️ yarn-workspace config, list dependencies specific to this package
β”‚
β”œβ”€β”€ node_modules/ ➑️ Contains all modules for the entire monorepo
β”œβ”€β”€ package.json  ➑️ Root yarn-workspaces configuration + helper scripts, core developer only dependencies
└── turbo.json  ➑️ Monorepo config, manages dependencies in build scripts + caching of tasks

πŸ’‘ {app-feature}, {app-name} & {comp-lib} are just placeholders and you can have multiple of these

πŸ“¦ Keep your apps seperate with /apps/* & /features/* workspaces:

For every app you're building in this monorepo, you'll need a few folders:

  • /apps/next - Entry for web where only next.js related config/setup for an app should live. Should list only core next.js related deps & polyfills.
  • /apps/expo - Entry for mobile where only expo related config/setup for an app should live. Should list only core react-native and expo related deps.
  • /features/{app}-core - Where most of your core app specific UI, logic and screens will live. Should list app dependencies not listed elsewhere.

In each of these folders own a package.json file, where a name property should be specified to identify that workspace. This name can then be referenced during installs via e.g.

yarn workspace next add {package-name}

To install Expo modules for the specific Expo SDK you're using:

yarn expo-cli install {package-name}

Which will run yarn workspace expo-app expo-cli install {package-name} under the hood.

πŸ‘Ύ Stack and Template benefits + Next steps πŸ‘Ύ

If you've read the sections above, It's likely the ease of use, time saving capabilities and scalability of this stack & template are clear.

The starter repo comes with some opinionated extra packages and abilities.
Here's a list of what you can start doing out of the box:

  • Link pages and screens cross platform with the <Link> component from aetherspace/navigation
  • Use tailwind to style UI responsively on web / mobile with <AetherView tw="sm:px-2"> / tailwind-rn
  • Add illustrations or icons with react-native-svg
  • Bring the power of GraphQL to JSON or REST apis with aetherResolver() and schemas as single sources of truth.
  • Document your components and APIs with Storybook.
  • Deploy to vercel by importing your repo in their UI (view live example)
  • Deploy to netlify via this guide (view live)

Possible next steps:

πŸ’Ό Why this makes sense from a user, dev & business perspective

For users:

  • Solutions built for how they prefer to use software, whether that's on a phone, tablet or desktop.
  • Can share any page or feature with a link, which will open in the correct app or browser.
  • Full feature parity across all platforms.

For developers:

  • Write-once UI, logic, routing, data fetching & resolvers
  • Easily onboard new devs to the project with auto-generated Storybook docs
  • Save time & reduce risk by defining data structure once, instead of 4 times for types, graphql, docs & validation

For businesses:

  • Speed and flexibility to build/update features and pages for any platform.
  • Reach more users by being available on more devices.
  • Free organic leads from web SEO, which you can easily guide to mobile where higher conversions happen.

Whether you're a startup or established company, having both web and mobile apps is a great competitive advantage. There are many stories of market leaders suddenly being overtaken because the competition were able to move faster or had more devices their solution was available on for their customers.

This stack makes it near effortless to enable extra platforms. It helps keep teams small and enables them to move fast when building new pages or features for phones, tablets and/or the web.

More deliverables for less time invested in turn means flexibility in one or more of these areas:

  • ... negotiation room about budget or deadlines (in case of client work)
  • ... πŸ’° to be distributed among the entire team
  • ... πŸ•— available for experimentation
  • ... budget available to market the product
Show full πŸ•—πŸ•— to πŸ’°πŸ’°πŸ’° Comparison

Let's talk Return on Investment:

πŸ•— = time required = devs / teams / resources invested
πŸ’° = deliverable sale value = costs to build + profit margin
ROI = πŸ•— -> sold for -> πŸ’°

Web only project ROI = πŸ•—πŸ•— -> πŸ’°πŸ’°

  • πŸ•— Web Front-End πŸ’°
  • πŸ•— General Back-End (REST / GraphQL + Templates / SSR) πŸ’°

Native iOS + Android project ROI = πŸ•—πŸ•—πŸ•— -> πŸ’°πŸ’°πŸ’°

  • πŸ•— iOS App with Swift πŸ’°
  • πŸ•— Android app with Java πŸ’°
  • πŸ•— API Back-End (REST / GraphQL) πŸ’°

React-Native Mobile App ROI = πŸ•—πŸ•— -> πŸ’°πŸ’° to πŸ’°πŸ’°πŸ’°

  • πŸ•— iOS + Android App with RN πŸ’°(πŸ’°)
  • πŸ•— API Back-End (REST / GraphQL) πŸ’°

Expo Mobile + PWA ROI = πŸ•—πŸ•— ->πŸ’°πŸ’° to πŸ’°πŸ’°πŸ’°πŸ’°

  • πŸ•— iOS + Android + PWA with Expo & RN (Web without SSR) πŸ’°(πŸ’°πŸ’°)
  • πŸ•— API Back-End (REST / GraphQL) πŸ’°

Now, things get really interesting when you try to compare full cross-platform apps

Full Cross Platform with Separate Dev Teams ROI = πŸ•—πŸ•—πŸ•—πŸ•—πŸ•—πŸ•—πŸ•—Β ->Β πŸ’°πŸ’°πŸ’°πŸ’°πŸ’°πŸ’°πŸ’°

  • πŸ•— Web Front-End πŸ’°
  • πŸ•— iOS App with Swift πŸ’°
  • πŸ•— Android app with Java πŸ’°
  • πŸ•— Windows App Dev Team πŸ’°
  • πŸ•— MacOS App Dev Team πŸ’°
  • πŸ•— Linux App Dev Team πŸ’°
  • πŸ•— API Back-End (REST / GraphQL) πŸ’°

Full Cross Platform with GREEN stack ROI = πŸ•—πŸ•— -> πŸ’°πŸ’° to πŸ’°πŸ’°πŸ’°πŸ’°πŸ’°πŸ’°πŸ’°

  • πŸ•— Web (PWA & SSR & Web Vitals) + iOS + Android + Windows + MacOS + Linux πŸ’°(πŸ’°πŸ’°πŸ’°πŸ’°πŸ’°)
  • πŸ•— Back-End (REST + GraphQL + SSR + Static Exports + ISSG + universal JS utils thanks to Next.js) πŸ’°

Key takeaway: Always build or upsell more platforms / devices the app could run on

When not to use the GREEN stack? πŸ€·β€β™‚οΈ

The GREEN stack is unlikely to be the best fit when your project...

  • ... will always be web only πŸ‘‰ Use next.js
  • ... will always be mobile only πŸ‘‰ Use Expo
  • ... will always be desktop only πŸ‘‰ Use Electron + React / Vue / Svelte
  • ... is very Bluetooth / AR / VR / XR heavy πŸ‘‰ Go native with Swift / Java
  • ... is not using React πŸ‘‰ Use Svelte / Vue + Ionic
  • ... has no real need for Server Rendering, SEO or Web-Vitals πŸ‘‰ Use Expo (+ Web Support)
  • ... is using React, but the project is too far along and has no budget, time or people to refactor πŸ€·β€β™‚οΈ

If your project has required dependencies / SDKs / libraries that are either not available in JS, are not extractable to API calls or cannot function cross-platform, this may also not be a good solution for your use-case*.

πŸ›  * However, for JS libs, you could always try adding cross platform support yourself with `patch-package`

πŸ“š Further reading / Relevant docs:

Frequently Asked Questions πŸ€”

What's the benefit of using this over X-solution?

See the Core Concepts section

How can I apply the same navigation and deeplinks between web and mobile?

Deeplinks on mobile come out of the box with Expo-Router, which Aetherspace's Universal Routing uses under the hood.

How does automatic docgen work?

See the README on Automation or the Anouncement post

How should I manage my icons?

See the Icon Management README

I have a question about the license.

Check out the License and its FAQ section.


License: MIT


This repo is a free ambassador version of the GREEN stack starter. Keep the disclaimer above somewhere in your main README (or mention Aetherspace in your front-end) so this repo and any repos created from this template continue to fall under the free ambassador licence

For optional plugin branches, and an always updated version πŸ‘‰ Aetherspace/green-stack-starter

...

About

A Zod & Typescript-first approach to building cross-platform experiences with GraphQL, React-Native, Expo & Next.js, in a write-once way.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Sponsor this project

 

Packages

No packages published