[ ] Get the following microservices working via Ansible to enable cleaner environment setups
[x] ps2alerts-website
[ ] ps2alerts-api
[ ] ps2alerts-webocket
[ ] Get the following projects working again in local development environment
[x] ps2alerts-website (without V2 API)
[ ] ps2alerts-website (with V2 API)
[ ] ps2alerts-api (V2)
[ ] ps2alerts-websocket
Stage 2: Websocket rewrite
[ ] Initiate re-write of webocket
The biggest issue with the stack is the collection script. It's in a 4k+ line crappy nodeJS script which is vastly out of date, using basically no best practices and crashes all the time.
[ ] Decide on the websocket tech
Ideally, we need to port this over into a singular language. Therefore, ReactPHP with native websocket support seems like the most logical course of action.
[ ] Decide on how to supplement data
I used to use Jhett's "Enhanced API" system which basically just took extra material from the normal census API and bolted it alongside requests. This made my code very easy as all the data was in a single message. However this also had drawbacks as when the 3rd party system had issues, I also had issues. It also meant I was entirely dependant on Jhett to maintain it, which he no longer does.
[ ] Decide on whether to continue using a websocket collection micro-service or to include it as part of the overall API repository
I plan on having the websocket collection script call the PS2Alerts API directly so there's a standard interface for creating new data and extracting data. This will assist with the overall creation of the API itself as we can implement a proper REST & CRUD interface, rather than directly importing into the database and having to change two different places.
Alternatively, the websocket could integrate into the ps2alerts-api project so we can use entities and persistence. It also requires less maintenance as we can perform migrations and the websocket code is instantly up to date. Then again, as long as the interface to the API doesn't change, the database part of things should not matter. Requires further thought.
Stage 3: API V3 rewrite
[ ] Initiate API rewrite
The API is a bodge job. It was created when I was only starting to truly get to grips with PHP (questionably I still am at that stage).
It's been recommended that I seriously consider the API Platform. It's basically an ideal candidate, however it requires a lot more learning time and it has additional complexity. However, the benefits mostly outweigh the extra work, as we can create CRUD, authentication, caching, validation etc etc from one configuration.
[ ] Research into stack for the API platform
AFAIK API Platform can't be deployed as a microservice - at least a containerised one.
Stage 4: Frontend website rewrite
Considering that the other tools are getting gutted, the website frontend itself, at least in terms of Angular, needs re-assessing. The interface between the API and the website will drastically change, all the requests will be totally different.
[ ] Research into alternatives for Angular, or see if the new Angular setup is better.
The current site is running on Angular v1.6, which is donkeys old. A choice needs to be made whether we should keep the current version and just swap it out for the new API and websocket, or go ahead with a new version.
[ ] Implement the new frontend framework, if chosen.
Stage 1: Development Environments
Stage 2: Websocket rewrite
The biggest issue with the stack is the collection script. It's in a 4k+ line crappy nodeJS script which is vastly out of date, using basically no best practices and crashes all the time.
Ideally, we need to port this over into a singular language. Therefore, ReactPHP with native websocket support seems like the most logical course of action.
I used to use Jhett's "Enhanced API" system which basically just took extra material from the normal census API and bolted it alongside requests. This made my code very easy as all the data was in a single message. However this also had drawbacks as when the 3rd party system had issues, I also had issues. It also meant I was entirely dependant on Jhett to maintain it, which he no longer does.
I plan on having the websocket collection script call the PS2Alerts API directly so there's a standard interface for creating new data and extracting data. This will assist with the overall creation of the API itself as we can implement a proper REST & CRUD interface, rather than directly importing into the database and having to change two different places.
Alternatively, the websocket could integrate into the ps2alerts-api project so we can use entities and persistence. It also requires less maintenance as we can perform migrations and the websocket code is instantly up to date. Then again, as long as the interface to the API doesn't change, the database part of things should not matter. Requires further thought.
Stage 3: API V3 rewrite
The API is a bodge job. It was created when I was only starting to truly get to grips with PHP (questionably I still am at that stage).
It's been recommended that I seriously consider the API Platform. It's basically an ideal candidate, however it requires a lot more learning time and it has additional complexity. However, the benefits mostly outweigh the extra work, as we can create CRUD, authentication, caching, validation etc etc from one configuration.
AFAIK API Platform can't be deployed as a microservice - at least a containerised one.
Stage 4: Frontend website rewrite
Considering that the other tools are getting gutted, the website frontend itself, at least in terms of Angular, needs re-assessing. The interface between the API and the website will drastically change, all the requests will be totally different.
The current site is running on Angular v1.6, which is donkeys old. A choice needs to be made whether we should keep the current version and just swap it out for the new API and websocket, or go ahead with a new version.
[ ] Implement the new frontend framework, if chosen.
[ ] Release to the public