I'm developing an app which has both a serverand a client api. The client api does not necessarily send data to the server, in most cases it is used only to display or filter data on the client.
I was about to build my client api the usual way, by exposing a select group of functions via myapp.filterData(...)or myapp.addColumn(...), etc. etc.
But seeing as I'll be using GraphQL for the server api, I thought it would be nice to have a consistent api for both. I'm not seeing anywhere this has been done. Everything I've seen is client-to-server.
Has anybody used graphql in this way? Or is there a reason not to do what I'm describing? Is this a bad idea?
Related
I'm looking at using an JavaScript API (npm package) in my Net Core project where I will require fetching the API key from my Net Core server in order to use the API within JS. In the past I've always used external APIs through C# on the server side so things like passwords and keys are never exposed to the UI / browser client.
The library I'm looking at is for Elastic Cloud, https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current/client-connecting.html although the choice of API is not wholly relevant to the question as I'm interested more in understanding how secret keys and credentials are generally handled securely within JS (client side code) when using a NET Core project...
My initial idea was to fetch the API key and credentials using AJAX from my Net Core controller, then as soon as I return the secret keys I would run the call to the external API, then as soon as the call is processed then I would delete the keys in JS, but this clearly isn't the right way to go about it because anyone debugging the JS code would surely be able to sniff out the details that I don't want to be exposed.
It's a fairly generic question but not something I've had to think about before, could someone please point me in the right direction of what procedure or methodology needs to be followed here?
I've realised that I could save a lot of development time by calling an external APIU through JS rather than having to create a load of server side code as well, many thanks
Don't. If you do not trust the client to debug and reverse engineer your code, grab the API key and perform any and all operations that the key grants him access to, that key has no business on the client side at all. Hide the API behind a server side layer that you control, even if it's more time consuming, it is the only way to securely restrict access
Is there such thing as an API controller in Nodejs? An API layer that communicates with multiple APIs [that each return the same type of data, but completely different data models] and massaging the data to return to our client-side display? Is there a different term for this?
I have a simple CRUD application.
AngularJS front-end calls my RESTful Nodejs APIs on the back end.
Now, however, there is a 3rd party who has their own APIs and data that I would like my front-end to be able to use if the user wishes.
The data from the 3rd party API's is similar data to ours, but will not follow the same data model. I am trying to wrap my head around how I should begin to write an API the front-end will call that could go to either our API or the 3rd party [and possibly future 3rd parties] and massage the data so either way it is the same to the display.
Any resources or better ways to handle this scenario?
Yes, there are a number of ways this could be accomplished with nodeJS. How you set it up will be dependent on the details of your project, but here are a few ways to get that functionality:
Setup an endpoint that queries other endpoints. For example, all api requests hit /api/1.0/:routing_params, and based off of that routing_param send out requests to various other apis. This data is returned to your backend which then sends the response to the browser.
Use something like expressJS to mount multiple routers, with each router handling the various endpoints for each api. Documentation for express routing can be found here. ExpressRouting
Depending on your scaling/performance requirements you can also consider using something like nginx to handle incoming requests and direct them to separate nodejs processes handling the various api logic. This may be overkill, but is an easy way to keep things modular if you expect the need to run multiple nodejs processes and handle multiple future api endpoints.
That should provide some starting points, what you choose to do and how you implement it will be highly dependent on the specifications of your application.
I'm creating single page web app with ArangoDB for storage. Arango provides awesome ways for accessing and manipulating data. One of them is classic JS API. It would be easy to write straightforward DB queries in client side JS which would be direct queries for DB. So no server application in middle.
Of course, this is really unsecure pattern. So I should write some sort of REST-full API service that queries data from server via URL and later server queries the DB. But this is really inconvenient, since I'd need to write two or three times more code (first query for my server, second query for DB, and perhaps some translator between the two queries). Also, I think that API calls for my server would look almost same as API calls for DB.
I don't want to go for full abstraction since the app should be complex and there would be a lot of types of API request, which would only bring bugs and eat more time.
So what is the best way for requesting data in client app from DB in terms of, firstly, security and, secondly, ease of coding?
I'd really suggest to write REST API calls (or generally URL calls) to access your data. Anything what run on the client side or any traffic from the client can be accessed and manipulated. That comes with authentication and SQL calls themselves.
What you want to secure? DB client authentication? If you encrypt it, you need to decrypt it on the client side. SQL calls - if you build and transmit them, the client could manipulate them to get / update ANY data with ANY values. Really no easy way around..
So - to be safe - stick to the patterns here..
I found a GraphQL with Relay by Facebook which solves this problem best.
I would to ask a few questions to better understand some procedures. I'm trying to write a web api project which will be a backend for both web and mobile clients.
The problem that i've in mind is about security. I don't want to use Identity or any other providers. I want to use my own database user and role structures.
Only authenticated client applications should be consuming my application. So that anonymous applications should not consume it.
So what should be the approach ? I 've written a custom AuthorizationAttribute and check some custom headers like "AppID","AppSecurity" key which i store in my own database and if the client sends the right appId and the key it means the app is authenticated to consume the API which does not sound very secure to me.
Another issue is that ; Lets say i've developed a javascript web application and i've to first authenticate the application itself before making GET/POST/PUT/DELETE etc requests which means i've to add some kind of authentication data like username, appkey, password in one of the js files for sending the "AppID" and the "AppSecurity" keys in the header. A client who knows how to use some developer tools or fiddler can easily capture my header values that are being sent to the server side? Even if i pass authentication values on the body of my json request it still can be found on the js files that are sent to the client. I'm also confused about that tooç
So basically i want to build a server side api that will serve the data and get data from the authenticated client applications only. What i need is a simple example for that without using any identity providers.
When I am creating a simple website with node.js I am fine with using the view engine (eg. jade) and controllers that provide data to it (eg. simple todo list). However, if I decide to add AngularJS as the client framework then it seems that I must implement REST API on the backend to get data from it. Almost all examples I see online with AngularJS have this basic architecture: client (angular) communicates with the server via REST API.
Can AngularJS be used without REST API and if so should I do it or should avoid it? Are there any recommendation/best practices for using AngularJS without REST API backend?
Absolutely. Angular can still do a lot on your site even if you never utilize the $http service to talk to your server. You can still take advantage of the utilities for helping out with managing your DOM.
That said, most modern apps need to get data from the server. There are tons of reasons why you might need to do this. For example, if you had users that needed to sign up then you'd need to store their username and password somewhere. That somewhere would be in a database that only your server can access. Then your server would provide some URLs that you can talk to via Angular's $http service.
If you do have an app that makes calls to the server but you want to turn off the network communication for testing, you can mock the $http call responses. Angular provides an $httpBackend for that exact purpose. You can use it to set up dummy URLs that pretend to respond to your $http calls so that your $http calls don't know they aren't actually talking to a server.
authRequestHandler = $httpBackend.when('GET', '/auth.py')
.respond({userId: 'userX'}, {'A-Token': 'xxx'});
Perfect for testing your code without a REST backend during testing.
REST which is short for Representational state transfer is basically things or resources instead of actions. Yes AngularJS can be used without REST API.
You can use nodeJS for your restful API and AngularJS as your javascript framework.
Even without a restful API AnguarlJS is a very strong tool to use in a project although to use it to it's full potential (fully scaled web app) then you would need a restful API.
use $http for not RESTful API
use $resource for RESTful API