I did a quick initial proof of concept spike in Vue.
But we should have some coordinated conversation about what tools we want to use, especially if we allow for outside contribution.
At the moment, we don't really have code from Janis that is in shape to be re-used outside of Janis, so most decision decisions aren't going to be code dependent.
Any stack we use needs to be capable of outputting an application that meets accessibility standards and is compatible with IE11.
Ease of maintenance
Projects like this tend to be implemented in ways that emphasis easy of initial deployment but neglect maintenance. We want to consider who will be responsible for maintaining this app, and what their skill sets may be.
For instance, all of the developers currently at ODD are comfortable with a React + JSX stack.
But not every developer at CTM is familiar with that stack.
It is also possible that volunteers may be interacting with the code base, especially if this project gets used as an open source project. Were possible, its helpful to default to the 'lowest common denominator' tech tools to up the odds that a future individual will have the skills needed to maintain the code. Some architectural decisions could also go a long way, such as:
Writing good documentation
Having guidelines for contributing and some linting set up
Keeping content for the site in easily editable 'non-code' file formats
Using config files for managing parameters for deployment or maintenance
Using base-level Javascript APIs where appropriate (ex. URLSearchParams is a native API, we can use that rather than a 'insert react or npm library for URL queries here' library)
Developer friendliness
At the same time, we want to make it as easy and quick as possible to develop this project. Where possible, we want to re-use skills and toolsets across our stack.
While it may not currently be possible to re-use much Janis code for this project, it is possible that we could write code for this project that could be useful in Janis.
Other architectural concerns:
Given our stakeholder meetings and other research, we want to allow for the ability to have close to real-time accuracy for data.
For this and other reasons, we want the data to be fetched when a client visits the site rather than have a static build that would need to be updated (especially since Socrata doesn't have webhooks to push a new build if data is added). This could be accomplished via server-side rendering, an SPA that fetches the data and then filters it client side, or a more traditional MVT or MVC approach.
We're mainly offloading the backend requirements to a given provider, such as Socrata. This means this project will primarily be responsible for retrieving JSON data from an endpoint, validating it against a configured schema, and displaying that data to the client.
I did a quick initial proof of concept spike in Vue.
But we should have some coordinated conversation about what tools we want to use, especially if we allow for outside contribution.
At the moment, we don't really have code from Janis that is in shape to be re-used outside of Janis, so most decision decisions aren't going to be code dependent.
The main concerns (in order of priority):
Accessibility
Any stack we use needs to be capable of outputting an application that meets accessibility standards and is compatible with IE11.
Ease of maintenance
Projects like this tend to be implemented in ways that emphasis easy of initial deployment but neglect maintenance. We want to consider who will be responsible for maintaining this app, and what their skill sets may be.
For instance, all of the developers currently at ODD are comfortable with a React + JSX stack.
But not every developer at CTM is familiar with that stack.
It is also possible that volunteers may be interacting with the code base, especially if this project gets used as an open source project. Were possible, its helpful to default to the 'lowest common denominator' tech tools to up the odds that a future individual will have the skills needed to maintain the code. Some architectural decisions could also go a long way, such as:
Developer friendliness
At the same time, we want to make it as easy and quick as possible to develop this project. Where possible, we want to re-use skills and toolsets across our stack.
While it may not currently be possible to re-use much Janis code for this project, it is possible that we could write code for this project that could be useful in Janis.
Other architectural concerns:
Given our stakeholder meetings and other research, we want to allow for the ability to have close to real-time accuracy for data.
For this and other reasons, we want the data to be fetched when a client visits the site rather than have a static build that would need to be updated (especially since Socrata doesn't have webhooks to push a new build if data is added). This could be accomplished via server-side rendering, an SPA that fetches the data and then filters it client side, or a more traditional MVT or MVC approach.
We're mainly offloading the backend requirements to a given provider, such as Socrata. This means this project will primarily be responsible for retrieving JSON data from an endpoint, validating it against a configured schema, and displaying that data to the client.