Implementation of a GraphQL server with an email-password-based authentication workflow and authentication rules, based on Prisma, graphql-yoga, graphql-shield & GraphQL Nexus.
Clone the repository
git clone https://github.com/douglasswm/lantu-graphql-prisma-postgres.git
Install Node dependencies:
npm install
To run, you need the Prisma CLI. Please install it via NPM or using another method:
npm install -g prisma
Run Prisma locally via Docker:
- Ensure you have Docker installed on your machine. If not, you can get it from here.
- Run
docker-compose up -d
Export Prisma management API secret
export PRISMA_MANAGEMENT_API_SECRET="lemo_lantu_secret_666"
To set up database, run:
prisma deploy
You can now use Prisma Admin to view and edit your data by appending /_admin
to your Prisma endpoint.
Launch your GraphQL server with this command:
npm run dev
The schema that specifies the API operations of your GraphQL server is defined in ./src/schema.graphql
. Below are a number of operations that you can send to the API using the GraphQL Playground.
Feel free to adjust any operation by adding or removing fields. The GraphQL Playground helps you with its auto-completion and query validation features.
query {
feed {
id
title
content
published
author {
id
name
email
}
}
}
See more API operations
You can send the following mutation in the Playground to sign up a new user and retrieve an authentication token for them:
mutation {
signup(name: "Alice", email: "alice@prisma.io", password: "graphql") {
token
}
}
This mutation will log in an existing user by requesting a new authentication token for them:
mutation {
login(email: "alice@prisma.io", password: "graphql") {
token
}
}
For this query, you need to make sure a valid authentication token is sent along with the Bearer
-prefix in the Authorization
header of the request:
{
"Authorization": "Bearer __YOUR_TOKEN__"
}
With a real token, this looks similar to this:
{
"Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJjanAydHJyczFmczE1MGEwM3kxaWl6c285IiwiaWF0IjoxNTQzNTA5NjY1fQ.Vx6ad6DuXA0FSQVyaIngOHYVzjKwbwq45flQslnqX04"
}
Inside the Playground, you can set HTTP headers in the bottom-left corner:
Once you've set the header, you can send the following query to check whether the token is valid:
{
me {
id
name
email
}
}
You need to be logged in for this query to work, i.e. an authentication token that was retrieved through a signup
or login
mutation needs to be added to the Authorization
header in the GraphQL Playground.
mutation {
createDraft(
title: "Join the Prisma Slack"
content: "https://slack.prisma.io"
) {
id
published
}
}
You need to be logged in for this query to work, i.e. an authentication token that was retrieved through a signup
or login
mutation needs to be added to the Authorization
header in the GraphQL Playground. The authentication token must belong to the user who created the post.
mutation {
publish(id: "__POST_ID__") {
id
published
}
}
Note: You need to replace the
__POST_ID__
-placeholder with an actualid
from aPost
item. You can find one e.g. using thefilterPosts
-query.
You need to be logged in for this query to work, i.e. an authentication token that was retrieved through a signup
or login
mutation needs to be added to the Authorization
header in the GraphQL Playground.
{
filterPosts(searchString: "graphql") {
id
title
content
published
author {
id
name
email
}
}
}
You need to be logged in for this query to work, i.e. an authentication token that was retrieved through a signup
or login
mutation needs to be added to the Authorization
header in the GraphQL Playground.
{
post(id: "__POST_ID__") {
id
title
content
published
author {
id
name
email
}
}
}
Note: You need to replace the
__POST_ID__
-placeholder with an actualid
from aPost
item. You can find one e.g. using thefilterPosts
-query.
You need to be logged in for this query to work, i.e. an authentication token that was retrieved through a signup
or login
mutation needs to be added to the Authorization
header in the GraphQL Playground. The authentication token must belong to the user who created the post.
mutation {
deletePost(id: "__POST_ID__") {
id
}
}
Note: You need to replace the
__POST_ID__
-placeholder with an actualid
from aPost
item. You can find one e.g. using thefilterPosts
-query.
To make changes to the GraphQL schema, you need to manipulate the Query
and Mutation
types.
Note that the start
script also starts a development server that automatically updates your schema every time you save a file. This way, the auto-generated GraphQL schema updates whenever you make changes in to the Query
or Mutation
types inside your TypeScript code.
Mostly reasonable guidelines for commit messages.
Commit messages consist of a message, description and related.
<message>
<description>
<related>
A message consists of a type, scope, and subject.
No line should be longer than 80 characters long, for optimal github viewing.
<type>(<scope>): <subject>
Examples: refactor(plans#show): remove 1 of 4 templating languages
feat
: New featurefix
: Bug fixformat
: Change not affecting the meaning of code (white-space, formatting, etc)docs
: Documentation-only changestyle
: Stylesheet-only changerefactor
: Change that neither fixes a bug or adds a featureperf
: Change that improves performancetest
: Addition of a missing testchore
: Changes to the build process or auxiliary tools and libraries
The scope could be anything specifying the site of the commit change. For
example plans#show
, PlanPerson
, LiveChatMessageList
, .tab-list
, etc...
The subject contains a succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't use capitalize first letters
- don't use trailing punctuation (.)
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes" The body should include the motivation for the change.
The footer should contain any information about Breaking Changes and is the place to reference Trello cards, or GitHub issues that the commit Closes.
This guide is pirated from inspired by Angular's excellent
CONTRIBUTING.md.
A detailed explanation can be found in this document.
Your stuff's on staging but you're making small, progressive tweeks. fixup
is your friend.
Fixup commits are associated with commit you've already made. They allow you to make commits without inserting additional messages. They can also be automatically squashed, for those civilized developers.
Here's how it works. commit
takes --fixup
as on option. When used, you'll have to provide the SHA of the commit your is fixing up. Like so:
git commit --fixup a9b8c7
# aliases also work but get confusing after your first fix
git commit --fixup head
You probably don't memorize your recent commit SHAs. You can use the syntax below as a backword search. This fixup commit will attach to the most recent commit, where "style" is in the message:
git commit --fixup :/style