I'm currently developing a project in Node JS that uses microservices architecture, in which each service has it's own repository that contains both the code for the service itself (NodeJS express server), and also an SDK file that I publish for other services to use with methods that are available in this service and Typescript definitions.
So for instance I have a users-service that handles all of the user related actions, and a reports-service that handles all of the reports that users can CRUD.
users-service has a method called "deleteUser" that also goes to reports-service SDK in order to delete all of this user reports. On the other hand reports-service uses user-service SDK to "getUserById" for instance. So what happens is that user-service has reports-service-sdk as one of it's dependencies, and reports-service has users-service-sdk as one of its dependencies. Because the SDK is inside the same npm module with the service, I get users-service-sdk as one of the dependencies of users-service.
I thought of separating the SDK with a different package.json file, but I wanted to know if it's the right way to go or am I doing something really wrong in my architecture :)
Thanks.
This sounds like Circular Dependency which as you stated in the title is tough to deal with. Microservices are great but this sort of architecture sounds like a lot of extra unnecessary work without any added benefit.
You should look into running your services/packages/repositories as Cloud functions (or Firebase functions). AWS also has their own solution for microservices architecture. The reason being is each service can communicate with other services by using internal authorized calls or authorized REST API calls --- or you can make them totally public.
The great thing about these Google Cloud Functions is each function is automatically an Express end-point that accepts GET, POST, DELETE, PUT. Or if you use the internal call for Firebase, each function automatically contains relevant context from the frontend (such as the user's authentication details).
You also configure IAM permissions to only allow who and what service you want to be able to execute your cloud functions so that you have full control of permissions.
To answer your questions directly though, I would definitely avoid Package A having Package B as a dependency as Package B has Package A as a dependency. You absolutely can make that work but there's no upside and a lot of downside.
Here's an old thread which covers the topic.
Related
i would like to know if i am the only one thinking to not use Amplify's API and instead use the classic SDK. The reasons are
1st: I am a beginner to AWS and development so the fact that Amplify is hiding the complexity isn't helping me to learn what's going on behind the scenes, control and understand everything well.
2nd: Can i modify the API without changing the generated to local project files? (files that generated while running "amplify add auth" command.
I am very confused about it, and can;t really find a guide of how to modify local files after doing changes to API through AWS platform.
I been working on a React project using firebase auth and cloud firestore as the database and I been reading the official documents. But I am grappling with the idea of whether to use mobile/web SDKs and server client libraries and I am afraid I might have some misconceptions about Cloud Firestore Security Rules.
I read this page https://firebase.google.com/docs/firestore/client/libraries several times and it is about SDKs and client libraries for firestore. It seems to me that it suggests there are two ways of using firestore: one is through Mobile and web SDKs and one is through Server client libraries. And if I am using Mobile and web SDKs then my project would be classified as serverless since I am only building the front end and let Goole to handle the database and user authentication. The other way to use firestore, which is Server client libraries, it seems like it is meant to be used with your own server. It then refers to this as client libraries in the section, But the thing I don't quite understand is, what does client mean here? I'm sure it doesn't mean the same thing as in "the mobile and web SDKs support serverless app architectures where clients connect directly to your Cloud Firestore database.", where I assume a client is an end user who is browsing your website or web app. So what does this the client mean as in Server client libraries?
Since I am only able to build front end app or the client side app, I guess I should go with Mobile and web SDKs option to start using the firebase. Here comes the second question, when selecting a starting mode for my Cloud Firestore Security Rules, there are two modes: Test mode
and Locked mode. For Test mode, it says "Good for getting started with the mobile and web client libraries, but allows anyone to read and overwrite your data. After testing, make sure to review the Secure your data section.". My first confusion is, does client libraries refer to the Server client libraries previously I mentioned? If so, as a serverless project without a server I cannot technically I cannot choose this mode? Then for Locked mode it says, "Denies all reads and writes from mobile and web clients. Your authenticated application servers (C#, Go, Java, Node.js, PHP, Python, or Ruby) can still access your database." Again this option seems like it is not for me since it mentioned Your authenticated application servers, and for my project I don't have a server, or the server is on the google cloud platform. So can someone please correct me if I am understanding this wrong. Also, if I opt-in the Test mode, I suppose it allows anyone to read and overwrite my data. But I feel like there needs more explanation on the word anyone here. I think at least the person needs to have the exact firebase configuration as my project has. something like this
const config = {
apiKey: "myapikey",
authDomain: "my-auth-domain.firebaseapp.com",
databaseURL: "my-db-url.com",
projectId: "my-pid",
storageBucket: "my-storage-bucket",
messagingSenderId: "my-sender-id",
};
to access my database. I think by anyone, here it means anyone with this config file and doesn't need to log in to my project in order to mess with my database. This is my understanding, can someone please correct me? Finally, in my case, I just want that anyone who can log in to my project can have access to the database(both read and write). Which mode(test or locked) should I go with? Or I need more configuration for this?
Is it true that whether I choose web SDKs or Server client libraries to start my firestore project, I all need to use firebase-admin? But do I need to use Firebase CLI to init my project as a firebase project with the automatically generated firebase.json?
The official documents constantly use the word web and node.js, such as this image. . I actually don't know what they exactly mean. If I am writing React, should I go with web or node.js? If it belongs to web, I am importing stuff like import firebase from "firebase/app"; in my react project, these are also modules for Node.js. Again I am confused here.
I know this might be too long to read and the questions might be a bit trivial but I really appreciate if someone could clear up my confusion about firebase.
As far as I know, Here are the answers to your questions:
1) So what does this the client mean as in Server client libraries?
Server client libraries are used to access Firebase from servers which run on Java, Python, Go etc.
2) Which mode(test or locked) should I go with? Or I need more
configuration for this?
Test mode opens your database to the public which means any user can access your database without authenication.
Locked mode keeps your database locked down by default. You can then add rules to grant access to certain read or writes.
I would recommend to start out the project with this and later configure firestore security rules to open up access to your database according to your application's requirements. You can find references here : https://fireship.io/snippets/firestore-rules-recipes/
3) Is it true that whether I choose web SDKs or Server client libraries
to start my firestore project, I need to use firebase-admin? But do I
need to use Firebase CLI to init my project as a firebase project with
the automatically generated firebase.json?
firebase-admin available on npm is the Firebase Admin Node.js SDK to access your firebase database with admin privileges. This can be useful when you initialize/access the application specific configurations and parameters in your database.
You don't need Firebase command-line to initialize your firebase project and generate the firebase config file. You can access it through Firebase console of your project once you create your project in firebase. Reference : https://support.google.com/firebase/answer/7015592?hl=en
4) If I am writing React, should I go with web or node.js?
You should go with Web because node.js SDK is used for access to your Firebase services from privileged environments (such as servers or cloud) in Node.js.
Reference: https://www.npmjs.com/package/firebase
Additional Point: Found this for React in the Google's documentation for FIrebase SDKs. https://github.com/tylermcginnis/re-base
Hope its clearer now.
I am tring to make CRUD operations on Active Directory via nodejs.
The only package that handle CRUD operation in node that i have found is ad-
https://www.npmjs.com/package/ad.
Are you familiar with other packages?
Is this the only one for update operations?
It seems that integration with Active Directory in nodejs is not popular and mature. Am I wrong? should I implement such integration in Java or .Net core?
Thanks!
The right way is the way that works :) If you are already using NodeJS, then do it in NodeJS if at all possible.
Communication with AD would happen through LDAP, so you can look for NodeJS packages for LDAP. Here are a couple I found:
ldapjs
ldap-client
But that one you linked to is more specific to AD (and AD does have its own flavor of LDAP) so I would choose that as long as it works for you.
If it doesn't work for whatever reason, either ask a new question here to get specific help, or you can start looking into making a separate Java or .NET app to do it. But I wouldn't consider a separate app just for AD queries unless you absolutely couldn't do it in NodeJS.
I would like to know what is the best approach in create several deploys from a big code base. The idea is to divide the big API into microservices (each one in it's own server/vm),
The first idea: I could simply create a folder with only the available routes for that microservice, but still using the "common" codebase...
I currently end up with this, and it's a running API in production (with staging environment in heroku with their pipeline):
and I was thinking that I could have something like:
can anyone point me to a good reference on ... where to start? how can I push multiple version of the same base code to a server?
for more detail on the used technologies, I'm using:
mocha and chai for tests
sequelize for mariaDb modeling and access
restify for server engine
When you divide the API into microservices, you have few options:
Make completely separate repos for all of them with some code duplication
Make completely separate repos but sharing common code as Node modules
Make one repo with multiple microservices, each as its own Node module
Make one repo with one big codebase and build multiple modules with needed parts from that
I'm sure you can do it in even more ways
Having a mismatch of the number of Node modules and code repos will cause some troubles but it may have some benefits in certain cases.
Having a 1-to-1 mapping of repos and modules will be easier to work with with some cases, like the ability to add private GitHub repos directy to dependencies in package.json.
If you want to factor out some common functionality then you can do it in several ways:
The npm supports organizations, scoped packages, private modules and private scoped packages with restricted access.
You can host a private npm registry
You can host a module on GitHub or GitLab or any other git server
For more info see:
Node.js: How to create paid node modules?
There are some nice frameworks that can help you with splitting your code base into microservices, like Seneca:
http://senecajs.org/
Or to a certain extent with Serverless if you're using AWS Lambda, Microsoft Azure, IBM OpenWhisk or Google Cloud Platform:
https://serverless.com/
Inside a custom endpoint in Kinvey, I see the modules parameter which exposes inbuilt modules like so:
function onRequest(request, response, modules) {
}
I could see from the documentation here that Kinvey has some existing inbuilt functions
http://devcenter.kinvey.com/rest/reference/business-logic/reference.html#modules
My questions are,
Is it possible to have our own custom reusable modules defined somewhere in Kinvey and use it within the custom endpoint function above? If so how?
Is it possible to define (similar to package.json) and use external npm packages within the above custom endpoint function?
Great to see that you show interest in using Kinvey!
Regarding your questions - yes, if I got you correctly both are possible. See below for further explanations...
You can implement Common Code, and use it to create reusable functions which can be used across your business logic scripts. Please refer to the following link for more information.
You can implement Kinvey Flex Services, which are low code, lightweight NodeJS micro-services that are used for data integrations and functional business logic. FlexServices utilize the Flex SDK and can consist of FlexData for data integrations, FlexFunctions for trigger-based data pre/post hooks or custom endpoints, and FlexAuth for custom authentication through Mobile Identity Connect (MIC). Please refer to the following link for more information.
I hope, I have informed you well.
No, this is not possible in the free tier, in Business Logic you are limited to using the modules that are explicitly whitelisted.
There are options to run any node code (including any npm module you want) inside the platform in the paid "Business Edition".