All Projects → cleverbeagle → Pup

cleverbeagle / Pup

The Ultimate Boilerplate for Products.

Programming Languages

javascript
184084 projects - #8 most used programming language

Projects that are alternatives of or similar to Pup

Example Storefront
Example Storefront is Reaction Commerce’s headless ecommerce storefront - Next.js, GraphQL, React. Built using Apollo Client and the commerce-focused React UI components provided in the Storefront Component Library (reactioncommerce/reaction-component-library). It connects with Reaction backend with the GraphQL API.
Stars: ✭ 471 (-16.34%)
Mutual labels:  graphql, apollo, mongodb, graphql-client, ssr
Meteor Apollo Starter Kit
Meteor, Apollo, React, PWA, Styled-Components boilerplate
Stars: ✭ 91 (-83.84%)
Mutual labels:  graphql, apollo, meteor, boilerplate, styled-components
Ssr Sample
A minimum sample of Server-Side-Rendering, Single-Page-Application and Progressive Web App
Stars: ✭ 285 (-49.38%)
Mutual labels:  graphql, apollo, ssr, styled-components
React Firebase Starter
Boilerplate (seed) project for creating web apps with React.js, GraphQL.js and Relay
Stars: ✭ 4,366 (+675.49%)
Mutual labels:  graphql, boilerplate, ssr, styled-components
Razzle Material Ui Styled Example
Razzle Material-UI example with Styled Components using Express with compression
Stars: ✭ 117 (-79.22%)
Mutual labels:  example, boilerplate, ssr, styled-components
Pizzaql
🍕 Modern OSS Order Management System for Pizza Restaurants
Stars: ✭ 631 (+12.08%)
Mutual labels:  graphql, apollo, ssr, styled-components
Omdb Graphql Wrapper
🚀 GraphQL wrapper for the OMDb API
Stars: ✭ 45 (-92.01%)
Mutual labels:  graphql, apollo, graphql-server, app
Ran
⚡ RAN! React . GraphQL . Next.js Toolkit ⚡ - SEO-Ready, Production-Ready, SSR, Hot-Reload, CSS-in-JS, Caching, CLI commands and more...
Stars: ✭ 2,128 (+277.98%)
Mutual labels:  graphql, apollo, boilerplate, styled-components
Gqlify
[NOT MAINTAINED]An API integration framework using GraphQL
Stars: ✭ 182 (-67.67%)
Mutual labels:  graphql, graphql-server, mongodb, graphql-client
Graphql To Mongodb
Allows for generic run-time generation of filter types for existing graphql types and parsing client requests to mongodb find queries
Stars: ✭ 261 (-53.64%)
Mutual labels:  graphql, graphql-server, mongodb
Morpheus Graphql
Haskell GraphQL Api, Client and Tools
Stars: ✭ 285 (-49.38%)
Mutual labels:  graphql, graphql-server, graphql-client
Express Graphql Mongodb Boilerplate
A boilerplate for Node.js apps / GraphQL-API / Authentication from scratch - express, graphql - (graphql compose), mongodb (mongoose).
Stars: ✭ 288 (-48.85%)
Mutual labels:  graphql, mongodb, boilerplate
Create Graphql Server
Generate your GraphQL server one type at a time
Stars: ✭ 321 (-42.98%)
Mutual labels:  graphql, graphql-server, mongodb
Graphql Deduplicator
A GraphQL response deduplicator. Removes duplicate entities from the GraphQL response.
Stars: ✭ 258 (-54.17%)
Mutual labels:  graphql, apollo, graphql-client
Altair
✨⚡️ A beautiful feature-rich GraphQL Client for all platforms.
Stars: ✭ 3,827 (+579.75%)
Mutual labels:  graphql, graphql-server, graphql-client
Kite
🌴 Kite 前台页面是vue ssr服务端渲染、后台页面是react spa、服务层nodejs express、mysql编写的一套多权限文章、动态管理系统
Stars: ✭ 455 (-19.18%)
Mutual labels:  graphql, markdown, ssr
Scalable React Boilerplate
⭐️ Scalable feature-first React micro-framework made for Udacity Alumni collaborative projects
Stars: ✭ 260 (-53.82%)
Mutual labels:  graphql, apollo, boilerplate
Aws Lambda Graphql
Use AWS Lambda + AWS API Gateway v2 for GraphQL subscriptions over WebSocket and AWS API Gateway v1 for HTTP
Stars: ✭ 313 (-44.4%)
Mutual labels:  graphql, apollo, websockets
Brian Lovin Next
My personal site
Stars: ✭ 522 (-7.28%)
Mutual labels:  graphql, apollo, styled-components
Parse Server
API server module for Node/Express
Stars: ✭ 19,165 (+3304.09%)
Mutual labels:  graphql, graphql-server, mongodb

Pup

The Ultimate Boilerplate for Products.

Read the Documentation

CircleCI

Want to work side-by-side with an experienced, trusted mentor? Check out Clever Beagle.


NOTE: The following represents example README.md content for your product. The information below should be customized for your product.


  1. Infrastructure
  2. Settings & Configuration
  3. Dependencies
  4. Commands
  5. Git & Branching
  6. Testing
  7. Releasing

1. Infrastructure

