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".
Related
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.
I want to create a workflow automation where an activity comes in and user can setup a multilevel workflow.
For frontend i am using https://reactflow.dev
How to structure things in nodejs backend. Things like database, accessing control flow statements, statements which requires crons.
You also may want to have a look at node-red.
It's an open-source product that does exactly that.
There's a set of built-in nodes.
You can develop your own nodes, or import 3rd party ones. Which are stored in NPM.
You can also just create a node with javascript or typescript code in it, on the fly.
You should check Flumejs: https://flume.dev/
https://flume.dev/docs/quick-start/
Also you should see this code sandbox example. Try to read the code
and all the dependencies: https://codesandbox.io/s/node-based-code-generation-test-forked-ll9flz?file=/src/App.tsx
I hope you find this helpful.
I have an application developed with Node.js/expressjs. It's working fine. Now I need to generate API document using Swagger. There is a module swagger-node. Do I need to re-write the whole app using this module or is there any other solution to use this module and what is the use of swagger-ui if using swagger-node.
Not from what I can tell. You should be able to generate your swagger project as described, and then just make sure that the information in the yaml file points to the actual controllers and methods that your code uses.
You can create a standalone yaml file that is compliant with Swagger/OpenAPI which can therefore be rendered into Swagger documentation. The Swagger-UI is useful for creating this yaml file. Swagger also offers various tools for testing APIs and generating code -- to use these effectively you will need a method for integrating the controller/model definitions in your yaml file into your existing codebase.
To achieve this integration I typically expose my existing codebase as an api of controller functions -- then import it as a module into the code generated by my documented API. This allows me to trust my API documentation without the burden of porting my whole codebase into Swagger's required directory structure. I believe this is the best currently available approach but is not always worthwhile.
We want to create general public web services and we create customized APIs.
But how to isolate, version and bind those endpoints as a hyperscaled system?
We want to have:
https://api.domain.tld/v1/..
https://api.domain.tld/v2/..
https://api.domain.tld/latest/..
https://api.domain.tld/bosch/v1/..
or
https://domain.tld/api/v1/..
https://domain.tld/api/v2/..
All endpoints should be isolated. Behind an endpoint like https://domain.tld/api/v2/.. exists at least 3 instances of an ASP.NET WebAPI. We do not want to separate versioning by namespaces inside the WebAPI project and use internal route configurations to resolve this.
We want to have this behavior onpremise and aswell on Azure.
Is there any recommendation or best practise and configuration samples out there?
I could only found one thread here (How to version and configure WebApi with multiple aliases) which is very old and there is no answer.
I always use the version as the api route, like you so:
https://domain.tld/api/v1/..
https://domain.tld/api/v2/..
which has always worked fine, but other use url parameters, which I find to be less explicit:
Visual Studio Team Services - API
I would just not recomend you to go with this pattern:
https://api.domain.tld/latest/..
https://api.domain.tld/bosch/v1/..
It would you make you API look a bit messy, but it could make sense if you use logical services in your API:
https://api.domain.tld/service1/v1
https://api.domain.tld/service1/v2
https://api.domain.tld/service2/v1
I'm trying to integrate Firebase with Parse to add real-time capabilities to my application. However, some API functions (like the ability to limit queries to Firebase with limit() or startAt()/endAt()) are not available with the firebase REST API.
They are available with the Node.js module, but even though Parse Cloud support CommonJS-like modules, I'm not sure it's possible to integrate the Firebase node module without some major tweaking.
Any idea how I could access these functions, other than running my own node.js server with the Firebase plugin and using it to redirect my calls to firebase?
It looks like it's possible. What you'll want to do is create a "Cloud Code Module" and wrap the Firebase tools you need. They have a tutorial here
It's pretty standard node.js structures. You put all your Firebase methods into exports, add an initialize method (this is where you'd probably do things like auth?), and you're off.
Wrapping Firebase isn't hard or lengthy. Here's a gist that wraps Firebase in a promise structure, for example. You could basically take the methods from that gist as a blueprint for wrapping them into Parse.
I find it not easy, firebase is dependent on faye-websocket and in its turn requires other libs. We can make it work using "Cloud Code Module" but I don't like adding libs this way.
This is a request for Parse to support node modules, unfortunately the answer is a flat NO from them for now https://parse.com/questions/using-npm-modules-in-cloud-code.
Would appreciate any update on this. Thanks!