In this section, you'll find answers on the following frequently asked questions:
- How do I update my Apollo Universal Starter Kit project without forking the repository?
- How do I use a custom GraphQL backend?
- How do I use a different database?
- How do I enable Facebook and Google OAuth?
- How do I set up environment variables for development?
- How do I add support for a custom domain name in the local development environment?
- What extensions can I use when creating files in my project?
- How do I always keep my Apollo Starter Kit project up-to-date?
Follow the steps below to create an Apollo Starter Kit project and updating the fork:
- Initialize a new Git repository
- Add the starter kit as a remote upstream repository:
- Run the following command:
git merge upstream/stable
- When you are in
master
branch of your project:
https://help.github.com/articles/syncing-a-fork/
Whenever you want to receive updates, first run:
git fetch upstream
Then run when you are in the master branch of your project:
git merge upstream/stable
To set your custom GraphQL back end endpoint, set BACKEND_API_URL
environment variable or change URL in packages/server/build.config.js
for the __API_URL__
property:
__API_URL__: process.env.BACKEND_API_URL || 'https://my-custom-domain/graphql', // set the full URL to the external GraphQL API e.g. https://
We recommend that you still run the back-end code provided by the starter kit to use the server-side rendering (SSR).
You can also turn off SSR if you don't use the starter kit back end. Set the environmet variable SSR
to false
or edit root build.config.js
:
To disable Server Side Rendering (SSR), change set environment variable SSR
to false
or edit root build.config.js
More information: Server Side Rendering with Apollo Universal Starter Kit.
You can almost all relational database management systems that use SQL and are supported by Knex such as PostgreSQL, MySQL, MSSQL, MariaDB, SQLite3, and Oracle.
Apollo Universal Starter Kit is database-agnostic. You can any other databases if they support a JavaScript client provided by Knex. This way you can create a simple connector and export it normally in place of the Knex connector.
Reference: #525
You can enable the social login functionality in the config/user.js
file:
export default {
// other configurations are omitted
auth: {
facebook: {
enabled: false, // set to true to enable login with Facebook
clientID: process.env.FACEBOOK_CLIENTID,
clientSecret: process.env.FACEBOOK_CLIENTSECRET,
scope: ['email'],
profileFields: ['id', 'emails', 'displayName']
},
github: {
enabled: false, // set to true to enable login with GitHub
clientID: process.env.GITHUB_CLIENTID,
clientSecret: process.env.GITHUB_CLIENTSECRET,
scope: ['user:email']
},
linkedin: {
enabled: false, // set to true to enable login with LinkedIn
clientID: process.env.LINKEDIN_CLIENTID,
clientSecret: process.env.LINKEDIN_CLIENTSECRET,
scope: ['r_emailaddress', 'r_basicprofile']
},
google: {
enabled: false, // set to true to enable login with Google
clientID: process.env.GOOGLE_CLIENTID,
clientSecret: process.env.GOOGLE_CLIENTSECRET,
scope: ['https://www.googleapis.com/auth/userinfo.email', 'https://www.googleapis.com/auth/userinfo.profile']
}
}
};
First, modify the host file in the following way:
127.0.0.1 localhost.host
Then, add this setting into /packages/client/.sprinjs
file under options
section
webpackConfig: {
devServer: {
public: 'localhost.host'
}
}
Apollo Universal Starter Kit suggests that you use the following extensions when creating your modules:
Platform | Directory | Possible extensions for application files |
---|---|---|
server | packages/server/ | .tsx , .jsx , .ts , .js , .json |
web | packages/client/ | .tsx , .jsx , .ts , .js , .json |
When you develop a native mobile app, we also recommend that you follow the naming convention below:
Platform | Directory | Possible extensions for application files |
---|---|---|
native | packages/mobile/ | .native.tsx , .native.jsx , .native.ts , .native.js , .json |
android | packages/mobile/ | .android.tsx , .android.jsx , .android.ts , .android.js , .json |
ios | packages/mobile/ | .ios.tsx , .ios.jsx , .ios.ts , .ios.js , .json |
Notice that you should use the .native.tsx
and similar extensions for files with the same logic for both Android and
iOS platforms. If the logic for these two platforms is different, use .android.tsx
(and similar extensions) for
Android, and .ios.tsx
for iOS.
For example, here's how the files may be called for the Storage module:
storage.tsx
for the web and server platformsstorage.native.tsx
for the mobile app for files with the same logicstorage.android.tsx
for the custom logic for the Android platformstorage.ios.tsx
for the custom logic for the iOS platform
Apollo Universal Starter Kit uses Webpack to build the code for all the platforms – server, web, Android, and iOS.
The starter kit uses the resolve.extensions
Webpack property to understand which files should be used for generating
a specific platform bundle when there are several files with the same name but different extensions.
The best way for keeping your Apollo Universal Starter Kit project always up-to-date is to configure a remote repository that points to the upstream of the original repository.
You can consult Configuring a Remote for a Fork documentation on GitHub. Using this feature, you can easily pull in the latest changes made to this kit. For that, consult the Syncing a Fork.
If you intend to make significant changes to existing modules, we suggest you copy and rename the modules, to limit the amount of merge conflicts to a minimum.