NestJS : Passport LinkedIn strategy with graphql - node.js

I have nestjs application running on typescript, Graphql, Postgres with Jwt strategy defined, now I need to workout LinkedIn strategy with it. I am not really sure where to start with it, there are a couple of packages available but they are missing the Graphql part and they are mostly pointing to API endpoints on local like /auth/linkedin/callback, I would like to know here and how to start.

If you look at LinkedIn's OAuth documentatioin you'll see that LinkedIn needs to know about a callback url for when authorization attempts are successful. You'll also see that the response for the initial authroization call (what calls your callback URL) is a GET request that doesn't conform to GraphQL format, so you have to implement a REST endpoint for this.
This is pretty true for most OAuth2.0 calls. You need to implement them in REST, not GraphQL. If you really wanted to, you could take the REST call and do some transformation to make it a GQL call, then forward it on to your GQL server, but that's still a REST endpoint you've got in your server.

Related

How does frontend apps hide backend API call URL's?

I'm fairly new to the webdev. I have a React frontend built with Vite, and a Node.js backend that uses MongoDB. I finished my little project and when It came to deploy it to my Linux server, I got confused about how to handle API calls.
Is there any way to hide API URL's on frontend apps? Because everything is done in client side, and frontend is basically an interface between user and backend, that should be impossible. But how does for example, big companies like Facebook handle this? If I go to Facebook and inspect the code, can I find the exact IP and API address that facebook backend serves me the posts? Or are there any tricks to make this more secure? What are the industry standards are on this topic?
The interface between your web application in the browser and your backend service is HTTP(s). There are HTTP verbs such as GET, POST, DELETE, etc. You can pass argument or information to your backend services via query parameters which are visible in the URL, or you can send it in the body of a request. An HTTP POST, for example would have a body that is not seen or viewable unless the end user made specific effort to view it.

Should I run "apolloServer.executeOperation" on Next's "getServerSideProps"?

I'm trying to figure out the best way of running GraphQL queries in the getServerSideProps of a Next.js app.
Since the GraphQL server is running on the same Next.js instance, the obvious solution is to run apolloServer.executeOperation() on the getServerSideProps function of my pages.
However, I'm worried about this solution because:
The documentation of executeOperation describes it as an integration tests function. It literally says "The executeOperation method provides a single hook to run operations through the request pipeline, enabling the most thorough tests possible without starting up an HTTP server.". But it doesn't say it should only be used for testing.
Pretty much all online Guides I find online about running GraphQL on Next.js says I should use an apollo client (Example). However, running an Apollo Client on the same server as my GraphQL server seems like an obvious unnecessary overhead.
Which leads me to think I maybe missing something obvious.
Is it OK to call apolloServer.executeOperation on my Next.js getServerSideProps?
We run a basic async fetch on the getStaticProps, in our Next app, a formatted response gets passed to the Home component and used to setup the redux store.
I imagine that if you were to do a graphql request you would need to init the graphql client before you can use it - which happens later in the call chain for us, and i imagine you. You could maybe do your GQL client setup server side and pass the object by props to Home, but doesn't seem like thats the intended use.
I'd say if you need to server side request with GQL, create a client getServerSideProps and close it after your request, don't see much of an issue with that.

How to process Callback from API POST NodeJS

I am using this API Function
https://developers.cryptoapis.io/technical-documentation/wallet-as-a-service/transactions/create-coins-transaction-from-address-for-whole-amount
And a NodeJS back end with an Angular Front end.
I cannot figure out how the Callback in that functions POST works, It requires a domain setup and then for a JS function to take the post in but I cannot figure out how to do that.
Could someone please advise how to work with an API callback function like that
it looks like you would need a route on your NodeJS server that this service ( cryptoAPI ) could call - so like (needs to be HTTPS) https://yourDomainTheApiIsHostedOn.com/callBack
The documentation does say it will only fire when the create coins function is called. The call back URL also will have some info so you can verify the HTTP traffic is really from them
The callbackSecretKey can only be generated by the customer. It is used to create a unique hash string in the x-signature response header in the callback request sent from Crypto APIs 2.0 when the event occurs.
The domain verification is basically a process for cryptoAPI to ensure that you own that domain which is hosting your API
Documentation is here:
https://developers.cryptoapis.io/technical-documentation/general-information/callbacks#callback-security

Extending existing RESTful API using Node.js

I am currently running a web service on an Apache Tomcat servlet container. The web service has a base URL and exposes my applications data using the following structure:
http://[hostname]:[port]/path/to/root/[db_table_name]/[primary_key]?fields=name,...
An HTTP GET call to a URL like the one above would return a JSON formatted string.
Though the documentation for my application describes this as a RESTful API, I am confused because I was under the impression that true RESTful APIs do not use query strings. Rather, as I understand it, a true restful API provides a uniform structure, in the form of resource endpoints.
My questions relate to how I can create a custom API to leverage the existing API using Node.js. I do not want to rewrite the application logic or database calls; I just need to know how I can create the API calls using Node.js (possibly using Express or some other framework) and let the existing API handle the request.
For example, I could write Node.js code using the Express module that has several routes, these routes would handle client requests that in turn would call the existing API (i.e. /path/to/root/[table_name]/[pk]... and return the response.
If my Apache Tomcat server is listening on port 8080, how would I deploy my Node.js server to listen on another port and then redirect requests to the existing WS URL on port 8080.
Does the Express framework support explicitly specifying a root path (such as http://localhost:3000/path/to/root/[table_name]/[pk]) as the default root path?
Finally, I know REST APIs support CRUD operations. In the case of a POST method, does Express (or Node.js) have built-in logic to handle duplicate POST requests so that duplicate records don't get created in the database.
I'm reading through different article and tutorials on REST but I think I'm missing something. Any information or advice that can take me in the right direction would be much appreciated.
there's a lot to cover here but I'll try to cover your three questions. Since you have mentioned using Express I will answer assuming that Express is the framework you are using.
If you are using Express, you can choose which port to listen to when you start the server, so you can choose any port that you like at that point (see here).
If you need to redirect a request you can do so easily with res.redirect() (see here). However, you could also call the other web service directly, retrieve the data and return it to the client instead of redirecting them if you prefer. That would require some more code to make the http requests in node.js though.
I am not 100% sure if this is the answer to your question, but there are ways to add a "base path" or namespace to all of your routes. I found this example where various namespaces are used but in your case you only need one which applies to all routes.
I don't think there is a built-in way to do this. The best I can think of is potentially creating some kind of ID for the request so that if it is sent twice you could use this to check but it's far from ideal.
I would like to add that I'm not sure where the idea that query parameters not being RESTful comes from? I think query parameters are fine because that is how you query! Otherwise you couldn't ask for the right data from your RESTful API. Let's say you have a /posts endpoint and you want to get the posts of a particular user (user ID = 1). The RESTful way to do this would be to issue a GET request to /posts?user=1.
Hope this helps!

validate requests with swagger and lambda

We are using aws gateway api with lambda functions to create our api.
We then decided that it would be a good idea to have it all documented with swagger, and use it to validate the requests in a similar fashion as it happens with express middleware frameworks.
However i cant find a way to pass a request object and validate it against a swagger spec manually without using one of these frameworks.
Now my question is:
How do validate a request against a swagger spec, by pointing the request at a specific path in spec, what frameworks could i use to achieve it?

Resources