If you write frontend application - I assume that it interacts with backend API server. If your app is small - you do not think about architecture and scaling. But if it is a big LTS application - you need to think about it! Why? Because You will develop and support that application in future, so just pray that you wont hate yourself in time. I want to tell you how people often develop an interaction between UI and API.
To be on the same page, lets define that Interaction - is an object/class/method/function that allows you to send requests to a backend server.
You can try to search some solution! And you may find some guidelines or libraries, also it may be a part of a framework you use, like angular.$resource. In general, there will be 4 types of Interaction architecture.
- “Micro” services
So you will find that there is no silver bullet, which will be the best or the most popular.
I do not want to describe the implementation of every approach because it is your job. :) I want to show how you will use it, pros and cons.
I suppose you remember how popular jQuery was, maybe it is still the best tool for somebody. jQuery provided us a big amount of good things, one of them - is a short notation of the AJAX. No XmlHttpRequest more, just simple
So the first style - is to write an AJAX query immediately when you need it.
I do not want even to discuss why that way is bad. If you will try to write SPA in a such way - you may find that all your requests are scattered by your application. And if you will make a small error - you will find it, only when user will do the action to run that query.
And as always - one day someone would say “We need some time for refactoring”.
Now we have a configuration of all our requests, and you create them dynamically when you need. For example
resource in angular 1.x, someone may say that example is not good, but I want to note that implementation may vary. The idea of the factory - generate objects (requests in our case) dynamically depending on some configuration.
Lets imagine two most popular interfaces with configuration:
var client = request('client');
Singleton - is the most popular pattern in software development. So we have a single class to keep all requests and configurations.
The approach is not so bad, but
api.js will grow in time. So it becomes really hard to change and to add new queries. Gritting one’s teeth you will add new methods to the file, and one day you will decide that you need to split it.
I assume that your architecture will be next:
And usage will be changed to the next one:
It looks nice and understandable, but there is one small problem - separation of contests. So working with project API - you have an access to client API and you can remove it, instead of a project. That is why you need to isolate classes.
No, wait! I do not want to talk about some big changes to split everything. I just want to note that every such file as
./app/api/client.js is a service. And we do not need that singleton to keep the composition of all that services.
It seems that last solution is ideal. But the more services you have - the more imports and dependencies you need. Some can say that you need to separate by logic and make some groups of services. But it is a long way to discuss.
Every solution has pros and cons, and only you can define what is relevant for you.
I told you how to develop an interaction between UI and API. And I hope you defined what approach is the best for you! Write your comment and let me know!
I want to mention that the more you write - the more you repeat yourself and others. Who knows, maybe we will return to simple jQuery style one day. :)