I am playing with node.js porting a webAPI currently implemented in Delphi and learning how to do things the node way.
My application uses two instances of a database-backend connected to a different DB each. Service-code can get a connection to each from one of two global instances of a connection-pool.
How would one do this in node.js?
I know how to write the pool as a module exporting a constructor so I can create two instances, configured with a different connection string. I can hold these in global variables in the main server-file or in a module holding references to various services and doing routing of requests.
But how would the individual service-modules that want to get a connection, do something with it and then return it to the pool get access?
So far I have been happy with require()-ing such shared modules everywhere I use them, so they behave as singletons and the state is shared between everywhere they are require()-ed. But how to do that if I want two (or n) instances that are configured differently?
All I can think of so far is actively injecting a reference to them everywhere. Would work, but is that the proper solution?
P.S.: I did not know up to now that Doubletons are a thing.
Related
Global class?
I'd like to use a module in 2 other modules. And use defaults.
Then update the module after application is initialized (and connected to DB).
How this can be achieved?
Example use case:
Logger module is started with default configuration. It will fetch custom one from the database after database is connected.
Database module is using same logger (using default configuration until it gets configuration from that same database).
In many other languages I could create a class, then use instances of it and finally update class (not the instance) with new configuration. Updated values will be shared across the instances.
Some ideas that came into my mind:
Maybe I am thinking about it wrong way?
Can I use global variables?
I can use a local shared resource (file for example) to trigger change after startup is completed and connections are established/configuration fetched.
Another problem: How to avoid strong coupling between the modules?
Maybe I am thinking about it wrong way?
Right or wrong isn't really black and white here. It's more about benefits of modularity.
Can I use global variables?
You can, but you probably shouldn't.
Modularity in nodejs offers all sorts of benefits. Using a global variable creates a global environment dependency that breaks some of the fundamental tenets of modularity.
Instead, it generally makes more sense to create a single module that encapsulates the shared instance that you wish to use. When that module is initialized, it creates the shared instance and stores it locally in its own module level variable. Then, when other modules require() or import this module, it exports that shared instance. In this way you both retain the modularity and all the benefits of it and you get a common, shared instance that everyone who wants to can use.
The only downside? One line of code is required in any module that wants to use the shared resource to import that shared resource. That one line of code helps you retain all the benefits of modularity while still getting access to a shared resource.
I can use a local shared resource (file for example) to trigger change after startup is completed and connections are established/configuration fetched.
It isn't clear what you mean by this. Any modular, shared resource (without
globals) as described above can capture a configuration and preserve that configuration change.
How to avoid strong coupling between the modules?
This is indeed one of the reasons to avoid globals as it creates strong coupling. Any module that exports or shares (in any way) some shared resource creates some level of coupling. The code using the shared resource has to know what the interface is to the shared resource and that cannot be avoided in order to use it. You can often take advantage of existing interfaces (like eventEmitters) in order to avoid reinventing a lot of new interface, but the caller still needs to know what common interface is being used and how.
We have a C# Azure Function App (consumption plan) which scales dynamically i.e new instances are added depending on the load, now we have an object which needs to be used across all instances of this Azure Function, as the object is complex (has delegates) I cannot serialize to put on an external cache so that all instances can access it from there, please suggest the best way to handle this scenario.
Azure Function instances are running on different servers, they do not share the same memory, so there is no way for all of them to access a single .NET object without remote calls (and thus serialization).
There's something fundamentally contradictory in your question: you can't have both a) a function that scales to many machines; b) all instances sharing in-memory objects as if they were running on a single machine.
It goes the other way too: serverless means that if nobody is using your function, all infrastructure can be shut down (hence saving you money) - but that implicitly means you'd lose your in-memory state and need to be able to serialize it.
Minimize the shared state, make it serializable (there are patterns for dealing with things like delegates [1]), and use external storage (Azure Storage, or a cache like Redis).
[1] For delegates, one trick is to maintain a dictionary of handles to delegates, and then serialize the handle. Similarly, for polymorphism, you might serialize the type name.
I'm currently writing an application which has sockets engine running on one node.js instance and restful API for various resources on other. I'm wondering what could be the best way (performance wise) to communicate between these to instances if they would be located on a different servers. I don't want to duplicate data access logic on different instances and I want to keep everything (what's related to data access) in one place.
I thought about using simple HTTP API where sockets engine would make request to resources instance and get what it asked for but I'm not sure if I won't hit any performance bumps. In fact I could actually connect straight to mongodb and get the data that I want from there without making a request to other service but I feel like it would be nice to isolate data so that could be only used by resources instance and that would be the only application that uses mongodb instance.
Is there any other better ways to achieve something similar?
What is the proper way of using domain module in NodeJS applications?
Wrap up the code blocks with the domain instance like how we use try-catch blocks? If yes, should we create new instances of domain each time for each separated block?
Wrap up the main function with the domain run method? If yes, is that really sufficient for an enterprise application for example?
P.S. Is there any well-known open-source node project with an extensive use of domain module where I can study their code?
P.P.S. Looking at the node documentation and tutorials, I see that almost all of them just simply wrapped up the main function within the domain's run method, however as far as I can see they are mostly copying each other. I basically can't see how people use domain module in different situations (what I see is mostly a copy of node documentation with couple of minor changes)
I've written two relatively large socket.io apps, one for playing a game and the other for chat, which I've separated into two namespaces.
I would like to now move these out of my main file app.js into some namespace directory, and just require them in my express app leaving all of the functionality intack.
How would I go about this, or is there some way to get the effects of what I'm looking to do in some other manner?
In order to use separate files you need to use modules in node.js and use require to load them.
Modules have special structure and syntax to follow, in order to be able to call modules functions and interact with it.
Read about modules here: http://nodejs.org/docs/latest/api/modules.html
If you need to interact with functions, objects and data inside of the module, then it might be a lot of work on remaking architecture of your application.
This is something that you have to take care from the earliest moments of the development, in the process of architecture and technical design of application.
To use same socket, you have to initialize it in parent module that require child modules, and pass socket app handle to those child nodes, that they will be able to use it.
The worst and straight forward option to make it, and is absolutely not the option in commercial world, is to load js file content and just eval() it. But remember - this is absolutely not recommended and in commercial world you should never use it.