|
1 | 1 | --- |
2 | 2 | id: getting-started |
3 | | -title: Getting started |
| 3 | +title: Getting started with @accounts/boost |
4 | 4 | sidebar_label: '@accounts/boost' |
5 | 5 | --- |
6 | 6 |
|
7 | | -# accounts |
8 | | - |
9 | | -## About |
10 | | - |
11 | | -The `@accounts` suite of packages aims to provide the consumer an end to end authentication and accounts management solution, with a simple to start with interface while preserving options for configuration. These packages provide OAuth support for popular providers such as Instagram, Twitter, Github, two factor authentication, password based accounts along with recovery options and customizable account creation and validation. |
12 | | - |
13 | 7 | The `@accounts` packages are modular by nature and can be manually installed and configured, however we provide `@accounts/boost` - a package containing useful abstractions to get a GraphQL accounts server started with minimal configuration. |
14 | 8 |
|
15 | | -## Getting started with @accounts/boost |
16 | | - |
17 | 9 | **Install the core** |
18 | 10 |
|
19 | | -`npm install @accounts/boost` |
| 11 | +```bash |
| 12 | +// Npm |
| 13 | +npm install --save @accounts/boost |
| 14 | + |
| 15 | +// Yarn |
| 16 | +yarn add @accounts/boost |
| 17 | +``` |
20 | 18 |
|
21 | 19 | **Choose your database database driver** |
22 | 20 |
|
23 | | -`npm install @accounts/mongo` |
| 21 | +```bash |
| 22 | +// Npm |
| 23 | +npm install --save @accounts/mongo |
| 24 | + |
| 25 | +// Yarn |
| 26 | +yarn add @accounts/mongo |
| 27 | +``` |
24 | 28 |
|
25 | 29 | **Choose your authentication services** |
26 | 30 |
|
27 | | -`npm install @accounts/password` |
| 31 | +```bash |
| 32 | +// Npm |
| 33 | +npm install --save @accounts/password |
| 34 | + |
| 35 | +// Yarn |
| 36 | +yarn add @accounts/password |
| 37 | +``` |
28 | 38 |
|
29 | 39 | The following starts an accounts server using the database, transport, and authentication services you provided with the default settings. |
30 | 40 |
|
@@ -241,54 +251,3 @@ const accountsServerUri = 'http://localhost:4003/'; |
241 | 251 | console.log(`GraphQL server running at ${apolloServer.url}`); |
242 | 252 | })(); |
243 | 253 | ``` |
244 | | - |
245 | | -### Prior Art |
246 | | - |
247 | | -This project is inspired by Meteor's accounts suite of packages. Meteor |
248 | | -framework had a plug and play approach for its monolithic framework that saved a |
249 | | -ton of work that is traditionally done by any development team, over and over |
250 | | -again. Meteor's accounts system had a couple of restrictions: |
251 | | - |
252 | | -- First it was published in Meteor's "atmosphere" package repository and was |
253 | | - dependent on the Meteor's build tool. |
254 | | -- Second, Meteor is built around DDP and so its accounts system was taking that |
255 | | - for granted. |
256 | | -- Third, Meteor's dependency on MongoDB meant that the business logic was |
257 | | - dependant on how the data is stored in the database. |
258 | | - |
259 | | -### FAQ |
260 | | - |
261 | | -Going into this project we asked ourselves (and were asked by others) a bunch of |
262 | | -questions that helped us define what this project is all about. This is part of |
263 | | -these questions: If you have a question that you think could shape this |
264 | | -project please PR this document or open an issue! |
265 | | - |
266 | | -### Why wouldn't you just use passport? |
267 | | - |
268 | | -We are not here to replace passport.js. Actually, in our vision, passport.js |
269 | | -will be one authentication method that you can plug in. Currently, the only |
270 | | -problem with passport.js in that regard is that it is designed to work with |
271 | | -connect middlewares and adapter code is needed to plug into let's say a WS |
272 | | -transport. We currently implemented our own local strategy just to make sense |
273 | | -out of basic accounts packages. In the near future it will be separated into its |
274 | | -own package. |
275 | | - |
276 | | -### Why not refactor out the Meteor accounts suite? |
277 | | - |
278 | | -Well, as explained above, Meteor's accounts system is tied to the data storage |
279 | | -and transport in a way that is actually harder to separate than rewriting with |
280 | | -those abstractions in mind. We do offer an adapter package that allows Meteor |
281 | | -applications an easy and gradual way to move out of Meteor's current accounts |
282 | | -system. |
283 | | - |
284 | | -### Why do you use a mono-repo? |
285 | | - |
286 | | -Early on we understood that a mono-repo is required in order to have a good |
287 | | -developer experience while adding any accounts logic. This also helps us keep the |
288 | | -codebase relatively small for using apps as you will not load in client code on |
289 | | -server apps and vice versa. Although having a mono repo is great, we feel that |
290 | | -someone maintaining the Redis package should not get notifications regarding |
291 | | -changes on the Mongo or React packages. If you are adding in a |
292 | | -feature that requires changes to the transport or the data store packages, we |
293 | | -recommend cloning all of the accounts-js packages into the same directory and just |
294 | | -open your IDE on that directory as project root. |
0 commit comments