In the midst of developing a Graphql API for our application we decided to embrace the microservices architeture and made a desicion that we should have another API for payments (which also would be a Graphql API) just so we could start with decoupling our App. We are using MongoDB for our database with Mongoose. The problem that we are facing at the moment is that in order to work with payments we would need to get user data but our Payment API does not have Mongoose Models through which we could query user data. We are wondering what would be the best approach to solve this. Do we copy the Models that we need to query from the first API? What is it that we are doing wrong here? Is it a wrong approach altogether to have a shared database in microservices architecture?
The whole idea of GraphQL is to have a single endpoint. This reduces the complexity for the "front-end" developers (API consumers).
So you would have a GraphQL endpoint service that manages database access.
Usually "micro-services" have their own databases.
You can still put business logic in microservices, but you would have those services contact your GraphQL service for database access.
But if you are fronting the system with a GraphQL API, then you make a single endpoint.
To have these discrete microservices as you describe, you would usually make them REST or gRPC for the consumer.
Related
Throughout my career, I've relied on and used various API services in my project. I saw multiple mechanisms of how these APIs are secured, but most common one seems to be via API Keys.
I am now planning to build out my own API service and being unfamiliar with security part of this I had few questions:
So far, what I gathered is to do the following: Create API key, store it's hash in db, only show api key to user 1 time, check for api key in requests and rate-limit based on it.
But above raises one concern, if someone was to inspect customer website they could easily get this api key (if customer is calling api directly from their front end) and abuse it, correct? This can be done in form of constantly hitting rate-limits or sending bad data to customers dashboard.
I feel like I am missing few key parts here and would appreciate if someone could outline best practices of how this is done nowadays in NodeJS. Thank you.
EDIT: Users of such service would be developers utalizing this API in their product
I'm working for a project which has multiple microservices. For Ex: AuthenticationService (Only to get authentication token), UserService(Get All Users with token), InventoryService(To get the inventory data with token) etc. GraphQL API Gateway is used to get the token or inventory. Now when i want to get the list of the inventory which is based on user then i'm not sure that whether i should use RabbitMQ or Axios API Call.
I'm sharing 3 diagrams. Please help to get the some clarity.
Image 1:
Image 2:
Image 3:
I personally used image one in our project, because for contacting internally you don't need to pass requests through the gateway.
use the api gateway as an endpoint of your application.
I recommend using #golevelup/nestjs-rabbitmq npm package because it is easy to use.
if it is useful plz vote up :)
I need to query this API: https://docs.art.rmngp.fr/#search I have a react app where I was planning on making HTTP requests to this API but I haven't been able to perform a search. My question is how to go about doing this? Do I need to make a server to query this API? or what the architecture would look like.
How would you query this API https://api.art.rmngp.fr/v1/ with nodejs.
If I'm wrinting BDD style tests. What would be better practise:
When User A creates new record
Then DB contain correct record
or
When User A creates new record
Then User A can get his new record by some API request
And Admin-user can get this new record by another API request
So should I check internal state of DB or just use API and consider application + DB as a black box?
You should test your application as much as possible using the APIs, as it gives the actual behaviour of your application. In your case, it would be
When User A creates new record
Then User A can get his new record by
some API request
And Admin-user can get this new record by another API
request
Reason being:
By using the Admin API, you are making sure the record is in database and the Admin API behaves as expected
In the future, if your DB changes, which is internal to your application, but the API's behaviour doesn't change then your BDD would work without any issues. In other words, if the devs decide to change DB and not the API, the business service which uses the API is not impacted
If you test only DB, but the Admin API changes, your scenario would pass but the Business service, which uses the Admin API, would fail
The only scenario, you would check the record in DB directly without an API is, when there is no API to verify the record. You shouldn't develop an API purely for BDD. The Admin API should be used in a business service and if this is not the case, you can check the DB record directly (your 1st option).
PS: We have developed a product NoCodeBDD. As the name implies, you can automate BDD without any code using NoCodeBDD. I would love to get some feedback from the community. You can download a free version from www.nocodebdd.com/download
Generally the thing that creates should be the thing that validates. So
if a user (human interacting with a UI) creates
then a user interacting with the UI would validate by viewing the created thing.
if an api client creates
then the api client would validate by examine the response from the create call
additionally the api client could get the thing created using a link in the response
In both cases I would only consider validating via the DB as a temporary measure whilst you are working on the scenario
I have created a webservice by implementing the web connector callback methods and I have 2 apps running in webconnector for 2 usecases: invoices and customers.
I want to determine which app is triggering my web service so that I can decide whether to push customers or invoices to QB. How do I do it? I was hoping to do it through 'AppID' field but its not returned in every SendRequestXML call. In fact, not even in the first SendRequestXML call. Has anyone implemented these scenarious?
If you have two apps in the Web Connector, then each app should be using a different username, and pointing to a different URL.
If they're using the same URL or the same username... then you did something wrong and you should fix your implementation.
With that said... it sounds like you have sort of a wonky implementation anyway. Why do you have two apps for two different use-cases? Why not just send BOTH customers and invoices through the same app...?