Prevent many requests initially with SPA - ajax

I am currently developing a web app using vue. When my app starts it makes several requests to my api to get necessary resources.
await Promise.all([
store.dispatch('setUserOnStartup'),
store.dispatch('getAds'),
store.dispatch('getCompanies'),
store.dispatch('getCities')
]);
I am just wondering if you usually try to prevent this in your apps? If you make an endpoint where you get all the initial resources at once? For ex: /api/initial
Are there any other ways to prevent this or is it fine to do my approach with several requests initially?
Thanks in advance.

JSON API to the rescue.
You can fetch all you need with single request, if all entities you need are related. See http://jsonapi.org/format/#fetching-includes for details.

Related

SendBird Laravel API with React Front End

I have a Laravel back end serving APIs to a React front end for a solution I am developing. I want to integrate SendBird Chat API into the application to allow authenticated users to chat with each other.
My query is, how can I pass authenticated user details to SendGrid? I.e., if user X and user Y both log into the website, how do I allow them to talk to each other?
I am pretty sure I've misunderstood something around sessions but any help is appreciated.
I am not looking for a specific code answer but a general architectural answer.
You send request from your frontend app, Laravel API receives request, builds whole application (all of your code) to process it and returns response. That is one request lifecycle and Auth::user() is going to be the user which sent request.
Request lifecycle explains this in much more detail but I recommend first learning about the basics of Client <-> Server architecture

How to set up authorization using js-SSR and SPA?

I want to develop my own single page web application (SPA) to get to grips with the modern and highly fluid world of web development. At the same time, I would like to use the page rendering technology (SSR) with built in data into html. However, there is an authorization problem.
Suppose that the user has already logged into the account before, as I imagine re-opening the site:
First request: the client makes a request to the frontend server along with identification and authorization data (for example, user id and token; the only option is to save them in cookies), the frontend server makes a request to the api server, transferring these service data, then the api server gives the information about the user and the content of the current page (in the same json), the frontend server renders this into a finished page and delivers it to the client.
Subsequent requests: the client directly addresses the api server, transferring the same (or updated after the first request) authorization data, receives json and processes it independently.
Actually, I want to move on to the question. Do I understand this interaction correctly? Can you do it differently / better? Are there tools that allow, for example, to use the components of the frontend framework as components of the MVC backend framework, so that one server does the rendering without unnecessary requests? Or a unified tool that includes the same coding for the frontend and backend to solve these problems? I will say right away that I would not like to write a backend in JS.
I can roughly imagine how you can get by with one request when using AngularJS (with a module for single page applications) and any backend MVC framework; although there will not be a full-fledged render, but search robots will not have to wait for my first fetch, since the data will be delivered initially, for example, through the data attribute. But in this case, I plan to choose Svelte (Sapper) and Ruby on Rails as the stack, although I think this is not important.
Thank you for your attention to the question!
Are there tools that allow, for example, to use the components of the frontend framework as components of the MVC backend framework, so that one server does the rendering without unnecessary requests?
If that's what you want you can install a frontend framework in Rails using webpacker. After that you will have a folder in your rails project that will contain your Svelte components. Then you import Svelte components in erb templates and pass data as props.
I have tried that approach but personally I prefer a separate frontend and backend talking through API calls. Then in your frontend you need something like Sapper if you need SSR. With webpacker you don't(assuming you mostly use Rails for routing).
If you are worried about authorization it's not really hard to implement. And after login you can store user info on local storage for instance for subsequent requests. But of course if you install with webpacker it's all done within Rails hence it's easier.
From my experience, using webpacker it's easy and quick in the beginning but you are more likely to get headaches in the future. With separate backend and frontend takes a bit more work, especially in the beginning, but it's smoother in the long run.
This helped me set the authentication between rails api and vue frontend.
So, if you wish to separate them, just install Rails as API only and I suggest you to use Jbuilder to build your jsons and serve them to the frontend as you need them.

Phonegap and Django Authentication

I am in the middle of building a PhoneGap (Cordova) app which I would like to be able to talk to a Django site of mine. The steps needed to get the app working are:
Authenticate the user (stay logged-in across app restarts) (e.g. get session cookie from Django for communication with the service - where to store?). Note: The Django endpoint uses https.
When app receives push notification load some data from my django site.
Make selection on data and submit response back to my django site (will need the csrf token?)
I was able to sort out the push notifications but now I am wondering which solution would work best for the communication with Django.
As I understand there are two possible approaches:
Either to implement a REST service with something like tastypie or
try to setup the communication via ajax (e.g. jQuery)
At the moment I am thinking that going simply ajax might be the best approach since the app is fairly small and there are no additional requirement for a REST API.
It would be great if anyone could give me any pointers on how to solve this or share some experiece / code. Especially the steps of the authentication process are unclear to me.
I am not sure if this is still an open question but it is sure an interesting one.
I would strongly suggest on using the django-tastypie and you could start by using the docs which are indeed a great point of reference.
My experience until now has shown that I should always start by making my api clear(and rest) than choosing an easier faster solution(e.g. ajax) because if your app is a successful one, frameworks like tastypie help you scale.
The authentication process is pretty straightforward if you choose the basic one.
You just ask for the user credentials and there are many clients implementing the client side basic auth.
Fortunately, tastypie supports more than this. For example, the api authentication and you could read more here.
If you need anything else, please let me know.
Regards,
Michael.

POSTing entities to WebAPI in batch?

Do I need to send individual entity updates to WebAPI, or can I POST an array of them and send them all at once? It seems like a dumb question, but I can't find anything that says one way or another.
Brad has a blog post that talks about implementing batching support in Web API.
Also, Web API samples project on codeplex has a sample for doing batching in web API hosted on asp.net.
It seems like WEB API 2 has support for this
From the site (Web API Request Batching):
Request batching is a useful way of minimizing the number of messages
that are passed between the client and the server. This reduces
network traffic and provides a smoother, less chatty user interface.
This feature will enable Web API users to batch multiple HTTP requests
and send them as a single HTTP request.
There are a number of samples for different scenarios on this page.
https://aspnetwebstack.codeplex.com/wikipage?title=Web+API+Request+Batching
You will have to create an action that accepts a collection of items.
If all you have is an action that accepts a single item than you need to send separate requests.
With batching always think about how you would report the failures and whether a failing of a single item should invalidate the whole batch.

Should I do API requests server side or client side?

I am trying to make a web app using ExpressJS and Coffeescript that pulls data from Amazon, LastFM, and Bing's web API's.
Users can request data such as the prices for a specific album from a specific band, upcoming concert times and locations for a band, etc... stuff like that.
My question is: should I make these API calls client-side using jQuery and getJSON or should they be server-side? I've done client-side requests; how would I even make an API call from the server side?
I just want to know what the best practice is, and also if someone could point me in the right direction for making server-side API requests, that would be very helpful.
Thanks!
There's are two key considerations for this question:
Do calls incur any data access? Are the results just going to be written to the screen?
How & where do you plan to handle errors? How do you handle throttling?
Item #2 is really important here because web services go down all of the time for a whole host of reasons. Your calls to Bing, Amazon & Last FM will fail probably 1% or 0.1% of the time (based on my experiences here).
To make requests users server-side JS you probably want to take a look at the Request package on NPM.
It's often good to abstract away your storage and dependent services to isolate changes and offer a consolidated and consistent web api for your application. But sometimes, if you have a good hypermedia web api (RESTful responses link to other resources), you could reference a resource link from another service in the response from your service (ex: SO request could reference gravatar image/resource of user). There's no one size fits all - it depends on whether you want to encapsulate the dependency or integrate with it.
It might be beneficial to make the web-api requests from your service exposed via expressjs as your own web-apis.
Making http web-api requests is easy from node. Here's another SO post covering that:
HTTP GET Request in Node.js Express
well, the way you describe it I think you may want to fetch data from amazon, lastfm and so on, process it with node, save it in your database and provide your own api.
you can use node's http.request() to fetch the data and build your own rest api with express.js

Resources