Saga Farmann is a web application for a viking boat expedition.
This is a Next.js project bootstrapped with create-next-app.
- Getting started
- Overview
- Our process
- Variables
- Maintenance
- Further development
- Code style
- Fetching data
- Technical debt
First, run the development server:
npm run dev
# or
yarn dev
# or
pnpm devOpen http://localhost:3000 with your browser to see the result.
You can start editing the page by modifying pages/index.tsx. The page auto-updates as you edit the file.
API routes can be accessed on http://localhost:3000/api/hello. This endpoint can be edited in pages/api/hello.ts.
The pages/api directory is mapped to /api/*. Files in this directory are treated as API routes instead of React pages.
To learn more about Next.js, take a look at the following resources:
- Next.js Documentation - learn about Next.js features and API.
- Learn Next.js - an interactive Next.js tutorial.
You can check out the Next.js GitHub repository - your feedback and contributions are welcome!
The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.
Check out our Next.js deployment documentation for more details.
Since most of the pages will serve static content we opted to use NextJS static site generation which means that NextJS prebuilds and fetches all the data in build time and generates static HTML pages. This approach has many advantages the main one being speed, while in a traditional SPA the user needs to download the entire application with SSG the user only downloads what they need and NextJS takes care of making the application feel like a traditional SPA behind the scenes with almost instant page loads. This saves the user's bandwidth and makes it cheaper to serve the application on any server. We have also utilized other NextJS specific features such as using Next Images which has image optimization built in contributes even more to efficiency and speed.
The app fetches data from WordPress, and WordPress is being used as a headless CMS. There are no special features but we are listing what users can do. Users can:
- Follow the journey with a map
- Look at blog posts and news related to journeys and destinations
- Find crew for each journey
- Donate
- Watch Livestream
- See sponsor
- Read technicals about the boat
- React - JS library
- Next.js - Fullstack React framework
- SwiperJs - Slider library
- TypeScript - TypeScript is a strongly typed programming language that builds on JavaScript
- Mapbox - Map Library
- react-map-gl - Makes using Mapbox GL JS in React applications easy
- React transition group - Exposes simple components useful for defining entering and exiting transitions
- Semantic HTML5 markup
- CSS custom properties
- Flexbox
- CSS Grid
- CSS modules - Scoping CSS
- Reusable components
- React hooks - useEffect, useState, useRef
We decided that we use test-main as the test branch and merge to main when test-main is working without bugs to keep main bug free, we have also decided to have someone else than the person that pushed the code look over the code and merge.
We have used Wordpress as a headless CMS and made the Wordpress site inaccessible for non-logged-in users. We have also used fields in WordPress that can be filled out so that all the data is organized and the client know beforehand what needs to be filled out and uploaded, we have also provided an explanation for what everything is in the CMS so that they do not need us to use the solution and understand what everything is, that is our CMS documentation because it provides everything they need to know.
Base url can be found in .env file.
Color scheme can be found in globals.css file as variables.
All the standard endpoints from WordPress can be found: REST API Developer Endpoint Reference
In addition we have the following endpoints:
| Name | Request type | Endpoint |
|---|---|---|
| Get all crews | GET | http://localhost:3000/wp/wp-json/wp/v2/crew_members |
| Get a crew | GET | http://localhost:3000/wp/wp-json/wp/v2/crew_members/{id} |
| Get all sponsors | GET | http://localhost:3000/wp/wp-json/wp/v2/sponsors |
| Get all destinations | GET | http://localhost:3000/wp/wp-json/wp/v2/destinations |
| Get a destination | GET | http://localhost:3000/wp/wp-json/wp/v2/destinations/{id} |
| Get all stages | GET | http://localhost:3000/wp/wp-json/wp/v2/stages |
| Get a stage | GET | http://localhost:3000/wp/wp-json/wp/v2/stages/{id} |
The backend is WordPress used as a headless CMS, but will require maintenance and updates.
They will need to make some changes in the future one example is to switch from this year's journey to next year's journey and maybe some libraries need to be updated in the future and that might require some changes in the code if they introduce breaking changes this is also part of technical debt. This requires someone competent with the technologies used.
They want a live boat but we did not have time to make the feature because the AIS data is difficult to get and the only solution we found is a solution that requires websockets which means we need another backend for the websocket because the next API does not support websockets. We contacted other suppliers of AIS APIs but they have not responded because their target customers are large shipping and comercial companies.
- ES6 syntax
- Camelcased function names, props, and parameters
- Descriptive function names, prop names, and parameters
- Destructuring props
- CSS naming with hyphens
- Export default for components
- Break down components when it makes sense or if it can be reused
- Empty tags instead of React Fragments
The HTML is generated at build time and will be reused on each request, we have utilized getStaticProps and getStaticPaths read more about Static Generation
Incremental Static Regeneration ensures static pages get updated automatically by rebuilding the pages that have changes read more about Incremental Static Regeneration
As mentioned in maintenance this solution requires someone competent to do further development and updates both for the backend and for the frontend. We have also opted to use the older style of using NextJS because Next warns about the new type as being experimental, which we think should not be used for a production application because of that. If the new experimental way becomes the standard it could mean it could get more difficult to find people that know the current way. Also since this is the largest project many of us has worked on the architecture is not ideal, we found a way to do on-demand ISR but we are dependent on a plugin and should the plugin become not compatible with our version of wordpress it could break the on-demand ISR.