Okay, so its almost fully reactive. The API is still blocking as of
current. Everything else is reactive now:
- Command system
- All utility methods
- Event listeners
- Announcement Thread
- Google calendar auth
Added simple reactive wrappers for google calendar blocking calls
I have no idea if any of this works, but it *should* work. Time to test!
Massive changes to the bot and d4j required migrating to the latest
snapshot. So far everything seems to work well, but will be tested later
on this week. Hopefully this is one step closer to being able to deploy
this to production in order to make the bot more stable and responsive.
Completely rewrote our in-house logger so that its completely async.
Also designed the new logger so that we could pull it out of this
project and incorporated into our general utils library for all of our
other projects
Apparently several tables were setup with incorrect datatypes resulting
in mapping issues. This is now resolved with the migration scripts
converting the datatypes to the correct types.
This commit introduces the r2dbc api for all database handling to make
it fully reactive so future updates to make the bot fully reactive.
While most calls to the database are still blocking, this does use a
reactive driver for it so further work down the line will be able to use
the database reactively without much additional work.
These changes have not been tested, and will need to be tested
thoroughly as database use is the backbone for the bot's persistence
data scheme.
We have narrowed down where the slowdown starts and ends, however there
is still a lot of things happening between there, so therefore we are
checking what parts of those sections of the code are causing issues.
Its taking, on average, 10-15 seconds to handle this request. To combat
this, we are adding a bunch of debug statements to diagnose *where* the
slowdown is occurring. The next part of this debugging process is to
figure out *why* it is running slow, and how to speed it up to
acceptable speeds.
Messed out how to deploy to repos in the poms as I forgot how to do it,
this issue is now fixed and it will correctly go through the deploy goal
while only actually deploying core to the repos.
This is because they become out of range of JS's `number` type and cause
problems. So, by handling them as strings, and only strings withing the
API, this solves the issue and we should not run into precision issues
anymore.
This commit gets typescript compiling to browser-safe javascript using webpack.
Also fix some issues regarding handling status endpoints, missed debug and error reports, and cleaning some other things up.
Last change involves getting maven to automatically compile typescript and styles for the website without needing to do it in cli before the package
This commit changes a lot of things, the major changes are as follows:
- removed all old web files from server module
- Switched to using Typescript for development of the frontend
- fixed /events/list/list endpoint duplication
- Compile all TS code into a single JS file
- Add automatic gulp building/cleaning on maven steps
- Add object parity in TS for OOP handling
- All relevant API calls have own TS file for request eliminating duplicated code
- Add read-only API key support for embed pages (so that a temp key can be generated for anonymous users without write permissions)
- Fixed several typos and small issues
Completely finished the doc pages on the API,
as well as refined some of the code in the API endpoints
so that everything is nice and standardized,
as well as comprehensive.
Add back everything that was accidentally removed, fix up some stuff, and make it bootable. Next up is getting the theming corrected and adding the rest of the public pages before working on the dashboard.
