Avoid global namespace pollution #2
Assignees
Labels
enhancement
New feature or request
Comments
|
What I completely forgot to mention is testability, which requires stub classes to isolate individual components. And good luck writing stub classes when there are no classes to begin with. |
fef1312
added a commit
that referenced
this issue
Apr 4, 2020
Part of a series on #2. I am more or less just trying out random stuff right now and see how things work out. Rationale: Your plan can't fail if there is no plan to begin with.
fef1312
added a commit
that referenced
this issue
Apr 4, 2020
Part of a series on #2. The next step is to transform all routes to a subsystem as well, and make that subsys depend on the mongo and http ones. Let's see how that is going to turn out...
fef1312
added a commit
that referenced
this issue
Apr 4, 2020
Part of a series on #2. I originally planned to use one general interface for both MongoDB and cache data access classes, and just treat both the same in every way. This, however, turned out to be quite complicated because the repositories would not know when a document is _really_ created. This new approach splits data sources into two categories: authoritative and cache. That way, a repository can always first insert new documents into the authoritative (MongoDB) data source, and then populate the cache. Let's see how many refactors are left to get to version 1.0...
fef1312
added a commit
that referenced
this issue
Apr 6, 2020
Part of a series on #2. This version includes a kind of nasty hack to provide backwards compatibility with the old JWT wrapper in src/util/jwt.ts (by far not as nasty as the original JWT utils, though). That will get removed once I finally replace the routing stuff with an own subsystem, which turns out to be more difficult than expected.
fef1312
added a commit
that referenced
this issue
Apr 7, 2020
Part of a series on #2. There are still some old things in place, but that's mainly because I am too afraid to cause some random error by deleting them. It will get removed completely once all route handlers are rewritten.
fef1312
added a commit
that referenced
this issue
Apr 9, 2020
Part of a series on #2. This should be one of the last commits to fix this issue; that took me long enough. The next step is to get rid of all those legacy code snippets to remain compatible with the old architecture, which will probably take the rest of the day. Really looking forward to that.
fef1312
added a commit
that referenced
this issue
Apr 14, 2020
Part of a series on #2 (we're almost there!). Maybe it's a good idea to just get rid of Express all together, I mean I'm using only like 20% of its features and implementing an own routing framework might even be faster. But that of course is no priority right now, maybe just before the 1.0 release in like, 5 years from now.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now, anything that is required in multiple places is either stored in the
global.videuobject (for configuration data) or the module exporting it is just imported wherever needed (e.g. the repositories).This scheme kind of works, but making mistakes is quite easy and it gets more and more difficult to maintain as the codebase grows. Especially stuff like modifying types from external packages (express in this case) is probably a time bomb. We should migrate to a more sophisticated, object-oriented design. This not only provides better ways of abstraction, it also enables us to use TypeScript's type system to its full extent (I'm thinking of stuff like the request body from express, which has no central validation system right now and has an
anytype).The text was updated successfully, but these errors were encountered: