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.
Related
I am looking for some Next.js Architecture advise please 🙏
I am in the middle of migrating a very large express NodeJS app which has a custom SSR setup over to a Next.js setup.
For the current NodeJS site I have:
A bunch of routes (which hook up controllers / apis, do fancy redirections etc)
Have a ton of middlewares
Ton of logic in a bunch of express controllers (these controllers do things like API calls, transforming data, validation and the SSR of some React components to form the application)
Most of the time the NodeJS server calls other Microservice APIs (on the same VPC) to fetch data within these controllers (eg: search api, auth api, location api etc - which are all seperate REST api servers) Note: when it fetches from these APIs its done so on an internal api address only
The React Website itself calls the same NodeJS server to fetch data via client side JS when there is a route change eg: The frontend URL would be: www.mywebsite.com.au
And any api call done from the frontend is done with route: www.mywebsite.com.au/api/*
Based on all the docs i have read so far, I figure the best setup is:
To keep my existing express setup for routes / middlewares (for which I have a ton of) this includes the /api/* ones
Migrate controller fetching logic to the publically accessible express apis /api/* (which I kind of already have but need to clean up)
For the existing express controller routes, route these to Next.js instead and use nextApp.render to specific next pages
Use getInitialProps in the Next.js pages to fetch data from those apis I mentioned in 2.
Also add the old prop transform logic that was in the express controllers to getInitialProps
This is so that the server and client share the same logic of whats in getInitialProps - and this will make the architecture clean and give me the ability to have smooth transition to use Link.
The thing im struggling with it is step 4.
It means now on SSR of a page request it needs to call out to the public api (www.mywebsite.com.au/api/*) on getInitialProps to fetch its data.
To me seems like a performance overhead to do this as it requires a network hop to public domain mywebsite.com.au to fetch data it could have got locally on that same request (by calling localhost:3000/api/* for instance)
Any advise on how to avoid the network hop outside for server render?
Can I detect if its a server render and then use an internal URL (eg: use localhost:3000/api/* on the request to the same web server) or is that not best practices when using Next.js?
The server needs to call out to itself to fetch its data, alot of the overhead involved with fetching data is around the delay (I.E Between the client and nearest datacenter) this will be less of a concern when its (datacenter -> datacenter).
If performance is still an issue, your next best bet will be to do SSR caching, of which there are many different methods alot you can find in a quick google search however it will depend on your hosting/setup.
I treat listing-page.jsx and handler for api/listing route to be the same. You may need to write 2 small functions to extract the parameters passed into the request and pass it down to your service module function like ListingService.getSingleListisng(id)
I'm working in javascript(React) to create a web app that makes use of multiple APIs(Spotify, Twitch, Youtube) and so far I have been using Axios to make
the REST calls successfully. But now I have begun running into Cross-Origin Resource Sharing (CORS) errors and I have been told
that I need to make calls to external APIs from a server instead of from my client. I've never made API calls from a server and
have some questions:
Everything I am doing is currently running locally using Node and I dont have a "server" unless that's what Node counts as. Do I need to get a "server"?
Should I be creating my own API and hosting it on some server so that I can call that API from my javascript code?
How do I create my own API if that's what I should be doing?
Is there a different language I will need to use to make server-side api calls?
Everything I am doing is currently running locally using Node and I dont have a "server" unless that's what Node counts as. Do I need to get a "server"?
React comes with a bunch of development tools that use Node, including a development server. It isn't designed for production use though, so you shouldn't use it for that.
Should I be creating my own API and hosting it on some server so that I can call that API from my javascript code?
Yes.
How do I create my own API if that's what I should be doing?
Write some code which accepts an HTTP request, gets the data you want to respond to it with, and makes an HTTP response.
Express.js is a popular way to do this in Node. You can combine it with Next.js to apply server-side rendering for your React app (resulting in better performance, accessibility, reliability, and SEO).
Is there a different language I will need to use to make server-side api calls?
You can write your server-side code in any language you like.
I assume you are hosting your application on a development nodeJS server, therefor you
will need an extra server.
Yes. Create an API and call it from your frontend.
Create a server which takes http requests and does your stuff according to the route
chosen.There are many examples on how to do this with for example nodeJS+Express on the
internet.
The Language you use for the server side is your choice.
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?
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.
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