Finishing the NodeJS platform
• Mark Eschbach
I’m wondering when the correct time to get a decent logging framework in place is. I really want to exhibit strong bias towards an ultimate platform where logging is setup on day 1, however this is rarely the correct choice when we just need to get something up and running. I look forward to the I can develop platform libraries so each programming environment (Node, Python, Go, etc) may be ready to go out of the box. I suppose that will get done sometime after my long await release engineering library intended to be reused between our projects.
I’m going back through the Node application to update the console.log
statements to use the bunyan
loggers instead. For the most part it’s fairly straight forward. So far I’m realizing if I had injected the loggers instead of using the globals then I would have been fine.
With more complicated structual components I really want a registry for components I could draw from, something like a Spring Context
. I would imagine in JavaScript this would be a relatively easy system to build: have a register
method which would take the name of recipe for construction and a factory to produce the component. When asked to build the element, the factory would be given the context and expected to build a result. The simplist implementation would allow for a one-per-reference style with the container. The factory could memoize the results for singletons within the context. We could even design delegation for the contexts, although that would become more complicated as I was thinking the first context implementation would build object properties on the registry.
Normally I would go with this being overengineered but I’m spending a lot of time extracting data in one location only to be recorded and used in another. It would definitely be nice to invert that, having the clients of specific modules ask for the data they need. This would also make decisions to activate different subsystems a lot easier. Anyway, I’ve gotten through most of the trails there, I’ll need to return later when I have higher network throughput.
Okay, so I got Sentry integrated after a brief head scratching moment. Sentry was complaining about too many 302 redirects. Turns out I had a trailing single quote character due to a copy/paste error. Not to bad I guess in the end. Unforunate it wasn’t more explicit.
Containzering the application was a bit interesting as building some of dependneices required Python and gpy. I’ve taken the approach of forking the dependency and moving forward without the native dependencies. To install Python would greatly increase the footprint size of the containers to do otherwise.
Next step is to use Vault from a Docker container. The approach suggested here looks interesting and worked out of the box. I really need to read up on scutil at some point.
The application came up and operated as expected, less some minor issues regarding last minute parameter modifications which were easy to modify.
I’m distributing the credentials one-per-project for deployments. This isn’t going to scale well in the long run unforunately. I’ve got some ideas but it’s going to take a bit of time to ensure the understanding of the development process is encoded correctly. It’s been pretty stable for the last year, less some minor hiccups.