Add a database to GitHub Pages and store the JSON-data there. Pull data from theme repositories occasionally, convert it to JSON and update the database. Serve requests to the API from the database.

Both GitHub and Netlify only host static web pages. We need hosting for interactive node.js. We have hosting at Loopia, but something else could be a better fit.

Check out wpnode for example.

Basically the public hosted version of this backend is built from this very repository. The hosted version is kind of it´s own build though, just a copy of this repository. When the repo is updated so is the hosted build, but we also need it to be the other way around. When the database in the hosted build is updated with new information, the repository needs to be updated with this new database-version as well.

This is the clincher, the big thing! Make a server that answers to API-requests.

For example, use a guide like this.

https://www.freecodecamp.org/news/building-a-simple-node-js-api-in-under-30-minutes-a07ea9e390d2/

This will enable the ability to update the database from outside the database. It will be used to connect NFC cards to specific pages in the database.

Right now the API is only able to send data from a specified table, from a hard coded page; "about". The goal now is to be able to choose page in the URI too, for example not only localhost:8080/fruit, but now also localhost:8080/fruit/apples.

In sprint 1, read customer theme from same repo.

Make the converter run every time the user renders the home page
Or at least on running the start script

Converting to and from JSON seemed a bit too much and not needed, so we decided to store HTML directly, which can be sent out as the response when API is called.

Read customer theme from database or secondary repo

https://phiresky.github.io/blog/2021/hosting-sqlite-databases-on-github-pages/

There was no way we would get the old version up and running, almost not even for a demo, so we decided to completely ditch the old backend and invest our remaining time and energy in the Laravel version of this project. Most parts of the NFC functionality can be migrated and used in Laravel, all the colors, images and styles used can also be moved and used in the new version.

The main upsides of this version is the ability to have safe and professional (and working) authentication, even a version built for multiple users of the same theme. It can also be hosted more easily, with the database not requiring some octokit bullsh*t to function even remotely.

Run SQLite in memory.

1. Make Controller ask Model 1 for markdown-files for one theme.
2. Give data to View and convert md to JSON.
3. Let Model 2 store JSON in SQL
4. When request comes via API, ask Model 2 for JSON and return it to the API

The updater right now runs everytime the user enters the login-page, which is the same for everyone.
Instead, the updater should run everytime the user enters their own home page, which would be a URL like "https://bord.com/fruit". This will also specify for the updater which catalog to read from, and which table in the database to update with set information.

When the customerId doesn´t exist as a table in the database, a 404-page is loaded, but this doesn´t happen if the same happens with the pageId. Instead nothing happens at all, the browser just keeps on trying to load the URL and no console log of any error happens.

Split the code in to three separate files/groups of files. One for Model, one for View and one for Controller.

Put the two pieces together and make the two halves work together. Just make everything work as intended! This might include:

• Testing of all the NFC cards, all pages and both at the same time
• "Making" new customers/users, do everything like how we would set it up for a new customer (including following up on the howto)
• Test complete project on different devices, double check compatibility
• Make @seetee try to break it, and if he succeeds... well fix it!

Setup some npm scripts to run the necessary development environment.

• Node.js
• ESLinter
• Snyk

What else?

Make the code ready and suitable for pushing to the hosting service. Might include things like:

• Correct paths (not absolute local ones)
• Correct scripts
• Removal of unnecessary dependencies
• Code clean-up (remove unncessary comments or not used code)
• Correct commentary for future bug fixing or further developing
• Security checks (i.e. SQL in the backend)
• Looot´s of testing...!