The following explains how the production and staging environments for this app are managed and configured.

Where is DNS configured for this app?

DNS for the app is configured and managed via DNSimple.

Where does the database live?

The database is hosted via Compose. A single deployment cleverbeagle exists with a pup database for the production environment and a pup-staging database for the staging environment. Additionally, the "Oplog Access" add-on has been enabled to improve the performance of Meteor in production.

Where does this app live?

The app is deployed to https://galaxy.meteor.com. It has two versions:

  1. staging which is accessed via https://pup-staging.cleverbeagle.com and is used to test a release in a production environment before being deployed to production.
  2. production which is accessed via https://pup.cleverbeagle.com and is the live, customer-facing server.

Deployment to these domains is controlled via NPM scripts defined in the package.json file at the root of the project, npm run staging and npm run production.

How does the SSL work?

SSL certificates are generated via the UI at https://galaxy.meteor.com/cleverbeagle. Each application's certificates are managed via the app's settings page:

SSL certificates are auto-generated by Galaxy using the Let's Encrypt Certificate Authority and shouldn't require any maintenance. If maintenance or edits are required, locate the "Domains & Encryption" section of the app's settings page (linked above) and click on the domain you'd like to manage.

2. Settings & Configuration

Settings for the app are defined in three files at the root of the project:

  • settings-development.json contains the settings specific to the development environment (i.e., when running the app on your computer).
  • settings-staging.json contains the settings specific to the staging environmnet (i.e., when deploying the app to pup-staging.cleverbeagle.com).
  • settings-production.json contains the settings specific to the production environment (i.e., when deploying the app to pup.cleverbeagle.com).

Each settings file should only be used in conjunction with the environment it's intended for. Further, each settings file's contents should be restricted to that specific environment (i.e., don't use an API key intended for the production environment in development and vice-versa—only break this rule when a given service's API key provisioning makes this prohibitive).

How do I load the settings file?

Settings files are automatically loaded for you as part of the NPM commands listed below. It's best to rely on these instead of doing it manually.

How do I access the accounts used in the settings files?

If you need to obtain an API key, password, or other secret information, you can find this in the [email protected].

3. Dependencies

Dependencies for pup.cleverbeagle.com are installed via NPM and Meteor's Atmosphere package system. Atmosphere dependencies are installed automatically on app startup. NPM dependencies can be installed with the following command before the first startup of the application:

meteor npm install

4. Commands

The following NPM commands can be used when working on the app.

dev

$ npm run dev

Runs the app development server at http://localhost:3000 and loads the settings-development.json file.

staging

$ npm run staging

Deploys the app to the staging server at https://pup-staging.cleverbeagle.com and loads the settings-staging.json file.

production

$ npm run production

Deploys the app to the production server at https://pup.cleverbeagle.com and loads the settings-production.json file.

test

$ npm run test

Runs all Jest test suites in the app once and then quits.

test-watch

$ npm run test-watch

Runs all Jest test suites in the app in watch mode and reruns whenever a test or file in the app changes.

test-e2e

$ npm run test-e2e

Runs all end-to-end tests using TestCafe once and then quits.

5. Git & Branching

Read the "Managing branches in Git" tutorial in the Pup docs

6. Testing

There are two types of testing performed in relation to the app: manual and automated. Manual testing is any testing where you're manually clicking around the app yourself to test things out. Automated testing is any where you're relying on the automated test suites in the app to test things out.

Test Users

When you start the app for the first time in development and staging mode, we create a set of test users to use when testing different permissions:

Email Address Password Roles Notes
[email protected] password admin Full access to the application.
[email protected] password user Access to user-only features.
[email protected] password user Access to user-only features.
[email protected] password user Access to user-only features.
[email protected] password user Access to user-only features.
[email protected] password user Access to user-only features.

Test Data

When you start the app for the first time, we create test data for all collections in the application. If you ever want to "start over" with fresh data in your development environment, stop the app and in your terminal run:

meteor reset

Upon restarting the app, the databased will be reseeded with the default test data.

FAIR WARNING: This command will PERMANENTLY ERASE (😈) any data that you've added to the app manually. If you've added something that you will need/want after the reset, make sure to back it up first.

Writing Tests

Read the "Writing and running automated tests" tutorial in the Pup docs

7. Releasing

Releasing the app to both the staging and production environment should be performed primarily via continuous integration. This is configured via Circle CI and the .circleci/config.yml file at the root of the app.

If an emergency deployment is required, the npm run staging and npm run production commands detailed in the "NPM Commands" section above can be utilized.

Performing a release

In order for a release to be pushed to either the staging or production environment via continuous integration, code must be pushed to:

  • The master branch when releasing new code into production.
  • The staging branch when releasing new code to the staging server.

When code is pushed, the continuous integration service should pick this change up and automatically deploy per the rules in the .circleci/config.yml file in the app.

Tagging releases on master

When code has been tested and confirmed ready for production, it's important to tag the release in Git so that it's clear when and where certain code is introduced. In order to tag a release, it's recommended that the Git Extras library be used, specifically, the git release <Semantic Version Number> command be utilized.

This pushed the code to the master branch while also creating a tag locally and remotely, all simultaneously.

For more information on Semantic Versioning, visit the official documentation site.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].