Welcome to www.mysticdream.net (Vision Jinx's Developer Disneyland!)
This is a developer playground for www.visionjinx.net (Coming Soon!) This is where we get to play and test out new ideas and concepts and build new services and APIs.
This site is where you are most likely to find code demos and cool things to check out where the main site will consist mostly of a documentation and knowledge sharing site (like Wikipedia).
Background images are provided as Public Domain from NASA Images
AMIE started as a "Automated Monitoring and Integration Engine" that was designed to be coupled with Prometheus and Grafana for monitoring large scale N-Tier, Container and Microservice Architectures (hundreds of VMs).
We needed a way to federate all our monitoring endpoints into a single location (similar to an API gateway and abstraction layer) for that application deployment and wanted all the documentation for that application to be deployed with the application. Including Fault Management, Alarming and Enrichment Data, Proactive Monitoring and Maintenance, Provisioning and Staging Data in SQL Relational Databases and the list goes on...
While in the beginning, using markdown files was working and just pushing them into a source control repo was meeting our requirements. After a while it started to become "clunky" trying to mange and edit all the markdown files and push/pull them into production, so it just made sense to move it to a NoSQL Document Database like MongoDB. From here we could build essentially the backend for a MERN/MEAN Stack that can be rapidly and easily deployed.
AMIE comes with a bunch of API services and you may not need all of them so you can disable the routes for them if needed.
AMIE was also intended to be installed on an internal network (behind your corporate firewalls) where your Network Teams control the ACLs and load balancing etc. This allows AMIE's APIs permissions to be a bit more permissive internally as trust can be established on an internal network easier then the public Internet.
For Public Internet deployments considerations need to be established for if you want all your API services to be available (like NASA Images) and use CORS (Cross-origin resource sharing) so anyone can access them, or do you prefer to remove them completely (or enforce a Same Origin Policy) or have them require an API Key which would require you to have to allow users to sign up for your API services and register their API keys (or Service Keys, probably preferred approach) in your system.
If you are considering a user signup section, remember that AMIE doesn't use usernames and passwords in the conventional terms (everyone "could" be "anonymous" like with a 4chan site using TripCodes/Secured TripCodes). It has a PassKey server that you would have act as a "Certificate Authority and Issuing Server" for your session (like a NPM JWT type token) in that context and you are having your requests "signed" by AMIE.
AMIE doesn't include a "front end" (in the context of React, AngularJS etc), it was designed to be the backend framework that can easily be dopped where you need it and start prototyping ideas. It's components/servers are decoupled (modular) so they can be separated out and scaled accordingly if needed, or just used within vsCode and it run on your local host, AMIE's experience "out of the box" should look and feel the same! It's a minimalist approach so you have the flexibility to take it where you need it to go! After all, you are limited only by your imagination!
We also didn't want to store usernames and passwords in the database (or the Application!) or deal with clunky cloud SSO options (or Corporate LDAP). So AMIE comes bundled with its own "Password-less" PassKey Server. This PassKey server is completely decoupled from the application and does not store or persist any info of any kind or have a database behind it. It only Generates and Authenticates its PassKey Certificates and Sessions.