fox-archives / tails Goto Github PK

we use mostly 'names' when doing db ops, rather than ids. use ids more and stuff

title

have a doctor command that tests if things are right
potential use cases

• to ensure versions between packages and plugins match up
• to ensure node version (at least until we transpile to engine <=12.10)
• to ensure yarn, pnpm versions match (for what?)

rn anyone can just hit up the api, add some auth, maybe with pasetos instead of jwts

right now the err.message is a single word of the specificity of the error. change that to err.what, and have actual good err.message

so right now we are using raw http reqs for calling in between microservices

obviously this is pretty jank so were going to have to implement some message broker to facilitate better communication

was looking into solutions including rabbitmq, apache kafka, and nats. after almost choosing each one separately i finally decided on nats. mainly because it fits in the cncf ecosystem and it is as simple as we need it - even if its not as popular as kafka or rabbitmq. considered kafka over rabbitmq, but its probably too heavy weight, not to mention zookeeper and jvm overhead. maintenance of it within our app will probably be difficult (and have a suboptimal configuration), since i do not have a strong background in distributed system development

going to close this issue once our services integrate with nats pretty 👌

right now all components are meant to be cloud native

consider creating some daemon on local computer that we need, say, for example, opening up a code editor, or interacting with the file system (through storage service)

some configuration files repeat across packages. try to eliminate them

cli printing is inconsistent. have good printing with nice colors

with the creation of the filesystem folder, this creates a tails npm package that we can install anywhere to manipulate projects on the file system. this can potentially be installed and used in cli and paws to handle this kind of stuff. for now, we will be using it exclusively in cli

this should simplify some things. it will allow

• to use the tails project management interface locally (by only installing the package, no running daemon (as in if we used coordinator)
  • which will simplify the the more simple installation procedures
• plop it in paws when it is ready. unlikely, but good to thing about, is this could completely replace paws if we change how we approach things

prettier dependent eslint linting doesn't seem to be working

right now we do a terrible job importing the protobufs and implementing them, we have to import each one individually. change this

relevant file: tails-server/serc/util/read.ts

currently passing in namespaces to physicalProject actions has no effect. take these info account. also maybe remove those unecessary abstract functions for sorting. they aren't really needed

fix up docs for tails-fs. be sure to take into account Config.get() calls returning errors (they are not handled by functions that call them

right now errors are handled ad hoc and not generalized to some handler function. refactor and keep handling more dry

we have the infra for the graphql endpoint, we just need to set it up with the right schema

ensure paws has good logging

when we distribute paws (at least for linux), we log to stdout and setup systemd service unit files. later we can add crap that logs to a file, such as on windows or mac

ex jest 24 config

create project.helper.js and namespace.helper.js from util/index.js

when passing in more than one named arguments, we make the required arguments optional