We wanted to build our own admin backoffice to manage our content. But the task has revealed itself much more complicated than what I thought it'd be.
- React-admin is much harder to use than what I hoped for:
- It lacks TS support and extensive documentation, cost of learning is very high
- Official examples are often outdated
- Finding community help wasn't as easy as expected, despite a 12K+ stars counter
- In short, the cost of "getting started" is much, much higher than expected and broke our confidence in our ability to deliver a product of quality on time
- The "react-admin <> GraphQL" data provider I had found when building my initial POC isn't maintained and not advanced enough for our use cases
- We had to spend quite some time finding a proper alternative (fork), but despite being used in production it was still not advanced enough and was lacking a lot of good practices (huge npm package, outdated TS, broken tests, etc.)
- We built our own data provider and spent quite some time on it
- We learned that the GraphCMS API we're using would change it's API in a breaking way, which would force us to update this package again in the future
- At this point we believe there was too many issues with the whole things, and too many chances that something would go wrong and would stop us from growing (ROI)
- Thus, we decided to find another alternative and released this package under a stable and documented version, for other people to have a better experience than we did.
- Check our roadmap to get an overview of what we want to build with NRN-Admin
- Check what's left to do for v1 release
- Check our Community open discussion for v1 and share your thoughts, questions, etc.
- Check open issues for v1 and let us know what you'd like to work on. Make sure you understand the specs properly before starting, don't hesitate to ask for clarifications if unclear.
Next Right Now Admin is a boilerplate to quickly build an Admin frontend, based on NRN and react-admin
- See React Admin features
- Adapts to any backend (REST, GraphQL, SOAP, etc.)
- Powered by material-ui, redux, react-final-form, redux-saga, react-router, recompose, reselect and a few more
- Super-fast UI thanks to optimistic rendering (renders before the server returns)
- Undo updates and deletes for a few seconds
- Complete documentation
- Relationships (many to one, one to many)
- Data Validation
- Internationalization (i18n)
- Conditional formatting
- Themeable
- Supports any authentication provider (REST API, OAuth, Basic Auth, ...)
- Full-featured datagrid (sort, pagination, filters)
- Filter-as-you-type
- Supports any form layout (simple, tabbed, etc.)
- Custom actions
- Large library of components for various data types: boolean, number, rich text, etc.
- WYSIWYG editor
- Customize dashboard, menu, layout
- Super easy to extend and override (it's just React components)
- Highly customizable interface
- Can connect to multiple backends
- Can be included in another React app
- Inspired by the popular ng-admin library (also by marmelab)
- See NRN benefits
- B2B multi-tenants (AKA "monorepo") first-class support (optional, advanced use-case)
- Supports configuration, deployment, testing, monitoring of multiple customers through the same project (identical code base, monorepo design)
- This is a very special consideration, and required quite a lot of efforts to make it works smoothly
- With multi-tenants setup, we don't use the native Zeit <> Github integration, but our custom Zeit <> Github Actions integration instead (.github)
- Most projects do not need such capability, but we build our own projects with such requirement in mind, and thus released NRN with such built-in capability
- It's very easy not to use it if you don't need to, but it'll be a huge time saver for you if you need it!
- Built-in stages (development, staging, production) workflow
- TypeScript first-class support
- GraphQL support (thanks to Apollo, and others)
- GraphCMS first-class support, which hosts our GraphQL API (server) and database, fully hosted (thanks to GraphCMS1)
- GraphQL schema available in the developer environment (thanks to GraphQL Config)
- SSR and CSR capabilities (thanks to the Next.js framework)
- React hooks over HOC (functional components over classes)
- Internationalisation (i18n) first-class support (SSR + CSR friendly) (thanks to react-i18next)
- I18n of the database (thanks to GraphCMS1)
- I18n of the project (thanks to Locize1)
- Automated fallback language
- In-context editor
- Auto-add i18n keys with default translation when working locally
- Testing first-class support
- TS-friendly (thanks to ts-jest)
- End-to-end (E2E) tests (thanks to Cypress)
- Other tests, such as unit tests, etc. (thanks to Jest, Jest extended)
- Strong observability of the system (monitoring) and push-notification on your own messaging channel (i.e: Slack) when things go wrong (thanks to Sentry1)
- Universal JS, to re-use code as much as possible between frontend and backend (i.e: universal cookies API)
- Powerful CSS-in-JS styles, SSR & CSR friendly, JSX-friendly, styled-component friendly (thanks to Emotion)
- Font first-class support (SSR/CSR friendly, no FOUT effect) (thanks to WebFontLoader)
- Fine-grained frontend analytics, react-friendly, flexible, SPA-friendly (thanks to Amplitude12)
- Integrated CI/CD pipeline, automated deployments to preview domains and production domains (thanks to the Zeit, GitHub Actions)
- Including a dedicated "per-deployment domain", for fast feedback loop and testing means, in an online environment (staging)
- Including a dedicated "per-branch domain", for fast feedback loop and testing means, in an online environment with a url which is automatically updated as new pushed commits are being deployed (staging)
- Built-in utilities
- Convert SVG to TSX components (thanks to SVGR)
- Font Awesome icons as react components, with SSR support (thanks to Font Awesome)
- Bootstrap support (thanks to Reactstrap)
- Node debug mode for the server side (only built-in on WebStorm)
- NPM security audit (script)
- NPM developer-friendly outdated packages (script)
- Display warning on outdated browsers, works even if bundle isn't ES5 compatible (IE11, etc.)
- Use Zeit secrets for sensitive information
- Fully documented usage of all our third party NPM libraries (AKA dependencies)
- B2B multi-tenants (AKA "monorepo") first-class support (optional, advanced use-case)
- Getting started
- Understanding
EnvironmentsandStages - I18n (Internationalization)
- GraphCMS
- Amplitude
- Continuous Integration & Continuous Deployment (CI/CD)
- Testing
- Project folders structure
- License
- Vulnerability disclosure
- Contributors and maintainers
- [ABOUT UNLY]
https://nrn-admin.unly.now.sh/
Tip: You can get metadata at /api/status
Tip: All
/api/*are serverless functions, running under AWS Lambda
This assumes you've cloned the project on your own computer.
Follow this guide if you just want to try it out on your local machine
Tip: Using now@17+ is required for CI to work properly, but you don't care about that if you just want to get started quickly.
- Duplicate the
.env.build.exampleand rename it.env.build(this file is only used on your local computer) nvm use- (Optional) Selects the right node.js version based on our.nvmrcfileyarn add -D now@16.7.3, now@17+ requires to be authenticated to Zeit in order to launch the project, even if only working locally, so you can use now@16 instead to avoid creating a Zeit accountyarn- Installs all deps frompackage.json- (Optional) Customise
GRAPHQL_API_ENDPOINTandGRAPHQL_API_KEYto use your own. You can also use the default ones (readonly) - (Optional) Customise
AMPLITUDE_API_KEYandSENTRY_DSNto use your own. You can also leave them empty yarn start- Starts the app on http://localhost:8888/- That's it! The project now runs on your local computer
- Tip: It'll still be using the demo GraphCMS/GraphQL endpoint if you haven't changed
GRAPHQL_API_ENDPOINT - Tip: The default GraphCMS token is readonly, mutations (add, update, delete operations) will fail
- Tip: It'll still be using the demo GraphCMS/GraphQL endpoint if you haven't changed
Tip: You can start the project in debug mode (built-in for WebStorm only) by running the WebStorm "Debug" configuration in debug mode
Tip: If there are tools that you don't need/like, read our guide about how to remove them.
If you want to deploy your local project online, run yarn deploy:production.
You will likely need to run now first, to authenticate and such. Also, you need to define the secrets (see Zeit advanced configuration guide).
See https://github.com/UnlyEd/next-right-now/blob/master/README_HOW_TO_USE.md#online-installation-on-zeit
Steps are similar. This NRN-Admin doesn't use Locize though, so you can skip it.
The application relies on environment variables to function correctly. Those variables are provided differently depending on the environment.
When working on the development environment (localhost), the variables from .env.build are used by the webpack configuration
When deploying an instance to the Zeit's platform, the variables used are the one that belong to that instance, such as:
yarn deploy: This script will deploy in staging (AKA "Preview" on Zeit) using thenow.staging.jsonfile.yarn deploy:production: This script will deploy on production using thenow.production.jsonfile.
In those files, it's the
build.envpart that is used at build time (build is done on Zeit), which basically replaces all references of every environment variable by the actual value (string replace).
An environment is "where" the application is running. It can be either "development" (localhost) or "production" (on Zeit's servers).
The
environmentis defined by theNODE_ENVenvironment variable.N.B: It is not possible to any other value, as enforced by Next
When working on your local computer, you automatically use NODE_ENV=developement.
The environment affects how the application is bundled, it is used at build time. (webpack, hot-reloading, etc.)
i.e: In
developmentenvironment, you have access to PropTypes warnings, but you won't inproduction.
A stage is "how" the application is running. It can be either "development" (localhost), "staging" or "production" (on Zeit's servers) - You can add more if you need
The
stageis defined by theAPP_STAGEenvironment variable.N.B: You can use any stage name you like, there is no restriction.
- When working on your local computer, you automatically use
APP_STAGE=developement. - When creating a Zeit preview deployment (i.e: when pushing a commit/branch (CD), when using
yarn deploy, etc.), you automatically useAPP_STAGE=staging. - When creating a Zeit production deployment (i.e: when using
yarn deploy:production, when merging a PR tomaster, etc.), you automatically useAPP_STAGE=production.
The stage changes the behaviour of the application, because we sometimes need the application to behave differently depending on the stage.
i.e: In
productionstage, the Locize configuration uses theproductionversion. When using another stage, it uses thelatestversion.
i.e: We don't want to enable the same level of debugging in production environment. For instance, Locize is configured to be in
debugmode only in non-production stages.
- Admin platform i18n - See https://marmelab.com/react-admin/Translation.html
- Content i18n - TODO
Using the coupon code
unly-nrnwill grant you a 3-month 15% discount on the premium plans.
TODO
Amplitude (Analytics)
Amplitude is used to collect usage metrics (analytics) of the application.
Amplitude is used only on the frontend part of the application. It is composed of two parts:
@amplitude/react-amplitude: React components easy to use, see their blog post.amplitude-js: The JS SDK, only compatible from the browser. (They're working on making it compatible with SSR)
See the documentation example at react-amplitude to understand how it's meant to be used. We only use react-amplitude to manipulate events.
Known limitation: Amplitude doesn't provide any backend-compatible API. See amplitude/Amplitude-JavaScript#164
The amplitude team has released a Chrome plugin to see the events from the browser.
It is a must-have when working with Amplitude. It's very simple to use and quite helpful.
Every time a commit is pushed to the repository, or a branch is merged, automated actions are triggered.
Those actions are managed through Github Actions
Here is how the multiple steps are ordered:
- [Event] A commit is pushed, a branch is merged (or on any change made on the remote repository)
- [Trigger] Our Github Actions are triggered
- Either the staging scripts is executed, or the production script, depending on which branch is impacted (see Github Actions <> Zeit integrations)
- No matter what script (production vs staging) gets executed, those actions are always triggered:
- A new Zeit deployment is triggered, which runs our tests first (
yarn test:once) (Failing tests will stop the deployment) - Then, the deployment is deployed, and automatically linked to a custom domain which depends on the git branch name (xxx.now.sh)
- Then, our 2E2 tests are triggered using Cypress
- If they fail, artifacts (screenshots, videos) recorded by Cypress are uploaded to Github to help further debug (See example)
- A new Zeit deployment is triggered, which runs our tests first (
Zeit will automatically run the tests before deploying, as configured in the yarn build command.
If any test fail, the deployment will be aborted. This ensures that any code that doesn't pass the tests never get deployed online.
Once a deployment has been deployed on Zeit, Github Actions will run our E2E tests, to make sure that the app behaves as expected. This can also be considered as an integration tests suite.
You can run interactive tests using Jest with yarn test script.
You can run interactive E2E tests using Cypress with yarn e2e:open script.
You can also run them non-interactively using yarn e2e:run script.
You may need to run
yarn e2e:installscript first
Overview of the project folder and files structure
cypress: Folder used by Cypress (E2E), see "Getting started"public: Static files, see "Static file servingsrc: Source code of the appComponents: React components__snapshots__: Folder used by Jest when using Snapshot testingsvg: SVG components, imported fromsrc/svg
gql: GraphQL queries, partials, etc.pages: Next.js pages, see "Pages"propTypes: Shared propTypes (for re-usability)svg: Contains both.svgfiles and their react.tsxversion. When a SVG is converted to a TSX component, it should then be copied tosrc/components/svgto be used within the app.types: Shared types (for re-usability)data: Types that are data-related, basically those that are related to a database record
utils: Various utilities
MIT
This project is being maintained by:
- [Unly] Ambroise Dhenain (Vadorequest) (active)
Special thanks to:
- [Contributor] Hugo Martin (Demmonius) - Github Actions CI/CD pipeline
Unly is a socially responsible company, fighting inequality and facilitating access to higher education. Unly is committed to making education more inclusive, through responsible funding for students.
We provide technological solutions to help students find the necessary funding for their studies.
We proudly participate in many TechForGood initiatives. To support and learn more about our actions to make education accessible, visit :
- https://twitter.com/UnlyEd
- https://www.facebook.com/UnlyEd/
- https://www.linkedin.com/company/unly
- Interested to work with us?
Tech tips and tricks from our CTO on our Medium page!
#TECHFORGOOD #EDUCATIONFORALL
