You'll have to copy .env.development to a local .env on first run. Configure it to your liking.
Sensitive information which is not stored in .env.development can be found in heroku secrets. If you do not have access to heroku and need these, ask around
To install
yarn
To run
yarn dev
When you create/edit gql queries or server schema
yarn generate
To access the Hasura console (to edit the database) run
npx hasura console
You'll need eslint and prettier plugins in your editor of choice. If using VS Code, automatic import organisation is turned on as well through .vscode/settings.json file, which is part of this repository.
Everything lives on Heroku. There's a verdikto pipeline which builds us review application for each opened PR - these last for 1 day only, but you can redeploy them manually from the pipeline. Production build of the app is updated with each merge into master (TODO maybe add staging that deploys from master and deploy to production manually ?).
While we're using Hasura to access the db (see next section), the Postres addon lives on the verdikto instance.
This is the basic free db addon - if you need rollbacks or automatic backups (recommended once in production), please up uprage to payed version or roll your own automation on top of current solution.
You can see all the logs piped into Papertrail addon on Heroku instance.
These are searchable for 1 day and retained for 7 days in the free version.
Please, either back the archived logs up to S3 or upgrade to payed version of Papertrail if you need more (it's rather reasonably priced).
The "Why the hell is this split into 2 Heroku apps?" explanation.
TLDR: ease of building the admin part and typesafety against db for backend.
We use Next.js to serve static pages & SSR content, while still writing just a (mostly) React app (and using React to handle the dynamic content) - this is the app where all bussiness logic resides.
We use Hasura to access Postgress in a typesafe way, as a shortcut to easily access db data with React-Admin, and also as a database-migrations tool - this is the second 'app', but feel free to think of it as of 'posgres on steroids', or more accurately 'postgres with a graphql interface'.
Hasura needs to run as it's own service/container - and even if we were to integrate it as a middleware (like Postgraphile, a similar service, allows you to do), this would mean we'd lose some of the bells and whistles of next.js (like automatic static optimization).
This means that from 'server side' (either from getInitialProps SSR functions, or from api functions) we access the db through remote GraphQL queries which are typesafe. The fact this is a request to another server is of course a drawback, but shouldn't be to big of a hurdle currently.
Hasura has tools to manage access by users directly into database column. We don't use that for now - the only "direct" access to Hasura from frontend is from the admin page.
That means that when user needs to access or modify some database record, he needs to call one of the endpoints from pages/api. These have full admin access to hasura.
TODO in the future, we might need to dynamically load data from database directly from react app (not in the SSR/static phase) - when this happens, we'll have to configure unauthorized Hasura accesses TODO more
We're disabling the remote console endpoint to track migration files in git - read more in this section of the documentation. Therefore, you need the hasura console installed locally to manage our hasura instances. Existing instances to play with:
Dev endpoint - https://verdikto-hasura-dev.herokuapp.com/
Production endpoint - https://verdikto-hasura.herokuapp.com/
Currently passphrase to both is a base64 encoded admin:admin - that is: YWRtaW46YWRtaW4=. (TODO change on production before real data start arriving).
You should set up your own instance to write and test migrations, but feel free to use the https://verdikto-hasura-dev.herokuapp.com/ otherwise.
To open console, edit the config.yaml to match your configuration (or pass in the --endpoint and --admin-secret on the CLI)
hasura console
Start by deploying a new hasura instance to heroku.
Disable the remote console, optionally set the admin password by setting the following heroku env vars:
HASURA_GRAPHQL_ENABLE_CONSOLE false
HASURA_GRAPHQL_ADMIN_SECRET yoursecret
Create a local config.yaml (.gitignored) - you can change the config.yaml.development appropriately to fit your setup. Then apply all the missing migrations to your db:
hasura migrate apply
Read more on migrate command here.
(You can also just sync your db state with current migrations by providing params directly on command line, i.e. hasura migrate apply --endpoint http://your-hasura-instance.herokuapp.com, without setting up config.yaml)
By default, when you create a new Hasura instance, it will spin up with an admin console on the /console endpoint. This allows you to create and modify tables through it's UI, each of the changes generating a new migrations. If we want to record these migrations in git, we need to run this console locally from this directory.
Read more in the hasura docs (i.e. here https://hasura.io/docs/1.0/graphql/manual/migrations/reference/how-it-works.html#migrations) Same if you want to write the migrations by hand.
Recommended workflow when creating a new query against database is to use the GraphiQL Explorer from the hasura console dashboard - use checkboxes to select what you need, then copy over to a .graphql file and parametrize to your liking.
Afterwards run yarn generate - you will find your query exported as a function on client object in utils/gql - use it to access db data in a typesafe way.
Check out yup. Import the same validation schemas on frontend and backend, types will get inferred automatically.
Forked from here https://github.com/mpinter/nextjs-wordpress, check it out if you need wordpress integration.