Ts restify the backend

[wu-lee]

What? Why?

Related to issue #6

This PR converts the back end from using the fastify-openapi-glue implementation to an equivalent one using the new ts-rest based contract. It also fixes the test suite (such that there is) and adjusts the contract to match the API in use, in particular with respect to the errors (they now return messages), the dataset ID (it's now a number) and the version endpoint (the response is more specific, not just a pass-through).

What should we test?

• Check it builds (dev and build front and back end) and that intellisense works in your editor.
  • The build should also now update the common package to ensure the contract is up to date
• Check the version endpoint works and provides sensible information. You may want to add some test tags to your working repo to see how that changes the version information.
• Check the tests pass.

Checklist

• [ ] Updated or added any necessary docs in docs/ I dont think the documentation there needs additions? I have however included TSDoc style comments to the new code I've added.
• [ ] Added UTs (Not applicable)
• [x] Checked that all automated tests pass

Deployment notes

[wu-lee]

This whole branch has been rebased to the end of main and some minor conflicts resolved (just package-lock.json)

[wu-lee]

Some extra things to note. As well as fixing-up those things as requested, I found some other problems and addressed them too. These were:

• I discovered the front-end got re-hardwired to load the API from http://localhost:3000. Hope t this isn't annoying, but I needed to adjust this back to use the environment variable VITE_API_URL in order for both the back-end in a production-mode installation to work, and npm run start on the front-end, as they both need to get the API from elsewhere. Therefore I think you will need to set this variable explicitly now for npm run dev to work with the back-end on http://localhost:3000. (Similarly, you need to set this to /api for npm run start to work, see notes below.) Possibly this could be set in the dev runscript via cross-env VITE_API_URL=http://localhost:3000, this works but I hesitate to add it without conferring first)
• I added a more correct QName validation in the contract. The XML spec makes this hard to do exactly, I decided to go for something close so that the regular expression doesn't even become (even more) hairy.
• I added some unit tests for the validation regexes for QName and URL-safe Base64 strings. This required exporting these validations from the contract for use in a test.
• I removed a spurious @ts-nocheck and some comment typos. These aren't strictly related to this branch topic but seem necessary.
• Changes earlier in the branch meant the Fastify plugin stopped respecting the prefix option, which breaks production mode. I needed to correct this in the back end, with knock-on corrections in the front end.

As I said earlier, I plan to flatten these corrections into the appropriate commits before merging. I'm not sure if it's easier for you to review before or after that, so let me know if you want me to do that first.

I've tested npm run dev/start/build on the front end, and npm run dev/build/test on the back end. These seem to work as expected now.

To test npm run start you need to set VITE_API_URL=/api in the front-end environment before building. It then mimics the way the app will run when deployed in production, when the API is served from /api.

You can check this is working by:

• visiting http://localhost:3000/api/dataset/test-A - you should see the test dataset contents as JSON.
• visiting http://localhost:3000?datasetId=test-A - you should see some points obtained from the test-A dataset rendered on the map

Setting SERVER_DATA_ROOT=test/data (or an equivalent) in the back-end environment isn't necessary in development (npm run start), but is necessary in production. Of course an alternative location can be used, pointing to different data. Our new back-end implementation, when it arrives, should continue to respect this option, as this is used by the production deployment to define where the data is.

[rogup]

@wu-lee Thanks, this is looking good.

• Happy for you to add cross-env VITE_API_URL=http://localhost:3000 and cross-env VITE_API_URL=/api to the runscripts
• I've reviewed your changes, so feel free to merge however makes most sense.
• There are 2 outstanding comments. Once they're addressed, feel free to resolve them yourself and merge the PR without passing it back.

[wu-lee]

Fixes for above changes requested now added as fixup commits above, then the branch rebased on to the current main branch to verify it can be integrated.

Then fixups squashed into relevant commits, or promoted to primary commits, as appropriate.

Result rebased again to integrate a fix added to main branch.